Design Clinic: Small-Site IPv6 Multihoming
I decided to stop caring about IPv6 when the protocol became old enough to buy its own beer (now even in US), but its second-system effects keep coming back to haunt us. Here’s a question I got for the February 2023 ipSpace.net Design Clinic:
How can we do IPv6 networking in a small/medium enterprise if we’re using multiple ISPs and don’t have our own IPv6 Provider Independent IPv6 allocation. I’ve brainstormed this with people far more knowledgeable than me on IPv6, and listened to IPv6 Buzz episodes discussing it, but I still can’t figure it out.
I wrote about this particular elephant-in-the-room in 2010 (a dozen years ago), and concluded NPT66 might be the only viable option in 2011.
In the meantime, a number of RFCs modified host source address selection rules, first-hop router selection and other aspects of IPv6 prefix advertisements. Either those fixes weren’t good enough or weren’t implemented – questions along the same lines keep popping up on v6ops mailing list and every time the sad conclusion is “we’re not there yet”. There’s also exceedingly-complex Enterprise Multihoming Using Provider-Assigned IPv6 Addresses stating in its abstract:
Connecting an enterprise site to multiple ISPs over IPv6 using provider-assigned addresses is difficult without the use of some form of Network Address Translation (NAT). Much has been written on this topic over the last 10 to 15 years, but it still remains a problem without a clearly defined or widely implemented solution.
Nick Buraglio1, the author of IPv6 ULA Made Useless draft, agreed to join us in the live Design Clinic session on February 2nd, and we’ll try to figure out how one could do small site IPv6 multihoming in real-life scenarios. Have an IPv6 grudge? Join us!
-
Who’s still trying to get IPv6 working in environments other than mobile networks or WiFi hotspots – the only scenarios some vendors seem to care about. ↩︎
If you really must solve this particular problem just use NAT and stop complaining. AFAIK all the vendors have implemented it by now.
I couldn't agree more with you. Unfortunately, the "end-to-end principle" seems to be the holy grail for true IPv6 believers so the cognitive dissonance prevents them to admit that NPT66 is the only solution that works (somewhat) reliably at the moment.
People reading IPv6 blogs and listening to IPv6 podcasts are thus left confused and clueless.
I agree NPTv66 seems like the best practical answer here but what IPv6 should be used on the "inside" of the network then? ULA is pretty useless, as Burgalio helped point out. Using 2001:db8::/32 seems like a bad idea as well.
@Gary IMHO you have 2 options:
1) Use something else instead of ULA as a "workaround", just like Ivan pointed out. 2) Use ULA and modify the IPv6 source address selection policy of the end-hosts.
For my home network, I went option #2 several years ago and cannot complain about it (yet). At Windows I've simply deleted policy entry for ULA which makes it equal to GUA (= "netsh interface ipv6 delete prefixpolicy fc00::/7 store=active"). For Linux, you can modify the policy in the file /etc/gai.conf.
@Gary: We finished this discussion literally moments ago ;)
If you have your own PI space, and have no NPT/NAT limitations like "one translation with NPT-66 only", then use your own PI space on the inside.
Failing that, decide which ISP is your primary ISP and use that delegated prefix as the "native" address space doing NPT/NAT toward the backup ISP.
There's also 0200::/7 (see https://codepoints.org/registry/ipv6/internet-protocol-version-6-address-space/)
Yeah, but the implementation varies, unfortunately: F.e. in IOS-XE 16.x, NPTv6 is there but you can only configure a translation of you internal ULA prefix to a single external GUA prefix globally. Because of that, it's totally unusable for small-site IPv6 multihoming unless you "solve" it by throwing additional hardware onto the problem (f.e. one dedicated router per IPv6-NPTv6-enabled circuit), IMHO. I would have hoped for a more flexible approach, interface-centric, policy-based or whatever... Anyway, besides that, the Cisco implementation might also to break IPv6 traceroute (only asterisks...), at least in my case - but I'm not sure if that's NPTv6, ZBF or combination of the two (you're doomed to use ZBF because simple reflexive ACLs are not supported in IOS-XE).
I don't know about the track record of other vendors in that regard (and if they made similar bad implementation choices), but at least the implementation of f.e. Vyatta / VyOS looks more promising / flexible in that regards.