IPv6 Is Hard
techlog.jenslink.net
techlog.jenslink.net
What is hard, is dual stack networking. Dual stack networking absolutely sucks, it's twice the stuff you have to deal with, and the edge cases are exponentially more complex because if your setup isn't identical in both stacks, you're going to hit weird issues (like the article suggests) with one stack behaving one way and the other behaving another way.
None of this is the fault of IPv6, it's a natural consequence of the strategy of having two internets during the transition period. A transition period which has now been going on longer than the internet existed when it started.
Maybe 100 years from now we'll finally be able to shut off the last IPv4 system and the "dream" of IPv6 will become a reality, but until then, life is strictly more difficult on every network administrator because of dual stack.
(Note: no, we could not have done it any other way. Any upgrade strategy to IPv4 that extended the address size would have necessitated having two internets. It just sucks that it's been this long and we're still not even at 50% IPv6 usage.)
The addressing is intimidating, getting your head away from NAT, thinking about being globally routable, the lack of (or variances in) DHCP, ND, "static" addressing via suffixes, etc.
None of this is technically "hard", but it's a significant barrier to entry because it's quite different to what most normal technical users are used to.
Dual stack may create some new problems, but it fixes a lot of others. All of the major cloud providers have awful IPv6 only support, and many prominent web resources that usually invisibly "just work" have little to no IPv6 support.
I suspect that if the situation were reversed and we always had IPv6, and someone proposed a new IP suite where you had to use NAT for everything, and all hosts needed to have their addresses hand-picked (or served via a DHCP server that used an ugly hack to communicate with hosts that don't have an IP yet), you'd find that to be the "hard" one.
I can remember two numbers from 0 to 255, but four? Not in a million years.
Isn't there an idea that our working memory holds seven pieces of information? Which would be two of those numbers and change, if you consider each digit as a piece of information.
I've been sending my mail via IPv6 for ages without issues… did you mean reputation or reputation?
IPv6 nodes aren't individual random addresses in a 128-bit address space. They are going to be grouped in subnets, so it makes sense to explore /64 ranges where you know there's already at least 1 address active. There's a pretty decent chance at least some addresses are going to be sequential - either due to manual configuration or DHCPv6 - so you can make a decent start by scanning those. For non-client devices, SLAAC usually generates a fixed address determined by the NIC's MAC address, which in turn has a large fixed component identifying the NIC's vendor. This leaves you with a 24-bit space to scan in order to find other devices using NICs made by that vendor - not exactly an unfair assumption in larger deployments. Much faster scanning can of course be done if you can use something like DNS records as source for potential targets, and it's game over once an attacker has compromised the first device and can do link-local discovery.
It's not going to be extremely fast or efficient, but IPv6 scanning isn't exactly impossible either. It's already happening in practice[0], and it's only going to get worse.
[0]: https://www.akamai.com/blog/security-research/vulnerability-...
Then there is this one customer, they are colocated in other ISP owned datacenters, and some of their server maybe have fully IPv6, some may have only IPv4, some may be a mixture of both. Supporting them is a never ending nightmare.
The really sad thing about IPv6 is that it's a relic of a bygone era. The internet was envisioned as a thing where every device on every network could, in principle, initiate a connection to any other device on any other network. But then we started running out of addresses, ISP's wouldn't give you more than one for a household, so we started doing NAT, and that kind of sealed the internet's fate.
Nowadays, we wouldn't want a world where everything was connectable, even if we had enough addresses. Everyone's network in essence has a firewall. If you run IPv4 and using NAT, you're going to be dropping unsolicited incoming packets no matter what (let alone that you wouldn't know where to route them even if you wanted to let them through) and with IPv6 you'd be insane to allow them.
Devices have "grown up" in a world where we expect the router we're connecting to, to shield us from incoming unsolicited traffic. I certainly don't have the firewall enabled on my linux desktop. Windows I _think_ has it enabled by default, but I often turn it off because I want LAN connections to work. MacOS is probably similar. Suffice to say, if the IPv6 dream happened overnight and everyone's devices were instantly connectable, all hell would break loose. We need our routers to disallow traffic. (Edit: This wasn't all that clear, so let me restate: In both the IPv4 and IPv6 world, you'd be insane to disallow incoming unsolicited traffic, which is why basically everyone blocks it in IPv6 as well as IPv4. I'm not trying to say IPv6 can't do this... quite the contrary: IPv6 routers absolutely do, and should, block unsolicited incoming traffic. But my point is that this is what prevents the original vision of IPv6 from becoming a reality: We can't design software around the idea of direct peer-to-peer communication, without stuff like UPnP. Oh, and UPnP works with NAT and IPv4 anyway so, there's the rub.)
So, even in a pure-IPv6 world, that instantly prevents any startup with an idea to allow true peer-to-peer communication using end-to-end routability. What are you going to do, train your users to log into their router and enable traffic? Approximately 0% of your customers know how to do that, even in a counterfactual universe where IPv6 happened and we all have routable IP's on our devices. Maybe in such a universe, people would be trained to use local firewalls on their device, and say "ok" to popups asking if you want to let software through. But I'd wager that a lot of people would prefer the simplicity of just having their gateway drop the traffic for them.
No, the "all devices are routable" idea came from a naive world where there wasn't a financial incentive for malicious behavior at every turn. Where there aren't millions of hackers waiting for an open port to an exploitable service they can use to encrypt all your data and ransom it for bitcoin. The internet is a dark forest now. We don't _want_ end-to-end connectivity.
IPv6 makes P2P routing substantially easier, even in a world of default firewalls that drop unsolicited packets. You can still apply standard NAT busting techniques like STUN with IPv6 devices behind firewalls, and you get much better results because IPv6 removes the need to track and predict the port mapping a standard NAT does. Two P2P systems can both send unsolicited packets to each others IPv6 addresses, with a specific port, and know that port number isn’t going to be remapped, so their outbound packets are guaranteed to have the right address and port data in them to get their respective firewalls to treat inbound traffic on those addresses and ports as solicited.
This is particularly useful when dealing with CGNATs, where your residential devices ends up behind two NAT layers, both of them messing with your outbound traffic, which just creates an absolute nightmare when trying to NAT bust. IPv6 means that you’re no longer dealing with three or more stateful NATs/firewalls between two peers, and instead only have to deal with at most 2 (in the general case) stateful firewalls, who’s behaviour is inherently simpler and more predictable than a NAT ever is.
(Of course, the other huge benefit of IPv6 is "more addresses", so we need it just for that. But my point is that "global routability" isn't really the dream people think it is. In practice, the only differences between modern GUA-but-deny-by-default IPv6 setups and NAT'ed IPv4 setups are the simplicity of the former for the network administrators.)
You should tell that to my ISP, they’ve managed to deploy a CGNAT that’s proven to be completely STUN proof. The only way I can achieve any kind of P2P comms is using IPv6. IPv4 is useless for anything except strictly outbound connections.
> and you're going to need something like that even if there were no NAT, so to me it sounds like a bit of a wash, at least to the end-user.
Not in my case. As above, I simply can bust my ISPs CGNAT, so IPv6 is invaluable to me. Makes a huge difference to me, the end-user.
It's not the only benefit, as anyone who's tried to build a large network or merge two networks with overlapping address space will tell you.
Sometimes. I've experienced a few networks where even with STUN I'm still not able to get a workable session in IPv4.
There is also a bit of conflated use of terms. A firewall on windows is just a fancy name of permission management. A program want to open a port and the user get a prompt if they want to allow it (assuming the user has such privileges). It is indistinguishable from similar permission system found on phones that ask if an app is allowed to access contacts. The only distinguishable "feature" is that programs might not be aware that the permission was denied, thus opening a port that is not actually open. Windows programmers may know more of the specific of this.
... which is ... virtually all of them ...
get p0wned on a massive scale? You know, now with AI powered assaults for extra special vulnerability levels...
And then a magic wand happens, and the IT orgs that couldn't even install patches will be able to back-discover all the compromised hard drive firmwares, rootkits, and nth-level security holes after the fact?
I get a NAT wall isn't perfect security. But pretending it is NO security is disingenuous.
IMO this is the only way forward.
You have a firewall at the edge of the network. It blocks incoming connections by default, but supports Port Control Protocol. The cacophony of unpatched legacy IoS devices stay firewalled because your ten year old network printer was never expected to have global connectivity and doesn't request it. End-to-end apps that actually want it do make the requests, and then the firewall opens the port for them without unsophisticated users having to manually configure anything.
The protocol is an evolution of NAT-PMP (RFC6886) for creating IPv4 NAT mappings, but RFC6887 supports IPv6 and "mappings" that just open incoming ports without NAT.
There's no way in hell enterprise admins are going to give that kind of control to random devices, and home users aren't going to have the skills to cull vulnerable devices from their networks. So who's going to use it?
In my opinion the current kind of hole punching is a far better option: instead of creating a mapping allowing essentially unrestricted access from everyone, have the app use an out-of-bounds protocol to allow a single incoming connection from exactly one vetted source. You get all of the benefits of a direct peer-to-peer connection with none of the risks of exposing yourself to the internet. It's well-researched when it comes to the interplay between firewalls, NAT, and UDP[0].
And that pretty much solves the problem, to be honest. These days you only really need incoming traffic to support things like peer-to-peer video calls. Hosting game servers on your local machine is a thing of the past, everything has moved to cloud services. What's left is a handful of nerds running servers for obscure hobby projects at home, but they are more than capable of setting up a static firewall rule.
It's not about new or old. The devices that don't have any reason to be globally reachable never request it. New ones would do likewise.
Devices that are expected to connect to random peers on the internet are going to do that anyway. It's not any more secure for them to do it via hole punching rather than port mapping; causing it to be nominally outgoing doesn't change that it's a connection to a peer on the internet initiated by request of the remote device.
> There's no way in hell enterprise admins are going to give that kind of control to random devices, and home users aren't going to have the skills to cull vulnerable devices from their networks. So who's going to use it?
Enterprise admins can easily use it because they have control over the gateway and how it answers requests, so they can enable it for approved applications (in high security networks) or all but blocked applications (in normal networks), and log and investigate unexpected requests. They should strongly prefer this to the alternative where possibly-vulnerable applications make random outgoing HTTPS connections that can't easily be differentiated from one another.
Whether they will or not is a different question (there are a lot of cargo cult admins), but if they don't they can expect their security posture to get worse instead of better as the apps that make outgoing HTTPS connections to avoid rigid firewalls become the vulnerable legacy apps that need to be restricted.
Home users are already using NAT-PMP or UPnP and this has only advantages over those older solutions.
> instead of creating a mapping allowing essentially unrestricted access from everyone, have the app use an out-of-bounds protocol to allow a single incoming connection from exactly one vetted source. You get all of the benefits of a direct peer-to-peer connection with none of the risks of exposing yourself to the internet.
There are significant problems with this.
The first is that it's a privacy fail. The central server is at a minimum in a position to capture all the metadata that shows who everyone is communicating with. It's made much worse if the payload data being relayed isn't end-to-end encrypted as it ought to be.
But if it is E2EE, or the server is only facilitating NAT traversal, the server isn't really vetting anything. The attacker sends a connection request or encrypted payload to the target through the relay and the target is compromised. Still all the risks of exposing yourself to the internet, only now harder to spot because it looks like an outgoing connection to a random server.
Worse, the server becomes an additional attack vector. The server gets compromised, or the company goes out of business and the expired domain gets registered by an attacker, and then their vulnerable legacy products are presenting themselves for compromise by making outgoing connections directly to the attacker.
Doing it that way also requires you to have a central server, and therefore a funding source. This is an impediment for open source apps and community projects and encourages apps to become for-profit services instead. The central server then puts the entity maintaining it in control of the network effect and becomes a choke point for enshitification.
Meanwhile the NAT traversal methods are ugly hacks with significant trade offs. To keep a NAT mapping active requires keep-alive packets. For UDP the timeout on many gateways is as short as 30 seconds, which prevents radio sleep and eats battery life on mobile devices. Requiring a negotiated connection is a significant latency hit. For real peer to peer applications where nodes are communicating with large numbers of other nodes, keeping that many connections active can exceed the maximum number of NAT table entries on cheap routers, whereas an open port requires no state table entries.
> What's left is a handful of nerds running servers for obscure hobby projects at home, but they are more than capable of setting up a static firewall rule.
The point is to allow interesting projects to benefit more than a handful of nerds and allow them to become popular without expecting ordinary users to manually configure a firewall.
But it doesn't seem to be in widespread use, does it? Like, would a random internet gateway from podunk ISP support this? I kinda doubt it, right? Pretty sure the default Comcast modem/router setup my mom uses doesn't support this.
But I guess my point was about the contrapositive universe where IPv6 was actually used everywhere, and in that universe I suppose RFC6887 might have been commonplace.
Then it starts to make it into popular internet gateways. For example, the Comcast consumer gateways generally do support UPnP, which is a miserable protocol with an unnecessary amount of attack surface that should be transitioned to Port Control Protocol as soon as possible, but it demonstrates you can get them to implement things of this nature.
You do what has already been done for decades. You ship a client premises router that does deny by default inbound and allow all outbound and things behave pretty much the same as they do today with these exact same rules in IPv4.
Network firewalls still exist in a publicly routable network. If I want my game console to allow incoming traffic for game matchmaking, I can then do that. Or have systems that auto configure that. But then I don't have to have multiple devices fighting for a limited port range, each device has more IPs and ports than they could know what to do with.
To use your example:
> If I want my game console to allow incoming traffic for game matchmaking, I can then do that
My point is that because of the fact that even in IPv6, consumer firewalls will block traffic by default, the company that makes the game would not have designed it to require your console to have special configuration on your firewall. Because this is not something a typical gamer knows how to do.
Instead, companies use UPnP for matchmaking, and UPnP works in both NAT and GUA environments, so what exactly does GUA give you?
You'll have even more problems if you're on CGNAT networks. You're not going to be able to get any of that traffic.
None of this is a problem if each device has its own IP address and its own range of ports to deal with. Every device can have its own :5000, it can know it's public IP address without having to have something see from outside, and with how big assignments usually are it can have dozens of things all listening on a public :5000 all at the same time.
Having globally allocated address space doesn’t actually imply openness of connectability
Not just difficult, but impossible, even in principle, because there are more than one device sharing the same IP so at most one host would be vulnerable. Not the same as with IPv6, where screwing up the defaults leaves your entire network vulnerable.
Tons of firewalls ship with this as a default logic, it doesn't require NAT in the slightest.
https://www.anvilsecure.com/blog/dhcp-games-with-smart-route...
Are you not doing that already? If you trust whoever else happens to be on the same wifi in the cafe you're a braver man than I.
Of course not, that's not my point. My point is that because of the fact that your home router still firewalls with both IPv6 and IPv4, any software which relies on being able to "just" connect to a peer over the internet, is doomed. Our networks don't work that way any more (they probably did in the early 90's though.)
My point is that even if we had global routability, we still wouldn't have open connectability, because open connectability is a stupid idea. Which means any software ideas people might have that rely on connectability, are already a non-starter. So why do we need open routability in the first place? (Honest question. This is the crux of the issue. Yes, open routability means you can have a host listen on the open internet, but fewer than 1% of people know how to configure their home firewalls to do this, so it's effectively not possible to rely on this being something your users can do.)
With IPv6 the only thing you need is PCP (or equivalent).
With IPv4 you need PCP/whatever plus a whole bunch of STUN/TURN/ICE infrastructure.
Just hole punching is a lot easier to support than more-than-just hole punching.
I'd say the biggest practical objection (not just "NAT is ugly" or "DHCP is ugly" or "NAT is evil since it delayed IPv6") is CGNAT, which really does put a lot of restrictions on end-users that they can't circumvent. The more active hosts stuffed behind a single NAT, the more they have to compete for connections.
> but fewer than 1% of people know how to configure their home firewalls to do this, so it's effectively not possible to rely on this being something your users can do.
And a chunk of that 1% are on WANs that they aren't authorized to configure even if they wanted to.
| | IPv4 | IPv6 |
|--------------+-------------------------------------+-------------------------------------|
| With uPnP | Unsolicited connection goes through | Unsolicited connection goes through |
| without uPnP | Unsolicited connection blocked | Unsolicited connection blocked |
I thought the problem was lack of upload bandwidth for almost all households without fiber to the home. Surely, if people had symmetric broadband internet at home, then there would have been commercial solutions to allow devices to connect to each other, thereby decreasing the need for giant cloud providers.
"All devices are routeable" is a good idea, because it means when we want devices to be routeable there's a simple and obvious way that should be done.
Where we've ended up with NAT though is worse though: we still need a lot of devices to routeable, and so we enable all sorts of workarounds and non-obvious ways to make it happen, giving both an unreasonable illusion of security and making network configuration sufficiently unintuitive we're increasing the risk of failures.
Something like UPnP for example - shouldn't exist (and in fact I have it turned off these days because UDP hole-punching works just fine, but all of this is insane).
Just look at the distribution of successful attacks in 2000 and in 2025.
Yes, and not only for the NAT reason you say; see "The world in which IPv6 was a good deisgn" by Apenwarr, from 2017: https://apenwarr.ca/log/20170810
> We don't _want_ end-to-end connectivity.
YOU dont want that.
The wish to not have all devices connected to the Internet does not defeat the need of having a protocol that allows that. NAT is merely a workaround that introduced a lot of technical debt because we don't have enought IPv4 addresses. And having IPv6 does not mean that you must connect everything to the internet.
IPv6 Is good and absolutely necessary. NAT is really expensive and creates a lot of problems in large networks. Having the possibility to just hand out routsble addresses solves a lot of problems.
There's a kind of holy war, where people pick sides, and if you're "team IPv6", you look for any post that kinda vaguely smells like it defends IPv4, call them ignorant, and respond with the typical slew of reasons why IPv6 is better, NAT is a hack, you can still firewall with IPv6, etc. If you're "team IPv4" you look for the IPv6 posts and talk about how NAT is useful, IPv6 should have been less complicated, etc etc.
It's really tiresome.
Personally, I'm not on either "team". These things I believe:
- We need more addresses
- IPv6 is as good a solution as any, as no solution was going to be backwards compatible.
- We should get on with it and migrate to IPv6 as soon as possible. What's the hold up? I'm sick of running dual stack.
- But don't throw away NAT, please. I want my internal addresses to be stable and if possible, static and memorizable (An fd00::1 ULA [0] is even easier to remember than 192.168.1.1! And it won't change when my ISP suddenly hands me a new prefix.)
- But CGNAT is The Devil. Don't conflate my desire for using NAT at my house for some desire to be behind CGNAT. Again, we should get on IPv6 ASAP to banish CGNAT back to hell.
- Oh and don't pretend that IPv6 would have led to a more decentralized internet. A client/server model is inevitable for so many reasons, and true peer-to-peer where customers just communicate directly with one another is not a realistic goal, even with IPv6. Even with PMP/PCP. Even with DDNS. You just can't design software around the idea that "everyone's router is perfectly configured."
[0] No, I don't actually use fd00::/64 as my ULA prefix, I actually put my cellphone number in there :-P. The point being it's as memorizable as you want it to be.
True.
>IPv6 is as good a solution as any...
There aren't any other practical solutions. Debatable if it was the best solution but it is what it is.
>We should get on with it and migrate to IPv6 as soon as possible
Most LANs will run IPv4 forever. IPv6 offers nothing to LANs larger than home labs (when SLAAC is not enough) but smaller than huge companies (when there are more than enough addresses even in IPv4. 240/4 is for every practical purpose private). The community's hostility to NAT/NPT means LAN admins will get it de facto by running another stack internally.
>I want my internal addresses to be stable and if possible, static and memorizable.
Right. But ULAs have ridiculous routing rules. It would take at least a decade for fixes to be deployed everywhere.
>Don't conflate my desire for using NAT at my house for some desire to be behind CGNAT.
Right. But most users don't care.
> A client/server model is inevitable for so many reasons.
Right.
But for certain, today if we had IPv6 everywhere, it still wouldn’t let you design something like a VoIP phone (or a pure peer-to-peer version of FaceTime) that just listened for connections and let other people “call” you by connecting to your device. That software would only be usable by people who know how to configure their router, and that doesn’t make for very good market penetration. You still need something like UPnP, so you’re basically right back to where we are today. At least the connection tracking would be stateless, I guess?
I have two SIP phones both wanting to register port 5061 to forward to their address. How does this work with IPv4/UPnP?
Routers have a stateful firewall meaning by default they only allow incoming packets that belong to a connection that was initiated from the inside. By default you also have this kind of firewall on every operating system. NAT adds 0 additional security.
No, this isn't right. Instead of having IPv6 we ended up extending IPv4 by using port numbers as extra address bits and using NAT. This transition was painless (for the most part), and didn't require building a second internet.
In a better and saner world we could have got roughly the same thing - except conceptually simpler and standard - instead of IPv6.
In reality we just really do need more IP’s. 32-bit addresses with 16 bits of ports isn’t enough.
Sadly, that's a feature, not a bug.
Two layers of NAT sucks, but I guess it could have been avoided if a designed (instead of ad-hoc) solution to the problem was devised.
> And there are more internet subscribers in the world than there are IP’s for them
Is this really true, did somebody actually run the business math? "Internet subscriber" roughly corresponds to "household", not to "person".
Obviously you can use (just) IPv6, e.g. GitHub.
https://labs.apnic.net/index.php/2024/10/19/the-ipv6-transit...
Adoption will slow down and my guess is that we'll be stuck with a long tail forever, and only time will tell if that happens at 50% adoption or 90% adoption.
But that long tail will probably look like figure 4 of that link, only reversed: IPv4 running mostly as tunnels over a core IPv6 network. Some large cellphone networks are already at that stage, using things like 464XLAT to run IPv4 with NAT over an IPv6 network.
Depending on what that dream is, it may already be a reality in the upper layers (webrtc, websockets, quic/http3, etc). This is why not many really bother if IPv4 will go away?
That said, a lot of posts here don't seem to reckon with the fact that a slim majority of www.google.com connections in the United States are via IPv6, and a super-majority from India, Germany, and France. Comcast, T-Mobile, Verizon, as far as I have experienced, these all default to IPv6. While dropping IPv4 support is both a worthy, distant goal and sometimes used in goal-post moving rhetoric, it's not like nobody uses IPv6...rather, mobile broadband networks have depended on it for over a decade (see T-Mobile's deployment of 464XLAT)
There are multiple v6 prefixes already allocated for containing the v4 space. It would help if all ISPs ran NAT64 routers on the standard NAT64 prefix, but e.g. how would that function with software that only works with v4 addresses?
On an ipv6 only device if I type "ping 1.1.1.1", I would expect that to be translated by the OS (not the program) to 64:ff9b::1.1.1.1, rather than relying on DNS64 to do it.
Then at some point upstream it would go via a nat64 gateway to reach that legacy IP.
This should have been in OS stacks 20 years ago.
You can try this on a vanilla macOS install if the router advertisement hints at a NAT64 prefix (RFC8781) and you either don’t run DHCP4, or your DHCP4 server lists the IPv6-preferred option (RFC8925). I think they’ve also added a check to query a well-known ipv4-only hostname on DNS, and if it gets a AAAA back and the connection works, it knows it must be behind a working nat64 setup, which obviates the need for the router advertisement to have the PREF64 option.
I tried this a year ago and it worked great, macOS skips DHCPv4 and gives itself a single 192.0.0.1/32 address so that legacy apps can “see” an IPv4 interface, and any packets sent from it are translated to IPv6 and sent to the nat64 prefix. So “ping 1.1.1.1” works fine. I stopped using this though, because I have a garage door opener (ratGDO) that only works with ipv4, and my nat64 prefix can’t “hair-pin” the packet back to the LAN address… it basically only works if everything on your LAN is IPv6, which my garage door is not.
I think android supports this as well, but I’m not sure about vanilla Linux, I think you need to install a clat daemon to do the translation.
It did take way too long for this to work though, as you point out.
Basically every server program ever supports the notion of "which IP address am I supposed to bind to?" Normally the answer is either "localhost" or "whatever my LAN or WAN address is, for a particular interface". And specifying this (both for servers and for clients) is much less effort than replacing all the standard-ish ports with ad-hoc ones.
Just assign multiple IPv6 to your loopback interface and everything will work as expected. You can use either private IPv6 or even link-local IPv6 range.
There’s no need to waste thousands of addresss on this use case.
IPv6 is still the only game in town as a successor technology to IPv4, and it makes no sense to invent some other new thing.
The real question at hand, is do we keep trying to make IPv6 happen, or do we give up and just deal with IPv4 until the end of time. (It’s not an obvious answer. L7 load balancing and IP anycast makes it so you can basically run an entire tech company on a single IPv4 address. CGNAT is becoming more and more commonplace. The pressure on IPv4 availability is alleviating all the time. Maybe 4 billion addresses will ultimately be enough for humanity, who knows.)
But I mean it when I say that if we continue as is and just sorta gradually, grudgingly add IPv6 on a best-effort basis, it’ll likely be 100 years or so before we can actually turn off IPv4.
Clearly you have gotten some unfortunate hands on experience with those edge cases. In my uses the dual-stacking of IPv4 & IPv6 has been a big benefit in that I have to worry a lot less about locking myself out of systems, as I can always reconnect and correct configuration mistakes on the second stack.
Comparing the IPv4+IPv6 dual-stack story to the one from the 90s of IPv4 with IPX/SPX (Novell Netware) and/or NetBIOS (Microsoft Windows), the current state is a lot more smooth and robust.
I've so far only run into 3 issues over the years (2013 till now). A local train operator running IPv6 on routers that didn't properly support non-default MTU sizes (fragmented packages getting dropped) and Microsoft where Github is still IPv4-only and Teams recently developed an IPv6-only failure on a single API endpoint.
Should we ever turn off IPv4 during my working life-time, I hope we have at that point introduced a successor to IPv6, so I can keep using a dual- or triple-stack solution, using different network protocols for robustness.
Partially due to companies like Metronet whose focus is on growing rather than doing what it should be doing.
See apenwarr's by now nearly a decade old blog post "The world in which IPv6 was a good design": https://apenwarr.ca/log/20170810, previous discussions of it here: https://hn.algolia.com/?query=The%20world%20in%20which%20IPv..., as well as the follow up blog post here: https://apenwarr.ca/log/20200708, previous discussions here: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
And the issues with IP (and by extension, TCP, ignoring the fundamental results from the Delta-T research at Lawrence Livermore keeps biting us all in the ass) whether IPv4 or IPv6 go even deeper, far deeper, than what that blog post already tells us, so here, have this—flawed in some minor aspects, which makes CCIEs burry their head in the sand of denial about the deeper point of it—polemic for dessert: https://web.archive.org/web/20210415054027if_/http://rina.ts...
Where did I give that impression? I tried my hardest in that post to not make a judgement call one way or the other as to whether it was a good design, only that dual stack fucking sucks.
My followup post in fact, totally agrees with you? https://news.ycombinator.com/item?id=43070286
No it's not. Slaac and NA make it a totally different beast.
If ipv6 only had dhcp6-pd, it would have been "just like ipv4 with longer addresses".
How many ways to be assigned an ipv6 address are there anyway? Two or three too many?
Why should the ISP know what devices I have behind their router?
Considering the amount of enterprise-ish thought that went into ipv6, they thought preciously little of privacy, for example.
Broadcast was renamed to "all nodes multicast". ARP was renamed to Neighbor Discovery.
Slight improvements: ND isn't broadcast, but multicast based on several bits of the IP address. This allows NICs to filter most of the irrelevant ones based on multicast MAC address. And subnet broadcast addresses were removed. There's only local broadcast to your own subnet and not to someone else's subnet, since IPv4 routers found that to be a bad idea and mostly started blocking it anyway.
there is nothing really wrong with the design of ipv6 relative to ipv4
Having two internets suggests that it's totally different, in the sense that there is no address space overlap between IPv4 and IPv6, an inherent design flaw of the IPv6 protocol. Just to provide the architypical links:
This was documented about 25 years ago by DJB:
https://cr.yp.to/djbdns/ipv6mess.html
And has been repeatedly discussed on HN:
https://news.ycombinator.com/item?id=10854570
As you mention, IPv6 has exsited for the majority of the commercial internet's history, now 25 years later, it's still not the default transport protocol.
It _was_ possible to create an address space extension that was IPv4 backwards compatible, this option was just not chosen, and now we're still dealing with the dual stack mess.
It is not a design flaw of IPv6, it is a limitation of the laws of physics: how can you fit >32 bits of data (IPv6) into 32 bit data structures (IPv4: struct s_addr)?
Even if the IPng protocol could recognize IPv4 address and send out data, how can a host which only understands 32-bit addresses send back a reply back to the IPng host? If a packet with a >32b address comes in, how would a 32b-only hosts be able to handle it?
From Bernstein:
> In other words: The current IPv6 specifications don't allow public IPv6 addresses to send packets to public IPv4 addresses. They also don't allow public IPv4 addresses to send packets to public IPv6 addresses.
How would a non-updated IPv4 system know about the IPng protocol? If a non-updated router had a IPng packet arrive on an interface, how would it know how to handle the packet and routing?
All the folks criticizing IPv6 don't ever describe how this mythical system would work: how do you get 32-bit-only system to understand more-32-bits of addressing? Translation boxes? Congratulations, you've just invented 6rd BR or NAT64, making it no different that IPv6.
The primary purpose of IPng was a bigger address space, but how would that work without updating every single IPv4 device? You know, like had to be done for the eventual IPng, SIPP (aka IPv6).
Maybe you don't. I imagine it would work like this (where XXXX::<IPv4> is the transition block mapping the current Internet v4 into IPv6):
- 32 bit host could only talk to other 32-bit hosts, and other XXXX::<IPv4 Adress> hosts. We have this now, just without the XXXX::<IPv4> part.
- Hosts with v6 addresses outside of XXXX::<IPv4> could not talk to IPv4 addresses without having a 6to4 proxy. We also have this now.
- Hosts with v4 addresses could switch to IPv6, KEEPING their current v4 address by setting their IPv6 addres to XXXX::<IPv4>. They can now talk to all the hosts they used to be able to, AND they can start talking to IPv6 hosts, without having to have two IP, dual stack config, etc.
So we end up with a significant benefit of allowing people with IPv4 addresses and IPv6 connectivity to do an IPv6-only setup.
In my case, I simply don't see us transitioning to IPv6. Our main service has an IPv4-only address and we receive 0 complaints about it. We've literally never had anyone say they couldn't connect to our services because of it. Our users are geographically located in the central US, and everybody has IPv4s. Maybe they have an IPv6 as well, but if we went v6-only I can basically guarantee that we'd have users screaming at us. We'd probably have lawsuits over it. But going v4-only, not a peep.
Oh, you mean like IPv4-mapped Address (::ffff:0:0/96) as defined in RFC 4291 § 2.2.5, or NAT64 (64:ff9b::/96) as per RFC 6050. See also 6to4 in RFC 3056 dating back to 2001.
Your idea is not new.
By using nat46 on ISP's routers.
> By using nat46 on ISP's routers.
I do not understand.
In Ye Olde Times a system would call gethostbyname() and this send out a DNS packet asking for the IP address. Of course DNS record returned would be an A record, which is where your first problem is: A records are fixed at 32-bits (RFC 1035 § 3.4.1). So your first task is to create a new record type and update every DNS server and client to support the longer addresses.
Of course the longer address has to fit into the data structures of the OS you called gethostbyname() from, but gethostbyname() is set to use particular data structures. So now you have to update all the client DNS code to support the new, longer addresses.
Further, gethostbyname() had no way to specify an address type (like if you wanted the IPv4 address(es) or the IPng one(s)):
* https://man.freebsd.org/cgi/man.cgi?query=gethostbyname&manp...
The the returned data structures only allowed for one type of address type, so you either got IPv4 or IPng. So if you wanted to be able to specify the record/address type to query, a new API had to be created.
Luckily the next step, setting up a socket() and connect()ing is less of a burden, because that API already supported different protocols:
* https://man.freebsd.org/cgi/man.cgi?query=socket&manpath=Fre...
But if you have a host that support IPng, but its upstream router does not, how does it support a packet with a longer source address a shorter destination address get through?
Do you send IPv4 packets with embedded IPng packets with-in them to translation relays perhaps? How is this any different IPv6 transition mechanisms like Teredo?
How? People keep claiming this, but I've yet to see a coherent design (either back then or today). Do you think they broke backwards-compatibility _on purpose_? What's the motivation here?
This is not an inherent design flaw and is often brought up in IPv6 threads commonly referred to as the "just add more octets, bro" argument. This comment[0] sums it up well, but I'll leave it here for convenience:
> Fact is you'd run into exactly the same problems as with IPv6. Sure, network-enabled software might be easier to rewrite to support 40-bit IPv4+, but any hardware-accelerated products (routers, switches, network cards, etc.) would still need replacement (just as with IPv6), and you'd still need everyone to be assigned unique IPv4+ addresses in order to communicate with each other (just as with IPv6).
That's not at all what I'm suggesting, I'm saying "two internets" because there are two internets: IPv4 and IPv6. You need two internet stacks on every host to deal with this, hence two internets. If everything in the IPv6 protocol suite was literally identical to IPv4, but just with some extra bytes in every address, there would still be two internets, because they are not mutually compatible.
Saying "two internets" is not a judgement call on whether IPv6 changed too much or is too different. It's just the literal truth. There are two internets, because one can't communicate with the other.
$ ip -4 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
$ ping -6 ipv4.google.com
PING ipv4.google.com(sof04s06-in-f14.1e100.net (64:ff9b::142.251.140.78)) 56 data bytes
64 bytes from 64:ff9b::8efb:8c4e: icmp_seq=1 ttl=55 time=27.9 ms
> If everything in the IPv6 protocol suite was literally identical to IPv4, but just with some extra bytes in every address, because they are not mutually compatible.
This part is true though. v6 is backwards compatible in rather a lot of ways, but v4 isn't forwards compatible, and it's important to note that this comes entirely from the larger address size -- no amount of making v6 more identical to v4 than it already is would make v4 any more compatible with it, unless you undermined the entire point and made the addresses 32 bits.
(Yes, I understand there is no other way for a larger address space to exist that doesn’t have this problem. We are in violent agreement here. But that doesn’t mean there aren’t 2 internets. Let’s call a spade a spade.)
Yes there is: https://www.rfc-editor.org/rfc/rfc4291.html#section-2.5.5.2
>It _was_ possible to create an address space extension that was IPv4 backwards compatible, this option was just not chosen, and now we're still dealing with the dual stack mess.
This was never possible.
What's hard is getting people who should know better to do what they're supposed to do, without playing games. The very fact that there are people who will argue why IPv6 is unnecessary tells us everything we need to know, because occasionally those people are in the path of deployment of something public. They don't write software which works agnostically with IPv6, they don't implement addressing that's stack agnostic, they don't bother taking the extra five minutes to test with IPv6.
Then you have a corporation that requires manager types to have enough "justification" to actually fix whatever Mr.-IPv4-is-good-enough, and because they don't understand that their own phone uses IPv6 all the time, they don't see a "business case" for it.
The title would be longer, but perhaps more accurate, if it were "Getting know-it-alls to stop stubbornly clinging to IPv4-is-good-enough and getting managers to realize that IPv6 is not only inevitable, but ubiquitous, are hard".
This article's conclusion isn't totally off, but in this case it's something that could easily be fixed by having a junior network admin just simply set things up. It's a trivial problem that's probably there because someone thinks they know better.
* We can't not support IPv4.
* IPv6 clients can connect to v4 only hosts.
* Supporting IPv6 is nonzero additional work.
* The cost of v4 addresses is on the order of a deli sandwich.
* (If not greenfield) We have a working v4 system right now and adding v6 support is entirely risk with no benefit.
* (Meant negatively) v6 is substantially different. So we will forever be maintaining two sets of networking stacks that play by different rules.
May I introduce you to my ipv6-only vps
How do I do a guest wifi network with isolation? On ipv4 I just flip a switch and thanks to NATs it just works, always.
With ipv6? First I have to figure out what prefix delegation my ISP gives me. How do I do that? Manually, somehow, and hope it never changes. Already not "ridiculously easy" at the first step.
Oops, turns out I was given a /64. So now what? Please explain this "ridiculously easy" thing to me, thanks.
If ALL customers would get a static /48 and the router provided by ISP wouldn't be industrial waste, you could easily use a different /64 for guest WiFi. (Or even a /56, if for some reason your friend wants to delegate some /64s to VMs running on their notebook.)
But in that case these ISPs wouldn't be able to ask more money for "business" internet services.
I think this is just the result of negligence from IANA or RIRs, these "suggestions" or "best practices" should be mandatory for ISPs and enforced by RIRs.
So it's not easy.
Setting up a VLAN for the first time isn't ridiculously easy, but it's the same whether you are using IPv4 or IPv6.
Is that really the case though? I very much doubt it.
I get a /56. Dynamic configuration mechanisms exist. I literally do not have to anything except flip a switch. My router even supports Prefix Delegation, so a downstream router/access point can do its thing.
It's what AT&T fiber does. Well, they give a /60 to their shitbox, but if you want your own router with a public IP then you're stuck with a single /64 for it at least when doing the "easy" path.
You can get some routers to request multiple IPv6 blocks and then you get the freedom of a whopping 7 subnets but you've also left "ridiculously easy" way, waaaay in the rear view mirror at this point anyway
But I’m with you on prefix delegation sucking. Prefixes change, and that makes all your devices’ addresses change. ULA’s solve this. But then you start asking hard questions like “if I’m going to use a ULA anyway, why even use the GUA addresses?” And the answer is shrug.
I mean, it’s great that you can give real addresses to your devices when you want to host a service on them, but you can always just NAT your ISP-provided prefix to them anyway. You’ll probably want better addresses for them anyway, as those randomly generated host addresses aren’t easy to remember (may as well just start your public addresses at ::1 and increment from there, routing each one to the underlying ULA.)
If you have a static NAT you don't need connection tracking on the router.
OP was saying ipv6 makes it hard to do a guest network if all you get is a /64 from your ISP, but stateful NAT can fix that.
I've been writing software for pay for several decades and do not want IPv6.
Phones use IPv4 and IPv6 and you can switch your phone to IPv6 only in the networking settings, run like that for a month and observe multiple weird and bad behaviors.
I don't want IPv6 for several reasons, it looks like it was written by an alien and it inherently is privacy busting. I know many whose job it is to track people as closely as possibly will object but it's true, IPv6 is mainly only wanted by people whose job it is to track people.
It's just an IP. Worry about browser cookies and phone apps sending tracking IDs, not the randomized and non-persistent IPs they're sending them from.
Yeah, it tells us that the IPv6 standard was invented by retarded monkeys who don't know what they're doing.
(Yeah, yeah, I know, I've heard it before - akshually it's the rest of humanity who is stupid for not switching to IPv6. If only they were enlightened enough to know they need to throw away all their hardware and switch to an untested network stack for no practical benefit!)
My IPv6 connectivity tester at https://ready.chair6.net is still doing its thing, twelve years since https://news.ycombinator.com/item?id=2154124.
Looks like Hacker News has added support in five years since https://news.ycombinator.com/item?id=21382275.
will add a link to your site on the failed domains page.
With IPv4 it's easy to set up a static configuration. With IPv6, the Linux kernel is eager to listen to all sorts of advertisements from the network, and it's hard to say "no, stop, don't ever ever listen to anything except my static configuration".
I can bring up IPv4 networking in a tiny fraction of a second. IPv6 networking sometimes takes seconds to settle down and be reliable.
(I'd be interested in any suggestions for how to improve this.)
net.ipv6.conf.default.accept_dad=0
net.ipv6.conf.default.accept_ra=0
net.ipv6.conf.default.autoconf=0
sysctl -w net.ipv6.conf.default.accept_dad=0
sysctl -w net.ipv6.conf.default.accept_ra=0
sysctl -w net.ipv6.conf.default.autoconf=0
[Network]
IPv6AcceptRA=false
IPv6DuplicateAddressDetection=0Although I'd also argue that you should prefer automatic config over static in general. RAs can set your default route correctly and you can use `ip token` if you really need SLAAC to give you a specific address. I think it's better to be able to just connect machines and have them get the right config rather than need to hand-craft it on each one.
In this case I'm bringing up virtual machines, as fast as possible, and static is inherently faster and more predictable. Automatic configuration isn't compatible with literally counting milliseconds.
LinkLocalAddressing=no
sysctl -w net.ipv6.conf.default.addr_gen_mode=1What if you have multiple internet connections and you want to choose which one you go through? With ipv4 and nat you can just change the default route. And you don't even need to write down the router's address since it's <your prefix for the whole network> dot one number.
(I appreciate the confirmation of those settings, though, and those are all an important part of the setup.)
If anything, IPv4 is much harder. The Internet is in an abusive relationship with NAT, thinking it's normal.
But we're in a world where if a service breaks IPv4, they lose a very large set of their customers and it's the service's fault. If they break IPv6, it's is perceived that if any customer fails to connect, then it's the customer's fault (or their ISPs fault).
I'm also convinced that the length of IPv6 addresses and the difficulty in typing them is a major reason for lack of adoption. Very seemingly small UX annoyances can have a large effect.
I've been convinced of this since around 2000. Every network utility dealing with IPv4 had... dotted quad addresses. You could remember them, you could read them, you could speak them to someone else. Brainwise, we can remember 3-5 things - segments, digits, etc. Remembering more is harder for the average person.
Having the 6 be literally dotted sextant(?) - 5.73.192.168.0.4 for example - would have been much much much easier to transition in to, and would have given us 64k x 4 billion addresses. Yes, it's not the near infinity we have with IPv6, where apparently every molecule in the universe can have multiple IP addresses or whatever the max number is. But it would have been much much easier to transition. 27 years later we're not transitioned from ipv4, and we've got another 27 years of dotted quad baked in to daily usage everywhere.
Part of this would just be transitory, but... would take up far less space. Even as late as last year, I'm reading stories about BGP issues and slowdowns because routing tables are too large/many for the hardware. In 2024. How on earth was this expected to work on hardware from 1999?
But even if they had the counter argument to "128 bit addresses are too long, 48 bit would have been better" is obviously not "that's the same thing just with 48 bit addresses!"
No, it wouldn't have taken 'exactly as much work to transition'. See another reply. In 2024, I'm still reading about BGP/routing table issues, and hardware having problems keeping up with IPv6 networking - it's just too large. How was this supposed to work in 1999?
A smaller stepped transition from 4 billion addresses to... 64k of those would have been an easier transition step, and the ease - mental, UI, training, testing, security, etc would have given everyone involved the confidence and positive feedback to tackle a next stage to IPv6 (eventually).
Actually mDNS does exactly what they said just fine. You’re confusing it with the ability of a DHCP server to make updates in DNS on behalf of clients. There is more than one way to skin the cat. Both achieve the same affect, just differently.
> nor do they necessarily ever consider your local DNS server.
Hardcoded DNS servers are just as equally a thing with IPv4.
Of course, but they aren't the baseline expectation like it is with ipv6 since ipv6 baseline assumption is SLAAC. And SLAAC is terrible. If you control all the devices on the network, like a cloud install, you can just pretend SLAAC doesn't exist and live in a much better world.
If it's a home network then you're stuck expecting at least some usage of SLAAC. And you're better off just not supporting ipv6 at all at that point
Rather, most routers add DHCP hostname requests to the local DNS routes. That doesn't require mDNS, nor would you want to replace it with mDNS as mDNS is more limited & flakier.
Things like RA and NDP would clue hosts into the local DNS server as well. You don't need DHCPv6 to advertise a local DNS server.
Indeed. I meant that if evaluating the two de novo, IPv4+NAT is harder.
Then there are crimes against network protocols like NAT66 that are borderline necessary in some situations because terrible ISPs have decided to dynamically alter IPv6 prefixes so they can charge extra for a static prefix.
I still think NAT makes everything harder than it should be, but I get why some people struggle with IPv6 if their ISP is particularly terrible.
Everyone should bomb Android bug reports with complaints about lack of DHCPv6 until they fix it. Then people can de-facto deprecate SLAAC. AFAIK Android is the only major offender here.
Some corporate networks already don't do SLAAC if they don't need Android to work on them.
Possibly, but I think it's also that some aspects of IPv6 are just badly designed, and subsequent updates only fixed some of the issues.
SLAAC, for example, is godawful stupid. And while DHCPv6 exists to fix some of that, critical aspects of the protocol, like prefix delegation, are manually configured. This is beyond idiotic and makes things like subnets massively more difficult than they have any right to be.
SLAAC and PD combine to create the worst sin of all - flakiness. It's hard to figure out why IPv6 isn't working because everything is telling you it is (it "auto configured" a valid IP despite not having any actual route to anywhere else, so helpful! /s). If IPv6 was literally just "IPv4 but 128-bit addresses instead of 32-bit ones" it almost certainly would have been adopted en masse by now. But it isn't, it made things more fragile and harder to configure for no goddamn reason.
And of course you then have ISPs doing silly stuff, like my ISP only gives me a /64 so I literally can't use IPv6 on my network since I want VLAN isolation. 18446744073709551615 possible addresses are given to me yet dividing that up into 3-5 subnets is completely impossible. Fucking stupid protocol.
The core of V6 -- longer IPs -- is great. SLAAC and /64 being the smallest need to be deprecated. It's asinine.
Really absolutely everything but longer IPs should be deprecated and was a mistake.
Although https://www.rfc-editor.org/rfc/rfc7217 doesn't require a /64 or shorter prefix for its variant of address auto-configuration, for example Linux doesn't allow otherwise.
Heck, I would have probably simply added an Options flag for "long address" to support longer addresses. With the first part of the address being the IPv4 address of some ISP backbone router and the next 3 words being a device address on the network (with the all-0 device address reserved for the router itself). Then you don't even need to upgrade most of the routers beyond configuring them to accept packets with that option set. It would have been so simple and elegant and we would have probably upgraded most of the world by 2001.
The quantity of existing deployments that need to change is much larger for v6 than it was for v4. The problem with deploying v6 isn't that it's too different from v4, the problem is that it's different at all. Your v7 will have the same problems.
Last time I've checked, some telecoms such as Vodafone didn't even supported IPv6 yet.
b2b telecoms as a consequence also have at best zero incentive since if the consumer doesn't have ipv6, businesses don't need or want ipv6.
the solution here, which will inevitably strike a nerve with some, is to have a regulatory mandate for ipv6. a soft version would start with 'government networks must run exclusively on ipv6, this applies to any and all contractors, including govclouds' and work upwards from there. I understand such policies were in place or at least planned; OTOH in the current political climate it'll be sort of a miracle if the existing ipv4 networks keep working.
I spent a decade writing element management systems. An element is a network device - switch, router, ROADM, etc. Often you give the customer kit & software and they spend a couple of years assessing it. This software would be installed on secure out of band networks with no route to the internet. 10/8 would have been adequate for the lifetime of the hardware currently in service - 200G stuff. However, that's not how things played out.
When I started working on EMS software IPv6 support was a requirement but it was just a box ticking exercise. No one was actually going to use it. A decade later IPv6 HAD to work for northbound and southbound traffic, on an internal network. Otherwise, no sale. IPv6 is being used in anger in telecoms. I have no idea how long that will take to filter to in band networks.
Not entirely true. 10/8 is only so big, so the management of addresses very much has a nonzero opex cost.
And on top of that there's capex on "carrier grade NAT".
For the biggest providers 10/8 is not even big enough for their production environment. And then they acquire some some company that (obviously) also uses 10/8.
No, there's definitely incentive there. Just… not enough.
I don't think this is true. The IPv4 address exhaustion is still a problem and it's getting worse, and telecoms which also provide internet services need to allocate addresses to their clients. With the 5G rollout these telecoms need to make room for new devices, and that's not feasible with IPv4.
This is dependent on the firewall features of the NAT router, but at least its something, and the router provides one centralized point of protection from interent traffic.
In IPv6 typically every machine on a LAN is directly connected to the internet with a public IP address. Every one of those machines now needs a full strength internet firewall.
This complicates some intra-LAN communications, and removes the feature of having the LAN be a walled garden, mostly isolated from the interent.
Which is, coincidentally, exactly how it works if your LAN is made up of devices with publicly-routable IPv4 addresses as well, which happens in business/academic/military networks all the time.
They just want to watch some reels.
No they don't.
Most ISP boxes only implement the bare minimum of functions to make sure that youtube is available to the users. Which includes NAT, because otherwise youtube does not work, and does not include anything else.
Is that a real, full firewall? Heck no, I'm equally worried about what my systems leak than outside threats, and it does nothing for that.
but aren't we nitpicking a little here? veering on the "technically correct, worst kind of correct".
Yes, but that's because it's co-located with a stateful firewall, sharing the same connection tracking state. Without that firewall, if a device on the WAN side sends to your router a packet with destination address on the LAN side, your router will route that packet to the LAN, even though it's not a reply to anything sent from the LAN to the WAN. That is: it's a misconception that port mapping NAT blocks incoming connections; port mapping NAT only affects outgoing connections and replies to them.
But it is. Even a "full" firewall can't do anything against something on one of the inner host leaking into the outside. Most of the traffic is encrypted, even DNS. So the firewall can't operate on much more than the destination address to decide if a connection should be allowed.
If you want more security, you need to secure individual endpoints.
A system that can't track connection state, or doesn't have enough capacity to do so at line rate, can't meaningfully firewall. When the norm for home equipment is ISPs sending it out for "free", they absolutely send out the cheapest stuff they can get away with, and in the pre-smartphone era that meant "modems" that would just provide a straight PPPoA connection with no firewalling.
Pretty much everything else in a firewall in the modern world is just useless feature creep.
Note that curl itself also implements Happy Eyeballs if you don't force a particular protocol via `-4` or `-6`. You can see it in action with `curl -vvvv https://opentalk.mailbox.org`. So you shouldn't look at the author's example and extrapolate that `curl github.com` or `curl opentalk.mailbox.org` will fail in an IPv6 environment.
It's entirely a different thing for home users which get handed some shitty router from the only ISP around.
My options are cable or long-distance ADSL. The cable ISP has dynamic prefix, so I get a new prefix every week or so. If you contact them regarding IPv6 there's zero support, I had to find the prefix length by trial and error.
So much software relies on the prefix being fixed, so this can lead to a lot of frustration. On the bright side I actually get a prefix, some just get a /64.
IPv6 might not be hard, but using IPv6 might indeed be hard.
what's the difference?
I've posted here before about my home network with two internet connections. Not going to whine about it again, except restate that i basically have no idea what to do about it with ipv6.
https://github.com/systemd/systemd/pull/34165
So you can do.
RefuseRecordTypes=AAAA
So there, your DNS won't ever query for IPv6 AAAA records.
(in fact you can refuse any DNS questions like MX, SRV, TXT as well with:
RefuseRecordTypes=MX SRV TXT)
Note - I started adding that feature because some applications were "misbehaving" and querying AAAA records when IPv6 stack was disabled.
For example, if you want to do multi-homing with IPv6 for an SMB, you need to either do NAT (not great), or have your router advertise/whithdraw prefixes dynamically. If you do the prefix withdrawal, you can end up in a situation where your devices have _no_ prefixes. So even your internal functionality like printing or VoIP starts breaking.
Great.
Then there's ULA that is mis-prioritized. You'd think that simply adding a stable ULA prefix to all devices would solve the issue above, but that's not the case. The devices will prioritize the global IPv6 source address, so stuff can _still_ break.
I have two primary connections that I load balance between, each providing a /56. If either fails, all traffic goes to the other. I have a third connection that is used only as a backup in the event that both the other connections go down, providing a /64.
So simple case, I assign an address from each connection out to each device.
Except, whoops--the backup ISP only provides a /64 and despite that containing something like 18.5 quintillion addresses (a number so large my spell check is telling me it's not a real word), I can't actually split those up in any meaningful way so I can only allow _one_ subnet to access the internet via that connection.
And then I'm pushing responsibility for load balancing between the two primary connections out to each client. You know, to the place with the _least_ useful information for making decisions in this situation. And then I need to figure out how to convince each device to make these decisions individually. (As far as I can tell, with an equal cost, Linux will simply use the most recently added address. So in the event that one of the primary connections is having issues and bouncing up and down, that's going to be the one that all the Linux devices choose to use preferentially. Absolutely what I'd want!)
So I give everything a ULA (which I'd want to do anyway so my internet going down doesn't mean my TV can no longer stream media from the server across the house, since that's a reasonable thing to expect to happen) and then look at doing some sort of prefix translation. Except since nobody's using this stuff because it's so very not hard, I hit a bunch of weird edge cases in my network gear trying to do that. Not the least of which is that I need to statically configure the prefix I'm translating _to_ except that's not provided to me statically so now I need to set up some sort of script to monitor the prefix on the external interface and dynamically update my firewall rules?
Oh, except apparently the RFC was only updated like a year and a half ago to prefer IPv6 ULA addresses over IPv4 so most devices would end up just using IPv4 anyway and the IPv6 deployment would be little more than a box checking exercise until everything's updated. (Though it looks like that change may never have been adopted anyway?)
Last time I was digging in to this, I ended up down a path of starting to file forms with IANA to get a IPv6 block directly allocated so I could use a GUA internally (avoiding the preference issue), do prefix translation for load balancing, and announce the IP range from AWS and tunnel it to my router to work around the /64 issue on the backup connection.
Or, or, or... hear me out... I can just... _not_. Nothing is broken right now. I derive no personal value or enjoyment from stacking up a house of cards I'll have to keep standing back up so my toaster can have a globally reachable internet address.
People can tell me it's "not hard" all they want, but after... oh hell, 30 years of bending computers and networks to my will, I feel pretty confident in saying either:
1. It is hard; or
2. IPv6 is fundamentally unfit for purpose.
Sometime around 2035.
NAT sounds like a bad idea at first glance, but it doesn’t exist just to alleviate address shortages (although it does.) It doesn’t just exist to provide security by default either (although it does that too.)
NAT is also the only sane choice in residential setups. Because your public IP address prefix isn’t static. That was never going to happen. And just saying “never put an IP address in any configuration file” isn’t a satisfactory answer. When a reprefix happens, and your clients are all only speaking on GUA addresses, your network is going to be fucked until they expire the old addresses. Not in theory, in practice. None of my devices in my household did any sort of reasonable thing when Comcast changes my prefix. I had to just go around and reboot everything.
NAT means I am in 100% control over what IP addresses I configure in my own network. It means I can actually run a DNS server and it works. It means I can configure devices with static addresses and it actually works.
ULA isn’t some edge case, it’s the only sane option in residential setups. (You know, that thing you need to maximally support in order for ipv6 to have a chance in hell at succeeding.)
The IETF finally releasing guidance that ULA’s should be on equal footing to GUA’s feels like them finally admitting that there might be something to this whole NAT thing. It happened entirely too late IMO.
With IPv4 and NAT, I'm setting up a network. I control it from end-to-end. I can define whatever subnets I want, connect them how I want, put a static IP on my IoT device so Home Assistant can find them reliably, etc. Then I have _a_ point (well, three) where my network touches another network and all configuration and setup around how the two interface and interact is defined and controlled there.
With IPv6 the expectation is I'm building out another little piece of someone else's network. Now all the communication within my network is closely intertwined with theirs. There's really no good way for me to handle that today.
Using SLAAC so devices update when prefixes change leaves me unable to find/connect to anything. Short of installing a DDNS client on my air quality monitor somehow, how do I manage to connect to it?
I can use DHCP6 (not on Android though!) and let the server handle DNS registrations. This would also regain the ability to push a NTP server to clients which would be a nice thing to have. Except now when the prefix changes the devices have no way to know and (like you say) I have to run around and reboot everything.
And this still doesn't give me a path to load balancing across multiple connections!
I guess really the bigger issue here is the dynamic nature of the prefixes. If I could go log into IANA and click a button and get assigned a /48 then log in to my ISPs' sites and attach it to my connection and be on my way... I'd deploy it today, no problem.
I can't see any _technical_ reason that wouldn't be possible. But there isn't a snowball's chance in hell any ISP starts offering that ability on consumer connections when they could be gating it behind having a $5k/mo business connection.
Yes, this right here. It should work like a phone number where you can take it from provider to provider. You setup your gateway with your IPv6 prefix and then go.
Problem is all the technical and non-technical stuff to actually make that work.
- Verifying ownership of the prefix (rPKI or IRRs) and which ASNs are allowed to advertise it.
- Limiting allocations to someone? I guess phones solve this with SIMs
- Getting your ISP to route the traffic to your device
- Getting the device to announce it with RAs
- Dealing with asymmetric return routing over a slow "path" since it could be multi-homed
- Dealing with routing aggregation since IPv6 routing tables would explode with all the /56s in there
Maybe bring back Mobile IPv6? https://en.wikipedia.org/wiki/Mobile_IP
Because the other issue if you’re ULA-less is that if your router loses its connection and rescinds its RA (or you just stop the RA daemon, or shut down the router, etc), suddenly you don’t even have LAN connectivity any more because everything will have deleted its routes.
Every additional route and its ASN takes up RAM in nearly _every_ router that has a DFZ (default-free zone) view. This RAM is not cheap, so regional registries are incentivized to keep the number of new registrations down.
For IPv4 there are about 1 million routing entries right now, and for IPv6 about 200k. The IPv6 routing space can reasonably scale by about 5-10x before requiring serious changes in the core routers, but that's just not a lot of entries.
IPv6 just yelled at people and said it wasn’t a problem.
It took me a very long time to figure out how to configure my docker containers on my home server to have global IPv6 addresses. But I did it, and it taught me a lot about IPv6. I would personally prefer for the internet to be IPv6 only. It would make certain things much easier like firewall rules, IP whitelisting, and no more stupid CGNAT.
Would there be much of a security risk if you had a dedicated device on its own network that doesn't actually directly communicate with anything else in your home?
I’d prefer to keep it on but every time I try it I run into a bunch of odd bugs. Silly stuff like GitHub container registry pulls being dialup speeds but docker.io being fine. Disable ipv6 and both at gigabit speeds. Bizarre stuff like that which I just don’t have the time and energy to go spelunking into the mysteries of dual stack to untangle.
(Out of the box opnsense)
afk ghcr uses fastly and docker uses cloudflare.
That doesn't make any sense. 0-9 is base ten while 2^64 is base two.
docker pull ghcr.proxy.orca.toys/kpcyrd/apt-swarm:edge
Should you use this? Well docker's security model is pretty much only https, so it's like using a proxy server from some random hackernews comment for your `curl|sh` needs, without end-to-end encryption.
I wish github would just step up their game, at least for ghcr.io.
Also my key point is 'hard at scale', in contrast to yours 'smaller isps'.
I've lived in Canada for > 20 years in several cities and provinces. I'm telling you that CGNAT is extremely common.
I don't think you have any idea what you're talking about.
For mobile Bell uses 464XLAT. Bell mobility is IPv6 only network, also MPLS free, they are SRv6 early adopters, impressive!
Rogers, Videotron mobile use NAT44 for IPv6. IPv6 is native on Rogers.
The fact is ipv4 is scarce, why wouldn't ISPs NAT their customers? Hardly anyone cares, and that's why they get away with it.
I'm now on Bell Fibe and it's a relief to be reachable again, but who knows how long this lasts. But yes at least Rogers is on IPv6...
For the 90%+ of network clients on-prem that play by the rules you are often supporting both DHCP and SLAAC on IPv6 networks (unless android has figured out DHCP).
Dual WAN redundancy on IPv6 in SMB settings is actually worse relative to a NAT and ipv6.
The subnet size /64 is stupidly large, and the number of available subnets you can easily get annoyingly small from most upstream providers.
Firewall filtering has to be modified or you get weird errors. People don't always like ICMP coming through the firewall.
It's does lots of things differently, but for what? We do prefix delegation with DHCP but can't use DHCP to assign address (we are supposed to use SLAAC) but still need DHCP for lots of other stuff? It's nonsensical - you end up with just way too much garbage.
The privacy extension stuff hits IPv6 hard. You have lots of auto-rotating addresses.
The number of times turning of IPv6 fixes weird glitches / timeouts / stalls etc is still crazy too me.
ATT (massive corp) requires end user devices request /64 subnets one by one - which most end user gear does not support.
Getting static ipv6 IP's (despite claims there are lots of them) is seriously hard from upstream providers in many cases - but IPv4 is trivial by comparison.
The list goes on.
I would have made the subnet size 32 bits. Expanded the network part. Maybe even reduced the overall size - 128 bits feel dumb with /64's as the smallest subnet? Then just go super high interop / overlay to IPv4 with great suggestions so folks could ship ipv6 only stuff (even with on device bridge to ipv4 so outbound interface is ipv6) and no new concepts unless clearly justified.
One thing I hate about it is that they used 64 bits for host which is just absurd. 32 bits or even 16 bits would have been plenty for a single broadcast domain.
I admit it does make the address space look a bit lop-sided, but taking bits away from the host side (where they're being used) and giving them to the network side (where we should already have enough space anyway) wouldn't be a sensible trade.
Setting edge routers to simply drop all ipv6 packets and running only ipv4 works, is simpler, is faster (than dual stack) and easier to troubleshoot.
I don’t have any inheritant issues with IPv6 other than is has failed to make a case for why people like me should bother rolling it out.
To avoid ip-range clashes between customers, traffic inside the hub was IPv6-only, with each customer given their own prefix. Routing permissions were based on group membership, so we had a very easy and secure way to make sure each of our users was only able to reach their own customers, and personnel changes did not require any customer-side changes.
Wouldn't this be true with IPv6 as well, assuming that both companies happened to have chosen some overlapping ranges?
By comparison my company uses the entirety of the private IPv4 space. `docker compose up` often fails because there is no private IP range left that is not directed through the VPN.
curl -6 https://github.com -o /dev/null
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 273k 0 273k 0 0 957k 0 --:--:-- --:--:-- --:--:-- 956kWorking with IPv6 if you are not entitled to switch out every vendor, every piece of hardware, every piece of software that is lacking.. that's the hard part.
In short: reality is hard.
It's a meaningless way of saying "look at me I'm smart." Everything is or is not hard depending on the audience and what it's being compared against. IPv6 is hard compared to Ethernet, but easy compared to managing a mess of NATs to handle V4 networks with conflicting addresses at different locations. All of this is a lot easier than understanding the leading proposed theories of quantum gravity.
I mean even if there is no "Happy Eyeballs", it would still work for end users, no? Unlike `curl`, you don't specify -4 or -6 with browsers. Without HE, wouldn't (shouldn't?) it just try both in sequence?
> HE can have some funny side effects. In a project a connection to a development web server sometimes worked and sometimes didn’t. The solution was quite simple. The customer used a split VPN tunnel. IPv4 was routed via the VPN tunnel and those IPv4 addresses were allowed in the web servers access list. IPv6 was routed via the normal Internet connection and those addresses weren’t allowed.
This following sentence makes no sense, when the author literally said HE help it work when one IP family was broken and the other is not. So why would it work sometimes if IPv6 is consistently broken and IPv4 is not? (I'm not saying it won't happen; just that it shouldn't be "caused by HE" -- HE literally is the solution to this issue in general as the author said themselves!)
No browsers and other clients prefer IPv6 and there would be a rather long timeout till the client falls back and tries IPv4. If it falls back.
> So why would it work sometimes if IPv6 is consistently broken and IPv4 is not? > (I'm not saying it won't happen; just that it shouldn't be "caused by HE" -- HE > literally is the solution to this issue in general as the author said > themselves!)
IPv6 wasn't broken. For HE, an HTTP 403 is a valid connection. TCP handshake works, IPv6 works.
I had another case where the TCP handshake worked, and the browser decided to use IPv6 is good, but then came the TLS handshake, and it failed because PMTUD (Path MTU Discovery) was broken.
Which is why I deactivated IPv6 on almost every device in my network. My main issue is that the router/gateway provided by my ISP does not support DHCPv6 prefix delegation, which causes a couple of issues in my setup.
Sometimes you can try really hard to archive a goal, but when the workarounds to simple problems become new problems, it's time to say "no".
Amen - replace IPv6 in the above aphorism with $anything, and it's a great rule for running projects.
Asking for a friend, like, what all the ipv6 use in the world is.
I'm curious. On the other side of CGNAT, you know, the mobiles, can they individually address each other, or can they only talk to each other through the CGNAT? I honestly don't know.