Re: IPv4 flag day

[Pedro Prado via NANOG <nanog () lists nanog org>]

Sure, I’ve dealt with NAT issues related to SIP. PAT fundamentally worsens
the issue. So of course I’m not ignoring the issues NAT introduces…

I’m highlighting avoiding N/PAT it’s not an advantage of “a single L3
protocol and addressing to rule them all”. It’s a shortcoming of the upper
layers that should be more independent. Deploying a flat addressing space
can be thought of as a workaround to that, stretching quite a bit of course
:)

Using encapsulation as an example, we don’t (shouldn’t) care about the
outer protocol of the tunnel we’re riding - all we care is that our data is
delivered in an acceptable way. If we expand that thinking, there should be
enough information in the payload that no matter how it is transported, it
will still allow end to end communication.
We only care about addresses because we build sessions based on them, yet
host addressing is dynamic…

Applying Nat temporarily to the traffic that suddenly has to exit the
“other” ISP is not a problem; having communication that relies on the
addressing/ports never changing is. The endpoints should be able to simply
switch to the new address/port, after detecting that the connection started
to be natted. This way they can continue communicating and the NAT is
avoided.


*Pedro Martins Prado*
pedro.prado () gmail com / +353 83 036 1875 (FaceTime & WhatsApp)

On Fri 19 Jun 2026 at 18:57, Gary Sparkes via NANOG <nanog () lists nanog org>
wrote:

> Zero need for PAT. NPT means you *don't* have to PAT. Deploying PAT would
> be EXTRA steps.
>
> NPT means you're already 1:1 automatically, and you just open firewall
> ports for anything you need to inbound external access. No additional
> configuration or setup needed.
>
> PAT immediately eliminates most of the SMB benefits. The only one you
> retain is the V4 allocation cost reduction .... maybe.
>
> Any business internet will be giving you at least something like a /60 or
> /56, so as long as you subnet within that size space there's zero reason to
> put in additional effort for PAT and all the downsides it brings along with
> it.
>
> -----Original Message-----
> From: sronan () ronan-online com <sronan () ronan-online com>
> Sent: Friday, June 19, 2026 1:48 PM
> To: nanog () lists nanog org
> Cc: Marco Moock <mm () dorfdsl de>; Gary Sparkes <gary () kisaracorporation com>;
> nanog () lists nanog org
> Subject: Re: IPv4 flag day
>
> The SMB use case is absolutely PAT. They aren’t going to 1:1 NAT all of
> their internal hosts to both providers provided IPv6 space.
>
> > On Jun 19, 2026, at 1:16 PM, Gary Sparkes via NANOG <
> nanog () lists nanog org> wrote:
> > The cybercafe? Faster and more reliable online gaming. Better VOIP
> services for communication.
> > Gaming is something that *HUGELY* benefits from IPv6/NAT elimination.
> >
> > The SMB? More reliable/consistent SIP experience for their phones.
> > Cheaper network hardware for the same throughput. Reduced complexity.
> > Reduced costs (address space) if they're exposing anything externally
> > / need external inbound access. (All wins I've gained for my
> > customers, and yes, they're all either dual stack or v6 with edge
> > translation for some networks, but with reduced expenses overall and
> > more reliable/performant networks)
> >
> > Realistically, the only NAT that v6 should ever need is NPTv6 for the
> multihoming scenario (IEEE should just capitulate on that one, it just
> makes sense and it's not PAT that gives us all our problems in the first
> place), the rest just don't make sense and re-introduce complexity and
> issues that should be eliminated.
> > IPv6 enabled me to rip out a LOT of NAT workaround code from systems I
> support, which greatly simplified a lot of things. Re-introducing PAT into
> V6 land as a common practice would, once again, require re-adding all those
> insane hacks and workarounds and decreasing reliability.
> > We shouldn't need to solve those issues when we can eliminate them
> entirely.
> > -----Original Message-----
> > From: Pedro Prado via NANOG <nanog () lists nanog org>
> > Sent: Friday, June 19, 2026 1:01 PM
> > To: North American Network Operators Group <nanog () lists nanog org>
> > Cc: Marco Moock <mm () dorfdsl de>; Pedro Prado <pedro.prado () gmail com>
> > Subject: Re: IPv4 flag day
> >
> > … which sounds right (not implementing something you don’t need).
> >
> > “Need” has a different interpretation for those inside a simple network
> and those interconnecting that network to everything else - a separation of
> values that Nat and even pat happens to handle pretty well IMHO, for the
> most part anyway, bar the well known issues.
> > What value the granularity of addresses inside a SMB brings to the
> outside if the connectivity works without that? What does global-capable
> 128-bit addressing help a cyber cafe?
> > I would hope that the research that goes into solving NAT/PAT issues
> > would trickle into improvements to the end to end upper protocols
> > which would eventually be unaware of how the network operates, similar
> > to how L2 is transparent today (bar MTU mismatches…)
> >
> > *Pedro Martins Prado*
> > pedro.prado () gmail com / +353 83 036 1875 (FaceTime & WhatsApp)
> >
> > > On Fri 19 Jun 2026 at 15:33, Marco Moock via NANOG
> > > <nanog () lists nanog org>
> > > wrote:
> > >
> > > > Am 19.06.26 um 08:35 schrieb Arie Vayner:
> > > > To move IPv6 to the next level of SMB/enterprise adoption we need to
> > > > make it easier to consume by the average SMB - which means stop
> > > > saying "NAT is evil" or "NAT is not supported in IPv6", and unblock
> relevant IETF work.
> > > There are devices for SMB that support stateful IPv6 NAT if they
> > > really need this. Although, my experience is that most of the network
> > > infrastructure in SMB environments is created one time and never
> > > touched unless necessary. They will also not implement IPv6 with NAT
> > > unless they really need it. Same applies to various other protocols.
> > >
> > > --
> > > Gruß
> > > Marco
> > >
> > > Junk-Mail bitte an trashcan () stinkedores dorfdsl de
> > > _______________________________________________
> > > NANOG mailing list
> > >
> > > https://lists.nanog.org/archives/list/nanog () lists nanog org/message/A
> > > Z
> > > FJS4DBXNUQQWO2ON2VGB7H2JKLBJTL/
> > _______________________________________________
> > NANOG mailing list
> > https://lists.nanog.org/archives/list/nanog () lists nanog org/message/JR
> > CXLXRPKM2ELJPJFD4IBACOEOQ7LKMW/
> > _______________________________________________
> > NANOG mailing list
> > https://lists.nanog.org/archives/list/nanog () lists nanog org/message/VO
> > WZ3ODV43BY423LQ3RKNLHEIYLYBIBL/
> _______________________________________________
> NANOG mailing list
>
> https://lists.nanog.org/archives/list/nanog () lists nanog org/message/IQDSQDL5TEFNOOVEAUK65ZONK5SBUUTX/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/3MZ6OAMXP4I26OTNRCCCYBGNYU4DDFSL/