Re: IPv4 flag day

To consider that the entire problem lies solely in the stateful table of
outgoing and incoming connections is bordering on lack of knowledge.
The big issue lies in the related connections that are not handled by a
simple address translation. Be it 1:1, or 1:many.

The most trivial example to illustrate this is SIP.
And to make things more realistic, let's assume we're talking about secure
SIP, where all SIP communication between the endpoint and the Session
controller is fully encrypted (and therefore cannot be inspected by ALGs).
Address translation (whether in v4 or v6) will break parity in addresses
that are in layer 3 and layer 5.
And when this happens, we have a few possibilities:
The origin of that expected Secure-RTP stream may not know who it should
actually send the stream to.
Or if you send it to a public address, when that encrypted RTP, which was
signaled through an encrypted protocol, is sent, the firewall won't know
what it is or who to deliver it to... And the application will break.

I used SIP as an example.
But this applies to many other applications. Games are the ones that use
this the most.

Surely someone will come along and give ideas like:
"Ah, but then you just don't use encrypted SIP, inspect the signaling, and
prepare the entry of the related connection."
Or:
"Ah, you just put a specialized complementary agent alongside the SIP-Agent
to send signals to the firewall."

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.

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!
> >
> >
> >
> >> Em qua., 17 de jun. de 2026 às 12:45, Brandon Jackson via NANOG <
> >> [email protected]> escreveu:
> >>
> >> routerOS v7 (2021) supports IPv6 NAT66/NPT
> >> A quick search also shows that Vyatta supports NAT66/NPT
> >> edgeOS, well its Ubiquiti, what do you expect when trying to use trash?
> >>
> >>
> >> ----------------------------------
> >> Brandon Jackson
> >> [email protected]
> >>
> >>> On Wed, Jun 17, 2026 at 11:29 AM Matthew Petach via NANOG
> >>> <[email protected]> wrote:
> >>>
> >>> On Wed, Jun 17, 2026, 00:32 Marco Moock via NANOG <
> [email protected]
> >>>
> >>> wrote:
> >>>
> >>>> Am 17.06.26 um 08:29 schrieb Vasilenko Eduard via NANOG:
> >>>>> Has any CPE vendor implemented the redundancy NPTv6 scheme (with all
> >>>> IPv6 features) that Matthew mentioned for NAT44?
> >>>>
> >>>> No, as normal CPE devices are used by home users. They don't need
> that.
> >>>> Business users buy professional devices and use BGP or other routing
> >>>> protocols for real redundancy.
> >>>>
> >>>
> >>>
> >>> *facepalm*
> >>>
> >>> No, my small business with 15 people doesn't buy Juniper routers with
> two
> >>> BGP upstreams and pay ARIN for an ASN and provider independent IP
> space.
> >>>
> >>> But it *does* still want to be able to get work done on the Internet
> when
> >>> ISP A goes down by using ISP B.
> >>>
> >>> You seem to be denying the existence of all the small businesses in the
> >>> world.
> >>> Given that Google estimates there are 200 to 400 million enterprises
> with
> >>> less than 50 employees worldwide,  that's a pretty big chunk of the
> >>> business world to ignore.
> >>>
> >>> Or are you suggesting that 400 million small businesses should get
> their
> >>> own ASNs and provider independent IPv6 space, and use BGP to gain
> >>> redundancy for their businesses?
> >>>
> >>> (talk about driving a demand for more router RAM for the DFZ core!
>  ;-P
> >> )
> >>>
> >>>
> >>>>> Reminder: 6man WG makes all possible efforts to block NPTv6.
> >>>>
> >>>> It already exists, IIRC Cisco IOS supports that.
> >>>>
> >>>
> >>>
> >>> Too bad every small business using edgeOS or Vyatta or routerOS is left
> >>> out--no NPTv6 or NAT66 for them.  But that was some pretty good
> shilling
> >>> for Cisco there.  ;)
> >>>
> >>> In all seriousness, I hope we're coming to the realization that
> there's a
> >>> big use case that is not currently well supported on the V6 world, and
> >>> telling hundreds of millions of small businesses to add to the
> >> BGP-speaking
> >>> core routing tables is probably *not* the right answer.  Unless of
> course
> >>> you want Geoff Huston to do a NANOG talk entitled "What The Hell Just
> >>> Happened?" with a hockey-stick shaped graph showing the number of ASNs
> in
> >>> the v6 routing tables.  :/
> >>>
> >>> In summary: there are still technical hurdles to deploying IPv6 that we
> >>> created through our decisions long ago that need to be solved before we
> >> can
> >>> start talking about sunsetting IPv4.
> >>>
> >>> Thanks!
> >>>
> >>> Matt
> >>>
> >>>
> >>>
> >>>> --
> >>>> Gruß
> >>>> Marco
> >>>> Muell und Spam bitte an [email protected]
> >>>> _______________________________________________
> >>>> NANOG mailing list
> >>>>
> >>>>
> >>
> https://lists.nanog.org/archives/list/[email protected]/message/64HPVUSE2EXJH664UAY3T4YJX2G3VQET/
> >>> _______________________________________________
> >>> NANOG mailing list
> >>>
> >>
> https://lists.nanog.org/archives/list/[email protected]/message/TXYK36SDIONPF72NKIEY6XHR7DDCBD7G/
> >> _______________________________________________
> >> NANOG mailing list
> >>
> >>
> https://lists.nanog.org/archives/list/[email protected]/message/CKUBVOP46YDAYPT4SOWY7BSJ2QCF2MZW/
> >
> >
> >
> > --
> > Douglas Fernando Fischer
> > Engº de Controle e Automação
> > _______________________________________________
> > NANOG mailing list
> >
> https://lists.nanog.org/archives/list/[email protected]/message/ZYYE5WTQAVBWN27RVH2CJBM3E7DQVI6Y/
>


-- 
Douglas Fernando Fischer
Engº de Controle e Automação
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/[email protected]/message/S3FR5YF5UQ73764J3JW2IP5IX6HO25GH/