RE: IPv4 flag day

Hi Matthew,
We did try to list all solutions with all proc and cons: https://datatracker.ietf.org/doc/html/draft-fbnvv-v6ops-site-multihoming-03
We have found 6 solutions, many are very complicated. But actually you are right: practically it's only 2 (BGP and NAT).
The draft has been blocked because "it does mention NAT".
Eduard
> -----Original Message-----
> From: Matthew Petach via NANOG <[email protected]>
> Sent: Thursday, June 18, 2026 03:03
> To: North American Network Operators Group <[email protected]>
> Cc: Marco Moock <[email protected]>; Brandon Jackson
> <[email protected]>; Matthew Petach <[email protected]>
> Subject: Re: IPv4 flag day
> 
> On Wed, Jun 17, 2026, 11:20 Douglas Fischer via NANOG
> <[email protected]>
> wrote:
> 
> > To consider that the entire problem lies solely in the stateful table
> > of outgoing and incoming connections is bordering on lack of knowledge.
> 
> 
> > [...]
> >
> > So...
> > The real goal of IPv6 is not about using hexa ou integer to do some
> > pings...
> > Is about the communications being end-to-end and allowing
> > non-server-centricity is precisely to get rid of all these little
> > add-ons with each new application that is born on the Internet.
> >
> 
> So again I ask--are we saying the only answer for uplink redundancy in IPv6
> should be to get an ASN and PI address space and add another entry into the
> DFZ routing table?
> 
> Or do you have some other solution for redundancy in IPv6 that hasn't been
> mentioned yet that doesn't involve BGP (which inflates the routing table
> size) or NAT66 (which breaks the purity of the end to end communication flow
> you think is the whole purpose of IPv6)?
> 
> Because if you don't, I think you will have very effectively made my point for
> why IPv4 is never going to be replaced by IPv6.  :/
> 
> Matt
> 
> 
> > Em qua., 17 de jun. de 2026 às 14:49, <[email protected]>
> escreveu:
> >
> > > NAT is fine (1:1), PAT is the cancer (1:Many).
> > >
> > > > On Jun 17, 2026, at 1:40 PM, Douglas Fischer via NANOG <
> > > [email protected]> wrote:
> > > >
> > > > NAT is cancer!
> > > > NAT in IPv6 is spreading cancer cells to all the organs of a new,
> > healthy
> > > > body.
> > > >
> > > > NAT it's not just translate addresses... It needs to deal with the
> > > > applications upper layers.
> > > > NAT breaks everything that uses side-connections like P2P
> > communications.
> > > >
> > > > In other words, this idea that NAT66 can save dual-isp-home
> > > > connections
> > > its
> > > > a lie...
> > > > It breaks the applications. Especially the end-to-end applications.
> > > >
> > > > Suggesting this kind of solution just reinforces the
> > cloud-server-centric
> > > > non-opt-outable that we already live with.
> > > > That is the work way to go!
> > > >
> >
> >
> _______________________________________________
> NANOG mailing list
> https://lists.nanog.org/archives/list/[email protected]/message/6L6FYA5
> XSDFERI3SUQYNYAZFBSBIT6DO/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/[email protected]/message/TSVWTVYI2QYZUHA6ZBTVB7KATD6AJR4N/