I think the definition of a use case being significant depends on your point of view.
In global enterprise space or SMB this is a major use case and deployed in almost any large retailer, etc. ISPs around the world (and even with the USA) are not all made equal, and ISP services are not made queal either. For example, can you get BGP from your average LTE/5G connection? Are you sure you can BGP on a 200Mbps circuit from an ISP you've never heard of in Panama (just for the sake of the example...)? What about over a Starlink connection? Or a rural area long haul wireless path? Business cases are very diverse and YMMV as your cases get more "interesting" and global. Tnx Arie On Tue, Jun 16, 2026, 2:24 PM <[email protected]> wrote: > Sorry, but this is NOT a significant use case, and I wouldn’t buy service > from any Internet provider who doesn’t support BGP. > > But frankly you could implement this exact same solution with IPv6 without > BGP anyway. > > Shane > > > On Jun 16, 2026, at 5:21 PM, Arie Vayner via NANOG < > [email protected]> wrote: > > > > Hi everyone, > > > > There is also a significant set of use cases that currently work better, > or > > at least more easily, with NAT. > > > > The most common example is small branch sites with dual ISP uplinks. > There > > are a vast number of these sites deployed using two small > provider-assigned > > (PA) NAT pools. This setup is widely understood, simple to implement, and > > reliable. > > > > Moving these sites to IPv6 via BGP is often not feasible. Many ISP > circuits > > do not support BGP, and the teams operating these sites lack the time to > > navigate that complexity. Furthermore, other IPv6 dual-homing options > often > > don't align with enterprise requirements or expected complexity (or > really > > simplicity) levels. > > > > In my view, this is a core reason why IPv6 adoption remains low in the > > enterprise space: it requires fundamental paradigm shifts rather than a > > simple protocol update. > > > > Thanks, > > Arie > > > > > >> On Tue, Jun 16, 2026, 8:10 AM Tom Beecher via NANOG < > [email protected]> > >> wrote: > >> > >>>> > >>> Is NAT still such a severe problem that we needed a different protocol? > >>> Ask 1000 NANOG engineers, get 1000 different answers. In practice, no. > >>> IPv4 still works. > >> > >> > >> There are also plenty of well established things that NAT causes > problems > >> for, along with less than desirable protocol and standardization choices > >> that have been made because of the existence of NAT. > >> > >> We've gotten really good at engineering ways to disguise these issues so > >> users don't notice them. On one had that's good because user/application > >> experiences are better, on the other hand it sucks because people think > a > >> non-visible problem isn't a problem anymore. > >> > >> On Tue, Jun 16, 2026 at 10:53 AM Brian Knight via NANOG < > >> [email protected]> wrote: > >> > >>> On 2026-06-16 01:33, Saku Ytti via NANOG wrote: > >>>> Does anyone feel responsibility for the dual stack mess we've created? > >>>> It wasn't here when we found the Internet, and we're going to leave it > >>>> here after we leave, does not really jive with the whole leave > >>>> campground cleaner than found it ethos. > >>> > >>> It was the most comprehensive solution for the NAT problem. But NAT > >>> became the accepted way we connect to the Internet. > >>> > >>> World + dog knows how to connect to it, troubleshoot it, look at NAT > >>> tables on their edge firewall or router. > >>> > >>> Is NAT still such a severe problem that we needed a different protocol? > >>> Ask 1000 NANOG engineers, get 1000 different answers. In practice, no. > >>> IPv4 still works. > >>> > >>> Economics are a slightly different story, but so far, IPv4 space isn't > >>> prohibitively expensive. > >>> > >>> -Brian > >>> _______________________________________________ > >>> NANOG mailing list > >>> > >>> > >> > https://lists.nanog.org/archives/list/[email protected]/message/QEOMV5GN4WLNYOH7QZWYP5E26ZJ5AO57/ > >>> > >> _______________________________________________ > >> NANOG mailing list > >> > >> > https://lists.nanog.org/archives/list/[email protected]/message/ABXC2CERUCF64YKCK5YXOJTLPRJSTPBV/ > > _______________________________________________ > > NANOG mailing list > > > https://lists.nanog.org/archives/list/[email protected]/message/BZ6LKHSDLZ3WOR4GW2B544OKLSHFBIIG/ > _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/TQT6WUSTJZNIXO4EYXZT7EEP5UNADZ37/
