Lack of IPv6 multihoming: the elephant in the room?

Update (2009-05-13): As Roland Dobbins pointed out in his comment, the strictly hierarchical approach to IPv6 address allocation is no longer valid. Another reader kindly provided me with a link to the RIPE IPv6 Address Allocation policy.

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?

Update (2010-03-12): I've gathered a lot of IPv6-related information in the meantime. You will find an overview of the Service Provider-related IPv6 challenges in my Market trends in Service Provider networks workshop (register for the online webinar). Advanced backbone designs and configurations are explained in the Building IPv6 Service Provider core workshop (register for the online webinar).

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.

On the other hand, the IPv6 address space allocation policies should be strictly hierarchical to reduce the size of the IPv6 routing tables (which is a worthy goal), but this rules out the provider independent (PI) address space needed by multihomed customers.

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.

16 comments:

  1. Do we really need to migrate towards ipv6 especially service provider? I am not able to collect there was some proposed solution where ipv4 depletion issues were raised a new solution was proposed which could save lot of ipv4 addresses.

    ReplyDelete
  2. For multihoming in IPv6 I think we are going to default to what we do now in IPv4. You go get some PI space from RIPE/APNIC/ARIN etc and do BGP with your upstream, hierarchical addressing be dammed.

    ReplyDelete
  3. Yes, you've missed something. It's been possible to get PI IPv6 space for quite some time, and the whole 'hierarchical' business went away quite some time ago.

    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

    ReplyDelete
  4. Amount of hype and lack of production-grade functionality surrounding the whole IPv6 business is staggering. It appears to me that all the goals that IPv6 set from beginning are being scrapped, one by one, as they were all solutions in a search of a problem.

    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.

    ReplyDelete
  5. I am so looking forward to the ipocalypse. As a freelance consultant, I can smell the money! Whoopee!

    ReplyDelete
  6. I somehow suspect that's the exact driving source behind the whole IPv6. In fact, that's the only one that makes sense, come to think of it.

    Oh, God. I want to be telco vendor when I grow up!

    ReplyDelete
  7. I do the old Picard facepalm (google it) when I read these comments. Granted some are fine (I must be talking about yours!) but most are well... facepalm material.

    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.

    ReplyDelete
    Replies
    1. The most exciting feature for the end user is the freedom from the slavery of NAT and port forwarding. Sure, you can use NAT in IPv6 if you want, but dealing with UPnP and all sorts of VPN hacks was so annoying.

      Delete
  8. ^^ I meant "Expanding the address space of IPv4" sorry

    ReplyDelete
  9. I'll bite.

    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.

    ReplyDelete
  10. Sorry, it's 6PE, not 6VPN. Silly me.

    ReplyDelete
  11. I'll bite back.

    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.

    ReplyDelete
    Replies
    1. we don't need DHCP in IPv4 either. For home users DHCP is prevalent only because of NAT in routers. In a simple LAN, the hosts can autoassign everything through zeroconf/mDNS. As far as I understand you need DHCP in PXE booting. So v6 won't help you there.

      Delete
  12. IMHO LDPv6 is in draft only, so it's far away from implementing

    ReplyDelete
  13. I wonder if the whole v6 multihoming issue is a made moot by the introduction of this? http://tools.ietf.org/html/draft-troan-multihoming-without-nat66-01
    BTW does this site have a light markup support like textile. It is kind of annoying using html for comments.

    ReplyDelete
    Replies
    1. That draft might have solved simple cases, but it got nowhere in the last 2 years.

      Delete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.