RE: IPv4 flag day

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

I did believe too that the absence of redundancy for SMB/SOHO is the blocking factor for IPv6 deployment (and send a 
few messages here).
I am not so sure now. Of course, 6man would not fix it - they could not find a consensus for much smaller things. But 
redundancy may not be needed in the future.
The internet is monopolizing very fast. It would finish with 10 load balancer addresses (different 10 addresses for 
different countries) soon, 5 addresses would be OTTs and additional 5 would be CDN providers to host small businesses.
Hosted businesses would not need internet connection redundancy anymore, CDN provider would do it for them.
The Internet monopolization may help with IPv6 adoption.
PS: Have you spotted how many abandoned web sites on the Internet?
Eduard
> -----Original Message-----
> From: Matthew Petach via NANOG <nanog () lists nanog org>
> Sent: Wednesday, June 17, 2026 04:24
> 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/LF5EERL3BIRNGIHFDZP4EFW5OBTBGTEO/