>> 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 <[email protected]> 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 < > > [email protected]> wrote: > > > >> In-line comments. > >> > >> -----Original Message----- > >> From: Brandon Martin via NANOG <[email protected]> > >> Sent: Thursday, November 6, 2025 18:43 > >> To: North American Network Operators Group <[email protected]> > >> Cc: Brandon Martin <[email protected]> > >> 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://datatracker.ietf.org/doc/html/draft-fbnvv-v6ops-site-multihoming-03 > >> . > >> > 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://lists.nanog.org/archives/list/[email protected]/message/ZE6YQY2TDJR7DAAUGFKDAGXOLPUM4IUU/ > >> _______________________________________________ > >> NANOG mailing list > >> > >> > https://lists.nanog.org/archives/list/[email protected]/message/MOY3VCUHUAQXQUSJKRHSOZCEYCN3TMB4/ > >> > > _______________________________________________ > > NANOG mailing list > > > https://lists.nanog.org/archives/list/[email protected]/message/WTPLHRHMDOIEUUQXF5TBKTNHSZ6Z4FAY/ > _______________________________________________ > NANOG mailing list > > https://lists.nanog.org/archives/list/[email protected]/message/LOG7TKVA3XWW2PO5T6MMNCWEHRJWZO2N/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/7KQJSRNRAV7XSQS2VIB6HM5HHQRU3P2O/
