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 6, 2025, at 4:43 PM, Brandon Martin via NANOG <nanog () lists nanog org> wrote:

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!71aEiPt00U3CpLf-lSWlTKTzCOS4enIj3chYMQ_i-QKKLRfHwv1gh0bdlWTpx9njViKWv8h4ySz45-ohWSPhkOLTpx4$
 [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.

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.

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.

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.

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).

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.

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.

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!71aEiPt00U3CpLf-lSWlTKTzCOS4enIj3chYMQ_i-QKKLRfHwv1gh0bdlWTpx9njViKWv8h4ySz45-ohWSPhVLoRTd8$
 [lists[.]nanog[.]org]
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/MDC7F5W3B75YTHOR6RMXC2UEXF4TER32/