The Next Chapter in IPv6 Multihoming Saga

Remember the IPv6 elephant in the room – the inability to do small-site multihoming without NAT (well, NPT66)? IPv6 is old enough to buy its own beer, but the elephant is still hogging the room. Tons of ideas have been thrown around in IETF (mostly based on source address selection tricks), but none of that spaghetti stuck to the wall.

A new draft by Jen Linkova and Massimiliano Stucchi tries to solve at least some aspects of this problem with conditional RA functionality: the lifetime of a PA IPv6 prefix is adjusted based on the status of the corresponding uplink.

Interestingly, I was musing along those same lines in 2010 but had to conclude the approach is impractical due to inability to deprecate an IPv6 prefix through RA. The new draft (if widely implemented in routers and hosts, which could take years) could solve that problem, finally resulting in reasonable IPv6 multihoming options.

New to IPv6?

The IPv6 webinars on ipSpace.net are still pretty relevant (yeah, nothing much has changed in the meantime).

Latest blog posts in Site and Host Multihoming series

More blog posts in this series

Recent posts in the same categories

9 comments:

  1. Anonymous 11 April 2018 12:50
    Failover based on RA, how great is that. RFC 1925 has struck once again. What will be next?
  2. Anonymous 11 April 2018 13:39
    Multipath TCP is the right approach to solve multihoming problems from an architectural viewpoint. We should stop having single path transport protocols whose connections are bound to one particular IP address.
    Replies
    1. Anonymous 11 April 2018 14:25
      Hi namesake. I think you don't unterstand the problem described in this post. You would get 2 PA address ranges because you were multihomed but you don't run BGP with your service providers. Instead you run DHCPv6 PD with them. So your servers would get 2 IPv6 addresses from every prefix. So the one billion dollar question is now how do you deal with a failure between you and and your service provider with that scenario?
  3. Prasanna 12 April 2018 07:10
    I was wondering why enterprise cant have dedicated block of IPv6 address and ISP's route the traffic to it. Enterprise shall select the ISP's based on the routing and preferences configured? If any looping has to be avoided then EVPN kind of solution can be used?
    Replies
    1. Anonymous 12 May 2018 16:36
      1) do we really want to have /48 in global routing table for every coffee shop or 10-people office?
      2) some small companies have no resources and no desire to deal with RIRs and become LIRs (and it expensive).
      3) In some scenarios ISPs might not want/be able to run BGP with those customers.
  4. Anonymous 12 May 2018 16:33
    Well, the key point is it does not need to be implemented on hosts. Everything hosts need is already here (the whole idea of that draft was not to rely on the Rule 5.5 which is not yet supported by some popular OSes). For router support...well, we are getting there as at least one vendor has had the corresponding feature request opened for years...but the good news is: some very popular vendors support automation which allows the config to be changed based on events. So it can be done right here, right now, no need to wait for anything to be implemented...;)
    Jen L.
    Replies
    1. Ivan Pepelnjak 12 May 2018 17:16
      Hi Jen, really nice to hear from you (big fan of your work!).

      "some very popular vendors support automation which allows the config to be changed based on events" << assuming you can run the code on the same device.

      I believed in the magic powers of adaptability, flexibility and automation years ago and designed my home network around that... only to get phone calls along the lines of "Daddy, I can't print the photos I need for my homework" every time I'd be somewhere far off ;) Now it's as simple as I can possibly make it ;))
    2. Anonymous 13 May 2018 18:30
      >>""some very popular vendors support automation which allows the config to be changed based on events"

      >assuming you can run the code on the same device.

      Well, I'm talking here about things like JunOS event policies/even scripts. So yes, they are run on the devices.

      >I believed in the magic powers of adaptability, flexibility and automation years ago and designed my home network around that... only to get phone calls along the lines of "Daddy, I can't print the photos I need for my homework" every time I'd be somewhere far off ;) Now it's as simple as I can possibly make it ;))

      LOL ;) You know the most interesting thing about all that? (and it also answers the very first comment about 'OMG, it's too complicated, whet's next'...) This functionality *already* here for small CPEs. When I first realized I need in in enterprise network, the answer I got was 'get rid of expensive Junipers and Cisco, get TPLink with OpenWRT on it, it would do that'. So if we are talking about home network - you don't need to think about it, it's here (thanks to RFC7084). It's all about bringing it to enterprise grade boxes.
      I'm talking about it this Thu, at IPv6 WG at RIPE btw.
      / Jen
    3. Ivan Pepelnjak 13 May 2018 20:07
      "I'm talking about it this Thu, at IPv6 WG at RIPE btw." << and I'd love to be there, but unfortunately work calls...
Add comment
Home
Sidebar