RE: IPv4 flag day

[Gary Sparkes via NANOG <nanog () lists nanog org>]

> If you say "NPTv6" (which I fully expect to be the only reasonable answer you might give), I will agree, but note 
> that removes all the advantages normally claimed by IPv6, and puts us right back into the "might as well just stay 
> with IPv4 forever" scenario--which is fundamentally what we're all dancing around.
> For small networks, IPv6 fails to provide any significant benefit beyond what people are already experiencing in IPv4 
> networks behind NAT devices, and we're collectively trying to gaslight each other and the rest of the world into 
> thinking it does.

Alright, here's where I think that's *somewhat* wrong.

With NPTv6, you have 1:1 address mapping, so yes, it's effectively NAT in some ways, but it's always a 1-to-1 mapping. 
Which gets rid of most of the headaches I have with NAT supporting code. 

The only thing remaining is external address detection, which itself is absolutely trivial (and I do automatically if I 
detect ULA addressing anyway). That's all that needs to be handled there, so otherwise, you're gaining almost all the 
no-NAT benefits.

Most of the 'it just works' advantages are kept, inbound and outbound are still simple firewall rules, inbound opening 
is just firewall, etc. 

If we were all doing 1-to-1 NAT, I don't think many would be arguing the NAT issue at all, except maybe a little bit of 
processing power overhead. Since in 1:1 NAT scenarios, almost all the NAT problems are eliminated (except, of course, 
purely just external address detection). 

Buuuuut we can't do 1-to-1 NAT for every host with IPv4 (at least, most can't!) And that's a problem. 

So most of the NAT elimination benefits do come fully into play, even in NPT'd networks. 


-----Original Message-----
From: Matthew Petach via NANOG <nanog () lists nanog org> 
Sent: Tuesday, June 16, 2026 9:24 PM
To: North American Network Operators Group <nanog () lists nanog org>
Cc: Matthew Petach <mpetach () netflight com>
Subject: Re: IPv4 flag day

On Tue, Jun 16, 2026 at 2:24 PM sronan--- via NANOG <nanog () lists nanog org>
wrote:

> Sorry, but this is NOT a significant use case, and I wouldn’t buy 
> service from any Internet provider who doesn’t support BGP.
>
> But frankly you could implement this exact same solution with IPv6 
> without BGP anyway.
>
> Shane


I have been trying to figure this out for 20 years.

Please explain it to me like I'm a 30 year veteran of IPv4 and IPv6 networking, who has been using NAT on his IPv4 
upstream connections for decades with failover that "just works".

Two residential upstream ISPs, let's call them Winfinity and BTT for the sake of obscurity.

Two routers.  Each router is monitoring the upstream link.  Each router is running NAT to its upstream network.
Both routers are participating in VRRP.  Default gateway (.1) address priority is tied to the upstream connectivity, 
with BTT connection having a default priority of 120 and Winfinity having a default priority of 100.
Traffic flows through BTT router normally; if BTT connection goes away, health checking on the router decrements VRRP 
priority by 25, dropping it below that of Winfinity router, and default gateway flips to the other router.  Connections 
drop, a second request goes through, connection re-establishes.  Even devices that have static RFC1918 addresses 
assigned to them "just work" when traffic flips from one upstream to the other.

Then we get to IPv6.

Each router has a prefix from its upstream provider via DHCPv6-PD.
Each downstream interface gets an address from that upstream's delegated prefix.

Each host now has prefix information coming from two different routers, and installs two different prefixes.
Hosts that use SLAAC or DHCPv6 get addresses dynamically, one from each upstream router.

Devices that need static addresses like NFS servers have two addresses, one from each upstream provider's delegated 
prefix.

Default route information is handed out dynamically to autoconfiguring hosts via RAs, since DHCPv6 isn't allowed to 
pass along default route information.

For statically addressed hosts, a static default gateway can be configured to a VRRPv6 link-local v6 address, with all 
the chaos involved in having to statically assign link-local addresses.

Now, when BTT's link goes away, VRRPv6 can change priorities so that the
default gateway flips to Winfinity's router.   Yay!

Unfortunately, there's nothing that tells the downstream host "hey, stop using that address as a source address for 
connections".
So, the host continues trying to use BTT's prefixed address as a source IP for connections, even though the default 
gateway is now going out through Winfinity.
Winfinity, being a good network, sees what looks like IP spoofing going on, and drops the outbound packets.

Host keeps trying ineffectively to establish an outbound connection using the BTT prefix address, because there's no 
way to signal the statically addressed host "hey, stop using that prefix as a source address, use the other address you 
have instead"
Eventually, after enough failures, the user gives up and turns off IPv6.

So.

Tell me again in simple terms a 30 year networking veteran can understand, how exactly you fail over from ISP A to ISP 
B in an IPv6 world without having your own provider-independent IPv6 block, your own ASN, and BGP sessions going to 
each upstream network?


I will of course slap my thigh and laugh heartily if you say "shim6" at any point in your explanation.  ;P

If you say "NPTv6" (which I fully expect to be the only reasonable answer you might give), I will agree, but note that 
removes all the advantages normally claimed by IPv6, and puts us right back into the "might as well just stay with IPv4 
forever" scenario--which is fundamentally what we're all dancing around.
For small networks, IPv6 fails to provide any significant benefit beyond what people are already experiencing in IPv4 
networks behind NAT devices, and we're collectively trying to gaslight each other and the rest of the world into 
thinking it does.

I sincerely hope to be convinced otherwise.  :/

Thanks!

Matt
_______________________________________________
NANOG mailing list
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/CVZPQRAI52OKYTOMFQTXD6BT44M2HMW4/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/ATLSCTIQKKNR7F3FHGQQQ3IVJ5JI6EP5/