Re: Re: Re: [Ext] Artificial Juniper SRX limitations preventing IPv6 deployment (and sales)

[Samaneh Tajalizadehkhoob via NANOG <nanog () lists nanog org>]

I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh

On Nov 10, 2025, at 1:06 PM, Samaneh Tajalizadehkhoob via NANOG <nanog () lists nanog org> wrote:

I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh

On Nov 7, 2025, at 9:57 PM, Javier J via NANOG <nanog () lists nanog org> wrote:

Port forwarding (in the context of NAT44) should die a slow death.
It already is. Isn't it? :-)

It is in everything I touch :-)


On Fri, Nov 7, 2025 at 3:22 PM Chris via NANOG <nanog () lists nanog org>
wrote:

On 2025-11-07 07:37, Javier J via NANOG wrote:
One very big company has blocked DHCP on all mobiles (inside chipset).
Hence, it is not possible to delegate IPv6 prefix behind mobile link.
Hence, E2E IPv6 story is broken.

Why don't you name the company / companies involved in this? That is
just a
random statement with nothing to back it up.
While I get your argument about businesses moving towards ipv6 slowly,
the
bottom line is that forget the complexities, 95% of businesses have a
less
complicated setup than me. They plug in the router from the provider,
they
get ipv4+ipv6 and their network just works. a coffee shop or a flower
shop
doesn't need or care about BGP.

The bottom line is NAT is shit. The only reason it ever needed to exist
is
because we ran out of ipv4. It really is that simple.

Port forwarding (in the context of NAT44) should die a slow death.
It already is. Isn't it? :-)





On Fri, Nov 7, 2025 at 2:06 AM Vasilenko Eduard via NANOG <
nanog () lists nanog org> wrote:

In-line comments.

-----Original Message-----
From: Brandon Martin via NANOG <nanog () lists nanog org>
Sent: Thursday, November 6, 2025 18:43
To: North American Network Operators Group <nanog () lists nanog org>
Cc: Brandon Martin <lists.nanog () monmotha net>
Subject: Re: Artificial Juniper SRX limitations preventing IPv6
deployment
(and sales)

On 11/6/25 01:33, Vasilenko Eduard wrote:
Hi Marting, All your messages are true. But these are not all the
complexities.
Read here (if you like)

https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-fbnvv-v6ops-site-multihoming-03__;!!PtGJab4!9QI8UHU1CJ554dBdp4a6gnvExceScTdwvhxaTghwUXr4f9bptzSo0CTU22O8ZgR9S6x7oJlOJO9wcpIPe3u4_kMwSzs$
 [datatracker[.]ietf[.]org]
.
to see how deep is the rabbit hole and why it is better not to touch
it.

While I have not read that entire draft, I'm familiar with most of the
challenges it espouses, and they are indeed issues to deal with.

However, what you seem to be missing is that, IF you are willing to deal
with what is essentially the status quo in IPv4 when not doing true
multi-homing using BGP or similar (broken end-to-end connectivity and/or
address translation that changes without notification to hosts behind
the
border router), you can do the SAME THING in IPv6.
[EV:] Not at all.
One very big company has blocked DHCP on all mobiles (inside chipset).
Hence, it is not possible to delegate IPv6 prefix behind mobile link.
Hence, E2E IPv6 story is broken.
At the same time, IETF doing everything possible to block NAT in any
form.
NAT is the primary method for SMB/SOHO in IPv4.
Another one big company (or the same?) has blocked DHCP on the major
mobile OS. You have to use IPX-style SLAAC.
And so on.
IPv6 is very aggressive in the attempt to "change the world".
Telco people has found a work-around for this: they have put subscriber
inside the tunnel and disabled all complexities because it is P2P.

We try not to because IPv6 lets us do things in potentially BETTER ways,
specifically in ways that attempt to preserve end-to-end connectivity
and
notify hosts about addressing changes, but that's up to you as a network
administrator.
[EV:] You see - it is what I am talking about. Small group of people
know
how would be "BETTER".
IMHO: this group already isolated themselves.

Indeed, that draft mentions both ULA+NPT66 and ULA+NAT66 as options and
discusses the upsides and downsides of them noting that they basically
mimic the present-day situation with IPv4 including the known downsides.
[EV:] The draft would be never published because it mentions all
options,
but IETF consensus is "to be silent about any form of NAT and cancel it
from all documents".
It one of the 3 major factors that push me to believe that IPv6 would
not
be accepted by businesses.
Actually, IPv6 IETF people are effectively blocking themselves.

