IPv6 Support for Multiple Routers and Multiple Interfaces
Fernando Gont published an Individual Internet Draft (meaning it hasn’t been adopted by any IETF WG yet) describing the Problem Statement about IPv6 Support for Multiple Routers and Multiple Interfaces. It’s so nice to see someone finally acknowledging the full scope of the problem and describing it succinctly. However, I cannot help but point out that:
- I was ranting about that problem in 2009 (15 years ago) and did a summary of older rants in 2015.
- It was evident to everyone but the religious zealots that the only solution we have at the moment is either NAT (because stuff simply does not work otherwise) or host-based solutions that never got implemented (apart from a few rare cases of multipath TCP).
Anyway, Fernando wraps up his draft with:
As a result, this document concludes that protocol improvements that accommodate these deployment scenarios are warranted.
I wouldn’t be surprised if no IPv6-related working group adopts the draft – the number of vocal people with severe cognitive dissonance firmly believing in their interpretation of IPv6 is simply too large. You might enjoy the comments to my old rants saying, “we solved the problem with PI prefixes” (really?). There’s also the never-ending “we don’t need no DHCPv6” saga that hurts everyone trying to deploy certain IPv6 mobile devices into somewhat-controlled enterprise IPv6 networks.
No wonder we’re still yammering about the adoption ratio of a 29-year-old protocol.
This is not an IPv4 or IPv6 specific problem. This is based on the missing separation of a locator from an identifier. Any scheme that provides such a separation would solve the multi-homing issue. Even mobility would become easy for hosts as well for networks.
This is a very old problem already existing with telephony networks. Now we have number portability to solve the issue. It is not nice, but in daily use...
Couldn't agree more ;) Unfortunately, IETF had the opportunity to fix stuff in the TCPv6 WG, but squandered it.
You have also mentioned it before, that if programmers could use symbolic names and name resolution (e.g., DNS), then this problem could be solved outside of the network layer. However, the culture evolved differently and now we are forced to solve problems in the network layer, they would be better to be solved in other layers.
That all comes from the over simplifications of early IETF efforts. ITU-T has much better and cleaner approach to network architecture. G.805 and G.809 should be taught first to all network professionals, not the OSI model or the IETF layered model.
I would go as far as saying that the "evolution of culture" was caused by networking MacGyvers, a total lack of any engineering discipline, and vendors pushing overly complex solutions to create lock-in.
Alas, we are where we are...
I'm not sure I understand the problem? What I mean is that in my experience, at least with OpenWRT you can do multi-wan without NAT, it's pretty trivial to setup too. If you use interface tracking to setup the LAN side of your firewall then OpenWRT will automatically deprecate the prefix from the wan that goes down causing all clients to automatically switch to preferring the prefix for the other WAN. Is this feature not common among other firewalls? Is there something I'm not understanding?
What you're describing is the simplest possible scenario and works only if (A) you're OK with primary/backup setup, (B) you're OK with session loss after link failure (due to loss of outside IPv6 prefix), and (C) your hosts are OK with deprecating IPv6 prefixes immediately (that wasn't the case the last time I looked, but admittedly I stopped caring about IPv6 quirks years ago).
Anyway, do check the scenarios described in the I-D. You might also enjoy the LinkedIn comments.
A) You're right on this as even if you don't set a priority clients will tend to prefer one specific address for outbound and not load balance B) doesn't this happen anyway with NAT? The public IP would change and the session would die anyway, isn't PI space the only way to avoid that? C) Linux will deprecate immediately, admittedly I can't remember if I tried on any other OS but that's an interesting point
A) The router also has to select the uplink based on the source IPv6 address, and the only way to do that in most devices is through PBR. Changing PBR configuration based on dynamic prefix allocation is not a no-brainer either. OpenWRT obviously got this right.
B) Yes, a PI prefix is the only way to keep sessions intact.
Also: we're still talking about the simplest possible scenario.
Yes, OpenWRT actually has an option to create the default route for the WAN with a source address policy so the right route is automatically selected, cool feature for this setup but other firewalls might be missing it
Lol, that's totally fair, I just didn't fully understand the scope of the problem. Glad to see it getting some additional attention from someone. I am one of those religious anti-NAT zealots, but also understand using it if it's the only good solution, I just try to if at all possible find other solutions. Nice to see other solutions being talked about.