Published on , commented on March 10, 2023
Lack of IPv6 Multihoming: the Elephant in the Room?
I have to admit I have no hands-on Service Provider IPv6 experience (but then there are not too many people that can claim they do) and I don’t attend RIPE meetings, so I might have a completely wrong impression, but here it is: Is it just my perception or do we really lack any production-grade means of end-user multihoming in IPv6?
Just to make sure we’re on the same page: businesses that care about their continuous presence on the Internet (somewhat close to 100% of large enterprises, I would dare to guess) and use Internet as one of their sales/delivery/support channels usually decide to connect to multiple (at least two) Internet Service Providers. Due to the current state of protocols above layer 3, an end-user that wants true multihoming needs their own chunk of publicly routable IP address space that is advertised to the world via BGP, which would make IPv6 routing tables as bad as their IPv4 counterparts.
The proposed solution to this issue (shim6) uses unique host identifiers over multiple IPv6 addresses, allowing the end-to-end communication to continue even if IPv6 endpoints change. Great idea, but the shim6 working group has not managed to publish a single RFC yet and it looks like there are no production-grade implementations.
I would be delighted if someone could tell me that I’ve missed something, but from my current perspective, we are years away from being able to deploy high-availability IPv6 public networks that we take for granted in the today’s IPv4 Internet.
This produces other issues, which the LISP effort is intended to address (pardon the pun) via locator/EID separation:
http://tools.ietf.org/html/draft-farinacci-lisp-12
Anyone remembers "advanced QoS" that was supposed to be implemented wiyh IPv6? Not to mention the whole aggregation, that is now being scrapped, because people finally noticed the elephant?
Apparently, noone noticed 800-pound gorilla, yet. The one that is not compatible with IPv4 in any reasonable way?
On the other hand, when we started running out of ASN space, we added 2 byes and off we go. Why on earth can't we just do the same thing for IP addresses? Add 4 bytes, expand addresses to 64 bits, let them be compatible with IPv4 (0.0.0.0.A.B.C.D), call it IPv5 and to hell with the whole IPv6 business.
Oh, God. I want to be telco vendor when I grow up!
The PI space is solved. You can get PI space in IPv6. Sure the rules are stricter but that's for a reason - long term scalability. This strictness helps enforce better network design. For the vast majority of cases, the people who *think* they require multihoming should just put their servers in colocation datacentres instead. Even if their precious server only has 1 IP, that IP is extremely reachable through all the different peers the CoLO ISP peers with. Also - the central placement of the server in the colo reduces latency and avails more bandwidth. Not to mention security, power redundancy, environmental conditioning etc.
Also when you think 'outside the square' you'll find that a lot of the layer3 redundancy of PI space is actually solved at the application layer. Mail servers have MX preference values for redundancy. DNS lookups can return multiple A records. HSRP/VRRP/GLBP can work very will in place of BGP multihoming for client PCs.
If we take the breastmilk of PI space away, then the babies will scream for a while, but applications will become smarter to fill the void and people will be forced into better network design.
Onto another issue. Almost everyone seems to think of the expanded address space for IPv6 and somehow thing that's all there is too it. For me that's almost the least exciting aspect. I'm more excited by the simplified 64-bit aligned headers with no unnecessary checksumming, and the stripping out of broadcasts and intermediate router fragmentation, and the usefulness of the flow label.
Expanding the address space of IPv6 is like putting a new coat of paint on an old Ford Pinto. We need to trash that and start driving the luxury vehicles of IPv6.
Luxury vehicles that require us to dump and throw away perfectly operational and working networks that we have been building for decades? Somehow I ain't seeing that. Reminds me of how ATM was there to save the world.
Now, on another note. You mention all sorts of workarounds for the inherent problem with IPv6; basically defending the shortcomings of it, recommending such complex solutions for simple problem of multihoming. The very essence of good networks - simplicity, will be thrown away, just so IPv6 evangelists can live up to the expectations.
Now, I don't want to sound pompeous, inflamatory, or like a troll, but I have been in this industry for about 15 years. I have read and looked at IPv6 for at least 10. It's always just around the corner and aafter each one, we are faced with another obstacle and another IPv4-like workaround for the problems. I just remembered DHCP. The original idea called for no DHCP, because autoconfiguration would take care of that. Then someone with actual operational experience pointed out to thinkers that DHCP is a must. Then we have ugly port of DHCP.
What about MPLS? How does that work with IPv6? Sure, you don't need MPLS, as address space is so huge, there is no need for MPLS VPN's say thinkers. Experienced engineers say "what about traffic separation?". Oh, that. Let's invent 6VPN, but that requires IPv4 infrastructure, because we really don't know how to do label switching for IPv6... and so on.
No, sorry. It's *far* from operational readiness. Far, far, from it.
An IPv4 network close to address allocation exhaustion, held together with a whole bunch of NAT sticky-tape, about to collapse under the weight of its own routing tables (almost 300000 and growing!) whilst happily fragmenting packets and unnecessarily doing checksumming to boot is NOT the essence of a good network.
Now to your criticisms.
DHCP - The autoconfiguration of IPv6 works fine in a lot of instances but there are times when you need DHCP for some setups. So what? The DHCPv6 doesn't seem any better or worse that DHCP for V4 so I don't see the issue.
MPLS. Remember the "M" in MPLS stands for "multiprotocol". MPLS should be able to take IPv6 fine. And IPv6 can but used for next hop reachability (OSPFv3) and also LDP for v6. I suspect what you're describing is a limitation of Cisco and not of IPv6.
BTW does this site have a light markup support like textile. It is kind of annoying using html for comments.
Related to linked posts, and recently updated, so I'm putting this here - hope that is okay.
SCTP allows for multihoming. And I found that SCTP over IPv6 was smooth sailing - see my blog post on this - https://milind.ravindranath.com/sctp-on-the-internet-baby-out-with-the-bathwater/
Yeah, SCTP was a known solution for decades. Unfortunately, it requires application-level changes due to the broken socket API. See: