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):
- Lack of IPv6 multihoming – the elephant in the room (May 2009)
- Small-Site Multihoming in IPv6 – Mission Impossible (December 2010)
- IPv6 Multihoming without NAT – The Problem (December 2011)
- We just might need NAT66 (December 2011)
- IPv6 Legends and Myths – more opinions than data points (April 2012)
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.
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 ?
Its not ILNP but more like spin-off
I know, it's not going to happen...
@George: We might eventually get there. iOS is already using SCTP.