Re: [v6ops] Dual ISP deployment operational issues and uncertainties

[Kevin Myers <[e-mail]>]

Nick,

I agree with this completely and it matches the experience I’ve had when connecting the branch offices and remote workers of my company to our DCs and the Internet in general. Relying on hosts to manage PA failover has been slow, messy, inconsistent and far less smooth than the equivalent IPv4 + NAT44 connected site. Maybe that will get better with time, but if I need to deploy IPv6 PA across two providers today at a site, it’s a bit of a crapshoot.

Nobody wants to talk about it, but we’re going to need some level of NAT66 to facilitate the transition for large enterprise, SME and SMB. Rather than fight against it, it would be ideal to determine which use cases are good for dual addressed PA space, NPTv6 and NAT66 so that IPv6 can be more easily deployed and we (hopefully) limit where NAT66 is needed with clear guidance on pros/cons of the options you listed.

That also paves the way to addressing the problem of host failover long term so that the experience can get better without delaying IPv6 deployment. Much like the ULA problem in the draft you wrote, improving the host OS is a multi-year journey.

From: Nick Buraglio <[e-mail]>
Sent: Wednesday, August 31, 2022 4:32 PM
To: Brian E Carpenter <[e-mail]>
Cc: Ole Troan <[e-mail]>; Klaus Frank <[e-mail]>; [e-mail]; Kevin Myers <[e-mail]>
Subject: Re: [v6ops] Dual ISP deployment operational issues and uncertainties

I have been working on exactly this problem recently. Given the *current* landscape of affordable, widely available options, there aren't many. If one were to need to get this working today, what I have found is this:

Multi-netting:
* Prefix preference is hairy, not well understood, and poorly supported in a way that makes it easily deployed.
* Multi-netting is wrought with lack of awareness and that will make most security teams balk at it.
* It's fairly onerous for an operations team to support at the first level due to it being so foreign of a concept when a NOC is used to legacy IPv4.
* It suffers from the same issues that exist with DNS application support, RR failover is not always great making timeouts a thing, leading to perceptions of performance degradation or poor user experience.
* Many devices are unable to support it in a way that a given engineer can deal with, or have unexposed knobs, making it largely unsupportable.

NPTv6
My preferred option, but not well supported in most smaller devices with a few exceptions.
* I've never seen it in a provider issued CPE, ONT+Router, even in most of the MetroE gear that I have seen*
* Where it is available there are odd bit-shifting issues when both allocations are not the same, i.e. not a /48. This seems to kinda-sorta work but I'd never, ever try to support it at scale as it is available today given that most providers in this level of space, at least in North America, tend to delegate at most a /56 to a level of service that would be in use for something like a SD-WAN solution.
* Lacks a way to make it work with address space that is not myred in other operational problems (i.e. ULA doesn't work for this in dual stacked networks that have diverse devices or embedded/OT systems with no mechanism for adjusting address selection)

NAT66
My own deployments are using this for the backup link. It's my last choice, but it works without breaking outbound traffic, which let's be honest, that's that we're mostly talking about for these use cases - eyeball networks or soho/small biz deployments where they need to connect to a DC or cloud system "somewhere on the internet". Rarely have I seen the requirement for inbound connectivity. This has the advantage of being incredibly easy to set up, works as designed, and for ensuring backup connectivity in a primary link outage, it is largely seamless.

I will say that I begrudgingly came to what I can only assume will be an unpopular solution here, but it's what is easily available now, and can be supported with almost no overhead. This also works for IPv6-only client + NAT64 networks, which is how some of the testing was done.

Assumptions made:
All IPv6 is PA space
Backup link is not ECMP or load sharing - it is simply for backup
At least one service has native IPv6 (I have also done this via a tunnel on the backup over an IPv4-only network)
CPE must be available, commercially supportable, and well known (i.e. not a linux system or a random DDWRT box)



----
nb

ᐧ

On Wed, Aug 31, 2022 at 3:56 PM Brian E Carpenter <[e-mail]<mailto:[e-mail]>> wrote:
On 31-Aug-22 19:00, Ole Troan wrote:
>
>> Limitations with UPNPv6 and other limitations with the discovery. Or just because the NAT discovery is bypassed as E2E is assumed for IPv6 (otherwise you could just stick with IPv4 and wouldn't have to migrate from a use-case perspective; Also one of the main selling-points of IPv6 is the reduced complexity by not needing to implement complex NAT detection and traversal techniques)
>
> Given the apparent success of NAT64, it’s not at all obvious that IPv6 applications will not need the same level of NAT/firewall traversal logic that IPv4 applications require.

Absolutely, but are code paths in the end-node applications affected? I thought NATs were supposed to act as if they were transparent :-).

I must confess that I have never understood STUN properly, but RFC8489 appears to cover IPv6 already.

> I would also expect that other “middle boxes” in an IPv6 network that require traversal is at a level with IPv4.

Yes, the code paths in any NAT-aware middleboxes would be affected. But since NAT66 is already a thing in the real world, if not in the IETF, I would expect this to be taken care of.

    Brian
_______________________________________________
v6ops mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/v6ops