There’s a Problem with IPv6 Multihoming

In an amazing turn of events, at least one IETF working group recognized we have serious problems with IPv6 multihoming. According to the email Fred Baker sent to a number of relevant IETF working groups:

PI multihoming demonstrably works, but PA multihoming when the upstreams implement BCP 38 filtering requires the deployment of some form of egress routing - source/destination routing in which the traffic using a stated PA source prefix and directed to a remote destination is routed to the provider that allocated the prefix. The IETF currently has no such recommendation, or consensus that it should have.

Here are a few really old blog posts just in case you don’t know what I’m talking about (and make sure you read the comments as well):

After that I mostly gave up and focused on more interesting topics.

Obviously this is very old news, and it’s utterly sad to see a well-known real-life problem being ignored for years while at the same time whole working groups work on hypothetical problems like “how do I create a plug-and-play routed network with a chain of routers that can support thousands of segments in my home” (aka Homenet working group). The only explanations I could come up with are:

  • The problem is hard to solve and definitely not sexy, so nobody is interested in working on it;
  • IPv6-focused engineers working within IETF that have actual operational experience have solved their problems (large-scale enterprise networks, web properties or zillions of residential customers), and are not interested in the target audience (SMB), and people who do work in that segment don’t have time to waste arguing their case in the IETF ivory tower – see also Mid-Market Innovator’s Dilemma.

In short, I don't expect anything to change any time soon, and we'll probably remain stuck with NAT66 for decades.

In case you find this blog post way too sarcastic, subscribe to a few IPv6 mailing lists and wait till someone restarts a “do we need ULA”, “shall we give /48 to every residential customer” or “do we need default gateway in DHCPv6” debate (not to mention the fascinating discussions of whether SLAAC on non-64 prefixes should work or not).

Latest blog posts in Site and Host Multihoming series

11 comments:

  1. Are there any proposed solutions that are viable? I'm not being sarcastic, just curious. I don't really deal with IPv6 much, except at a basic level.
  2. A few things are needed to fix routing in IPv6.

    First you need Locator-Identifier separation. E.g. some parts of ILNP or LISP or a variant of those proposals. This is needed as the foundation for all the fundamental fixes of routing that are needed. Applications-people don't understand this. And they keep suggesting bandaids. Unfortunately IPv6 in the nineties was developed by Applications-people. (The routing people were busy building the Internet, and making lots of money. The less successful people staged a coup and stole IPv6).

    Then you need CLNS-style routing inside Autonomous Systems. We know how to do that with link-state protocols. This will give you host multi-homing. It will give you easier addressing and renumbering and relocating hosts inside networks.

    Secondly you need some form locator-rewriting at the boundaries of each Autonomous System. This will give you site-multihoming. You can also call this NAT or NAT66. This word will make people cry. But it is the best solution. Because you had implemented locator-identifier separation earlier, hosts don't care. They care about Identifiers. They won't care if Locators change on the fly.

    Now what is needed to achieve this ? I don't know.
    Once I asked about which of some two competing proposals would win. An old Russian guy told me: "Deployment tends to win".

    So I could envision a simple strategy.
    1) You need to get 3 big router vendors aboard of the proposal. Cisco, Alcatel, Juniper might be enough.
    2) You need 3 host-vendors aboard. MicroSoft, Apple and maybe Google (Android). Someone needs to write a Linux driver too.

    These 6 parties implement the changes I proposed. You can call it IPv6½ if you want to. Their largest customers get it deployed. Only then you start writing RFCs. Problem solved. Would this be possible ?
    Replies
    1. Or you could get those 6 parties to implement SCTP in their TCP/IP stacks and be done with multihoming issues for good.
    2. Locator-Identifier separation already seems on track. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0b233dc7167884f95f08e796ac6a6767ae7d0d70
      Its not ILNP but more like spin-off
    3. @Henk: ... or you finally admit that you need session layer between transport and application (which would solve most of these issues) and name- not address-based connectivity on the application layer (read: DNS integrated into the stack not slapped on top of it).

      I know, it's not going to happen...

      @George: We might eventually get there. iOS is already using SCTP.
    4. it uses MPTCP, actually. and does not expose the API to other programs (Siri is the only widely known user of MPTCP support on iOS)
  3. @Ivan: I think you're being a little harsh. The problem that Fred describes was discussed on HomeNet many years ago -- it's just that they haven't gotten around to developing a solution/consensus on it.
    Replies
    1. Wouldn't you say that this proves my point? ;)
  4. For larger enterprises that establish themselves as an LIR and then deaggregate their allocation there are some similar considerations as the deaggregates are technically PA address space. This use case has been documented by Iljitsch van Beijnum: https://ripe69.ripe.net/presentations/32-ripe69-bcop-controlled-deag.pdf makes good reading. As enterprises roll out IPv6 in earnest, this will be an important issue!
  5. There is a solution that goes back the fundamentals. It is called Named Data Networking. Just search for it in Google Search... :-)
Add comment
Sidebar