Only if you want to dynamically change the addressing that hosts see on
their interfaces do you run into issues that are unique to IPv6 (unless
you're one of the presumably vanishingly few people doing that with
public
IPv4 addresses from multiple carriers).  There are upsides to making
that
work, but you don't have to, and you, as network administrator, get to
choose what you do.
[EV:] For the IPv6 mandatory E2E story, you have to have dynamic IP
addresses, because you have to renumber your network automatically after
the uplink is lost, because the prefix was delegated from the Telco.
IPv6
addresses are ephemeral for small businesses and many branches of big
businesses.

In fact, the only mechanisms that paper mentions that AREN'T essentially
identical to the status quo with IPv4 are the PA-based mechanism using
adjustable RA timers on the LAN and NPT44, and both of these are only
because either you can't do it at all with IPv4 (the former) or because
there's no interest (the former again, plus NPT44 is a thing just not
commonly used in this application due to address-space runout).
[EV:] Of cause not identical. IPv6 is much more complex - it has much
more
options and a few order of magnitudes more challenges.

There are also approaches commonly referred to collectively as "SD-WAN"
that aren't discussed in that draft that are ALSO used with IPv4 and
that
are directly applicable to IPv6.  The most obvious one is to tunnel all
your traffic to a (hopefully) nearby endpoint with true (BGP-based)
multi-homed connectivity and use some hidden mechanism to choose which
local connection (for which BGP-based multi-homing is presumably not
viable) sees the tunneled traffic.
[EV:] They are discussed - It is section 5.3 (more general). Yet, the
specific corner case "SD-WAN" was not mentioned - it is a point for
improvement, people may search specifically for it.

There's multiple ways to approach a problem, and the one I'm generally
least fond of is "proclaim the problem intractable", but I guess the
"your
network, your choice" philosophy applies there, too.
[EV:] I predict that business people would choose to stay on IPv4.

The number of approaches available on IPv6 to solve this problem is
indeed
higher than at least the practical number of approaches available on
IPv4
due to the more flexible nature of IPv6, but the solutions themselves
don't
necessarily have higher complexity.

--
Brandon Martin
_______________________________________________
NANOG mailing list


https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog () lists nanog 
org/message/ZE6YQY2TDJR7DAAUGFKDAGXOLPUM4IUU/__;!!PtGJab4!9QI8UHU1CJ554dBdp4a6gnvExceScTdwvhxaTghwUXr4f9bptzSo0CTU22O8ZgR9S6x7oJlOJO9wcpIPe3u45yyG9Lk$
 [lists[.]nanog[.]org]
_______________________________________________
NANOG mailing list


https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog () lists nanog 
org/message/MOY3VCUHUAQXQUSJKRHSOZCEYCN3TMB4/__;!!PtGJab4!9QI8UHU1CJ554dBdp4a6gnvExceScTdwvhxaTghwUXr4f9bptzSo0CTU22O8ZgR9S6x7oJlOJO9wcpIPe3u4SkAVIJU$
 [lists[.]nanog[.]org]

_______________________________________________
NANOG mailing list

https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog () lists nanog 
org/message/WTPLHRHMDOIEUUQXF5TBKTNHSZ6Z4FAY/__;!!PtGJab4!9QI8UHU1CJ554dBdp4a6gnvExceScTdwvhxaTghwUXr4f9bptzSo0CTU22O8ZgR9S6x7oJlOJO9wcpIPe3u4f50zgI4$
 [lists[.]nanog[.]org]
_______________________________________________
NANOG mailing list

https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog () lists nanog 
org/message/LOG7TKVA3XWW2PO5T6MMNCWEHRJWZO2N/__;!!PtGJab4!9QI8UHU1CJ554dBdp4a6gnvExceScTdwvhxaTghwUXr4f9bptzSo0CTU22O8ZgR9S6x7oJlOJO9wcpIPe3u4Tr49zzo$
 [lists[.]nanog[.]org]
_______________________________________________
NANOG mailing list
https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog () lists nanog 
org/message/7KQJSRNRAV7XSQS2VIB6HM5HHQRU3P2O/__;!!PtGJab4!9QI8UHU1CJ554dBdp4a6gnvExceScTdwvhxaTghwUXr4f9bptzSo0CTU22O8ZgR9S6x7oJlOJO9wcpIPe3u4MxJcxrE$
 [lists[.]nanog[.]org]
_______________________________________________
NANOG mailing list
https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog () lists nanog 
org/message/D2ZX2SI6TYERB3PC6RAMXZJKTB7NTJYW/__;!!PtGJab4!7UA1CAekctcj5lRPgE8ZZooPDbYEMvSXA6LXYl-QG9smSZRQxiO65qDKujdbZV50LP2_oBv2IQig2dX4Co_QPQQJ2dw$
 [lists[.]nanog[.]org]
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/QLFXZ7EO62EMETFCFK4EVEV5D62JNAXD/