#IPv6 was defined in RFC1883 in December of 1995.
That's right, IPv6 is now *30* frickin' years old. I've spent at least 25 of those yelling at people, companies, service providers, and many engineers who really should know better that they need to enable it.
Doesn't look like 2026 is going to change that. Le sigh.
@jschauma I think one of the things hindering adoption is the lack of support in the prosumer/smb world
...and the hatred/purism against NAT/NPTv6 makes it basically impossible to use if you want to have a backup/bonded internet connection and can't do BGP (which is most people)
@jschauma like, I think it's a philosophical difference:
IPv4 will work even if your ISP is pretty much actively hostile to you.
You can plug in your own little network behind NAT and have it pretend to be a normal consumer device or whatever, and everyone is happy.
You can play around with VLANs, nested networks, and whatever else to your heart's content, and for the most part the internet is fine with dual- or triple- NAT.
IPv6 seems to assume that your ISP is willing to BGP peer with your, that you're given a whole /64 for every single VLAN you want to run, that your ISP can see exactly how many devices you're using, etc.
Which makes things a lot less portable and "Plug'n'Play", hindering adoption.
When a supposed security update of docker suddenly started applying NAT to IPv6 traffic our production systems broke in four different ways. We had to scramble to disable NAT again to get things running reliably.
Very often NAT is the problem and IPv6 is the solution. Porting NAT to IPv6 is extremely misguided. When I have deployed IPv6 to my systems the last thing I want is for some software update to reintroduce the problem IPv6 is there to fix.
Dual-homing is a challenge to be addressed. Neither NAT nor BGP is the right solution for that. But I have never seen a real-world scenario where this is what was holding back IPv6 deployment. It should be fixed of course, but I think the first step towards that is to open eyes to what benefit you already get today when doing dual-homing with some IPv6.
RFC 6555 was originally introduced to ensure IPv6 deployment would not be held back by a small percentage of networks with broken configuration. As far as I know this has been supported by all mainstream browsers since around 2010 and has in fact satisfied that purpose.
It can however also be used as a way to do dual-homing. In the simplest form you get internet connectivity from one provider with IPv6 support and one provider with IPv4 support. Just make sure each router is configured to only support one of the protocols and then connect the LAN ports of the two routers together. Then you have dual-homing with much faster failover than provided by BGP and without the connection drops caused by NAT.
In the simplest form this only gives you dual-homing for dual-stack sites. But if you add NAT64 on the internet connection with IPv6 support, then the result is a network with dual-homing even for reaching IPv4-only sites.
I really wish more people would deploy dual-homing that way, as I think it can be more reliable than dual-homing based on BGP or NAT. And if enough people see the advantages of that form of dual-homing, then maybe we can convince software developers that we need to extend it to supporting IPv6 on multiple connections. Currently there are many customers who struggle to find even one ISP with IPv6 support, which might be why dual-homing across two connections with IPv6 has not received enough attention.
IPv6 explicitly supports receiving addresses from multiple providers. There are two parts that are missing in making that truly good dual-homing. Routing needs to take source IP address into account such that outgoing packets are delivered through ISP who assigned that source address. And a successor to RFC 8305 needs to specify that browsers try multiple sockets bound to different local addresses. And of course we need to get support for this in other software and not only browsers.
@kasperd @jschauma of course, if you've already got IPv6 setup without NAT I'm not suggesting you add it randomly...
In the simplest form you get internet connectivity from one provider with IPv6 support and one provider with IPv4 support.
This... doesn't actually allow us to move forward with IPv6?
It just means that you're permanently tied to IPv4 (since if your IPv6 connection fails that is all you have), in which case you might as well just skip the IPv6 part and do IPv4-only (which is what everyone does).
IPv6 explicitly supports receiving addresses from multiple providers.
This is spectacularly broken on a lot of implementations, and I don't actually want each of the devices on my network needing to make individual choices about routing... that decision is best left to the router.
It does allow moving forward with IPv6 - at least compared to the current state of networks that I see. Using RFC 6555 for failover between two internet connections should give you faster and more reliable failover than the other suggested methods.
That means networks which are currently IPv4-only could get the improved reliability from dual-homing with IPv6 on one of their ISPs. That is a step forward. And it puts pressure on IPv4-only ISPs to upgrade - which currently is one of the biggest hurdles for IPv6 deployment.
If this sort of dual-stack-dual-homing gains traction I think support for doing it across multiple connections with IPv6 will also happen. The part which is missing is all client-side, which makes it a much easier to get that part done.
As for where the routing decisions happen, it all depends on how you configure your network. If you have two routers on your LAN, then the decision of which of them to use needs to be made by the client device. If you insist on clients not being allowed to make that decision, then you can buy a router with two WAN ports and let that router make the decisions. Applications don’t need to make any distinction between the two as both will behave the same from an applications point of view.
I just think more people would choose the solution with two routers as it means they can use the routers provided by the ISP and don’t have to buy one separately. Moreover it means the router doesn’t become a single-point-of-failure.
Jan Schaumann
JJTech
kasperd