alt Hacker NewsIn any scenario where you want to do traffic steering at a network level. Managing multiple network upstreams (e.g. for network failover or load balancing) is a common example that is served well by numerous off-the-shelf routers with IPv4. That's an important feature that IPv6 cannot offer without using NPTv6 or NAT66.
It's conceivable that OSes could support some sort of traffic steering mechanism where the network distributes policy in some sort of dynamic way? But that also sounds fragile and you (i.e. the network operator) still have to cope with the long tail of devices that will never support such a mechanism.
> Managing multiple network upstreams (e.g. for network failover or load balancing) is a common example ... that IPv6 cannot offer without using NPTv6 or NAT66.
I don't think that's true. I haven't had reason to do edge router failover, but I am familiar with the concepts and also with anycast/multihoming... so do make sure to cross-check what I'm saying here with known-good information.
My claim is that the scenario you describe is superior in the non-NATted IPv6 world to that of the NATted IPv4 world. Let's consider the scenario you describe in the IPv4-only world. Assume you're providing a typical "one global IP shared with a number of LAN hosts via IPv4 NAT". When one uplink dies, the following happens:
* You fail over to your backup link
* This changes your external IP address
* Because you're doing NAT, and DHCP generally has no way to talk back to hosts after the initial negotiation you have no way to alert hosts of the change in external IP address
* Depending on your NAT box configuration, existing client connections either die a slow and painful death, or -ideally- they get abruptly RESET and the hosts reestablish them
Now consider the situation with IPv6. When one uplink dies:
* You fail over to your backup link
* This changes your external prefix
* Your router announces the prefix change by announcing the new prefix and also that the now-dead one's valid lifetime is 0 seconds [0]
* Hosts react to the change by reconfiguring via SLAAC and/or DHCPv6, depending on the settings in the RA
* Existing client connections are still dead, [1] but the host gets to know that their global IP address has changed and has a chance to take action, rather than being entirely unaware
Assuming that I haven't screwed up any of the details, I think that's what happens. Of course, if you have provider-independent addresses [2] assigned to your site, then maybe none of that matters and you "just" fail over without much trouble?
[0] I think this is known as "deprecating" the prefix
[1] I think whether they die slow or fast depends on how the router is configured
[2] ...whether IPv4 or IPv6...