Well, RFC 7157 explains in sections 3.3 and 4.1 why it doesn't work "just fine". It proposes solutions which must be implemented on IPv6 endpoints. Until that happens IPv6 multi-homing is WIP (work in progress) and not ready for production.
The only issue is really the 4.1: end-to-end transparency for things like SIP or interactive games etc. I don't buy the section 3.3 issues for typical multihoming using NPT. Basically the router decides which prefix to use regardless of what the host uses. Since it's 1:1 this doesn't break end to end communications, but it does break the transparency since the end-host doesn't know what globally routed IPv6 it's really using.
Yes, a work in progress, but today with NPT you can multihome and it will work better than normal ipv4 which is just broken and has been for decades.
I'd agree the state of IPv6 multihoming is indeed... complicated still today.
Without Provider Independent (PI) Address Space and BGP the options of how you can implement it from a general consumer point of view are somewhat still experimental with a wide range of opinions on if doing X scenario is actually "right". Most of the IETF stuff I've seen is old, draft or experimental.
Mention NAT and IPv6 together around some people and they'll want to set you on fire, but then they probably haven't tried Multihoming IPv6 without it.
Here's an interesting video from the IETF perspective on it: https://www.youtube.com/watch?v=90y3ekF41FI, it is a few years old now though.
1 Like
IPv4 endpoints understand RFC 1918, are aware of address translation and and able to figure out and handle changes of the outside address for decades now. OTOH IPv6 renumbering has been designed during the 1990s for corporate networks, when nobody thought about dynamically assigned IPv6 prefixes for end users at all (as in: end users get their /64 on their Window 95 machine, the only connected device they are ever going to own and never bother with routing ever).
In fact people deploying OpenWrt routers everywhere wasn't even thought about. So prefix delegation was an afterthought figured out later including which prefix length to choose for standard ISP service (we dialed in on /56 rather late).
Dual stack operation (now the norm) was intended as a quick (less than a year) transition period, not a something lasting decades. It comes with its own set of problems including possibly degrading connectivity by enabling it under certain circumstances.
Overall the decades old design of the IPv6 protocol suite is completely outdated, made for a world which doesn't exist anymore: the pre-mobile, pre-wireless, pre-smartphone era. That's why we now look for crutches working around inherent limitations.
The fact that a end user device like a smartphone is connected to multiple networks (home network, corporate network, mobile network) and constantly roaming between them is something IPv6 was never designed for to handle. The idea that a device gets a globally unique address and the network figures out how to reach it doesn't work at all in practice. In fact, each network assigns its own IP address(es) and then the device has to figure out how to stay connected while the device roams and constantly switches connectivity. It's the same problem this thread is about BTW, just on another level.
I think T-Mobile has shown that IPv6 only with NAT64 on the edge works and works very well, better than dual stack.
1 Like
Well if we accept this, then we have to also say that ipv4 was even more so not designed to handle it. Ipv4 just doesn't work, where "work" is defined as "allowing two endpoints to be able to connect directly to each other". It only works if you are one of the "lords" who own some global ipv4 address space. For the "serfs" who get a CGNAT private IP on their router, and have double NAT, it's crap on a stick with band-aids.
ipv6-only networks with NAT64 are far superior in every way, except that key software that people want to run doesn't work right with it. And I'm looking directly at you game publishers. On mobile, with ipv6 only required in order to get your mobile app listed on the app-stores, it works really well. Android or iOS phones on T-mobile's network just do what they're supposed to.
The worst issues you refer to aren't really protocol inherent, but come mostly down to ISP policy decisions. It's not cast in stone that consumer IPv6 prefixes must be dynamic, there is no technical reason not to assign them statically (while still using DHCPv6-PD) for the duration of the ISP contract or at least semi-statically. ISPs intentionally do this to discourage server use - and sadly many vocal users have jumped onto this bandwagon citing privacy concern (as if regularly changing prefixes would help them hide from advertisers). Likewise BGP or multi-homing could work, if (consumer-) ISPs wouldn't actively work against it.
IPv6 might not be the most beautiful protocol (the worst aspects of it are down to the need of IPv4 coexistence), but it's the only thing we have, now - and which does solve the most pressing issues, while being (mostly-) supported by the already deployed (infrastructure- and consumer-) devices. It's not optional, but pretty essential for anyone having to deal with the fun of cgNAT - and it does do the job (for OpenWrt, computers, smartphones, IoT stuff and more).
Exactly, almost all of the problems are really policy issues that a well written consumer focused law could fix. I've actually started thinking about contacting EFF and asking them what they think about IPv6 policy legislation... ISPs are a huge lobby though.
We all thought 23 years ago, that IPv6 prefixes are going to be assigned statically and all problems with dynamic addresses are solved.
But IP hosts are not bolted down to racks and desks anymore. The digital world changed, and the result is that your prefix is primarily location-based. You move your device from one location to another and your prefix changes, due to the needs of routing. In the end it doesn't even matter if your ISP standard service (SOHO) assigns prefixes dynamically. If you need a location-independent static prefix, you need a tunnel anyway.
So IPv6-in-IPv6 tunneling is the solution to IPv6 multi-homing when you need static prefixes.
2024 update: Still is. Meanwhile I'm multi-homed again with two entirely useless /64 prefixes, because the wise 3GPP defined that as the access standard.
So for now it's NAT4444 (no, I'm not kidding), which works flawlessly though until my remote endpoints run out of IPv4 addresses. I don't care, that's their problem.
Maybe just choose a proper ISP?
IPv6 is well designed protocol.
Ever tried to renumber host/servers with public ipv4? Or stumble upon protocols which just brake apart when confronted with NAT? This is no fun either.
If people don't follow the design guides and principles it's (mostly) not the fault of the protocol itself.
IPv6 eases a lot of things IF implemented correctly.
What defines are "proper" ISP?
Do you understand that the ISP's equipment adheres to the 3GPP standards and is not going to violate them to provide the customer with more prefixes to delegate?
The IPv6 rollout as whole completely failed the design goal of providing end2end connectivity and never will. Outside data centers it was an entirely useless effort.
Doesn't matter as the only relevant protocol left is HTTPS over TCP and everything else being encapsulated in it, including DNS. That works fine with NAT4444 or NAT44444 or whatever it will be in the future, I no longer care.