nanog mailing list archives

Previous By Date Next
Previous By Thread Next

Re: IPv4 flag day

From: Arie Vayner via NANOG <nanog () lists nanog org>
Date: Wed, 17 Jun 2026 20:16:17 -0700
The SIP and Gaming use cases are a bit of a strawman argument for this
topic: We are discussing SMB/Enterprise branch use cases.
All of the relevant applications (Video Conferencing, SaaS, general
browsing, ZTNA access to services such as ZScaler/Prisma) don't have any
problems with NAT, and any NAT-specific requirements were solved years ago.

As Matthew mentioned as well... Please provide a working simple design,
that does not require getting an ASN and running BGP (and doesn't use NAT),
that works for this use case?
(please ignore residential use cases, gaming etc... Take into account that
the common IP Telephony solutions in this space are hosted PBXs, or in
larger solutions a self-hosted PBX that implements an SBC function)

To put my architect hat on: when designing a solution, you start with the
business requirements, not the protocol specifics...

Tnx
Arie

On Wed, Jun 17, 2026 at 11:20 AM Douglas Fischer via NANOG <
nanog () lists nanog org> wrote:


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, <sronan () ronan-online com> escreveu:


NAT is fine (1:1), PAT is the cancer (1:Many).


On Jun 17, 2026, at 1:40 PM, Douglas Fischer via NANOG <

nanog () lists nanog org> 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 <
nanog () lists nanog org> 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
bjackson () napshome net


On Wed, Jun 17, 2026 at 11:29 AM Matthew Petach via NANOG
<nanog () lists nanog org> wrote:

On Wed, Jun 17, 2026, 00:32 Marco Moock via NANOG <

nanog () lists nanog org


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 abfalleimer2002 () stinkedores dorfdsl de
_______________________________________________
NANOG mailing list







https://lists.nanog.org/archives/list/nanog () lists nanog org/message/64HPVUSE2EXJH664UAY3T4YJX2G3VQET/

_______________________________________________
NANOG mailing list






https://lists.nanog.org/archives/list/nanog () lists nanog org/message/TXYK36SDIONPF72NKIEY6XHR7DDCBD7G/

_______________________________________________
NANOG mailing list





https://lists.nanog.org/archives/list/nanog () lists nanog org/message/CKUBVOP46YDAYPT4SOWY7BSJ2QCF2MZW/




--
Douglas Fernando Fischer
Engº de Controle e Automação
_______________________________________________
NANOG mailing list




https://lists.nanog.org/archives/list/nanog () lists nanog org/message/ZYYE5WTQAVBWN27RVH2CJBM3E7DQVI6Y/





--
Douglas Fernando Fischer
Engº de Controle e Automação
_______________________________________________
NANOG mailing list

https://lists.nanog.org/archives/list/nanog () lists nanog org/message/S3FR5YF5UQ73764J3JW2IP5IX6HO25GH/

_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/G3PEYUSKKFMAY6CCVYR47MPACZNZWKKB/
Previous By Date Next
Previous By Thread Next

Current thread: