RE: IPv4 flag day

[Vasilenko Eduard via NANOG <nanog () lists nanog org>]

Has any CPE vendor implemented the redundancy NPTv6 scheme (with all IPv6 features) that Matthew mentioned for NAT44?
Reminder: 6man WG makes all possible efforts to block NPTv6.
Ed/
> -----Original Message-----
> From: Gary Sparkes via NANOG <nanog () lists nanog org>
> Sent: Wednesday, June 17, 2026 04:42
> To: North American Network Operators Group <nanog () lists nanog org>
> Cc: Gary Sparkes <gary () kisaracorporation com>
> Subject: RE: IPv4 flag day
>
> > 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/CVZPQR
> AI52OKYTOMFQTXD6BT44M2HMW4/
> _______________________________________________
> NANOG mailing list
> https://lists.nanog.org/archives/list/nanog () lists nanog org/message/ATLSCTI
> QKKNR7F3FHGQQQ3IVJ5JI6EP5/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/DWR523FGEIANXGWGKYNDIENLJ3EYQOJT/