Of course, this is not a good reason to not use IPv6, don't get me wrong. It's a problem that's easy to overcome, I just think it's not a good way to get people excited about the transition.
Globally routable ≠ globally connectible.
Your (stateful) firewall will still by default block any incoming connection attempts if they are not replies to an initial outgoing connection. It's just that it will no longer be necessary to go through the rigamarole of STUN, TURN, ICE, etc, that goes along with non-global addresses:
* https://en.wikipedia.org/wiki/Traversal_Using_Relays_around_...
Your end-user device knows its address and the address of the other connection point, and can tell the firewall to open a rule between only those two IPs:
* https://en.wikipedia.org/wiki/Port_Control_Protocol
* http://www.upnp.org/resources/documents/AnnexA-IPv6_000.pdf
Further, because you don't have only one external IP, you don't have to futz around with non-default ports if you want multiple instances of the same service (e.g., Minecraft), because each instance can have its own IP.
Further, if you want certain devices to not able to get outside: (a) give them static assignments and block them at the firewall, (b) don't give them a default route so they are subnet-local, or (c) give them site-local addresses via ULA and do not set up NTPv6 translation.
It's been available for some time: https://www.internetsociety.org/resources/deploy360/2014/pri...
On my macOS system, I currently have four IPv6 IPs (excluding the link-local IP), all of which are random.
For decades we have generally allowed all outbound and worried and fretted about and filtered inbound. I think it is time for us all to get a grip and do the job properly. However, with the delights of DNS over http and the like, the horse has not only bolted but has a new paint job, far better shoes than you can afford, eats grass that was prepared by a Michelin starred chef and belongs to someone else now.
We all need to be far more sophisticated about how traffic (knowledge/ideas/data) flows in and out of our networks/lives. Packet filtering is just one tool in the box and worrying about an addressing scheme being global (IPv6) instead of a weird hybrid (IPv4) is completely missing the real issue stabbing you in the nadgers.
They’re obviously doing recommendations based on IP address. (And this is purely over ipv4).
I have IPv6 at home and connect to Youtube over IPv6 (that's generally the default behaviour on macOS and many other OSes). I reboot my DSL modem-router every night and get a new IPv4 address and new IPv6 prefix every day.
Now: I live in Ontario, and my ISP is based in Ontario, but they serve clients in Quebec. Every so often, when surfing Youtube, I get served ads in French because according to my (IPv6) address I am "in" Quebec.
And, while I am not logged into any Google service, I do not block cookies. So even with cookies, Youtube seems to be fairly dumb about serving ads correctly just based on IP addresses (or at least IPv6 addresses and/or IPv6 prefixes), since cookies don't seem to be useful.
So I'm not quite sure about what people are talking about when they say "IPv6 tracking" if even Google/Youtube can't get their act together.
Iechyd Da!
eBay uses IPs showing content, too. I see 'items you've viewed recently' show items I've never looked at, since when on a mobile connection my IP changes fairly frequently and eBay carries over the recently viewed state from whoever else was previously using that IP.
It had puzzled me until I came across this[1] eBay topic where others had experienced this, from shared offices to spouses, etc.
[1] https://community.ebay.com/t5/Share-eBay-Technical-Issues/Re...
the only thing you'd "leak" is the prefix, which is no different than a IPv4 WAN address that you'd get with a v4 NAT.
Assuming you block unsolicited packets (that is, packets not related to existing connections/streams) at your border (the connection to your ISP), then outsiders won't be able to use tools like traceroute to learn anything. All that an outsider has is an IPv6 IP, and since you're not doing BGP with anything, all they'll know to do is to send the traffic to your ISP.
I'm curious to know: what (attack) do you hope to protect against?
I would think that most attacks come in two fashions: the first being that you run a service of some kind and that there's some JSP/PHP/whatever exploit for a public facing service, and someone does a 'magic' PUT/GET that has the application server execute some code, which downloads a larger malware attack package. After which point the black hats start scanning from the inside.
The second being that someone clicks on a link in a phishing e-mail or executes some attachment, after which malware code starts scanning from the inside and phones home.
(A third being an insider attack, who presumably know about internal topology.)
What attack are you thinking to protect against by hiding subnet and VLAN topology?
And what are those vector(s)?
Besides compromising a machine that is already inside per the above (which can then do scanning / lateral moves), or perhaps physically getting inside the premises (in which case a scanner can be physically installed to examine the network), what attack are you protecting against?
Can you give me a link about an attack that knowing the topology of the network ahead of time would allow, but that not knowing would prevent?
Seems intellectually dishonest not to acknowledge that making things easier, just y'know, makes things easier. Keeping attackers, who want to do you harm, in the dark as much as possible seems important to me.
An attacker looking to be stealthy is not going to blast the network with nmap...
ARP is broadcast, NDP is solicited node multicast so simply by passively listening on the network you will discover nodes in the same layer 2 segment, with v6 and properly configured switches your passive discovery will be a lot more limited.
Other passive techniques would be monitoring things like DNS, and things the host you've compromised is actively communicating with. This isn't any different regardless of the protocol used.
You can also actively communicate with services like DNS or Active Directory and query information about the network, depending on your level of risk.
Just knowing the in-use IPv6 block is useless, the blocks are massive so even just identifying active hosts in a single known IPv6 block is a lot harder than simply scanning the entire RFC1918 legacy address space.
For active discovery, IPv6 is harder to attack - you can't scan the entire address block looking for hosts. The fact that such scans should be detected is exactly the same for either protocol. You also have to consider response time and what an attacker may be able to achieve before your response kicks in.
IPv6 makes it harder for attackers, not easier.
Tell us with the next 0 day, because that big problem exist, and unfortunately happens every days.
IPv6 == All your devices are globally ROUTABLE and CONNECTIBLE from Internet, your home network is part of internet. It is an additional rule in the router's firewall what temporarily avoids it. Remark in temporarily, as one day the gifted packet will arrive to the router. This is not cool.
So much so -the home network is part of internet- that if you want to create a simple Video NAS or whatever, one have to use external DNS services, as no one have control over its own local IPs... what are served by the ISP. This is not cool.
Even if it was not designed for it, NAT has been helping to secure and giving flexibility to our local networks along decades, but someones decided to reject it from the specification. Bad decision.
Regarding firewalls bring prone to accepting by default, either way the packet has to go through the CPU to be routed. I don't believe there's any inherent bias in the design. You could argue that routers that use a single switch and vlan isolate the wan port are inherently biased, though.
Regarding local hostname resolution, there are several options that don't require your ISP. There's mDNS, DHCPv6 and DNS on your router, ULA prefixes, or you can continue using IPv4 for local traffic.
Firstly one ceases to have control of its own home network, what now have to rely on the ISP for to receive the "local" IPs, what are part of internet. And in addition each machine leaves a trace of its "local" ip on the Internet. This if one want internet access in the device, due the absence of NAT in the router's protocol.
Secondly one have to rely on a buggy piece of code called firewall for to make "local" those IPs, due the absence of NAT in the router's protocol.
https://nvd.nist.gov/vuln/search/results?form_type=Basic&res...
https://www.cvedetails.com/google-search-results.php?q=firew...
We are talking about millions of routers provided by the ISPs in each country, barely maintained and updated, what little by little will become exposed. And this without taking in account the unpublished firewall bugs that each artist keeps for themselves and takes 3 to 5 years become detected and fixed by the mainstream. I do not know how to express the negligence is going on, but I can see that Crackers, Advertisers (privacy) and "others" are in good time because things are getting more easier for them than it should be.
Why people keep down-voting the message is a mystery for me. If it is due the local hostname resolution, mDNS, ULA prefixes, etc, all are workarounds due it is a network one does not control, what is one of the main points I exposed (it also needs filters/rules what needs be manually added in the firewall, each user has to make efforts to try to protect the supposed "from internet" separation).
One could create another network as you said, but the main problem keep existing without NAT.
IPv6 has link-local addresses that aren't routable, so you can't really get more local than that. Unlike a typical IPv4 setup, typical IPv6 hosts have multiple addresses, and you can make your own for local traffic and only rely on ISP prefixes for internet access if you want to.
Sure, the internal host's internet routable IP address is visible rather than being masked behind the router's IP address. Pretty much all operating systems periodically randomize the bottom 64 bits, making it effectively as opaque as NAT. You could call that a hack, but people call NAT a hack. There's tradeoffs.
The CVE links you provided are just lists of vulnerabilities with "firewall" in the name. Skimming through them, I don't see how they're specific to IPv6? Most of the vulnerability descriptions I read seem equally problematic for NAT setups. The one IPv6 specific one I saw had to do with a bad firewall rule allowing access to LAN facing services running on the router; it could have just as easily been a bad IPv4 rule.
I agree, consumer network gear all sucks. IPv6 is bolted on as an afterthought, and is probably buggy in a lot of them. More features means more opportunity for bugs, but that's true of anything. IPv6 isn't being deployed for no reason; there's limited IPv4 addresses to go around. I still don't follow why IPv6 is fundamentally riskier than IPv4 when traversing a router. Sure, with NAT an incoming packet needs to have a port number that's been dynamically mapped back to an internal host and port, or have a static port forward. In IPv6, an incoming packet needs to have a destination address and port that's been dynamically mapped back to an internal host and port, or have a static firewall rule. It's basically the same, but also less complicated for the router because there's no translation involved. In time, less complexity is good for software hardness.
I also get anxiety from trying to wrap my head around IPv6 address assignment. It is nuts. It's very comforting to work in the effectively 8-bit address space of a /24 IPv4. I suppose it's true that you can't control internet routable IPv6 addresses in that they are dynamic and ephemeral in their nature. Coming from IPv4, it feels messy. I've experimented in detail with configuring my own ULA, DHCPv6 configuration, and SLAAC. I've tried to embrace the benefits of IPv6, and having used a few of the features I can appreciate them for what they are.
I put the CVE links with the generic word "firewall" because it is the point where the "local" vs "internet" resides with blind faith within IPv6 (without indicating an specific exploit, just vulnerabilities exist). For this case, the DDOS and buffer overflows that force the firewall to shut down, or code execution, what are periodically discovered, is what I wanted to show for being considered as a serious problem. Not everyone reports firewall bugs, and others I guess even wickedly insert them.
With NAT setups, the local and internet networks are different between them, what requires the packets to be filtered and rewritten by NAT for the address what solicited it, while unsolicited packages are discarded. The NAT in consumer gear is run mainly by software, but a poisoned packet will not aim to shut it down for network penetration because it would be the end. If the NAT stops working, the doors close for everyone.
It is about the double checking,
-IPv6 without NAT: If the firewall stop working, opened doors. Feast.
-IPv6 with NAT: If the firewall stop working, many rules get unfiltered, wild. But NAT keeps the local/internet separation besides filtering unsolicited packages. Not absolutely secure, nevertheless keeps being a complex target.
Like all of we, I suffered some problems that NAT can bring losing countless hours trying to make work some specific services, but when I first read IPv6 didn't implemented NAT nor something similar in the protocol (for whom whish to use it at least...) and what the supposed local IPs are merely part of internet (link-local addresses that aren't routable as first target, devices with internet connection are), each device with its own public address, I doubted seriously about what was going on.
Given that even Mikrotik RouterOs periodically have security vulnerabilities related with the firewall, I can't conceive the idea of people relying on firewalls rules to do the home/internet separation within IPv6 (plus the public address of each device gives me also anxiety), as it is a matter of time before such separation ceases to exist; it is like the crossing of fingers.
I mean, it is not a matter of misfit, it is more like the users will not even notice the router's firewall was shut down.
RFC1918 address space IS routable, it just doesn't have a global route. There is nothing to stop devices adjacent to your wan interface (ie other customers) from manually adding a route to your RFC1918 address space via your firewall. Will that traffic be allowed? that depends on the device and its configuration, have you ever tested this scenario? probably not.
NAT is a hack to get around a shortage of address space, nothing more. Once the shortage is gone there's no more need for NAT. That's why although NAT with IPv6 is possible, it's very rarely used because you no longer have any valid reason to use it. If you are think there are any other reasons to use NAT then you need to brush up on your network knowledge because a lot of smarter people than you or I are saying to avoid NAT and designing systems (eg IPv6) to fix the problems it causes.
US government advice is to avoid the use of NAT because of the extra complexity it introduces, which actually reduces security:
https://media.defense.gov/2023/Jan/18/2003145994/-1/-1/0/CSI...
I really don't understand the fearmongering. Your home router likely runs some flavor of Linux which uses Netfilter/iptables to perform both NAT and filtering. Do you believe that the filtering/firewall modules are inherently flawed, yet the NAT modules are infallible?
I see them as two sides of the same coin. If we're theorizing about a magic packet that not only removes your firewall rules, but also flips the default policy to ACCEPT, the very same packet could also sneak in a few NAT rules into your IPv4-only router.
This is an interesting point though personally I love how easy container technologies made exposing arbitrary ports, without trying to configure the software itself, or checking whether it even supports customizing the port.
For example, I could have 3 database instances, each using 3306, but expose them on 30000, 30001 and 30002 or whatever I want.
The Gods intended for each database service to have its own IP address and I curse the market forces that have trapped so many of us in the quagmire of NAPT!
Yes, and that's a very reasonable configuration.
But UDP hole punching (very widely used for VoIP, online gaming etc.) works orders of magnitude better with IPv6 than with IPv4, since there is no address and port translation to worry about.
With IPv4, it's very hit or miss, since it depends on both sides' NATs and also requires additional infrastructure (i.e. STUN discovery servers).
It's also probably impossible if you're with an ISP that does CG NAT.
What is the risk you're picturing here? I'm really curious. Features like RFC4941/8981 mean nobody can infer anything about your network from the source addresses they see making requests out if it.
If you want to use link-local V6 addresses and NAT to a global one, you can do that. But IMHO that's sacrificing one of the greatest advantages of IPv6 for no tangible benefit.
> It's a complete non-issue that nobody really cares about.
A significant number of people spend a significant amount of time trying to carve out and re-use address space in their existing IPv4 allocations and RFC1918 space. This becomes nightmarish the moment you start thinking about networks of any significant size and complexity. All of these problems go away with IPv6, and we care about that a lot.
Huh. IMHO it's the single most desirable feature, and the only reason I care about it at all.
If you're approaching this from the home networking point of view, than I suppose I agree: even the most complex home network is just too simple for anything like this to matter much.
As the network gets bigger, that sweet sweet global routability starts to make a lot of things a lot simpler... I'm lucky to have worked on an enormous deployment of V6-only servers, and it's downright magical in comparison to anything of comparable scale I've seen before or since.
But yes, my home network is three NAT'd /24's because I'm too lazy to figure out how to make prefix delegation work...
SLAAC scales really, really well, and is fairly stateless compared to DHCPv4 or V6.
Also, slaac allows one to easily change the global prefix of a vm/host if it lives on another layer 3 network.
A good example of this:
you have two seperate datacenter networks based on an EVPN-VXLAN solution, and you do no want to stretch layer 2 across both datacenters because stretching layer 2 is a terrible, terrible idea[0].
Before IPv6, moving VM;s across datacenters which have different public ip space was a major pain for two reasons:
- IPV4 has no concept of using multiple addresses per interface without it having unexpected bahaviour on a host. - address management at scale is a major PITA because DHCP is not scalable.
How to solve this with IPv6? It's fairly easy:
- Use slaac + prefix delegation of your globally unique address space (which is different per Datacenter). - Use a different (site local) address to reach the VM for management purposes. Because this address is not globally routable, you are sure it will never leak into the greater internet and be reachable from the outside world. - If you are using anycast, you can easily announce this prefix to upstream BGP neighbours because you can use BGP Neighbour Autodiscovery[1].
Trying to do this with Ipv4 will result in a mess of administration, not to mention have to do some clever technical hacks to make it work on some operating systems.
With IPv6 solving these issues becomes quite manageable.
[0] https://blog.ipspace.net/2021/06/stretched-vlan-define-probl... [1] https://www.juniper.net/documentation/us/en/software/junos/b...
Fair enough. For me, this is a thing I literally could not care less about.
The availability of IPv4 addresses is something that more people will care about, and getting IPv6 going may help folks. From another comment in this sub-thread:
> I've actually run into this [CG NAT] helping a friend host a game server on their residential internet in a more rural part of Texas. They had to call their ISP and request a static IP address at an extra cost of something like $5/mo.
They can infer that one IPV6 address matches to exactly one device. (reverse is not true, one device may have multiple addresses per privacy extensions)
Once device is identified all its past traffic is discernible.
Changing addresses means identification needs to be done again but once done it can be associated with past addresses and again, all its history is visible.
Identification might just mean querying a data broker with HTTP headers.
NAT does not have this issue.
No they can't: the whole point of RFC4941/8981 is to prevent that. The source address for external connections is effectively randomized.
All that can be inferred is that it came from your network, but even with NAT you know that anyway.
It's still unique to one device right?, even if random my argument still holds.
Or do you mean to say multiple devices can use the same address?
note: I've read the RFCs and they just mean - initial address is random but unique to a device. Each day the address will likely change but new address is still unique to the device (otherwise how would routing work).
This is what I structured my inital argument on. Do you see any fallacy in logic?
Once identity is known for address X you know its traffic for the day, including past traffic for the day.
once address changes you do the whole identification again.
All these logs where address is identified goes to bucket X.
On addresses where you couldnt identify that day you put them in unknown bucket.
Once you have a profile of the network, you can do exclusion (Only 4 people in household, 3 active with known addresses, not X, one unknown address, you can assume its X)
The “I don’t care if they track my household but it’s critical that Daddy’s activity not get disambiguated from my dealing daughter” is just not a valid reason to abandon the benefits of IPv6.
Please stop with this line of argument.
If you’re really desperate to ensure that the ads shown to your daughter are based on your porn viewing habits, then just set up IPv6 NAT.
That's a broad assumption, and I can assure you they will due to lower costs (no need to pay data broker if you already know target, no need for extra traffic, load, etc). Also due to better targetting you get better prices per ads served.
> just not a valid reason to abandon the benefits of IPv6
What are the benefits to allow each device its own address if I'm going to firewall them anyway?
> Please stop with this line of argument.
Why?, my concern is valid, all you've said so far is nobody cares. I disagree.
> If you’re really desperate to ensure that the ads shown to your daughter are based on your porn viewing habits, then just set up IPv6 NAT
That says a lot about yourself if you resort to this sort of snarky comments, I have no wish to continue this conversation.
Note: I said in another comment I have set up IPv6 NAT and it works great.
If I told my security information officer "We don't protect against foreseeable threat X because we assume no one will bother to try X" she would not be very happy with me.
When a valid data concern has been expressed and described, putting your head in the sand is the incorrect response. I want IPv4 to die as much as the next person but at a minimum organizations such as hospitals and government installations will not accept that sort of outside visibility into their network.
I don’t quite feel convinced yet by this argument.
For example, one essential difference is that while it’s true that my web browser does have those leaks, I can be reasonably sure that it’s only leaking to specific hosts, i.e. the one I’m visiting and its embedded resources.
Tracking on the IP source address level, however, would be a whole other thing: that means that whoever happens to see the byte stream can now track who is visiting what. That includes, for example, my ISP, all large Internet exchanges, and anyone tapping into those.
If you set up your device to spin up a new IPv6 address every hour (or even every minute), how will they track you using IPs?
On macOS it's 24h, but it doesn't have to be:
$ sysctl -a | grep temppltime
net.inet6.ip6.temppltime: 86400Minutes or less I guess would defeat tracking, but then what's the point?, it's almost equivalent to NAT it still breaks reverse connectivity? and does it actually work?
It also feels like a workaround for an oversight.
But how would they know it is to the same node?
I have my DSL router-modem reboot every night, and I get all sorts of crazy results for ads: I'm in southern Ontario, as is my ISP, but they service folks in Quebec, and so sometimes I get Youtube ads in French since (per my IP) I'm "in" Quebec.
Similarly with the reboot I get a new /64 prefix delegation (actually /56), so I would hazard to guess if IPv6 starts getting tracked, I'd get the same crazy results.
No one cares about tracking by port. Folks are tracking by IP(v4) address.
I know this first hand because I have my DSL router-modem auto-reboot every night (built-in Asus functionality), and I get all sorts of crazy results for ads: I'm in southern Ontario, as is my ISP, but they service folks in Quebec, and so sometimes I get Youtube ads in French since (per my IP) I'm "in" Quebec.
And given that I have IPv6, most OSes generally use that as a first preference for connectivity, and so my IPv6 address/prefix is "in" Quebec.
And this is even with cookies enabled, which should make tracking by browsing easier (esp. since I get decently-accurate recommendations based on viewing history), but yet I still get French ads because my IPv4/IPv6 address is "in" Quebec.
So I have no idea what people are talking about when they say IPv6 will make tracking easier than IPv4. With RFC 4941 it's a solved problem IMHO and no worse under dual-stack than it is under single-stack.
With IPv6 chances are your ISP has a single large address block, and then they split out parts of that address space to users in ontario and quebec. Unless the ISP publishes details of where they've allocated those blocks, any external site is just guessing.
With legacy IP chances are they have multiple small fragmented blocks, some of which are routed to ontario and some of which are routed to quebec so they're a bit easier to keep track of unless the ISP decides to move them.
Also when you address changes, the legacy address space is probably quite close to full so your previous address is released and probably taken by another customer fairly quickly. The IPv6 space will be much larger, and so recycling occurs far more slowly.
Either way youtube is just guessing, it only knows that the address space belongs to a canadian isp and it has to use the behaviour of whoever used those addresses last. If the previous user set their browser language to french and searched for french sites, youtube will remember that and is more likely to serve you french ads.
Yes there is. I sure as fuck don't want random people from the Internet to know how many devices and what kind populate my home LAN.
Security through obsecurity is not security.
Yes, let's just flash a giant "welcome, nobody is home right now" sign to burglars whenever you leave the house unlocked.
You're going to have a minimum of a /64, noone is going to scan that looking for devices.
Even if they do, your firewall is not going to allow the traffic unless you've explicitly configured it to do so.
The only way someone will discover devices, is by analysing outbound traffic you make. Outbound IPv6 traffic will come from randomised addresses so the addressing information is useless. Other things disclosed by the devices (eg user-agent headers on web browsers and other fingerprintable data) are protocol agnostic.
If we had networking protocols that took into account the complexities of private addresses it could probably work - but we don't have such a luxury. The entire TCP/IP stack assumes peer to peer connections, and NAT is literally a spanner in the works for all that.
Then... don't route anything on your network.
NAT is address translation, not routing.
NAT makes it difficult for you to host services on your network, forcing dependency on cloud services, and when ISPs do it (CGNAT), it makes it just about impossible unless you want to thread your traffic back through a third-party service. If you want a good chance of keeping some semblance of an Internet around that isn't dominated by huge centralized services, the cargo cult of "NAT is security" needs to die hard.
Imagine if I'm a medium-sized ISP, or a medium-sized software company, or a medium-sized website.
There's a bunch of hassle involved in deploying IPv6. Who knows what it'll do to my users' privacy? Or whether everyone's firewall rules will keep working right? Or whether it'll have some random impact on e-mail deliverability? Or something else?
The main benefit of IPv6 is providing routable addresses for home users, thus avoiding CGNAT.
But zealous firewalling and the rise of mobile devices mean these days almost everything is sent over HTTPS to a cloud server. I haven't had software ask me to open a port on my router in a decade or more. Even games and video conferencing software know they have to work out-of-the-box on networks where the user can't adjust the NAT.
So who's going to benefit from all this hassle - the 0.1% of users who are hosting websites from home?
IPv6 will fix that.
The reason IPv6 on a home network is still difficult is because the routers everyone buys at Best Buy still blow at supporting IPv6. Ubiquiti blows at supporting IPv6. It is laziness and/or incompetence of device manufacturers, primarily, holding us back. (and incompetence around IPv6 in general - I talked to a network guy at a large company recently and they were deploying /58s. WHY?!)
The benefits of IPv6 may not be just for you - it's for the planet, it's for the developing nations, it's for the future where IPv4 does not cut it. It's bigger than your home network.
> IPv6 does not do anything to save the planet.
The world doesn't have enough IPV4 addresses. It literally solves the problem. It is crazy to me so many people here are arguing for multileveled NAT instead of the obvious solution we have had for 20 years.
If 8 billion people wanted to host their own email and web, yes, we'd not have enough addresses for each person to have one. That isn't the case though. It will never be the case. If we look into the future and say well in 2023 5% of the world's population ran their own email and web for personal or business purposes and that number were to grow by 5% every year then in 20 years we would run out. That's a worse case, contrived scenario but even in that case, we'd still have 20 years to come up with something better than IPv6 that truly respects privacy and doesn't track each person.
Try starting a new ISP. You’ll either do CGNAT on a single /24 of v4 space, or you’ll have to spend tens of millions for some pointless, legacy IP addresses.
CGNAT is not the Internet working well. CGNAT makes you have to have your ISPs permission and coordination to originate outgoing traffic--imagine if you had to ask the power company for permission to operate each electrical device in your house.
Look at what they did with broadcast digital TV : it was announced that it would be illegal in a couple of years to sell hardware not compatible with the new standard, then a couple of years later on illegal to sell hardware compatible with the old standard...
The US has mandated IPv6 support for federal contracts since 2009, although they don't get involved outside of those directly providing services to the government itself. They now have plans to go IPv6-only, and eliminate the use of legacy IP within the federal government.
Allocation of legacy address space was always based on first come first served, so developed countries got the lions share of address space and left developing countries with scraps. This creates a severe inequality, and holds developing countries back. This is also why India and China are leading, as they have a huge disparity between their population and the number of legacy addresses available.
(Though the sooner we ban IPv4, the sooner they will stop using it too...)
Early hardware implementations could have settled on 32-bit, but 48-bit would make more sense to be in line with EUI-48/MAC-48 (ethernet frame). The world could then gradually upgrade hardware over the decade to handle a larger address.
It's because you could get through the firewall without a four month review with the firewall team.
Well, and you could reuse web tools and software. Ok, that's probably it, but the firewall convenience is DEFINITELY a thing.
It costs that third party real money to run that server...
What happens when they decide to shut if off because they no longer want to bear the costs? Your applications are a ticking timebomb...
What about privacy? What if the operator of that server decides to fund it through selling your data?
Sending your traffic through a third party server adds latency, sometimes a LOT of latency if that server is far away. This is very bad for certain latency sensitive things (gaming, calls etc).
If you're dependent on a third party server then you're screwed if it goes down, even if your own connection is fine.
Doing away with that and going back to peer to peer is MUCH better in most cases.
IPv6 has private addressing and a form of NAT as well, were it to be the will of router mfg'ers and network admins. No need to stay on a legacy protocol.
Also STUN makes your private addresses reachable without you making any mistake at all.
Your comment is a good example of the NAT cargo cult mentality that is damaging to the Internet.
The reality is that NAT has greatly improved the security of the internet, because before NAT people were exposing everything, including services like Windows file sharing, to the internet. NAT enabled those people to use multiple devices in their home and in return prevented them from unwittingly hosting things to the internet, which causes them to be hacked and turned into bots that harass the rest of the internet. Yes that still happens but not at the scale it happened before everyone was behind a NAT perimeter. If you want to see what could happen look up the SQL Slammer worm and imagine what could have happened if such a worm would have targeted a service more common than SQL Server.
It’s really nice to be able to host things on a consumer connection but it requires thought and management that most consumers just can’t and won’t care to provide and the damage they can cause is not only to themselves but to the rest of the internet as well. This capability really is better off by default.
And all those handwavy ‘workarounds’ for the ‘cargo cult mentality’, you typically can’t tell everyone on your network how to manage their computer to ‘just have their services listen on the local address’ and you can’t ‘just change the defaults of all routers’. But NAT makes it impossible for the default to be wrong and that is its great advantage.
Sure NAT has a lot of disadvantages and breaks the original idea of the internet with every host equally able to host services. But just as Postel’s law just doesn’t work out, every host being able to host services doesn’t work out. Because the internet is not a playground full of friendly colleagues and hasn’t been for a long time. It’s a war zone that requires strong, watertight defenses by default. And if you’re smart and careful enough to safely host a service to the internet, surely you can manage to forward a port.
NAT created a false sense of security, while also breaking a lot of other things. It is quite easy for the defaults to be wrong, you can end up with all kinds of unexpected scenarios which make internal hosts reachable - eg outbound traffic could open up inbound traffic on the same port from any source not just the one initially communicated with, UPNP can result in ports being opened, NAT slipstream attacks are another possibility, not to mention the fact that "not routable" and "there is no route" are two different things - someone who is on an adjacent network to your wan interface (ie other customers of the same isp) can easily direct traffic to your internal address space.
What reduced external attacks was not NAT, it was improved defaults - such as windows including a software firewall which blocks inbound connections by default, and unix based systems no longer shipping with large number of services (telnet, rpc, finger etc) enabled by default.
Consumer routers with IPv6 support don't allow unsolicited inbound traffic by default. Good luck scanning an IPv6 block in any case.
Slammer and other worms scanned sequential legacy IP addresses, including the well known and predictable RFC1918 space. This method simply couldn't work with IPv6 because the address space is too large, you would be flooding out huge amounts of traffic for years on end before you happened to hit upon an active device.
IPv6 is better, not worse.
NAT is bad because somehow magically a machine with an unroutable address can become routable. Because magically UPnP forwards every protocol in existence, not only a select group of programs that explicitly support it. And of course a connection opening up a theoretical hole to a specified host is just as bad (actually worse!) as opening it up to the whole internet.
Yet all routers have the right defaults and nobody ever makes a mistake. Oh and there’s so many addresses it’s so obscure it’s secure, and noone would guess to scan one’s own subnet in the absence of NAT.
These arguments are really grasping for straws, mostly nonsensical and the rest describes attacks so impractical they are pretty much impossible to carry out and are so much harder than simply sending a thousand emails with a link to an executable that pretty much nobody ever bothers.
Note I never said that IPv6 is worse, I said that NAT has relevant advantages and mostly irrelevant disadvantages. I really don’t care ftp doesn’t work with NAT.
You simply do not host services you do want public on your global unicast address but use a private/site local address instead.
What's wrong with a firewall that blocks everything by default, yet all your devices have a public IP?
Behind a NAT, observers can only make that connection (using only addresses) for the network as a whole, instead of an individual device on the network. So the privacy extensions are weaker than NAT
(If the IPv6 privacy extensions used a different address for each connection, they would be more like NAT in this regard.)
That said, other observable clues still allow connections from a single device to be associated, NAT or not. There's TCP OS fingerprinting for example, and the close timing of related connections.
In this scenario it's a lot more work trying to map out your infrastructure than to try performing a MITM connection against some of your outbound traffic.
With any usable N, a clever observer would still easily work out what you were doing and still map out your infrastructure.
More reasonable is to use new address for each connection. Then nobody can tell if 10 addresses and 10 connections are one device or ten.
You've saved the translation in the router, but now routing lookups and ARP caches have grown by TEMP_VALID_LIFETIME / TEMP_PREFERRED_LIFETIME.
What are valid values in the scenario you are proposing? The defaults are 1 week / 1 day, so 7X. If you chose to rotate each second, and say allowed addresses to only be valid for say 20 minutes, this still appears to be a ~1200X blowup in routing overheads.
They have not?
The global routing table size for ipv6 at max is a /32 (if i remember correctly) every customer gets a /56 prefix to use in their network, so the routing table entry would still be the same, no matter how many addresses you use to cycle through in your /64.
ARP caches do not exist in IPv6, and Neighbour discovery does not have the same "cache" mechanism as ARP does, it uses an entirely different mechanism for neighbour discovery. (which is also far more lightweight considering it is using multicast, compared to the broadcast of ARP).
There is a whole industry built around network traffic analysis.
What makes you think it doesn't happen on the internet?
The ISPs have the ability to see what is on your network by IPv4 egress. They have been able to do this for a decade.
Worrying that an IPv6 address divulges the network forgets that IPv4 devices betray their existence through DNS, their destinations and other network behavior.
The ISPs know.
2. You can't say anything about the percentage with just the absolute market value. At the very least you need something else to compare it too.
Please, be serious.
So, I mean, I dunno, 2 billion dollars seems serious to me, but maybe we just have different barometers for what counts as "serious amounts of money". Especially considering these devices that are like $300.
Finally, might I remind you of the guidelines? in particular:
> When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."
Many of these routers are managed by the ISP using protocols such as TR-069, several ISPs have already been found to not only manage the devices but also monitor certain data including what devices are present.
They are, but in practice they are muddled together and I suspect people are going to create subnets with IPv6 in the name of security. In IPv4 NAT is used to make sure your laptop isn't exposed to random script kiddies trying to scan for vulnerable services behind your router. A fun exercise is to plug a RaspberryPi up directly to a public facing IP address and log every packet it receives. Then give those scripts a few services to detect (HTTP server, SSH server, etc.) and look at how the traffic shifts from scanning for ports to scanning for vulnerabilities. Being connected directly to the public internet is a real eye opening experience.
I do believe future IPv6 networks will have gateway machines and/or bastions that are connected to the public internet with public IPv6 addresses. And then they'll have an interior network that they use NAT for. Individual machines will not be routable or discoverable without going through a bastion/gateway that explicitly controls the flow of traffic into a network. Not because this is the ideal way to structure an IPv6 network, but because this pattern is going to carry over from the IPv4 world and there is a lot of momentum in tribal knowledge using NAT as a form of firewall.
NAT does nothing for that. Those incoming connections are dropped on the WAN interface before NAT would even be involved. Which is why it works exactly the same way regardless of whether the destination IP for that traffic was IPv4 or IPv6.
That isn't really feasible with IPV6 though is it? The smallest IPV6 subnet is 18,446,744,073,709,551,616 addresses, so even if you setup a Pi fully open to the world with default passwords the chance of someone scanning it is basically zero. That type of scanning only works because the IPV4 range is so small (& you can efficiently ignore large parts of it like the US DOD space, private addresses, etc).
[0]: https://isc.sans.edu/diary/Targeted+IPv6+Scans+Using+pool.nt...
Right now, my macOS system has four publicly-routable IPv6 IPs, all random. New ones are generated, and old ones removed, regularly.
https://www.internetsociety.org/resources/deploy360/2014/pri...
With IPv6 instead of NAT deciding that port 2000 maps to 192.168.1.3 port 22, you have a firewall that may or not choose to route to xx:yy:zz or not, and to allow an incoming connection over port 22 to that host or not.
If you don't want to accept incoming connections to a given machine or network on IPv6 without NAT that's very easy to have.
Now, sometimes NAT is needed anyway: QubesOS supports IPv6 using NAT because it splits things up into many different VMs on one computer. But that's a pretty rare case.
It's security through obscurity at best, i.e: not security. You shouldn't be relying on size of address space to protect you from anything. An IDS/IPS that alerts on abnormal ICMP behavior will be useful whether an attack is 1GiB of traffic in size or 1024EiB of traffic in size. (Also you don't even need automated scanning to find some juicy targets: I've seen a lot of routers on the edge of a prefix configured at ::1/64 and ::2/64 for instance.)
I did not have to do anything to get this. My macOS system has IPv6 set to Automatic. My home ASUS router picks up the /64 allocation from my ISP, passes the info on to things on the LAN, and acts as a firewall for IPv6 (while continuing to act as a NAT for IPv4).
According to https://www.internetsociety.org/resources/deploy360/2014/pri..., this has been common for some time.
Ports on router are allocated by it and not client machines. So far my experience has been they're usually sequential without any preferrence.
(Hand waving a bit here with terminology don't shoot me)
Local firewalls on devices, maybe, but network firewalls generally are default-deny on untrusted interfaces, and between 0 and 1 interfaces are trusted by default.
Back in 2007 Apple's Airport Extreme Base Station shipped with a firmware that defaulted to allowing all IPv6 traffic, which was quickly pointed out in the tech media and fixed in a patch a few months later. A few of the garbage pile combo modem/router devices distributed by ISPs have had similar issues over the years as well. That's not normal behavior though, when it's observed it's rightfully considered a security flaw and tends to get the kind of attention vendors don't want.
If you know of a mainstream device that would "fail reachable" as you claim here, name and shame please.
> without explicit port forwarding or exposed hosts, NATs fail unreachable.
I work in VoIP and can say from plenty of direct experience this is not true. In the modern work from home era I've had to deal with a lot of the aforementioned garbage pile consumer devices and a recurring issue with some of our clients who had older phones is that their users' home routers did the laziest NAT possible and literally just opened a two way hole on port 5060 (SIP) so as long as the phone was communicating with our server and keeping the pinhole open *ANY* other traffic that hit port 5060 was also sent to the phone, which meant they got all kinds of "phantom calls" from bots looking for unprotected SIP relays.
Newer phones generally have an option to only accept SIP messages from trusted servers, but older ones sometimes don't so when combined with badly implemented NAT that happens.
And yea, obviously that's a consequence of a particularly bad NAT implementation, but your complaint is about an issue that would only occur in a particularly bad IPv6 implementation.
Bad IPv6 is as simple as not having a firewall or default-allowing it like AirPort did. If Apple can make that mistake, a lot of random manufacturers can too. I can see the whole NATless firewall setup but wouldn't use it for a very long time, to let things settle.
Of course, if the protocol added workaround for NAT and NAT is modifying that application layer data then it can cause another set of issues.
It gets even worse with higher level protocols like FTP. There is such a thing as FTPS (FTP over SSL) but it's rarely used because if you encrypt the traffic then the NAT gateway can't inspect and rewrite the traffic.
The same is true of IPSEC/ESP, if you have an encrypted TCP packet encapsulated with ESP the NAT gateway can't keep track of which internal host to forward it to because it can't see the source and destination ports.
A normal router does not need to care about anything further up the stack than IP. A firewall does, but even when a firewall doesn't explicitly support a particular protocol you could write a rule allowing any traffic with a particular protocol number between specific hosts is allowed, and anything else denied.
I get that an ipv6 router can have a firewall with good defaults blocking incoming connections, emulating that aspect of a NAT.
The type of NAT we're talking about here *only* applies to outbound connections. It doesn't do anything at all to inbound connections.
Even if you never allow anything in from outside that wasn’t established from the inside first, it still removes an added layer of complexity from things.
Of course I do. Why would you not want the option of easily allowing a device to be globally routable if you need it to be?
I think routers should be more explicit about how you set up each new device on a private network anyway. Guest wifi can have a sane default. Private wifi could make a notification pop up on your trusted device, asking you if you want the now device to have access to the internet, and if the internet should have access to the device, and if so, which subnets/countries should be able to access it through which ports.
A lot of would-be P2P applications end up using a relay server to get around that restriction, which adds significant cost and latency. Sure it's a well-established workaround by now, but it'd be nice not to rely on it.
The whitehouse has a public address, everyone knows its address and yet random people can't just walk in through the front door.
As the parent suggests, IPv6 creates more work to prevent more exfiltration. It is already difficult enough with IPv4.
Could IPv6 fix a web infested with "tech" company intermediaries and return it to one where all participants can connect directly and if desired publish to audiences (without "tech" interplopers). That sort of proposal would make an interesting read for end users.
That should be enough for all your devices to randomly rotate IPs for a lifetime or a few without any NAT.
Shitty ISPs do exist, or at least they existed two years ago.