Re: [v6ops] Primary/failover use-case for draft-fbnvv-v6ops-site-multihoming ?

[Nick Buraglio <[e-mail]>]

> On Jul 25, 2023, at 6:23 PM, Erik Nygren <[e-mail]> wrote:
>
> Thanks for the updates to draft-fbnvv-v6ops-site-multihoming. While this has a long history and lacks good solutions today, I think this is a critical problem for us to come up with easily usable and functional solutions for, at least for the most important use-cases.

> One use-case which might be worth having specific focus on in the draft would be the primary/failover scenarios. For home and SMB users this may be one of the most important cases to make "just work" but explicitly having a primary/backup asymmetry may allow for compromises when on "backup" and may allow for simplifications that aren't possible when trying to operate meaningfully in active/active. It could be that a way to approach this might also be to have a draft very much focused just at the primary/failover case and giving some guidance on how CPE devices may be able to handle this today, along with the downsides and things that might break after a failover.

Primary/backup was the bulk of what I was looking at, and I definitely agree that this is the largest use case in the wild, at least at the level we are thinking about here. My experience has shown me that active/Active is achievable using similar techniques as active/backup, but it’s even more clunky.

> For example, some things that might come into play or be part of a solution here:
>
> * When on the primary, you'd expect full e2e IPv6 to work (ie, normally no NAT66/NPT66/etc)
> * On failover, losing e2e and introducing some form of NAT/NPT/etc for IPv6 traffic may be a reasonable trade-off. Connections will break regardless, but a goal should be to allow clients to be able to re-establish them quickly.

The above is the only way I was able to get any notable success in creating a multi homed IPv6 deployment with the services available to a “normal customer”. NAT66 is significantly easier for this solution and definitely works as expected with the obvious caveats - which while unsavory to some, accomplish the goal of a failover. In fact, my 1G fiber had been experiencing some interruptions due to an upstream issue, and I was happily failing over to my DOCSIS for quite a few days without my even noticing, and 80% of my traffic is IPv6. This is a testament to “it may be ugly but it works”.

> * Trying to switch the network's IP addressing over to the backup network's addressing might be an option, but would need some guidance, especially since previously advertised prefixes will still be out there.

This is - at least today - inconsistent at best. I had to write some scripting to make it a bit easier, but it’s still a mess.

> * Doing some form of NAT66/NPT66/etc from either the GUA of the primary into the GUA space of the backup is one option. Perhaps this could happen during the transition. Depending on how long the backup may be in-use, it might be safer to just keep doing this for the lifetime and wait until near the end of the lifetime of the primary to start advertising the backup.
> * Having a ULA always present might also help to allow in-network/local connectivity (eg, to printers) but runs into the ULA-vs-rfc1918 priority issue.

Yup, this is exactly how I have done it. I have ULA as well for internal comms, and have adjusted source selection where possible, but it’s a fraction of the devices.

> * The prefix sizes from the primary/backup may be different (eg, T-Mobile US Home Internet that I use for backup only gives a single /64, so if normally using a /56 from a broadband provider with multiple active prefixes per use for different VLANs/SSIDs then some flavor of NAT66 is needed regardless).
> * Not everything will work in the failover mode, but keeping as much working as possible seems desirable.

> I worry that if we try to be purists here people will just deploy solutions outside the IETF (eg, what happened with NAT44) or this will result in another reason for IPv6 to be declared unsuitable and necessary to turn off, which I assume none of us one.

I 100% agree with this. My very strong opinion is that we would be woefully remiss to ignore working mechanisms and fail to acknowledge them, *especially* when they are undesirable.
It is better to control the narrative, and acknowledgment is absolutely not an endorsement. Controlling the narrative for things that are counter to a desired outcome is a key element in reducing the resulting blast radius.
Ignoring them is a license for someone else to write the stories ending, and NAT44 is a great example of how that turns out.

> Best, Erik

Thanks for your insightful input. It is very much appreciated.

----
nb