The problem isn't ipv6 (even with the tons of extra features that ipv6 forces upon you).
One major problem is dual stack. It doubles the workload for very limited benefit. You have all the downsides of making ipv4 work in the first place. You've then got all sorts of messes like NAT66 (ipv6 was supposed to get rid of NAT), a lack of clarity on which patch to use (NPTv6 and NAT66 are two different options for the same problem, a problem which was built into ipv6 in the first place), messy hacks like DNS64
Instead had the approach been ipv6 only from the start, with no dual-stack, having the OS transparently deal with sockets to ipv4 devices by converting to the ipv6 mapped address (:ffff:xxxxxxx), and thus eliminating the need for dual stack from the start, things would have moved far far faster. You'd be able to communicate with ipv6 by using stateful NAT at the edge of your ipv6 network (as you do now at the edge of your RFC1918 network), you could expose services on your ipv6 only devices with natting (as you do now).
You'd still have A and AAAA records, your client having an ipv6 stack could prefer AAAA instead of A, but if it needed to use an A record (or someone just tried to connect to 12.34.56.78) the stack would have gone "ok I'm ipv6 only, I'll connect to :ffff:12.34.56.78" and rely on the network to make it happen.
Throw in things like NPTv6 and 464XLAT from the start (rather than 16+ years in) -- the addons which were created to address the fundamental architectural flaws in ipv6 -- and you'd have had a far smoother transition.
Any solution to the 4->6 transition that assumes that all devices of some class (be it clients, servers, or middleboxes) moved to IPv6 at once is deluded and would not work.
There was no way to make the transition to IPv6 without dual stack. The problem was much more that the precise dual-stack approach was not well thought out, when it should have been a fundamental part of the IPv6 RFC itself.
Any ISP who wishes to move to IPv6 still to this day has to consider how it will handle clients that don't speak IPv6, servers that don't speak IPv6, routers they own that don't speak IPv6, and peers who don't speak IPv6. There is no way to make all of this work without having devices that translate between the two (losing most of the benefits of IPv6 when going through this translation, of course).
When you've spent 10 million dollars or more on a router that doesn't speak IPv6, you don't change it one year later just because a new protocol has come up. That thing is there to stay for 5-10 years, and you just work around it as best you can.
> Any solution to the 4->6 transition that assumes that all devices of some class (be it clients, servers, or middleboxes) moved to IPv6 at once is deluded and would not work.
464xlat allows communication from ipv6 only clients to legacy ipv4 ones without the need for a separate stack on your end device
nat46 allows communication from a legacy v4 device to a modern v6 device without the need for a separate stack on your end device
Had ipv6 transition been thought about better back in the 90s then you could have deployed your new subnets as ipv6 only back in 2005 and still communicate with all your older kit.
> That thing is there to stay for 5-10 years, and you just work around it as best you can.
IPv6 is 30 years old. I sweat assets like there's no tomorrow but the oldest kit I've got active today is less than half that. Even for ipv4 only devices, a single legacy subnet would be reachable from my v6-only management devices via my ipv6 backbone via 464xlat
> 464xlat allows communication from ipv6 only clients to legacy ipv4 ones without the need for a separate stack on your end device
> nat46 allows communication from a legacy v4 device to a modern v6 device without the need for a separate stack on your end device
How does that work if your ISP doesn't support IPv6? Can an OS developer deliver IPv6-only OSs to any end user? How about v4-only VPNs? Ultimately the answer is that devices must support both IPv4 and v6 until the day only one remains. Keeping both active at the same time may be more optional, but there is plenty of software which assumes IPv4 at other layers than simple connectivity. So running IPv6-only is generally a bad idea even today.
This whole discussion was about what should have been done differently at the start of the IPv6 rollout to help it complete in less than a lifetime, not about the situation some decades in.
But that's what I mean: lots of ISPs have supported IPv6 for 1-2 decades. Most hardware & software already supported it a decade ago, and nobody should be using anything that old without updates. The only reason for an ISP today to not provide it is incompetence.
Two decades ago I was a member of a ISP consumer group, and we discussed it with a couple ISPs back then. They all were working on a planning for it (one smaller ISP even already implemented it back then!). Apparently in other countries ISPs were allowed to behave irresponsibly.
Really, the only way to force such incompetent ISPs out is if governments get involved, or if all/most backbone providers and IX operators set a date where IPv4 will become very expensive, and then one where it will be switched off...
> Instead had the approach been ipv6 only from the start, with no dual-stack, having the OS transparently deal with sockets to ipv4 devices by converting to the ipv6 mapped address (:ffff:xxxxxxx), and thus eliminating the need for dual stack from the start, things would have moved far far faster.
This is, indeed, how dual-stack works; you open a PF_INET6 socket and use sockaddr_in6 addresses for everything, including IPv4 (which get mapped to ::ffff:/96 addresses). Been like that essentially forever. The “dual” in dual stack refers to the OS' stacks, not userspace.
Don't forget you may need to opt in to get mapping to work. It's not available by default on all platforms.
If you're unlucky you'll also have to sacrifice a goat to appease the JVM gods. JVM behaviours vary hugely across implementation, version and underlying platform. Not to mention the short sighted decision made by many sysadmins to disable IPv6 completely...
> The problem isn't ipv6 (even with the tons of extra features that ipv6 forces upon you)
The year is 2023, The chromium engine is full blown operating system, it has notifications, background task management, GPU acceleration for general compute, it's larger than Windows XP, and can in fact run windows XP in the browser. Teams consumes 500 mb of ram to do the same job ICQ did in 2002 with 5 mb of ram. Cars have 4G, lightbulbs need updates and security patches.
But Ipv6 features take a few extra bytes and are a problem.
> But Ipv6 features take a few extra bytes and are a problem.
Some people pay for each extra byte they have to send through a network, and design whole systems around the goal of minimizing the amount of data they ship around.
No one pays for the extra free gigabyte that Chrome takes over.
> No one pays for the extra free gigabyte that Chrome takes over.
Sure they do. It just doesn’t show up in Chrome’s metrics so Chrome doesn’t care about it.
* Start-up time of other applications. If a program needs 1 GB of RAM, and Chrome is holding all but 512 MB, then the program must perform multiple allocations, waiting for Chrome to release its cache after each one.
* Smaller cache in other programs. Consider a program that can run with 4 MB of RAM, but could use up to 1 GB of RAM to cache intermediate results and improve performance. Such a program would check the amount of RAM available and scale their own cache size accordingly.
* Competing caches in multiple Chrome instances. Multiple independent Chrome instances, such as from Electron shells, each try to cache as much as possible until RAM is exhausted.
In fact some of the earliest adopters of IPv6 were Google, Microsoft, Netflix. Companies who when you're considering the problem of (N * a few bytes) have a very large N so are the most likely to have material costs from it. Yet even to them, it's a rounding error.
For Netflix the cost is actually especially low. Cost as a percent of bandwidth is (a few bytes / packet size), and when you're streaming enormous media files packets are almost always max size.
The user pays for it or suffers the consequences. Anyone relying on such bloated browsers has externalised the cost for coming up with a resource efficient alternative to their users.
You say ipv6 was supposed to get rid of NAT. Can you explain why it doesn't? You then say the problem was built into ipv6 from the start.
From looking it up it looks like it's mostly required when IP's change (e.g. when you change ISP), which for me is more of an argument to use DNS if you want fixed addresses.
One reason could be the proliferation of prefix delegation, meaning an ISP now controls the numbering of your internal network, and it keeps constantly changing the net block, so you can never get stable local addressing… so you just keep running dual stack or try to use nat66 with a ULA network as a kludge or something.
You can have multiple IPv6 addresses on your interface, so you can have both the ULA address for internal use as well as the global address - no need for NAT
However, the priority order on your OS for address selection, even when it comes to stuff like choosing which DNS results to use is IPv6 global address > IPv4 > ULAs. So on a dual stack network, ULAs with not be used unless the only address is a ULA.
And even if you run your internal services with only an AAAA record pointing to the ULA, the client's source address will likely be the global address of the client device unless you tweak the tables on each client, which then means you'll need to have your global address in all your firewall rules to access the internal services on ULAs, which then means you're not saved from having your ISP-provided global address in your configuration, which is what you were trying to avoid by using ULAs.
The problems this caused/s seems to have been an unintended / unforeseen consequence that was more exposed as people gained experience. There's a draft being worked on to officially change the priority:
> The behavior of ULA addressing as defined by [RFC6724] is preferred below legacy IPv4 addressing, thus rendering ULA IPv6 deployment functionally unusable in IPv4 / IPv6 dual-stacked environments. The lack of a consistent and supportable way to manipulate this behavior, across all platforms and at scale is counter to the operational behavior of GUA IPv6 addressing on nearly all modern operating systems that leverage a preference model based on [RFC6724].
Leaving aside that the draft is badly worded (there are long descriptions of the problem, but no short paragraph saying what must be changed), the long time until this is deployed if ever, the new order will still leave ULA below IPv6 global addresses - which means it doesn't solve stock_toaster's problem at all.
The only in theory clean alternative to the kludges you mentioned is to let DHCPv6 renumber your network automatically which is a major change in how you have to think about your network.
The existence of NAT66 and NPTv6 are proof that there is still a need for NAT in an ipv6 environment. Maybe not in your environment, but people wouldn't make these solutions if there wasn't a need.
Would you rather have a bunch of routers sending out advertisements which every client needs to sort out, or have one consistent multi wan load balancing/failover policy that is transparent to clients?
IPv6 purists think that you can simple have multiple IP addresses on each client, all configured magically, and reconfigured transparently when your ISP changes, with every device somehow knowing via some form of policy deployment (perhaps via dhcpv6) which network to use for a given flow.
That's so much simpler than simple src-natting your clients at the edge of your control and routing your outgoing traffic based on a policy at your natting device /s
There's certainly a requirement for them, but it would be good to know what the justification of that requirement was before we know if there's a need. E.g. the justification could be "our SOPs say all network traffic must go through NAT", and if you dig deeper you might find that the SOP was written to save money on IPv4 addresses. That would not indicate a fundamental need.
NAT works well as an ultra simple firewall. All those ancient IoT devices don’t need to accept traffic from arbitrary addresses, but they may need to communicate with the outside world.
Using a firewall is obviously an option, but why give an IP to something you don’t want accessible by the outside world?
There's something that works even better as an ultra simple firewall: An ultra simple firewall!
> why give an IP to something you don’t want accessible by the outside world?
- You might change your mind about it needing to be accessible by the outside world, and if it already has a global address you don't need to renumber everything.
- Addressing and routing aren't the same thing; it can be useful to have globally unique addressing even without global reachability.
Ultra simple firewalls that expose your internal network architecture are less secure than NAT. You simply cannot information about your internal network without risk and there’s zero direct benefit for doing so.
I don't think this is a useful thing to say. If I keep trying to fill up my electric car with petrol, and get so annoyed that it keeps spilling on the floor that I pay someone to install a petrol cap and fuel tank, it would be equally silly to say that electric cars failed in their mission to get rid of petrol use.
One major problem is dual stack. It doubles the workload for very limited benefit. You have all the downsides of making ipv4 work in the first place. You've then got all sorts of messes like NAT66 (ipv6 was supposed to get rid of NAT), a lack of clarity on which patch to use (NPTv6 and NAT66 are two different options for the same problem, a problem which was built into ipv6 in the first place), messy hacks like DNS64
Instead had the approach been ipv6 only from the start, with no dual-stack, having the OS transparently deal with sockets to ipv4 devices by converting to the ipv6 mapped address (:ffff:xxxxxxx), and thus eliminating the need for dual stack from the start, things would have moved far far faster. You'd be able to communicate with ipv6 by using stateful NAT at the edge of your ipv6 network (as you do now at the edge of your RFC1918 network), you could expose services on your ipv6 only devices with natting (as you do now).
You'd still have A and AAAA records, your client having an ipv6 stack could prefer AAAA instead of A, but if it needed to use an A record (or someone just tried to connect to 12.34.56.78) the stack would have gone "ok I'm ipv6 only, I'll connect to :ffff:12.34.56.78" and rely on the network to make it happen.
Throw in things like NPTv6 and 464XLAT from the start (rather than 16+ years in) -- the addons which were created to address the fundamental architectural flaws in ipv6 -- and you'd have had a far smoother transition.