nanog mailing list archives

Re: BGP user friendliness (was Re: IPv4 flag day)


From: andrew--- via NANOG <nanog () lists nanog org>
Date: Tue, 23 Jun 2026 08:21:19 -0000

I'm amazed anyone in this list would consider PAT in IPv6 as a preferred solution.

If you need fast failover multihoming with consumer-class connections (ignoring the fact that connections will still 
break when failover occurs), then use NPT between the two providers. Pick your primary ISPs prefix as your internal 
prefix, NPT to the other one, no port translation needed. Or use ULA, whatever.

This multihoming issue could have been solved with better rigor in a few places in the v6 standard, having two routers 
advertising their two prefixes and default route priorities directly to clients. No complicated multi-wan routers, 
pizza place just buys two basic consumer routers, plug them both into the same LAN switch, and bam you have two ISPs. 
Clients get addresses on both prefixes, and default routes to both routers. Router withdraws its default route when it 
loses the upstream connection, clients deprecate the route, existing connections will fail because there is no longer 
an upstream link (which will happen with NA(P)T anyway!). Transport protocols see and can use both addresses if they 
are multihoming aware. Source address selection (rfc6742 rule 5.5) tells clients to pick an address from the higher 
priority router as the source address, meaning the router advertisement priority is used by the network operator to 
prefer one ISP over the other. Client software can bind to a
  specific address if it must use one ISP.

Unfortunately for us, rule 5.5 is optional and poorly implemented by OSes, so in reality this does not work that well. 
If that had been a requirement, it would have solved this issue without any packet mangling, and made transport layer 
support for multihoming significantly easier.
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/VKUAQOKO5GNCOMGI5CYVPWK3VRVOPQGZ/


Current thread: