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

[Nick Buraglio <[e-mail]>]

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]> 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]
> https://www.ietf.org/mailman/listinfo/v6ops
>