'ello, I've babbled about this before, but apparently I'm babbling about it again. 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. I don't see any future where organically IPv4 dies in such a way that people offering services on the Internet are comfortable offering them IPv6 only, the long tail will be too expensive to ignore. Dual stack adds complexity, cost, reduces quality and security. It is also blatantly an antitrust issue, as established players with access to large allocations can outcompete new entrants with no IPv4 allocation. In practice I'm thinking about something where relevant players all sign an agreement to drop ipv4 at their edge in e..g 15 or 20 years. Creating clear business justification for people to implement IPv6 in their next upgrade cycle. Today if I'm an edge with the IPv4 addresses I need, I wouldn't consider IPv6, because that's just a cost to me, with no upside. I know I could get some transit shops to sign off on such an agreement, but no one cares about transit, this obviously doesn't work without Amazon and Facebook et.al. Sure edges still can have IPv4, but that's like edge having IPX or AppleTalk, it'll be highly local issue, no one expects to reach anywhere with it, and anticipates to translate 100% of external traffic. Amazon? Facebook? Google? Microsoft? Any appetite? -- ++ytti
Why not filter at internet-AS edges much sooner than that? -Bill
On Jun 16, 2026, at 08:35, Saku Ytti via NANOG <nanog@lists.nanog.org> wrote:
'ello,
I've babbled about this before, but apparently I'm babbling about it again.
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.
I don't see any future where organically IPv4 dies in such a way that people offering services on the Internet are comfortable offering them IPv6 only, the long tail will be too expensive to ignore.
Dual stack adds complexity, cost, reduces quality and security. It is also blatantly an antitrust issue, as established players with access to large allocations can outcompete new entrants with no IPv4 allocation.
In practice I'm thinking about something where relevant players all sign an agreement to drop ipv4 at their edge in e..g 15 or 20 years. Creating clear business justification for people to implement IPv6 in their next upgrade cycle. Today if I'm an edge with the IPv4 addresses I need, I wouldn't consider IPv6, because that's just a cost to me, with no upside. I know I could get some transit shops to sign off on such an agreement, but no one cares about transit, this obviously doesn't work without Amazon and Facebook et.al.
Sure edges still can have IPv4, but that's like edge having IPX or AppleTalk, it'll be highly local issue, no one expects to reach anywhere with it, and anticipates to translate 100% of external traffic.
Amazon? Facebook? Google? Microsoft? Any appetite?
-- ++ytti _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/E2XOPUM5...
On Tue, 16 Jun 2026 at 09:50, Bill Woodcock <woody@pch.net> wrote:
Why not filter at internet-AS edges much sooner than that?
The idea is very poorly marketable, and short time frames would call for more objection. If it were up to me, 5-10y is enough. But I fear it'll never happen, IPv4 calcifies and those who come after us will curse us for forcing this future on them. -- ++ytti
Hi, I recently wrote a piece on IPv6 adoption: https://heng.lu/on-why-ipv6-will-never-happen/ One observation is that IPv4 scarcity remains one of the few genuine scarcity mechanisms in the Internet industry. From an economic perspective, many stakeholders have incentives to continue operating within that framework rather than accelerate a transition that would largely eliminate it. Whether one agrees or disagrees with that conclusion, I would be interested in hearing the community's views on the economic incentives surrounding IPv6 deployment and what, if anything, could realistically change them. On Tue, 16 Jun 2026 at 15:06, Saku Ytti via NANOG <nanog@lists.nanog.org> wrote:
On Tue, 16 Jun 2026 at 09:50, Bill Woodcock <woody@pch.net> wrote:
Why not filter at internet-AS edges much sooner than that?
The idea is very poorly marketable, and short time frames would call for more objection.
If it were up to me, 5-10y is enough. But I fear it'll never happen, IPv4 calcifies and those who come after us will curse us for forcing this future on them.
-- ++ytti _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/IXJASO6F...
-- -- Kind regards. Lu
On Tue, 16 Jun 2026, Lu Heng via NANOG wrote:
Whether one agrees or disagrees with that conclusion, I would be interested in hearing the community's views on the economic incentives surrounding IPv6 deployment and what, if anything, could realistically change them.
My take on it is that for instance the enterprise world has a shortage of people who knows how to make everything work, and the people they get can barely make IPv4 work plausibly, so asking them to understand IPv6 is a big hurdle. Also, NAT44 actually hides some problems that most IPv4 centric people today never had to contend with, for instance return routing for packets, and making sure the flow makes it back to the stateful device that it passed through. I started doing networking before NAT came around, so to me IPv6 is a return to normalcy, but I've seen plenty of cases where we deployed IPv6 and then the problem of stateful devices creep up for redundancy. With IPv4 NAT44 the packet makes it back to that device naturally, but with a stateful IPv6 filtering device, this is now a problem if there are several of them, perhaps multi-site. So I don't have a solution, it's just my observation that a lot of those who are affected by IPv4 scarcity also are the ones struggling getting enough competence to deploy the solution to this scarcity. -- Mikael Abrahamsson email: swmike@swm.pp.se
On 2026-06-16 09:08, Lu Heng via NANOG wrote:
One observation is that IPv4 scarcity remains one of the few genuine scarcity mechanisms in the Internet industry. From an economic perspective, many stakeholders have incentives to continue operating within that framework rather than accelerate a transition that would largely eliminate it.
I've worked for a cloud provider, a content provider, and an ISP. In all cases, there was no interest in artificially keeping IPv4 only. Cloud providers interest are aligned with their customers: if customers want IPv6, you'll implement IPv6. Small and large ISPs need IPv6 because large NAT boxes are expensive to maintain and IPv6 have nicer mechanisms to provide IPv4 than NAT44 or NAT444. Content providers are enabling IPv6 to workaround broken NAT boxes and avoid blocking N unrelated customers because they share the same IPv4 address. Once an ISP has most of its customers on IPv6, their traffic becomes mostly IPv6. Same discourse with a bit more details: https://vincent.bernat.ch/en/blog/2024-why-ipv6 All this won't make IPv4 disappear, but IPv6 already transports most of the Internet economy. Google stats show that more than half the users are on IPv6 and any IPv6-enabled stats show that two thirds of the services in volume are on IPv6. The only ones that have an economic interest in keeping IPv4 scarce are people leasing and selling IPv4 (and you seem to be in this group).
Hi Vincent, Very nice blog article. Only a note that in the case of 464XLAT, the stateless NAT46 only happens if there is no DNS64 (in the host - self-synthesis - or in the network), so mainly only when using literals (for example ping 8.8.8.8 instead of ping dns.google.com). So in practice, this tends to be much less than 1% of the traffic. Instead in MAP-T it is 100% of the traffic. Something that we always forget is that 50% is the IPv6 traffic without China. If we could count China IPv6 traffic, it will be already 65-70% right now. Regards, Jordi @jordipalet
El 18 jun 2026, a las 6:38, Vincent Bernat via NANOG <nanog@lists.nanog.org> escribió:
On 2026-06-16 09:08, Lu Heng via NANOG wrote:
One observation is that IPv4 scarcity remains one of the few genuine scarcity mechanisms in the Internet industry. From an economic perspective, many stakeholders have incentives to continue operating within that framework rather than accelerate a transition that would largely eliminate it.
I've worked for a cloud provider, a content provider, and an ISP. In all cases, there was no interest in artificially keeping IPv4 only. Cloud providers interest are aligned with their customers: if customers want IPv6, you'll implement IPv6. Small and large ISPs need IPv6 because large NAT boxes are expensive to maintain and IPv6 have nicer mechanisms to provide IPv4 than NAT44 or NAT444. Content providers are enabling IPv6 to workaround broken NAT boxes and avoid blocking N unrelated customers because they share the same IPv4 address. Once an ISP has most of its customers on IPv6, their traffic becomes mostly IPv6.
Same discourse with a bit more details: https://vincent.bernat.ch/en/blog/2024-why-ipv6
All this won't make IPv4 disappear, but IPv6 already transports most of the Internet economy. Google stats show that more than half the users are on IPv6 and any IPv6-enabled stats show that two thirds of the services in volume are on IPv6.
The only ones that have an economic interest in keeping IPv4 scarce are people leasing and selling IPv4 (and you seem to be in this group). _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/SC5O36U6...
********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
On 2026-06-18 09:44, jordi.palet--- via NANOG wrote:
Very nice blog article. Only a note that in the case of 464XLAT, the stateless NAT46 only happens if there is no DNS64 (in the host - self-synthesis - or in the network), so mainly only when using literals (for example ping 8.8.8.8 instead of ping dns.google.com). So in practice, this tends to be much less than 1% of the traffic. Instead in MAP-T it is 100% of the traffic.
Thanks! I'll update the schema with that. But this stateless translation on the device is mostly free. My understanding is that 464XLAT is popular for its flexibility (per customer allocation is possible), but has a cost because PLAT is stateful, while MAP-E/MAP-T is one-size-fits-all (but you could have a few different subnets), but as PLAT is stateless, this is very cheap to implement (we do that on devices that cost almost nothing).
On 16/06/2026 08:05:39, "Saku Ytti via NANOG" <nanog@lists.nanog.org> wrote:
The idea is very poorly marketable, and short time frames would call for more objection.
We turned off analogue TV despite some objections. But that had a government imposed deadline, funding and people in a body created to see through the transition, and an industry looking for the benefits of more people on the new platform which allowed more channels so more market. Can enough upsides be put in place to make IPv6 fly? Better user tracking has been over taken by privacy concerns Larger market is not desired by the incumbents who think they own it all already and don't want easier competition. This is global not national, things are a lot easier at national scale. Could the countries with national firewalls switch them to NAT64 while only filtering v6, though this route would end up with more countries with firewalls so probably not a good plan, and it has failed in previous tries.
If it were up to me, 5-10y is enough
Too long and people will leave it until later. There has to be some peril to get it into the next refresh rather than leave to future ones. It does feel like a transition method should be agreed and a timeline started. By who? brandon
The goal isn't to shut down IPv4, it's to let it starve to death. I didn't receive a document saying I should disable NETBEUI or IPX/SPX on my networks. IMHO I believe the focus of the effort should be on causing technical discomfort and embarrassment to those who maintain applications that are not yet capable of providing interoperability between clients that are on IPv4 and clients that are on IPv6. And in my view, the biggest villains in this case are the gaming platforms. Making these guys abandon the exclusively legacy methodology and focus on IPv6 is one of the keys that will begin to remove the last shackles to allow the end user to be on IPv6 only and not even know that IPv4 and IPv6 exist. Em ter., 16 de jun. de 2026 às 03:34, Saku Ytti via NANOG < nanog@lists.nanog.org> escreveu:
'ello,
I've babbled about this before, but apparently I'm babbling about it again.
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.
I don't see any future where organically IPv4 dies in such a way that people offering services on the Internet are comfortable offering them IPv6 only, the long tail will be too expensive to ignore.
Dual stack adds complexity, cost, reduces quality and security. It is also blatantly an antitrust issue, as established players with access to large allocations can outcompete new entrants with no IPv4 allocation.
In practice I'm thinking about something where relevant players all sign an agreement to drop ipv4 at their edge in e..g 15 or 20 years. Creating clear business justification for people to implement IPv6 in their next upgrade cycle. Today if I'm an edge with the IPv4 addresses I need, I wouldn't consider IPv6, because that's just a cost to me, with no upside. I know I could get some transit shops to sign off on such an agreement, but no one cares about transit, this obviously doesn't work without Amazon and Facebook et.al.
Sure edges still can have IPv4, but that's like edge having IPX or AppleTalk, it'll be highly local issue, no one expects to reach anywhere with it, and anticipates to translate 100% of external traffic.
Amazon? Facebook? Google? Microsoft? Any appetite?
-- ++ytti _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/E2XOPUM5...
-- Douglas Fernando Fischer Engº de Controle e Automação
In addition to continuing to strongly pressure developers and applications that are still stuck with legacy protocols. In the Telco scope, what we could promote are things that are already within our reach, such as: IXPs eliminating the IPv4 LAN and maintaining only the IPv6 LAN, and making everything happen exclusively using RFC8950 (RFC5549). The same line in the Transit Provider scenario. Encouraging the link network to be exclusively IPv6 using RFC8950 (RFC5549). Em ter., 16 de jun. de 2026 às 09:37, Douglas Fischer < fischerdouglas@gmail.com> escreveu:
The goal isn't to shut down IPv4, it's to let it starve to death. I didn't receive a document saying I should disable NETBEUI or IPX/SPX on my networks.
IMHO I believe the focus of the effort should be on causing technical discomfort and embarrassment to those who maintain applications that are not yet capable of providing interoperability between clients that are on IPv4 and clients that are on IPv6.
And in my view, the biggest villains in this case are the gaming platforms.
Making these guys abandon the exclusively legacy methodology and focus on IPv6 is one of the keys that will begin to remove the last shackles to allow the end user to be on IPv6 only and not even know that IPv4 and IPv6 exist.
Em ter., 16 de jun. de 2026 às 03:34, Saku Ytti via NANOG < nanog@lists.nanog.org> escreveu:
'ello,
I've babbled about this before, but apparently I'm babbling about it again.
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.
I don't see any future where organically IPv4 dies in such a way that people offering services on the Internet are comfortable offering them IPv6 only, the long tail will be too expensive to ignore.
Dual stack adds complexity, cost, reduces quality and security. It is also blatantly an antitrust issue, as established players with access to large allocations can outcompete new entrants with no IPv4 allocation.
In practice I'm thinking about something where relevant players all sign an agreement to drop ipv4 at their edge in e..g 15 or 20 years. Creating clear business justification for people to implement IPv6 in their next upgrade cycle. Today if I'm an edge with the IPv4 addresses I need, I wouldn't consider IPv6, because that's just a cost to me, with no upside. I know I could get some transit shops to sign off on such an agreement, but no one cares about transit, this obviously doesn't work without Amazon and Facebook et.al.
Sure edges still can have IPv4, but that's like edge having IPX or AppleTalk, it'll be highly local issue, no one expects to reach anywhere with it, and anticipates to translate 100% of external traffic.
Amazon? Facebook? Google? Microsoft? Any appetite?
-- ++ytti _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/E2XOPUM5...
-- Douglas Fernando Fischer Engº de Controle e Automação
-- Douglas Fernando Fischer Engº de Controle e Automação
It is unfortunate that it worked out this way, but if we're going to shut one of them off it should be IPv6 - the one that's adding no benefit for anybody - just cost, complexity and reduced reliability. The idea of intentionally hobbling IPv4 precisely because it works, in order to make IPv6 look more appealing, is a perverse and bad faith approach. Yet this is what people have been working on for the past 10 years to try to make IPv6 appear relevant. If there were a benefit to gain from IPv6 then most would have migrated to it already. At this point it's just a few zealots who are trying to figure out how to undermine IPv4 at scale, so IPv6 becomes the next best choice. The decisions to make things different from IPv4 are not helping either (RA/DHCP, multiple routers and the like). But the biggest turnoff is the group of people who reply to every networking thread with "IPv6 IPv6 IPv6" even when it's not relevant. There is even coercive language like "legacy internet" being thrown around. This has turned into dogmatic loaded framing rather than engineering. -Laszlo On 6/16/26 12:37 PM, Douglas Fischer via NANOG wrote:
The goal isn't to shut down IPv4, it's to let it starve to death. I didn't receive a document saying I should disable NETBEUI or IPX/SPX on my networks.
IMHO I believe the focus of the effort should be on causing technical discomfort and embarrassment to those who maintain applications that are not yet capable of providing interoperability between clients that are on IPv4 and clients that are on IPv6.
And in my view, the biggest villains in this case are the gaming platforms.
Making these guys abandon the exclusively legacy methodology and focus on IPv6 is one of the keys that will begin to remove the last shackles to allow the end user to be on IPv6 only and not even know that IPv4 and IPv6 exist.
Em ter., 16 de jun. de 2026 às 03:34, Saku Ytti via NANOG < nanog@lists.nanog.org> escreveu:
'ello,
I've babbled about this before, but apparently I'm babbling about it again.
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.
I don't see any future where organically IPv4 dies in such a way that people offering services on the Internet are comfortable offering them IPv6 only, the long tail will be too expensive to ignore.
Dual stack adds complexity, cost, reduces quality and security. It is also blatantly an antitrust issue, as established players with access to large allocations can outcompete new entrants with no IPv4 allocation.
In practice I'm thinking about something where relevant players all sign an agreement to drop ipv4 at their edge in e..g 15 or 20 years. Creating clear business justification for people to implement IPv6 in their next upgrade cycle. Today if I'm an edge with the IPv4 addresses I need, I wouldn't consider IPv6, because that's just a cost to me, with no upside. I know I could get some transit shops to sign off on such an agreement, but no one cares about transit, this obviously doesn't work without Amazon and Facebook et.al.
Sure edges still can have IPv4, but that's like edge having IPX or AppleTalk, it'll be highly local issue, no one expects to reach anywhere with it, and anticipates to translate 100% of external traffic.
Amazon? Facebook? Google? Microsoft? Any appetite?
-- ++ytti _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/E2XOPUM5...
On Jun 16, 2026, at 8:26 AM, Laszlo H via NANOG <nanog@lists.nanog.org> wrote:
It is unfortunate that it worked out this way, but if we're going to shut one of them off it should be IPv6 - the one that's adding no benefit for anybody - just cost, complexity and reduced reliability. The idea of intentionally hobbling IPv4 precisely because it works, in order to make IPv6 look more appealing, is a perverse and bad faith approach. Yet this is what people have been working on for the past 10 years to try to make IPv6 appear relevant. If there were a benefit to gain from IPv6 then most would have migrated to it already. At this point it's just a few zealots who are trying to figure out how to undermine IPv4 at scale, so IPv6 becomes the next best choice. The decisions to make things different from IPv4 are not helping either (RA/DHCP, multiple routers and the like). But the biggest turnoff is the group of people who reply to every networking thread with "IPv6 IPv6 IPv6" even when it's not relevant. There is even coercive language like "legacy internet" being thrown around. This has turned into dogmatic loaded framing rather than engineering.
History has shown time and time again that in order for any large project to be accomplished, it has to be under the guise of attacking or defending against an enemy. The enemy might be an intangible concept rather than people or animals, but there must always be warfare for those involved to feel justified in their investment of effort and resources. If something doesn’t have an enemy to attack or defend against, then the resources and effort will be invested instead toward a more immediate-seeming item that *does* have an enemy requiring combat, because otherwise the person making the investment would be open to accusations of inaction toward the other item’s enemies and/or action in conspiracy with said enemies. Forget turtles, it’s tribal warfare all the way down.
On Tue, Jun 16, 2026 at 6:26 AM Laszlo H via NANOG <nanog@lists.nanog.org> wrote:
It is unfortunate that it worked out this way, but if we're going to shut one of them off it should be IPv6 - the one that's adding no benefit for anybody - just cost, complexity and reduced reliability.
Just a reminder, in the USA ipv6 is the dominant protocol, from some meaningful vantage points https://www.google.com/intl/en/ipv6/statistics.html
The idea of intentionally hobbling IPv4 precisely because it works, in order to make IPv6 look more appealing, is a perverse and bad faith approach. Yet this is what people have been working on for the past 10 years to try to make IPv6 appear relevant. If there were a benefit to gain from IPv6 then most would have migrated to it already. At this point it's just a few zealots who are trying to figure out how to undermine IPv4 at scale, so IPv6 becomes the next best choice. The decisions to make things different from IPv4 are not helping either (RA/DHCP, multiple routers and the like). But the biggest turnoff is the group of people who reply to every networking thread with "IPv6 IPv6 IPv6" even when it's not relevant. There is even coercive language like "legacy internet" being thrown around. This has turned into dogmatic loaded framing rather than engineering.
-Laszlo
The goal isn't to shut down IPv4, it's to let it starve to death. I didn't receive a document saying I should disable NETBEUI or IPX/SPX on my networks.
IMHO I believe the focus of the effort should be on causing technical discomfort and embarrassment to those who maintain applications that are not yet capable of providing interoperability between clients that are on IPv4 and clients that are on IPv6.
And in my view, the biggest villains in this case are the gaming
On 6/16/26 12:37 PM, Douglas Fischer via NANOG wrote: platforms.
Making these guys abandon the exclusively legacy methodology and focus on IPv6 is one of the keys that will begin to remove the last shackles to allow the end user to be on IPv6 only and not even know that IPv4 and
IPv6
exist.
Em ter., 16 de jun. de 2026 às 03:34, Saku Ytti via NANOG < nanog@lists.nanog.org> escreveu:
'ello,
I've babbled about this before, but apparently I'm babbling about it again.
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.
I don't see any future where organically IPv4 dies in such a way that people offering services on the Internet are comfortable offering them IPv6 only, the long tail will be too expensive to ignore.
Dual stack adds complexity, cost, reduces quality and security. It is also blatantly an antitrust issue, as established players with access to large allocations can outcompete new entrants with no IPv4 allocation.
In practice I'm thinking about something where relevant players all sign an agreement to drop ipv4 at their edge in e..g 15 or 20 years. Creating clear business justification for people to implement IPv6 in their next upgrade cycle. Today if I'm an edge with the IPv4 addresses I need, I wouldn't consider IPv6, because that's just a cost to me, with no upside. I know I could get some transit shops to sign off on such an agreement, but no one cares about transit, this obviously doesn't work without Amazon and Facebook et.al.
Sure edges still can have IPv4, but that's like edge having IPX or AppleTalk, it'll be highly local issue, no one expects to reach anywhere with it, and anticipates to translate 100% of external traffic.
Amazon? Facebook? Google? Microsoft? Any appetite?
-- ++ytti _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/E2XOPUM5...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/3DJYDO3O...
It is unfortunate that it worked out this way, but if we're going to shut one of them off it should be IPv6 - the one that's adding no benefit for anybody
"no benefit for anybody" is an entirely incorrect statement. just cost, complexity and reduced reliability. Many who make the cost argument state that it's too expensive to swap out entire hardware and software stacks 'just for V6 support'. While that's probably true, it ignores that nobody actually has to do that. Everyone goes through hardware and software replacement cycles. All anyone has to do is require that the hardware and software they select in those cycles support V6. Eventually everything supports it, and you've had time to familiarize yourself to operate it. One could also reasonably argue that reliability is *improved* with V6, purely from the fact that all flavors of NAT are removed from the connectivity path. This is important to those that care about such things, but to everyone who thinks the current state is 'good enough', they likely consider this to be an academic argument. Yet this is what people have been working on for the past 10
years to try to make IPv6 appear relevant.
IPv6 became a draft standard 28 years ago. Since that point, more work has gone into extending the transition mechanisms intended to be temporary into full fledged workarounds to NOT use V6. If there were a benefit to
gain from IPv6 then most would have migrated to it already.
Translations : - "I have enough V4 space for my needs, anyone who doesn't can pound sand." - "I have been able to leverage workarounds so I can look good by never spending any money." - "The users of my networks never touch anything V6 so I don't have to care." These are all great answers if they apply to you, until they don't, and your bosses are up your ass to make it work. Might end up being career limiting events for some when their bosses find out they had a 30 year window to avoid it. But the biggest turnoff is
the group of people who reply to every networking thread with "IPv6 IPv6 IPv6" even when it's not relevant. There is even coercive language like "legacy internet" being thrown around. This has turned into dogmatic loaded framing rather than engineering.
On this point I agree with you. Stating that V6 is the 'answer' to a given challenge when it's not is unhelpful. At the end of the day , IPv4 and IPv6 are both standard addressing protocols used across the internet. That isn't going to change at this point anytime in any of our careers, and probably won't in the next generation's careers either. You have 3 choices. 1. Build a network that supports both. 2. Build a network that supports V4 only with a translation mechanism to talk to V6 should it be required, and hope that's good enough. 3. Build a network that supports V4 only and hope V6 never causes an issue. You will spend time and money no matter which way you go. How much and when that bill becomes due is the only difference. On Tue, Jun 16, 2026 at 9:26 AM Laszlo H via NANOG <nanog@lists.nanog.org> wrote:
It is unfortunate that it worked out this way, but if we're going to shut one of them off it should be IPv6 - the one that's adding no benefit for anybody - just cost, complexity and reduced reliability. The idea of intentionally hobbling IPv4 precisely because it works, in order to make IPv6 look more appealing, is a perverse and bad faith approach. Yet this is what people have been working on for the past 10 years to try to make IPv6 appear relevant. If there were a benefit to gain from IPv6 then most would have migrated to it already. At this point it's just a few zealots who are trying to figure out how to undermine IPv4 at scale, so IPv6 becomes the next best choice. The decisions to make things different from IPv4 are not helping either (RA/DHCP, multiple routers and the like). But the biggest turnoff is the group of people who reply to every networking thread with "IPv6 IPv6 IPv6" even when it's not relevant. There is even coercive language like "legacy internet" being thrown around. This has turned into dogmatic loaded framing rather than engineering.
-Laszlo
The goal isn't to shut down IPv4, it's to let it starve to death. I didn't receive a document saying I should disable NETBEUI or IPX/SPX on my networks.
IMHO I believe the focus of the effort should be on causing technical discomfort and embarrassment to those who maintain applications that are not yet capable of providing interoperability between clients that are on IPv4 and clients that are on IPv6.
And in my view, the biggest villains in this case are the gaming
On 6/16/26 12:37 PM, Douglas Fischer via NANOG wrote: platforms.
Making these guys abandon the exclusively legacy methodology and focus on IPv6 is one of the keys that will begin to remove the last shackles to allow the end user to be on IPv6 only and not even know that IPv4 and
IPv6
exist.
Em ter., 16 de jun. de 2026 às 03:34, Saku Ytti via NANOG < nanog@lists.nanog.org> escreveu:
'ello,
I've babbled about this before, but apparently I'm babbling about it again.
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.
I don't see any future where organically IPv4 dies in such a way that people offering services on the Internet are comfortable offering them IPv6 only, the long tail will be too expensive to ignore.
Dual stack adds complexity, cost, reduces quality and security. It is also blatantly an antitrust issue, as established players with access to large allocations can outcompete new entrants with no IPv4 allocation.
In practice I'm thinking about something where relevant players all sign an agreement to drop ipv4 at their edge in e..g 15 or 20 years. Creating clear business justification for people to implement IPv6 in their next upgrade cycle. Today if I'm an edge with the IPv4 addresses I need, I wouldn't consider IPv6, because that's just a cost to me, with no upside. I know I could get some transit shops to sign off on such an agreement, but no one cares about transit, this obviously doesn't work without Amazon and Facebook et.al.
Sure edges still can have IPv4, but that's like edge having IPX or AppleTalk, it'll be highly local issue, no one expects to reach anywhere with it, and anticipates to translate 100% of external traffic.
Amazon? Facebook? Google? Microsoft? Any appetite?
-- ++ytti _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/E2XOPUM5...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/3DJYDO3O...
Em ter., 16 de jun. de 2026 às 10:26, Laszlo H via NANOG < nanog@lists.nanog.org> escreveu:
But the biggest turnoff is the group of people who reply to every networking thread with "IPv6 IPv6 IPv6" even when it's not relevant.
My line of thinking is very similar to yours... The only difference is that I believe that the cause of cancer(turnoff) is those who have technical, emotional, or cognitive impediments to letting the legacy die of starvation and working with what is real. -- Douglas Fernando Fischer Engº de Controle e Automação
On Tue, Jun 16, 2026 at 11:04 AM Douglas Fischer via NANOG < nanog@lists.nanog.org> wrote:
My line of thinking is very similar to yours... The only difference is that I believe that the cause of cancer(turnoff) is those who have technical, emotional, or cognitive impediments to letting the legacy die of starvation and working with what is real.
My local monopoly hasn't even begun to think of deploying IPv6. On top of that, they decided they don't like static IPv4 anymore. I'm grandfathered in with a /30 at $15/mo, but if I want to set up new service or make changes the cost goes to $250/mo because their "network engineer" doesn't like messing around in the "cisco command line". So what now? Go to Starlink at 3x+ the price and 1/4th the speed? Continue using HE for a tunnelbroker for another decade or two? My local ISP might have technical, emotional, or cognitive impediments to enabling IPv6...but what it anyone going to do about it? They don't listen to customers. Their sole upstream is Lumen. Gonna get Lumen to refuse to connect with them? Or maybe get Facebook, YouTube, Netflix and everyone else to just disable IPv4 (and losing customers)? There's no incentive to "fix" the "problem". -A
there are ipv6 only transit networks, cernet being the most prominent, of course. kudos to them. telling others (with paying transit customers) that they should go v6-only when you do not run a v6-only transit network yourself is amusing at best; but very nanog. randy
I was waiting for you to recommend that all your competitors do that.... On Tue, Jun 16, 2026 at 2:50 PM Randy Bush via NANOG <nanog@lists.nanog.org> wrote:
there are ipv6 only transit networks, cernet being the most prominent, of course. kudos to them.
telling others (with paying transit customers) that they should go v6-only when you do not run a v6-only transit network yourself is amusing at best; but very nanog.
randy _______________________________________________
-- Jeff Shultz -- Like us on Social Media for News, Promotions, and other information!! <https://www.facebook.com/SCTCWEB/> <https://www.instagram.com/sctc_sctc/> <https://www.yelp.com/biz/sctc-stayton-3> <https://www.youtube.com/c/sctcvideos> _**** This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ****_
Em ter., 16 de jun. de 2026 às 18:34, Aaron C. de Bruyn <aaron@heyaaron.com> escreveu:
My local ISP might have technical, emotional, or cognitive impediments to enabling IPv6...but what it anyone going to do about it? They don't listen to customers. Their sole upstream is Lumen. Gonna get Lumen to refuse to connect with them?
Or maybe get Facebook, YouTube, Netflix and everyone else to just disable
IPv4 (and losing customers)?
There's no incentive to "fix" the "problem".
The person that will begin to solve that you described is you! Choosing with your wallet. -- Douglas Fernando Fischer Engº de Controle e Automação
On Tue, Jun 16, 2026 at 3:03 PM Douglas Fischer <fischerdouglas@gmail.com> wrote:
Em ter., 16 de jun. de 2026 às 18:34, Aaron C. de Bruyn < aaron@heyaaron.com> escreveu:
My local ISP might have technical, emotional, or cognitive impediments to enabling IPv6...but what it anyone going to do about it? They don't listen to customers. Their sole upstream is Lumen. Gonna get Lumen to refuse to connect with them?
Or maybe get Facebook, YouTube, Netflix and everyone else to just disable
IPv4 (and losing customers)?
There's no incentive to "fix" the "problem".
The person that will begin to solve that you described is you! Choosing with your wallet.
I'm not paying 3x the price to get 1/4 the speed when my IPv4-only local monopoly works just fine. Was there a backup plan for getting everyone to switch to IPv6, or was "vote with your wallet" it? ;) -A
Was there a backup plan for getting everyone to switch to IPv6,
the plan from the ipv6 designers was dual-stack. this was before ipv4 run-out. as dual-stack requires v4 space ~= v6 space, this plan was based on the assumption that the transition would be quick, before ipv4 run-out. there was no backup plan. when the transition was not quick, 42 ingenious transition schemes arose, of varying quality. some have stood the test of time. beyond that, ipv6 has been the biggest promoter of nat ever imagined. randy
On Jun 16, 2026, at 6:36 PM, Randy Bush via NANOG <nanog@lists.nanog.org> wrote:
Was there a backup plan for getting everyone to switch to IPv6,
the plan from the ipv6 designers was dual-stack. this was before ipv4 run-out. as dual-stack requires v4 space ~= v6 space, this plan was based on the assumption that the transition would be quick, before ipv4 run-out.
there was no backup plan.
when the transition was not quick, 42 ingenious transition schemes arose, of varying quality. some have stood the test of time.
Randy - You’re being a bit generous here, as the plan was actually to have “a rational and well-defined transition plan” – that was clearly specified in the "Technical Criteria for Choosing IPng” [RFC 1726] – but alas none of the proposals brought running code to the table… [see attached NANOG email from 5 years back on same topic - that seems to be the periodicity on this particular thread!] There was a decision made that we had to quickly select a winner and proceed anyway, and that meant leaving the transition issue to be solved by a number of new IETF working groups… “dual stack” / ships-in-the-night was definitely not the adopted IPng recommendation (i.e. it was only after that transition work - which mostly focused on tunnels - completely crashed & burned that IETF then retreated to “dual-stack is the answer”…) Luckily, those who had the need – the operator community – stepped up and made solutions happen… Yes, some might say far too many transition schemes, but then again, that’s understandable given the IETF decision to proceed with choosing the IP next generation protocol despite the lack of any actual transition architecture from day one. Thanks, /John p.s. Disclaimers: my words alone. Also, I was a member of the IETF IPng Directorate (not establishing credentials, but rather being complete with disclosing my complicity in the decision making that led to the IPv6 transition fiasco...)
Begin forwarded message:
From: John Curran <jcurran@istaff.org> Subject: Re: IPv6 woes - RFC Date: September 16, 2021 at 5:15:13 AM EDT To: Eliot Lear <lear@ofcourseimright.com> Cc: North American Network Operators' Group <nanog@nanog.org>
On 14 Sep 2021, at 3:46 AM, Eliot Lear <lear@ofcourseimright.com <mailto:lear@ofcourseimright.com>> wrote:
…. There is no evidence that any other design choices on the table at the time would have gotten us transitioned any faster, and a lot of evidence and analysis that the exact opposite is more likely.
Elliot -
If by “design choices” you mean the criteria that we set forth for the new protocol (IPng), then that’s potentially true - it’s fairly challenging to hypothecate what impact different technical criteria would have had on the outcome.
If by “design choices” you mean the tradeoffs accepted in selecting a particular candidate protocol and declaring victory, then I’d strongly disagree. I believe that we had the appropriate technical criteria for IPng (very nicely compiled and edited by Craig Patridge and Frank Kastenholz in RFC1726) and then made conscious decisions to disregard those very criteria in order to “make a decision” & “move forward.”
All of the IPng proposals where completely deficient with respect to transition capabilities. In the rush to make a IPng decision, the actual IPng Transition Criteria [1] that mandated a straightforward transition plan from IPv4 was simply acknowledged and then declared as “resolved" because we would also simultaneously form some working groups to study all of the transition requirements and made good on the transition criteria via future deliverables...(deliverables that were subsequently not delivered on)
The right answer would have been to formally and critically evaluate each of the candidate protocols against the requirements and not make any selection until candidate presented itself that actually met the required technical criteria. Instead, IPv6 transition was left as an afterthought for the operator community to solve, and thus the battles with the IETF on NAT-based transition for nearly two decades to get this basic technical requirement met.
FYI, /John
Disclaimer: my views alone - made from 100% recycled electrons.
=== [1] The actual IPng Transition criteria (per RFC 1726) are as follows -
" 5.5 Transition
CRITERION The protocol must have a straightforward transition plan from the current IPv4.
DISCUSSION A smooth, orderly, transition from IPv4 to IPng is needed. If we can't transition to the new protocol, then no matter how wonderful it is, we'll never get to it.
We believe that it is not possible to have a "flag-day" form of transition in which all hosts and routers must change over at once. The size, complexity, and distributed administration of the Internet make such a cutover impossible.
Rather, IPng will need to co-exist with IPv4 for some period of time. There are a number of ways to achieve this co-existence such as requiring hosts to support two stacks, converting between protocols, or using backward compatible extensions to IPv4. Each scheme has its strengths and weaknesses, which have to be weighed.
Furthermore, we note that, in all probability, there will be IPv4 hosts on the Internet effectively forever. IPng must provide mechanisms to allow these hosts to communicate, even after IPng has become the dominant network layer protocol in the Internet.
The absence of a rational and well-defined transition plan is not acceptable. Indeed, the difficulty of running a network that is transitioning from IPv4 to IPng must be minimized. (A good target is that running a mixed IPv4-IPng network should be no more and preferably less difficult than running IPv4 in parallel with existing non-IP protocols). "
In short:
1) The protocol must have a straightforward transition plan 2) A number of ways to achieve this which are to be explored 3) IPng must provide backward-compatibility to IPv4-only hosts 4) The absence of a well-defined transition plan is not acceptable
===
Am 16.06.26 um 23:34 schrieb Aaron C. de Bruyn via NANOG:
Or maybe get Facebook, YouTube, Netflix and everyone else to just disable IPv4 (and losing customers)?
There will be a point when they are doing this, like they discontinued support for old browsers or mobile phone operating systems. But that means that 80 to 90% of their users needs IPv6 access, so they don't loose too much and push the remaining network operators to provide IPv6. -- Gruß Marco Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
In practice I'm thinking about something where relevant players all sign an agreement to drop ipv4 at their edge in e..g 15 or 20 years.
There's no guarantee that those who are 'relevant' now will also be 15+ years from now. So this will have no practical effect. It's still seen as cheaper to use the wrong technical solutions to avoid V6, and have it be 'good enough', than it is to actually deploy it correctly. Unless this ever changes, the status quo will persist. On Tue, Jun 16, 2026 at 2:34 AM Saku Ytti via NANOG <nanog@lists.nanog.org> wrote:
'ello,
I've babbled about this before, but apparently I'm babbling about it again.
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.
I don't see any future where organically IPv4 dies in such a way that people offering services on the Internet are comfortable offering them IPv6 only, the long tail will be too expensive to ignore.
Dual stack adds complexity, cost, reduces quality and security. It is also blatantly an antitrust issue, as established players with access to large allocations can outcompete new entrants with no IPv4 allocation.
In practice I'm thinking about something where relevant players all sign an agreement to drop ipv4 at their edge in e..g 15 or 20 years. Creating clear business justification for people to implement IPv6 in their next upgrade cycle. Today if I'm an edge with the IPv4 addresses I need, I wouldn't consider IPv6, because that's just a cost to me, with no upside. I know I could get some transit shops to sign off on such an agreement, but no one cares about transit, this obviously doesn't work without Amazon and Facebook et.al.
Sure edges still can have IPv4, but that's like edge having IPX or AppleTalk, it'll be highly local issue, no one expects to reach anywhere with it, and anticipates to translate 100% of external traffic.
Amazon? Facebook? Google? Microsoft? Any appetite?
-- ++ytti _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/E2XOPUM5...
On Tue, 16 Jun 2026 at 15:57, Tom Beecher <beecher@beecher.cc> wrote:
In practice I'm thinking about something where relevant players all sign an agreement to drop ipv4 at their edge in e..g 15 or 20 years.
There's no guarantee that those who are 'relevant' now will also be 15+ years from now. So this will have no practical effect.
Organisation arranging this would ask new players to sign as the situation changes. -- ++ytti
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
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 < nanog@lists.nanog.org> 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/nanog@lists.nanog.org/message/QEOMV5GN...
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 <nanog@lists.nanog.org> 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 < nanog@lists.nanog.org> 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/nanog@lists.nanog.org/message/QEOMV5GN...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ABXC2CER...
Many ISP circuits do not support BGP
LOL On Tue, Jun 16, 2026 at 3:51 PM Arie Vayner <ariev@vayner.net> 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 <nanog@lists.nanog.org> 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 < nanog@lists.nanog.org> 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/nanog@lists.nanog.org/message/QEOMV5GN...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ABXC2CER...
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 <nanog@lists.nanog.org> 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 <nanog@lists.nanog.org> 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 < nanog@lists.nanog.org> 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/nanog@lists.nanog.org/message/QEOMV5GN...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ABXC2CER...
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/BZ6LKHSD...
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 <sronan@ronan-online.com> 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 < nanog@lists.nanog.org> 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 < nanog@lists.nanog.org> 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 < nanog@lists.nanog.org> 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/nanog@lists.nanog.org/message/QEOMV5GN...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ABXC2CER... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/BZ6LKHSD...
On Tue, Jun 16, 2026 at 2:24 PM sronan--- via NANOG <nanog@lists.nanog.org> 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
I have been trying to figure this out for 20 years. Please explain it to me like I'm a 30 year veteran of IPv4 and IPv6 networking, who has been using NAT on his IPv4 upstream connections for decades with failover that "just works". Two residential upstream ISPs, let's call them Winfinity and BTT for the sake of obscurity. Two routers. Each router is monitoring the upstream link. Each router is running NAT to its upstream network. Both routers are participating in VRRP. Default gateway (.1) address priority is tied to the upstream connectivity, with BTT connection having a default priority of 120 and Winfinity having a default priority of 100. Traffic flows through BTT router normally; if BTT connection goes away, health checking on the router decrements VRRP priority by 25, dropping it below that of Winfinity router, and default gateway flips to the other router. Connections drop, a second request goes through, connection re-establishes. Even devices that have static RFC1918 addresses assigned to them "just work" when traffic flips from one upstream to the other. Then we get to IPv6. Each router has a prefix from its upstream provider via DHCPv6-PD. Each downstream interface gets an address from that upstream's delegated prefix. Each host now has prefix information coming from two different routers, and installs two different prefixes. Hosts that use SLAAC or DHCPv6 get addresses dynamically, one from each upstream router. Devices that need static addresses like NFS servers have two addresses, one from each upstream provider's delegated prefix. Default route information is handed out dynamically to autoconfiguring hosts via RAs, since DHCPv6 isn't allowed to pass along default route information. For statically addressed hosts, a static default gateway can be configured to a VRRPv6 link-local v6 address, with all the chaos involved in having to statically assign link-local addresses. Now, when BTT's link goes away, VRRPv6 can change priorities so that the default gateway flips to Winfinity's router. Yay! Unfortunately, there's nothing that tells the downstream host "hey, stop using that address as a source address for connections". So, the host continues trying to use BTT's prefixed address as a source IP for connections, even though the default gateway is now going out through Winfinity. Winfinity, being a good network, sees what looks like IP spoofing going on, and drops the outbound packets. Host keeps trying ineffectively to establish an outbound connection using the BTT prefix address, because there's no way to signal the statically addressed host "hey, stop using that prefix as a source address, use the other address you have instead" Eventually, after enough failures, the user gives up and turns off IPv6. So. Tell me again in simple terms a 30 year networking veteran can understand, how exactly you fail over from ISP A to ISP B in an IPv6 world without having your own provider-independent IPv6 block, your own ASN, and BGP sessions going to each upstream network? I will of course slap my thigh and laugh heartily if you say "shim6" at any point in your explanation. ;P If you say "NPTv6" (which I fully expect to be the only reasonable answer you might give), I will agree, but note that removes all the advantages normally claimed by IPv6, and puts us right back into the "might as well just stay with IPv4 forever" scenario--which is fundamentally what we're all dancing around. For small networks, IPv6 fails to provide any significant benefit beyond what people are already experiencing in IPv4 networks behind NAT devices, and we're collectively trying to gaslight each other and the rest of the world into thinking it does. I sincerely hope to be convinced otherwise. :/ Thanks! Matt
If you say "NPTv6" (which I fully expect to be the only reasonable answer you might give), I will agree, but note that removes all the advantages normally claimed by IPv6, and puts us right back into the "might as well just stay with IPv4 forever" scenario--which is fundamentally what we're all dancing around. For small networks, IPv6 fails to provide any significant benefit beyond what people are already experiencing in IPv4 networks behind NAT devices, and we're collectively trying to gaslight each other and the rest of the world into thinking it does.
Alright, here's where I think that's *somewhat* wrong. With NPTv6, you have 1:1 address mapping, so yes, it's effectively NAT in some ways, but it's always a 1-to-1 mapping. Which gets rid of most of the headaches I have with NAT supporting code. The only thing remaining is external address detection, which itself is absolutely trivial (and I do automatically if I detect ULA addressing anyway). That's all that needs to be handled there, so otherwise, you're gaining almost all the no-NAT benefits. Most of the 'it just works' advantages are kept, inbound and outbound are still simple firewall rules, inbound opening is just firewall, etc. If we were all doing 1-to-1 NAT, I don't think many would be arguing the NAT issue at all, except maybe a little bit of processing power overhead. Since in 1:1 NAT scenarios, almost all the NAT problems are eliminated (except, of course, purely just external address detection). Buuuuut we can't do 1-to-1 NAT for every host with IPv4 (at least, most can't!) And that's a problem. So most of the NAT elimination benefits do come fully into play, even in NPT'd networks. -----Original Message----- From: Matthew Petach via NANOG <nanog@lists.nanog.org> Sent: Tuesday, June 16, 2026 9:24 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Matthew Petach <mpetach@netflight.com> Subject: Re: IPv4 flag day On Tue, Jun 16, 2026 at 2:24 PM sronan--- via NANOG <nanog@lists.nanog.org> 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
I have been trying to figure this out for 20 years. Please explain it to me like I'm a 30 year veteran of IPv4 and IPv6 networking, who has been using NAT on his IPv4 upstream connections for decades with failover that "just works". Two residential upstream ISPs, let's call them Winfinity and BTT for the sake of obscurity. Two routers. Each router is monitoring the upstream link. Each router is running NAT to its upstream network. Both routers are participating in VRRP. Default gateway (.1) address priority is tied to the upstream connectivity, with BTT connection having a default priority of 120 and Winfinity having a default priority of 100. Traffic flows through BTT router normally; if BTT connection goes away, health checking on the router decrements VRRP priority by 25, dropping it below that of Winfinity router, and default gateway flips to the other router. Connections drop, a second request goes through, connection re-establishes. Even devices that have static RFC1918 addresses assigned to them "just work" when traffic flips from one upstream to the other. Then we get to IPv6. Each router has a prefix from its upstream provider via DHCPv6-PD. Each downstream interface gets an address from that upstream's delegated prefix. Each host now has prefix information coming from two different routers, and installs two different prefixes. Hosts that use SLAAC or DHCPv6 get addresses dynamically, one from each upstream router. Devices that need static addresses like NFS servers have two addresses, one from each upstream provider's delegated prefix. Default route information is handed out dynamically to autoconfiguring hosts via RAs, since DHCPv6 isn't allowed to pass along default route information. For statically addressed hosts, a static default gateway can be configured to a VRRPv6 link-local v6 address, with all the chaos involved in having to statically assign link-local addresses. Now, when BTT's link goes away, VRRPv6 can change priorities so that the default gateway flips to Winfinity's router. Yay! Unfortunately, there's nothing that tells the downstream host "hey, stop using that address as a source address for connections". So, the host continues trying to use BTT's prefixed address as a source IP for connections, even though the default gateway is now going out through Winfinity. Winfinity, being a good network, sees what looks like IP spoofing going on, and drops the outbound packets. Host keeps trying ineffectively to establish an outbound connection using the BTT prefix address, because there's no way to signal the statically addressed host "hey, stop using that prefix as a source address, use the other address you have instead" Eventually, after enough failures, the user gives up and turns off IPv6. So. Tell me again in simple terms a 30 year networking veteran can understand, how exactly you fail over from ISP A to ISP B in an IPv6 world without having your own provider-independent IPv6 block, your own ASN, and BGP sessions going to each upstream network? I will of course slap my thigh and laugh heartily if you say "shim6" at any point in your explanation. ;P If you say "NPTv6" (which I fully expect to be the only reasonable answer you might give), I will agree, but note that removes all the advantages normally claimed by IPv6, and puts us right back into the "might as well just stay with IPv4 forever" scenario--which is fundamentally what we're all dancing around. For small networks, IPv6 fails to provide any significant benefit beyond what people are already experiencing in IPv4 networks behind NAT devices, and we're collectively trying to gaslight each other and the rest of the world into thinking it does. I sincerely hope to be convinced otherwise. :/ Thanks! Matt _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/CVZPQRAI...
Has any CPE vendor implemented the redundancy NPTv6 scheme (with all IPv6 features) that Matthew mentioned for NAT44? Reminder: 6man WG makes all possible efforts to block NPTv6. Ed/
-----Original Message----- From: Gary Sparkes via NANOG <nanog@lists.nanog.org> Sent: Wednesday, June 17, 2026 04:42 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Gary Sparkes <gary@kisaracorporation.com> Subject: RE: IPv4 flag day
If you say "NPTv6" (which I fully expect to be the only reasonable answer you might give), I will agree, but note that removes all the advantages normally claimed by IPv6, and puts us right back into the "might as well just stay with IPv4 forever" scenario--which is fundamentally what we're all dancing around. For small networks, IPv6 fails to provide any significant benefit beyond what people are already experiencing in IPv4 networks behind NAT devices, and we're collectively trying to gaslight each other and the rest of the world into thinking it does.
Alright, here's where I think that's *somewhat* wrong.
With NPTv6, you have 1:1 address mapping, so yes, it's effectively NAT in some ways, but it's always a 1-to-1 mapping. Which gets rid of most of the headaches I have with NAT supporting code.
The only thing remaining is external address detection, which itself is absolutely trivial (and I do automatically if I detect ULA addressing anyway). That's all that needs to be handled there, so otherwise, you're gaining almost all the no-NAT benefits.
Most of the 'it just works' advantages are kept, inbound and outbound are still simple firewall rules, inbound opening is just firewall, etc.
If we were all doing 1-to-1 NAT, I don't think many would be arguing the NAT issue at all, except maybe a little bit of processing power overhead. Since in 1:1 NAT scenarios, almost all the NAT problems are eliminated (except, of course, purely just external address detection).
Buuuuut we can't do 1-to-1 NAT for every host with IPv4 (at least, most can't!) And that's a problem.
So most of the NAT elimination benefits do come fully into play, even in NPT'd networks.
-----Original Message----- From: Matthew Petach via NANOG <nanog@lists.nanog.org> Sent: Tuesday, June 16, 2026 9:24 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Matthew Petach <mpetach@netflight.com> Subject: Re: IPv4 flag day
On Tue, Jun 16, 2026 at 2:24 PM sronan--- via NANOG <nanog@lists.nanog.org> 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
I have been trying to figure this out for 20 years.
Please explain it to me like I'm a 30 year veteran of IPv4 and IPv6 networking, who has been using NAT on his IPv4 upstream connections for decades with failover that "just works".
Two residential upstream ISPs, let's call them Winfinity and BTT for the sake of obscurity.
Two routers. Each router is monitoring the upstream link. Each router is running NAT to its upstream network. Both routers are participating in VRRP. Default gateway (.1) address priority is tied to the upstream connectivity, with BTT connection having a default priority of 120 and Winfinity having a default priority of 100. Traffic flows through BTT router normally; if BTT connection goes away, health checking on the router decrements VRRP priority by 25, dropping it below that of Winfinity router, and default gateway flips to the other router. Connections drop, a second request goes through, connection re-establishes. Even devices that have static RFC1918 addresses assigned to them "just work" when traffic flips from one upstream to the other.
Then we get to IPv6.
Each router has a prefix from its upstream provider via DHCPv6-PD. Each downstream interface gets an address from that upstream's delegated prefix.
Each host now has prefix information coming from two different routers, and installs two different prefixes. Hosts that use SLAAC or DHCPv6 get addresses dynamically, one from each upstream router.
Devices that need static addresses like NFS servers have two addresses, one from each upstream provider's delegated prefix.
Default route information is handed out dynamically to autoconfiguring hosts via RAs, since DHCPv6 isn't allowed to pass along default route information.
For statically addressed hosts, a static default gateway can be configured to a VRRPv6 link-local v6 address, with all the chaos involved in having to statically assign link-local addresses.
Now, when BTT's link goes away, VRRPv6 can change priorities so that the default gateway flips to Winfinity's router. Yay!
Unfortunately, there's nothing that tells the downstream host "hey, stop using that address as a source address for connections". So, the host continues trying to use BTT's prefixed address as a source IP for connections, even though the default gateway is now going out through Winfinity. Winfinity, being a good network, sees what looks like IP spoofing going on, and drops the outbound packets.
Host keeps trying ineffectively to establish an outbound connection using the BTT prefix address, because there's no way to signal the statically addressed host "hey, stop using that prefix as a source address, use the other address you have instead" Eventually, after enough failures, the user gives up and turns off IPv6.
So.
Tell me again in simple terms a 30 year networking veteran can understand, how exactly you fail over from ISP A to ISP B in an IPv6 world without having your own provider-independent IPv6 block, your own ASN, and BGP sessions going to each upstream network?
I will of course slap my thigh and laugh heartily if you say "shim6" at any point in your explanation. ;P
If you say "NPTv6" (which I fully expect to be the only reasonable answer you might give), I will agree, but note that removes all the advantages normally claimed by IPv6, and puts us right back into the "might as well just stay with IPv4 forever" scenario--which is fundamentally what we're all dancing around. For small networks, IPv6 fails to provide any significant benefit beyond what people are already experiencing in IPv4 networks behind NAT devices, and we're collectively trying to gaslight each other and the rest of the world into thinking it does.
I sincerely hope to be convinced otherwise. :/
Thanks!
Matt _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/CVZPQR AI52OKYTOMFQTXD6BT44M2HMW4/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ATLSCTI QKKNR7F3FHGQQQ3IVJ5JI6EP5/
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.
Reminder: 6man WG makes all possible efforts to block NPTv6.
It already exists, IIRC Cisco IOS supports that. -- Gruß Marco Muell und Spam bitte an abfalleimer2002@stinkedores.dorfdsl.de
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/64HPVUSE...
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/64HPVUSE...
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/TXYK36SD...
On Wed, Jun 17, 2026 at 11:45:22AM -0400, Brandon Jackson via NANOG wrote:
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?
I was rather surprised to find that the Ubiquiti Unifi box I bought to play with allows NAT66/NPT -- it just warns that you lose hardware acceleration. My testing shows that the CPU is sufficient for my typical home traffic. As an aside: Today, there are a lot of software based routing implementations that get close to parity with "big boy" router features. If you have enough CPU interrupts to deal with your traffic volume, you may not meed as many ASICs as you did in the past.
Unifi and edgeOS, are two completely different things, nowhere near related at all other than the company who made them. That being said, Unfi is just now barely starting to get any kind of IPv6 support and recognition, but again its Ubiquiti, so it's still rather crappy. ---------------------------------- Brandon Jackson bojack1437@gmail.com On Wed, Jun 17, 2026, 12:23 John Osmon <josmon@rigozsaurus.com> wrote:
On Wed, Jun 17, 2026 at 11:45:22AM -0400, Brandon Jackson via NANOG wrote:
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?
I was rather surprised to find that the Ubiquiti Unifi box I bought to play with allows NAT66/NPT -- it just warns that you lose hardware acceleration. My testing shows that the CPU is sufficient for my typical home traffic.
As an aside: Today, there are a lot of software based routing implementations that get close to parity with "big boy" router features. If you have enough CPU interrupts to deal with your traffic volume, you may not meed as many ASICs as you did in the past.
On Wed, 17 Jun 2026 at 19:24, John Osmon via NANOG <nanog@lists.nanog.org> wrote:
I was rather surprised to find that the Ubiquiti Unifi box I bought to play with allows NAT66/NPT -- it just warns that you lose hardware acceleration. My testing shows that the CPU is sufficient for my typical home traffic.
As an aside: Today, there are a lot of software based routing implementations that get close to parity with "big boy" router features. If you have enough CPU interrupts to deal with your traffic volume, you may not meed as many ASICs as you did in the past.
I remember way back when, maybe decade or two ago, big IPv6 kooks like O et.al. saying how IPv6 will never get NAT much less NAPT. Even back then, there were several implementations. The biggest mistake of these well meaning IPv6 kooks are, that they wanted to force their opinions on what IP should be, when the actual problem at hand is simply 'not enough addresses'. Give people everything they do today, NAPT, DHCP (slaacless) etc. Just more addresses. It's fine, we can do it, there are absolutely no hard problems to solve. Just IPv4 + more addresses. https://weberblog.net/fortigate-enables-nat-for-ipv6-by-default-%f0%9f%a4%a6... If I read this right, fortigate out of box does IPv6 NAPT. I've told for decades to every enterprise asking about IPv6, to do ULA (with lucky random of 0) and 1:1 NAT to provider addresses, never deploy any provider IP addresses. Either own PA or ULA+NAT. But even 1:1 NAT may be forcing people to do something they don't want to care about, and IPv6 NAPT as default may be the right choice. It's their edge, let them do what they want to do, no matter how wrong we think it is. We just need the addresses, so that we stop creating monopolies. -- ++ytti
The point I've been trying to make is beyond specific support on specific platforms, or even beyond the specific SMB-Dual-Internet NAT use case (but I do believe it's a major gap). The point is about best practices, documentation, and industry guidance. Every book, document or standard right now says "IPv6 doesn't support NAT and you shouldn't be using it". It also has a list of complicated "best practices" (e.g. host based public prefix selection). These things confuse the average operator (the audience I'm referring to is not the average CCIE, but the average SMB sysadmin), and most of them are just too busy to care. It's that simple. For the thought experiment... What would be the reaction if someone came on stage at the next NANOG session and presented the NAT66 use case for dual Internet SMBs? Would they get an apploase, or some nasty "questions"? Tnx, Arie On Wed, Jun 17, 2026, 8:45 AM Brandon Jackson via NANOG < nanog@lists.nanog.org> wrote:
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/64HPVUSE... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/TXYK36SD... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/CKUBVOP4...
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/64HPVUSE... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/TXYK36SD... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/CKUBVOP4...
-- Douglas Fernando Fischer Engº de Controle e Automação
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/64HPVUSE... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/TXYK36SD... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/CKUBVOP4...
-- Douglas Fernando Fischer Engº de Controle e Automação _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ZYYE5WTQ...
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/64HPVUSE...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/TXYK36SD...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/CKUBVOP4...
-- Douglas Fernando Fischer Engº de Controle e Automação _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ZYYE5WTQ...
-- Douglas Fernando Fischer Engº de Controle e Automação
On Wed, Jun 17, 2026, 11:20 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.
[...]
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.
So again I ask--are we saying the only answer for uplink redundancy in IPv6 should be to get an ASN and PI address space and add another entry into the DFZ routing table? Or do you have some other solution for redundancy in IPv6 that hasn't been mentioned yet that doesn't involve BGP (which inflates the routing table size) or NAT66 (which breaks the purity of the end to end communication flow you think is the whole purpose of IPv6)? Because if you don't, I think you will have very effectively made my point for why IPv4 is never going to be replaced by IPv6. :/ Matt
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!
Hi Matthew, We did try to list all solutions with all proc and cons: https://datatracker.ietf.org/doc/html/draft-fbnvv-v6ops-site-multihoming-03 We have found 6 solutions, many are very complicated. But actually you are right: practically it's only 2 (BGP and NAT). The draft has been blocked because "it does mention NAT". Eduard
-----Original Message----- From: Matthew Petach via NANOG <nanog@lists.nanog.org> Sent: Thursday, June 18, 2026 03:03 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Marco Moock <mm@dorfdsl.de>; Brandon Jackson <bjackson@napshome.net>; Matthew Petach <mpetach@netflight.com> Subject: Re: IPv4 flag day
On Wed, Jun 17, 2026, 11:20 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.
[...]
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.
So again I ask--are we saying the only answer for uplink redundancy in IPv6 should be to get an ASN and PI address space and add another entry into the DFZ routing table?
Or do you have some other solution for redundancy in IPv6 that hasn't been mentioned yet that doesn't involve BGP (which inflates the routing table size) or NAT66 (which breaks the purity of the end to end communication flow you think is the whole purpose of IPv6)?
Because if you don't, I think you will have very effectively made my point for why IPv4 is never going to be replaced by IPv6. :/
Matt
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!
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/6L6FYA5 XSDFERI3SUQYNYAZFBSBIT6DO/
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/64HPVUSE...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/TXYK36SD...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/CKUBVOP4...
-- Douglas Fernando Fischer Engº de Controle e Automação _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ZYYE5WTQ...
-- Douglas Fernando Fischer Engº de Controle e Automação _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/S3FR5YF5...
Am 18.06.26 um 05:16 schrieb Arie Vayner:
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.
SIP does not work properly with NAT. Used by many companies here, although more and more get rid off their desk phones and replace them by MS teams - even for phone service with the old landline numbers. -- Gruß Marco Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
On Thu, Jun 18, 2026 at 8:14 AM Marco Moock via NANOG <nanog@lists.nanog.org> wrote:
Am 18.06.26 um 05:16 schrieb Arie Vayner:
The SIP and Gaming use cases are a bit of a strawman argument for this
SIP does not work properly with NAT.
SIP clients work just fine with NAT so long as the SIP registration timer is shorter than the NAT UDP state timeout. SIP servers are another matter, but as I might have mentioned I try not to mix servers and NAT. That's just not a good NAT use case. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/
Am 18.06.26 um 18:02 schrieb William Herrin:
SIP servers are another matter, but as I might have mentioned I try not to mix servers and NAT. That's just not a good NAT use case.
I do not know any NAT use case for everyday use where NAT gives any benefit. I use SPI firewalls on the end user machines and the network. NAT only for IPv4 where needed. -- Gruß Marco Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
On Wed, Jun 17, 2026 at 10:39 AM 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.
Hi Douglas, Hate on it all you want, 1:many NAT renders my internal network not just inaccessible from the Internet but inaddressible as well. That's a feature not a bug. It's a feature I want for some of my subnets. When I get around to deploying IPv6 on those subnets it's a feature I will use. You don't have to like it. It's not your network. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/
Makes me remember when I could open windows’ settings and use NetBEUI, NetBios with IPX, with IP… it was actually great: Windows networking would work with any of these. After all they are simply underlying layers. (Space for comments about my heresy praising windows networking: [ ]) IMHO the solution is thereabouts: the protocol shouldn’t matter. Can’t use NAT with IPv6? We shouldn’t care in the upper layers. To me it seems there’s enough effort in making ipv4 or ipv6 good protocols… but not so much on the uppers. *Pedro Martins Prado* pedro.prado@gmail.com / +353 83 036 1875 (FaceTime & WhatsApp) On Thu 18 Jun 2026 at 10:06, William Herrin via NANOG <nanog@lists.nanog.org> wrote:
On Wed, Jun 17, 2026 at 10:39 AM 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.
Hi Douglas,
Hate on it all you want, 1:many NAT renders my internal network not just inaccessible from the Internet but inaddressible as well. That's a feature not a bug. It's a feature I want for some of my subnets. When I get around to deploying IPv6 on those subnets it's a feature I will use. You don't have to like it. It's not your network.
Regards, Bill Herrin
-- For hire. https://bill.herrin.us/resume/ _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/VXIEFJOV...
I can't imagine any case in where the ability to arbitrarily punch through your firewall (as an attacker) once I have any kind of foothold is a good feature. It's explicitly one reason why I highly dislike 1:many NAT, having been party to cleanup of attacks where such technique was leveraged. -----Original Message----- From: William Herrin via NANOG <nanog@lists.nanog.org> Sent: Thursday, June 18, 2026 5:06 AM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: William Herrin <bill@herrin.us> Subject: Re: IPv4 flag day On Wed, Jun 17, 2026 at 10:39 AM 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.
Hi Douglas, Hate on it all you want, 1:many NAT renders my internal network not just inaccessible from the Internet but inaddressible as well. That's a feature not a bug. It's a feature I want for some of my subnets. When I get around to deploying IPv6 on those subnets it's a feature I will use. You don't have to like it. It's not your network. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/VXIEFJOV...
From: William Herrin via NANOG Hate on it all you want, 1:many NAT renders my internal network not just inaccessible from the Internet but inaddressible as well.
On Thu, Jun 18, 2026 at 6:31 AM Gary Sparkes <gary@kisaracorporation.com> wrote:
I can't imagine any case in where the ability to arbitrarily punch through your firewall (as an attacker) once I have any kind of foothold is a good feature.
Gary, With due respect, the issue you raise is not a characteristic specific to NAT-based firewalls. Whether you allow outbound traffic by default is a separate matter from whether you use a NAT with your firewall or another technique. With the exception of the rarely used application proxy firewalls, all can be programmed to allow outbound by default and all can be programmed to deny outbound except as whitelisted. They are equivalent on the question. I usually choose to allow it because security is a tradeoff with utility and disallowing outbound without pre-approval usually has a more expensive loss of utility than the risks it mitigates. I have the same choice to make regardless of whether I've employed NAT on that subnet. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/
My reference was to opening inbound traffic avenues, not outbound. -----Original Message----- From: William Herrin <bill@herrin.us> Sent: Thursday, June 18, 2026 10:20 AM To: Gary Sparkes <gary@kisaracorporation.com> Cc: North American Network Operators Group <nanog@lists.nanog.org> Subject: Re: IPv4 flag day
From: William Herrin via NANOG Hate on it all you want, 1:many NAT renders my internal network not just inaccessible from the Internet but inaddressible as well.
On Thu, Jun 18, 2026 at 6:31 AM Gary Sparkes <gary@kisaracorporation.com> wrote:
I can't imagine any case in where the ability to arbitrarily punch through your firewall (as an attacker) once I have any kind of foothold is a good feature.
Gary, With due respect, the issue you raise is not a characteristic specific to NAT-based firewalls. Whether you allow outbound traffic by default is a separate matter from whether you use a NAT with your firewall or another technique. With the exception of the rarely used application proxy firewalls, all can be programmed to allow outbound by default and all can be programmed to deny outbound except as whitelisted. They are equivalent on the question. I usually choose to allow it because security is a tradeoff with utility and disallowing outbound without pre-approval usually has a more expensive loss of utility than the risks it mitigates. I have the same choice to make regardless of whether I've employed NAT on that subnet. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/
On Thu, Jun 18, 2026 at 7:23 AM Gary Sparkes <gary@kisaracorporation.com> wrote:
My reference was to opening inbound traffic avenues, not outbound.
Then I don't know what you're talking about. Once you have a foothold inside the network, you're past the firewall and the benefits it gave you. Regardless of whether you used NAT. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/
Code running in a browser isn't a concern? That foothold can be extremely minimal, non-persistent, and enable far greater attack/leveraging than otherwise available. But yes, this technique of allowing inbound traffic flows to bypass NAT is something that's somewhat common (STUN servers anyone?) to support NAT legitimately, so it's hard to keep out of the mix. As I've noted in previous parts of this discussion, this is an example of the kind of NAT support network code I've ripped out of applications I maintain. So in 1:many NAT scenarios, it's no longer plug-and-play. But it's far simpler and easier to maintain. -----Original Message----- From: William Herrin <bill@herrin.us> Sent: Thursday, June 18, 2026 10:43 AM To: Gary Sparkes <gary@kisaracorporation.com> Cc: North American Network Operators Group <nanog@lists.nanog.org> Subject: Re: IPv4 flag day On Thu, Jun 18, 2026 at 7:23 AM Gary Sparkes <gary@kisaracorporation.com> wrote:
My reference was to opening inbound traffic avenues, not outbound.
Then I don't know what you're talking about. Once you have a foothold inside the network, you're past the firewall and the benefits it gave you. Regardless of whether you used NAT. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/
On Thu, Jun 18, 2026 at 9:03 AM Gary Sparkes <gary@kisaracorporation.com> wrote:
Code running in a browser isn't a concern? That foothold can be extremely minimal, non-persistent, and enable far greater attack/leveraging than otherwise available.
But yes, this technique of allowing inbound traffic flows to bypass NAT is something that's somewhat common (STUN servers anyone?) to support NAT legitimately, so it's hard to keep out of the mix.
As I've noted in previous parts of this discussion, this is an example of the kind of NAT support network code I've ripped out of applications I maintain. So in 1:many NAT scenarios, it's no longer plug-and-play. But it's far simpler and easier to maintain.
Hi Gary, Configure two firewalls identically. Changing nothing else, configure the second to implement 1:many NAT. Now, demonstrate a use of the technology you describe here where the NAT version of that firewall is more vulnerable than with the one without it. Your claim was that NAT _enables_ the sort of attack you describe. That it is vulnerable when the alternative is not. Show me. No one in this discussion has posited that NAT is a cure-all against every attack vector. I think you're probably arguing against a straw man. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/
I mean, it's precisely why technology like STUN/TURN/ICE exist. To do exactly this. Establish direct connections between hosts over NAT that wouldn't be otherwise possible. But even then, other techniques exist as well. Not every technique works in every NAT setup, but a lot work in most out of application availability necessity. Utilizing NAT to bypass firewalls isn't exactly a new or novel technique. This might be of interest - https://sa.my/pwnat/ - that's one of the 'other techniques' not involving external infrastructure like STUN/TURN/ICE do. As to your ask, with two firewalls, inbound default deny, accept related/established only (So, standard SMB/residential CPE setup), and one having NAT and the other not having NAT, I can..... Drop a box (raspberry pi, for example) inside the network and VPN into it without having to establish a reverse tunnel first. -----Original Message----- From: William Herrin <bill@herrin.us> Sent: Thursday, June 18, 2026 12:18 PM To: Gary Sparkes <gary@kisaracorporation.com> Cc: North American Network Operators Group <nanog@lists.nanog.org> Subject: Re: IPv4 flag day On Thu, Jun 18, 2026 at 9:03 AM Gary Sparkes <gary@kisaracorporation.com> wrote:
Code running in a browser isn't a concern? That foothold can be extremely minimal, non-persistent, and enable far greater attack/leveraging than otherwise available.
But yes, this technique of allowing inbound traffic flows to bypass NAT is something that's somewhat common (STUN servers anyone?) to support NAT legitimately, so it's hard to keep out of the mix.
As I've noted in previous parts of this discussion, this is an example of the kind of NAT support network code I've ripped out of applications I maintain. So in 1:many NAT scenarios, it's no longer plug-and-play. But it's far simpler and easier to maintain.
Hi Gary, Configure two firewalls identically. Changing nothing else, configure the second to implement 1:many NAT. Now, demonstrate a use of the technology you describe here where the NAT version of that firewall is more vulnerable than with the one without it. Your claim was that NAT _enables_ the sort of attack you describe. That it is vulnerable when the alternative is not. Show me. No one in this discussion has posited that NAT is a cure-all against every attack vector. I think you're probably arguing against a straw man. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/
On Thu, Jun 18, 2026 at 10:02 AM Gary Sparkes <gary@kisaracorporation.com> wrote:
I mean, it's precisely why technology like STUN/TURN/ICE exist. As to your ask, with two firewalls, inbound default deny, accept related/established only (So, standard SMB/residential CPE setup), and one having NAT and the other not having NAT, I can.....
Drop a box (raspberry pi, for example) inside the network and VPN into it without having to establish a reverse tunnel first.
I'm sorry, Gary, you're going to establish a VPN to the Pi behind the NAT _without_ the Pi initiating outbound packets and establsihing connection state in the 1:many NAT firewall first? I don't think so. You're going to at least send a set of packets from the Pi to establish state in the NAT firewall. That's how STUN works. TURN flat out defies your conditions: it fully establishes the connection for a reverse tunnel via the external TURN server. And that same set of packets establishes the same state in the non-NAT firewall. You haven't demonstrated your claim that the NAT version is -more- vulnerable to the attack. Meanwhile, I don't claim that the NAT firewall makes a network less vulnerable to this sort of physical infiltration. Merely that there are other common attacks to which it is less vulnerable, even when misconfigured. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/
I never said the Pi wouldn't send outbound packets. This is precisely why I linked pwnat. Because it's what cleanly enables that vector. It's worth a look at, and I've used it (legitimately) to set up a VPN on a network where the ability to configure some network layers was .... limited (terrible CPE).
I'm sorry, Gary, you're going to establish a VPN to the Pi behind the NAT _without_ the Pi initiating outbound packets and establsihing connection state in the 1:many NAT firewall first? I don't think so.
It's just sending ICMP echo packets to a destination that'll never respond and isn't owned or used by the attacker. Any arbitrary destination will work if you know what that is (and, since it's your payload, you configure that). In the "ready to connect" state, all you're seeing on your side is ICMP echos to X.X.X.X failing. I can then connect to your 1.2.3.4 from Y.Y.Y.Y over port XXXX. Allowing me to establish ingress from any arbitrary Y.Y.Y.Y without any knowledge or control of X.X.X.X So there never is, until I go to establish the connection FROM OUTSIDE THE NAT, a state between Y.Y.Y.Y and 1.2.3.4 Effectively, this turns into me establishing a connection from any arbitrary outside address, where I only need to know your external NAT IP, and no state had ever existed between us before. -----Original Message----- From: William Herrin <bill@herrin.us> Sent: Thursday, June 18, 2026 1:45 PM To: Gary Sparkes <gary@kisaracorporation.com> Cc: North American Network Operators Group <nanog@lists.nanog.org> Subject: Re: IPv4 flag day On Thu, Jun 18, 2026 at 10:02 AM Gary Sparkes <gary@kisaracorporation.com> wrote:
I mean, it's precisely why technology like STUN/TURN/ICE exist. As to your ask, with two firewalls, inbound default deny, accept related/established only (So, standard SMB/residential CPE setup), and one having NAT and the other not having NAT, I can.....
Drop a box (raspberry pi, for example) inside the network and VPN into it without having to establish a reverse tunnel first.
I'm sorry, Gary, you're going to establish a VPN to the Pi behind the NAT _without_ the Pi initiating outbound packets and establsihing connection state in the 1:many NAT firewall first? I don't think so. You're going to at least send a set of packets from the Pi to establish state in the NAT firewall. That's how STUN works. TURN flat out defies your conditions: it fully establishes the connection for a reverse tunnel via the external TURN server. And that same set of packets establishes the same state in the non-NAT firewall. You haven't demonstrated your claim that the NAT version is -more- vulnerable to the attack. Meanwhile, I don't claim that the NAT firewall makes a network less vulnerable to this sort of physical infiltration. Merely that there are other common attacks to which it is less vulnerable, even when misconfigured. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/
Gary, Does this depend on cone-NAT or what in the NAT device to create the wider-than-single-IP inbound mapping? Regards, Dorn On Thu, Jun 18, 2026 at 12:19 PM Gary Sparkes via NANOG < nanog@lists.nanog.org> wrote:
I never said the Pi wouldn't send outbound packets.
This is precisely why I linked pwnat. Because it's what cleanly enables that vector. It's worth a look at, and I've used it (legitimately) to set up a VPN on a network where the ability to configure some network layers was .... limited (terrible CPE).
I'm sorry, Gary, you're going to establish a VPN to the Pi behind the NAT _without_ the Pi initiating outbound packets and establsihing connection state in the 1:many NAT firewall first? I don't think so.
It's just sending ICMP echo packets to a destination that'll never respond and isn't owned or used by the attacker. Any arbitrary destination will work if you know what that is (and, since it's your payload, you configure that). In the "ready to connect" state, all you're seeing on your side is ICMP echos to X.X.X.X failing. I can then connect to your 1.2.3.4 from Y.Y.Y.Y over port XXXX.
Allowing me to establish ingress from any arbitrary Y.Y.Y.Y without any knowledge or control of X.X.X.X
So there never is, until I go to establish the connection FROM OUTSIDE THE NAT, a state between Y.Y.Y.Y and 1.2.3.4
Effectively, this turns into me establishing a connection from any arbitrary outside address, where I only need to know your external NAT IP, and no state had ever existed between us before.
-----Original Message----- From: William Herrin <bill@herrin.us> Sent: Thursday, June 18, 2026 1:45 PM To: Gary Sparkes <gary@kisaracorporation.com> Cc: North American Network Operators Group <nanog@lists.nanog.org> Subject: Re: IPv4 flag day
On Thu, Jun 18, 2026 at 10:02 AM Gary Sparkes <gary@kisaracorporation.com> wrote:
I mean, it's precisely why technology like STUN/TURN/ICE exist. As to your ask, with two firewalls, inbound default deny, accept related/established only (So, standard SMB/residential CPE setup), and one having NAT and the other not having NAT, I can.....
Drop a box (raspberry pi, for example) inside the network and VPN into it without having to establish a reverse tunnel first.
I'm sorry, Gary, you're going to establish a VPN to the Pi behind the NAT _without_ the Pi initiating outbound packets and establsihing connection state in the 1:many NAT firewall first? I don't think so. You're going to at least send a set of packets from the Pi to establish state in the NAT firewall. That's how STUN works. TURN flat out defies your conditions: it fully establishes the connection for a reverse tunnel via the external TURN server.
And that same set of packets establishes the same state in the non-NAT firewall. You haven't demonstrated your claim that the NAT version is -more- vulnerable to the attack.
Meanwhile, I don't claim that the NAT firewall makes a network less vulnerable to this sort of physical infiltration. Merely that there are other common attacks to which it is less vulnerable, even when misconfigured.
Regards, Bill Herrin
-- For hire. https://bill.herrin.us/resume/ _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/IUBECNWC...
So, obviously it doesn’t work in ALL NAT configurations, obviously, but it works in most. If you look down here at the how does it work section – https://sa.my/pwnat/ You’re effectively abusing ICMP echo handling. So in their example, the device behind the NAT is sending ICMP’s to 3.3.3.3, which of course, is not replying. “ Server (1.2.3.4): ICMP Echo Request -> 3.3.3.3 ... Server (1.2.3.4): ICMP Echo Request -> 3.3.3.3 ... Server (1.2.3.4): ICMP Echo Request -> 3.3.3.3 ... every 30 seconds ... At this stage, a client wishes to connect Client (6.7.8.9): ICMP Time Exceeded (includes ICMP Echo Request to 3.3.3.3) -> 1.2.3.4 Server's NAT: Sees server's Echo Request in client's Time Exceeded packet, sends entire packet to server because it matches server's outgoing packet Unsure if this works? Just traceroute any host while behind your NAT. You'll notice incoming packets coming in from random IP addresses your router knows nothing about. Your router knows to send those back to you, rather than another client on your network, based off of the data inside the ICMP time exceeded packet. “ From: Dorn Hetzel <dorn@hetzel.org> Sent: Thursday, June 18, 2026 2:23 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: William Herrin <bill@herrin.us>; Gary Sparkes <gary@kisaracorporation.com> Subject: Re: IPv4 flag day Gary, Does this depend on cone-NAT or what in the NAT device to create the wider-than-single-IP inbound mapping? Regards, Dorn On Thu, Jun 18, 2026 at 12:19 PM Gary Sparkes via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: I never said the Pi wouldn't send outbound packets. This is precisely why I linked pwnat. Because it's what cleanly enables that vector. It's worth a look at, and I've used it (legitimately) to set up a VPN on a network where the ability to configure some network layers was .... limited (terrible CPE).
I'm sorry, Gary, you're going to establish a VPN to the Pi behind the NAT _without_ the Pi initiating outbound packets and establsihing connection state in the 1:many NAT firewall first? I don't think so.
It's just sending ICMP echo packets to a destination that'll never respond and isn't owned or used by the attacker. Any arbitrary destination will work if you know what that is (and, since it's your payload, you configure that). In the "ready to connect" state, all you're seeing on your side is ICMP echos to X.X.X.X failing. I can then connect to your 1.2.3.4 from Y.Y.Y.Y over port XXXX. Allowing me to establish ingress from any arbitrary Y.Y.Y.Y without any knowledge or control of X.X.X.X So there never is, until I go to establish the connection FROM OUTSIDE THE NAT, a state between Y.Y.Y.Y and 1.2.3.4 Effectively, this turns into me establishing a connection from any arbitrary outside address, where I only need to know your external NAT IP, and no state had ever existed between us before. -----Original Message----- From: William Herrin <bill@herrin.us<mailto:bill@herrin.us>> Sent: Thursday, June 18, 2026 1:45 PM To: Gary Sparkes <gary@kisaracorporation.com<mailto:gary@kisaracorporation.com>> Cc: North American Network Operators Group <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Subject: Re: IPv4 flag day On Thu, Jun 18, 2026 at 10:02 AM Gary Sparkes <gary@kisaracorporation.com<mailto:gary@kisaracorporation.com>> wrote:
I mean, it's precisely why technology like STUN/TURN/ICE exist. As to your ask, with two firewalls, inbound default deny, accept related/established only (So, standard SMB/residential CPE setup), and one having NAT and the other not having NAT, I can.....
Drop a box (raspberry pi, for example) inside the network and VPN into it without having to establish a reverse tunnel first.
I'm sorry, Gary, you're going to establish a VPN to the Pi behind the NAT _without_ the Pi initiating outbound packets and establsihing connection state in the 1:many NAT firewall first? I don't think so. You're going to at least send a set of packets from the Pi to establish state in the NAT firewall. That's how STUN works. TURN flat out defies your conditions: it fully establishes the connection for a reverse tunnel via the external TURN server. And that same set of packets establishes the same state in the non-NAT firewall. You haven't demonstrated your claim that the NAT version is -more- vulnerable to the attack. Meanwhile, I don't claim that the NAT firewall makes a network less vulnerable to this sort of physical infiltration. Merely that there are other common attacks to which it is less vulnerable, even when misconfigured. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/IUBECNWC...
On Thu, Jun 18, 2026 at 11:18 AM Gary Sparkes <gary@kisaracorporation.com> wrote:
I never said the Pi wouldn't send outbound packets.
It's just sending ICMP echo packets to a destination that'll never respond and isn't owned or used by the attacker. Any arbitrary destination will work if you know what that is (and, since it's your payload, you configure that). In the "ready to connect" state, all you're seeing on your side is ICMP echos to X.X.X.X failing. I can then connect to your 1.2.3.4 from Y.Y.Y.Y over port XXXX.
Allowing me to establish ingress from any arbitrary Y.Y.Y.Y without any knowledge or control of X.X.X.X
So there never is, until I go to establish the connection FROM OUTSIDE THE NAT, a state between Y.Y.Y.Y and 1.2.3.4
Effectively, this turns into me establishing a connection from any arbitrary outside address, where I only need to know your external NAT IP, and no state had ever existed between us before.
Hi Gary, That's pretty convoluted but let's say for the sake of the argument that it works. What stops it from working with the non-NAT firewall? The claim you made against 1:many NAT was, "I can't imagine any case in where the ability to arbitrarily punch through your firewall (as an attacker) once I have any kind of foothold is a good feature." To sustain that claim as an argument against NAT (as opposed to an argument against outbound allow by default), you have to demonstrate an attack where you can punch through a 1:many NAT firewall but can't punch through a comparably configured non-NAT firewall. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/
Simply, the inbound firewall rules prevent it from working. There's no NAT to bypass the firewall to allow the ingress. You'd instead have to open the ingress port on the firewall to allow the traffic. (It does work, as I noted, I've used it for a legitimate customer before) In the non-NAT scenario, the port would have to be allowed through the firewall, or the device behind the NAT would have to connect to *me* at a point or infrastructure that I control. Remember, I am effectively, an unknown address endpoint, *initiating* the connection to the NAT'd device that has no prior knowledge of my address. -----Original Message----- From: William Herrin <bill@herrin.us> Sent: Thursday, June 18, 2026 2:37 PM To: Gary Sparkes <gary@kisaracorporation.com> Cc: North American Network Operators Group <nanog@lists.nanog.org> Subject: Re: IPv4 flag day On Thu, Jun 18, 2026 at 11:18 AM Gary Sparkes <gary@kisaracorporation.com> wrote:
I never said the Pi wouldn't send outbound packets.
It's just sending ICMP echo packets to a destination that'll never respond and isn't owned or used by the attacker. Any arbitrary destination will work if you know what that is (and, since it's your payload, you configure that). In the "ready to connect" state, all you're seeing on your side is ICMP echos to X.X.X.X failing. I can then connect to your 1.2.3.4 from Y.Y.Y.Y over port XXXX.
Allowing me to establish ingress from any arbitrary Y.Y.Y.Y without any knowledge or control of X.X.X.X
So there never is, until I go to establish the connection FROM OUTSIDE THE NAT, a state between Y.Y.Y.Y and 1.2.3.4
Effectively, this turns into me establishing a connection from any arbitrary outside address, where I only need to know your external NAT IP, and no state had ever existed between us before.
Hi Gary, That's pretty convoluted but let's say for the sake of the argument that it works. What stops it from working with the non-NAT firewall? The claim you made against 1:many NAT was, "I can't imagine any case in where the ability to arbitrarily punch through your firewall (as an attacker) once I have any kind of foothold is a good feature." To sustain that claim as an argument against NAT (as opposed to an argument against outbound allow by default), you have to demonstrate an attack where you can punch through a 1:many NAT firewall but can't punch through a comparably configured non-NAT firewall. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/
On Thu, Jun 18, 2026 at 11:41 AM Gary Sparkes <gary@kisaracorporation.com> wrote:
Simply, the inbound firewall rules prevent it from working.
What inbound firewall rules? The requirement was that the firewalls are identical except for NAT. If there's an inbound firewall rule, it's present on the NAT firewall too. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/
Correct, I specified both firewalls have an inbound default deny, accept only related/established. The standard CPE configuration for any NAT scenario, and the usual standard for any non-NAT scenario as well. NAT allows me to *bypass* this. -----Original Message----- From: William Herrin <bill@herrin.us> Sent: Thursday, June 18, 2026 2:49 PM To: Gary Sparkes <gary@kisaracorporation.com> Cc: North American Network Operators Group <nanog@lists.nanog.org> Subject: Re: IPv4 flag day On Thu, Jun 18, 2026 at 11:41 AM Gary Sparkes <gary@kisaracorporation.com> wrote:
Simply, the inbound firewall rules prevent it from working.
What inbound firewall rules? The requirement was that the firewalls are identical except for NAT. If there's an inbound firewall rule, it's present on the NAT firewall too. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/
On Thu, Jun 18, 2026 at 11:52 AM Gary Sparkes <gary@kisaracorporation.com> wrote:
Correct, I specified both firewalls have an inbound default deny, accept only related/established.
The standard CPE configuration for any NAT scenario, and the usual standard for any non-NAT scenario as well.
NAT allows me to *bypass* this.
Hi Gary, You still have not demonstrated that the non-NAT version rejects the packets. You've claimed it but offered no explanation. In your example, you sent ICMP echo-request packets to some random address. This would allow several types of ICMP packets to return to you from arbitrary IP addresses so long as they contained the same ICMP ID. After all, you have to be able to receive destination unreachable messages from intermediate routers. It would not allow UDP or TCP packets to reach you, at least not in the NAT case. Those use different translation tables which are not populated by outbound ICMP packets. The ICMP return packets are allowed in both the NAT case and the non-NAT case: both have state established to accept returns (including error returns) to the ICMP echo-request. Neither one has state established for TCP or UDP. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/
The ICMP echo request scenario is how we do the endpoint discovery so that the server knows the client's address. After that, you start falling into more "standard" NAT traversal techniques between the two endpoints. That's what gets you the established NAT state/session. -----Original Message----- From: William Herrin <bill@herrin.us> Sent: Thursday, June 18, 2026 3:22 PM To: Gary Sparkes <gary@kisaracorporation.com> Cc: North American Network Operators Group <nanog@lists.nanog.org> Subject: Re: IPv4 flag day On Thu, Jun 18, 2026 at 11:52 AM Gary Sparkes <gary@kisaracorporation.com> wrote:
Correct, I specified both firewalls have an inbound default deny, accept only related/established.
The standard CPE configuration for any NAT scenario, and the usual standard for any non-NAT scenario as well.
NAT allows me to *bypass* this.
Hi Gary, You still have not demonstrated that the non-NAT version rejects the packets. You've claimed it but offered no explanation. In your example, you sent ICMP echo-request packets to some random address. This would allow several types of ICMP packets to return to you from arbitrary IP addresses so long as they contained the same ICMP ID. After all, you have to be able to receive destination unreachable messages from intermediate routers. It would not allow UDP or TCP packets to reach you, at least not in the NAT case. Those use different translation tables which are not populated by outbound ICMP packets. The ICMP return packets are allowed in both the NAT case and the non-NAT case: both have state established to accept returns (including error returns) to the ICMP echo-request. Neither one has state established for TCP or UDP. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/
Unless I'm missing something, the pwnat mechanism will actually work through any stateful packet inspection (be it NAT or just a firewall) that allows Traceroute to work. They basically take advantage of ICMP unreachable messages to sneak through the stateful inspection mechanism... So a "malicious" host on your FW inside can basically punch through by creating this "ICMP" hole... Interesting technique for sure. On Thu, Jun 18, 2026, 11:44 AM Gary Sparkes via NANOG <nanog@lists.nanog.org> wrote:
Simply, the inbound firewall rules prevent it from working.
There's no NAT to bypass the firewall to allow the ingress.
You'd instead have to open the ingress port on the firewall to allow the traffic.
(It does work, as I noted, I've used it for a legitimate customer before)
In the non-NAT scenario, the port would have to be allowed through the firewall, or the device behind the NAT would have to connect to *me* at a point or infrastructure that I control.
Remember, I am effectively, an unknown address endpoint, *initiating* the connection to the NAT'd device that has no prior knowledge of my address.
-----Original Message----- From: William Herrin <bill@herrin.us> Sent: Thursday, June 18, 2026 2:37 PM To: Gary Sparkes <gary@kisaracorporation.com> Cc: North American Network Operators Group <nanog@lists.nanog.org> Subject: Re: IPv4 flag day
On Thu, Jun 18, 2026 at 11:18 AM Gary Sparkes <gary@kisaracorporation.com> wrote:
I never said the Pi wouldn't send outbound packets.
It's just sending ICMP echo packets to a destination that'll never respond and isn't owned or used by the attacker. Any arbitrary destination will work if you know what that is (and, since it's your payload, you configure that). In the "ready to connect" state, all you're seeing on your side is ICMP echos to X.X.X.X failing. I can then connect to your 1.2.3.4 from Y.Y.Y.Y over port XXXX.
Allowing me to establish ingress from any arbitrary Y.Y.Y.Y without any knowledge or control of X.X.X.X
So there never is, until I go to establish the connection FROM OUTSIDE THE NAT, a state between Y.Y.Y.Y and 1.2.3.4
Effectively, this turns into me establishing a connection from any arbitrary outside address, where I only need to know your external NAT IP, and no state had ever existed between us before.
Hi Gary,
That's pretty convoluted but let's say for the sake of the argument that it works. What stops it from working with the non-NAT firewall?
The claim you made against 1:many NAT was, "I can't imagine any case in where the ability to arbitrarily punch through your firewall (as an attacker) once I have any kind of foothold is a good feature." To sustain that claim as an argument against NAT (as opposed to an argument against outbound allow by default), you have to demonstrate an attack where you can punch through a 1:many NAT firewall but can't punch through a comparably configured non-NAT firewall.
Regards, Bill Herrin
-- For hire. https://bill.herrin.us/resume/ _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/TYNHRRA4...
The missing part is that we’re *effectively* performing an unsolicited inbound connection. The ICMP part is used to discover the client IP. Then you perform the NAT traversal techniques now that you have that information. The ICMP portion could be leveraged to trigger something behind a non-NAT firewall to connect *out* to something you control (listening server, network you can open inbound ports on, etc). But not unsolicited inbound UDP tunneling from an arbitrary address and network architecture. From: Arie Vayner <ariev@vayner.net> Sent: Thursday, June 18, 2026 3:55 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: William Herrin <bill@herrin.us>; Gary Sparkes <gary@kisaracorporation.com> Subject: Re: IPv4 flag day Unless I'm missing something, the pwnat mechanism will actually work through any stateful packet inspection (be it NAT or just a firewall) that allows Traceroute to work. They basically take advantage of ICMP unreachable messages to sneak through the stateful inspection mechanism... So a "malicious" host on your FW inside can basically punch through by creating this "ICMP" hole... Interesting technique for sure. On Thu, Jun 18, 2026, 11:44 AM Gary Sparkes via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: Simply, the inbound firewall rules prevent it from working. There's no NAT to bypass the firewall to allow the ingress. You'd instead have to open the ingress port on the firewall to allow the traffic. (It does work, as I noted, I've used it for a legitimate customer before) In the non-NAT scenario, the port would have to be allowed through the firewall, or the device behind the NAT would have to connect to *me* at a point or infrastructure that I control. Remember, I am effectively, an unknown address endpoint, *initiating* the connection to the NAT'd device that has no prior knowledge of my address. -----Original Message----- From: William Herrin <bill@herrin.us<mailto:bill@herrin.us>> Sent: Thursday, June 18, 2026 2:37 PM To: Gary Sparkes <gary@kisaracorporation.com<mailto:gary@kisaracorporation.com>> Cc: North American Network Operators Group <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Subject: Re: IPv4 flag day On Thu, Jun 18, 2026 at 11:18 AM Gary Sparkes <gary@kisaracorporation.com<mailto:gary@kisaracorporation.com>> wrote:
I never said the Pi wouldn't send outbound packets.
It's just sending ICMP echo packets to a destination that'll never respond and isn't owned or used by the attacker. Any arbitrary destination will work if you know what that is (and, since it's your payload, you configure that). In the "ready to connect" state, all you're seeing on your side is ICMP echos to X.X.X.X failing. I can then connect to your 1.2.3.4 from Y.Y.Y.Y over port XXXX.
Allowing me to establish ingress from any arbitrary Y.Y.Y.Y without any knowledge or control of X.X.X.X
So there never is, until I go to establish the connection FROM OUTSIDE THE NAT, a state between Y.Y.Y.Y and 1.2.3.4
Effectively, this turns into me establishing a connection from any arbitrary outside address, where I only need to know your external NAT IP, and no state had ever existed between us before.
Hi Gary, That's pretty convoluted but let's say for the sake of the argument that it works. What stops it from working with the non-NAT firewall? The claim you made against 1:many NAT was, "I can't imagine any case in where the ability to arbitrarily punch through your firewall (as an attacker) once I have any kind of foothold is a good feature." To sustain that claim as an argument against NAT (as opposed to an argument against outbound allow by default), you have to demonstrate an attack where you can punch through a 1:many NAT firewall but can't punch through a comparably configured non-NAT firewall. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/TYNHRRA4...
Do I misunderstand, or does it only allow inbound traffic from random hosts *as long as it meets the format of ICMP unreachable* and has the correct contents? On Thu, Jun 18, 2026 at 3:34 PM Arie Vayner via NANOG <nanog@lists.nanog.org> wrote:
Unless I'm missing something, the pwnat mechanism will actually work through any stateful packet inspection (be it NAT or just a firewall) that allows Traceroute to work.
They basically take advantage of ICMP unreachable messages to sneak through the stateful inspection mechanism...
So a "malicious" host on your FW inside can basically punch through by creating this "ICMP" hole...
Interesting technique for sure.
On Thu, Jun 18, 2026, 11:44 AM Gary Sparkes via NANOG < nanog@lists.nanog.org> wrote:
Simply, the inbound firewall rules prevent it from working.
There's no NAT to bypass the firewall to allow the ingress.
You'd instead have to open the ingress port on the firewall to allow the traffic.
(It does work, as I noted, I've used it for a legitimate customer before)
In the non-NAT scenario, the port would have to be allowed through the firewall, or the device behind the NAT would have to connect to *me* at a point or infrastructure that I control.
Remember, I am effectively, an unknown address endpoint, *initiating* the connection to the NAT'd device that has no prior knowledge of my address.
-----Original Message----- From: William Herrin <bill@herrin.us> Sent: Thursday, June 18, 2026 2:37 PM To: Gary Sparkes <gary@kisaracorporation.com> Cc: North American Network Operators Group <nanog@lists.nanog.org> Subject: Re: IPv4 flag day
On Thu, Jun 18, 2026 at 11:18 AM Gary Sparkes < gary@kisaracorporation.com> wrote:
I never said the Pi wouldn't send outbound packets.
It's just sending ICMP echo packets to a destination that'll never respond and isn't owned or used by the attacker. Any arbitrary destination will work if you know what that is (and, since it's your payload, you configure that). In the "ready to connect" state, all you're seeing on your side is ICMP echos to X.X.X.X failing. I can then connect to your 1.2.3.4 from Y.Y.Y.Y over port XXXX.
Allowing me to establish ingress from any arbitrary Y.Y.Y.Y without any knowledge or control of X.X.X.X
So there never is, until I go to establish the connection FROM OUTSIDE THE NAT, a state between Y.Y.Y.Y and 1.2.3.4
Effectively, this turns into me establishing a connection from any arbitrary outside address, where I only need to know your external NAT IP, and no state had ever existed between us before.
Hi Gary,
That's pretty convoluted but let's say for the sake of the argument that it works. What stops it from working with the non-NAT firewall?
The claim you made against 1:many NAT was, "I can't imagine any case in where the ability to arbitrarily punch through your firewall (as an attacker) once I have any kind of foothold is a good feature." To sustain that claim as an argument against NAT (as opposed to an argument against outbound allow by default), you have to demonstrate an attack where you can punch through a 1:many NAT firewall but can't punch through a comparably configured non-NAT firewall.
Regards, Bill Herrin
-- For hire. https://bill.herrin.us/resume/ _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/TYNHRRA4... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/LYNHL7WX...
ICMP Time Exceeded, not unreachable. In this case we’re abusing that ICMP Time Exceeded packet to communicate to the host behind the NAT the client-side IP. Then all the magic can light up between the two endpoints. From: Dorn Hetzel <dorn@hetzel.org> Sent: Thursday, June 18, 2026 5:46 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Gary Sparkes <gary@kisaracorporation.com>; Arie Vayner <ariev@vayner.net> Subject: Re: IPv4 flag day Do I misunderstand, or does it only allow inbound traffic from random hosts *as long as it meets the format of ICMP unreachable* and has the correct contents? On Thu, Jun 18, 2026 at 3:34 PM Arie Vayner via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: Unless I'm missing something, the pwnat mechanism will actually work through any stateful packet inspection (be it NAT or just a firewall) that allows Traceroute to work. They basically take advantage of ICMP unreachable messages to sneak through the stateful inspection mechanism... So a "malicious" host on your FW inside can basically punch through by creating this "ICMP" hole... Interesting technique for sure. On Thu, Jun 18, 2026, 11:44 AM Gary Sparkes via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote:
Simply, the inbound firewall rules prevent it from working.
There's no NAT to bypass the firewall to allow the ingress.
You'd instead have to open the ingress port on the firewall to allow the traffic.
(It does work, as I noted, I've used it for a legitimate customer before)
In the non-NAT scenario, the port would have to be allowed through the firewall, or the device behind the NAT would have to connect to *me* at a point or infrastructure that I control.
Remember, I am effectively, an unknown address endpoint, *initiating* the connection to the NAT'd device that has no prior knowledge of my address.
-----Original Message----- From: William Herrin <bill@herrin.us<mailto:bill@herrin.us>> Sent: Thursday, June 18, 2026 2:37 PM To: Gary Sparkes <gary@kisaracorporation.com<mailto:gary@kisaracorporation.com>> Cc: North American Network Operators Group <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Subject: Re: IPv4 flag day
On Thu, Jun 18, 2026 at 11:18 AM Gary Sparkes <gary@kisaracorporation.com<mailto:gary@kisaracorporation.com>> wrote:
I never said the Pi wouldn't send outbound packets.
It's just sending ICMP echo packets to a destination that'll never respond and isn't owned or used by the attacker. Any arbitrary destination will work if you know what that is (and, since it's your payload, you configure that). In the "ready to connect" state, all you're seeing on your side is ICMP echos to X.X.X.X failing. I can then connect to your 1.2.3.4 from Y.Y.Y.Y over port XXXX.
Allowing me to establish ingress from any arbitrary Y.Y.Y.Y without any knowledge or control of X.X.X.X
So there never is, until I go to establish the connection FROM OUTSIDE THE NAT, a state between Y.Y.Y.Y and 1.2.3.4
Effectively, this turns into me establishing a connection from any arbitrary outside address, where I only need to know your external NAT IP, and no state had ever existed between us before.
Hi Gary,
That's pretty convoluted but let's say for the sake of the argument that it works. What stops it from working with the non-NAT firewall?
The claim you made against 1:many NAT was, "I can't imagine any case in where the ability to arbitrarily punch through your firewall (as an attacker) once I have any kind of foothold is a good feature." To sustain that claim as an argument against NAT (as opposed to an argument against outbound allow by default), you have to demonstrate an attack where you can punch through a 1:many NAT firewall but can't punch through a comparably configured non-NAT firewall.
Regards, Bill Herrin
-- For hire. https://bill.herrin.us/resume/ _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/TYNHRRA4...
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/LYNHL7WX...
Can we agree NAT is NOT a Firewall first?
On Jun 18, 2026, at 1:45 PM, William Herrin via NANOG <nanog@lists.nanog.org> wrote:
On Thu, Jun 18, 2026 at 10:02 AM Gary Sparkes <gary@kisaracorporation.com> wrote:
I mean, it's precisely why technology like STUN/TURN/ICE exist. As to your ask, with two firewalls, inbound default deny, accept related/established only (So, standard SMB/residential CPE setup), and one having NAT and the other not having NAT, I can.....
Drop a box (raspberry pi, for example) inside the network and VPN into it without having to establish a reverse tunnel first.
I'm sorry, Gary, you're going to establish a VPN to the Pi behind the NAT _without_ the Pi initiating outbound packets and establsihing connection state in the 1:many NAT firewall first? I don't think so. You're going to at least send a set of packets from the Pi to establish state in the NAT firewall. That's how STUN works. TURN flat out defies your conditions: it fully establishes the connection for a reverse tunnel via the external TURN server.
And that same set of packets establishes the same state in the non-NAT firewall. You haven't demonstrated your claim that the NAT version is -more- vulnerable to the attack.
Meanwhile, I don't claim that the NAT firewall makes a network less vulnerable to this sort of physical infiltration. Merely that there are other common attacks to which it is less vulnerable, even when misconfigured.
Regards, Bill Herrin
-- For hire. https://bill.herrin.us/resume/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/V7CEX3NO...
On Thu, Jun 18, 2026 at 11:26 AM <sronan@ronan-online.com> wrote:
Can we agree NAT is NOT a Firewall first?
1:Many NAT (sometimes called PAT) uses a stateful packet inspection firewall as an inherent part of its technology core. It can't exist without that firewall technology. While 1:1 NAT does exist and does not require any firewall technology, it sees so little use that the module for stateless 1:1 IPv4 NAT was dropped from the Linux kernel more than a decade ago. So no, we can't agree to a statement that's objectively false. Kinda sad that the kernel devs dropped it actually. I had a great use for 1:1 NAT to work around an AWS limitation in 2017 but ended up having to use Linux's stateful NAT instead. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/
Am 18.06.26 um 20:52 schrieb William Herrin via NANOG:
Kinda sad that the kernel devs dropped it actually. I had a great use for 1:1 NAT to work around an AWS limitation in 2017 but ended up having to use Linux's stateful NAT instead.
In such a case I use the address space a /64 gives me - much easier. -- Gruß Marco Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
Am 18.06.26 um 11:06 schrieb William Herrin via NANOG:
Hate on it all you want, 1:many NAT renders my internal network not just inaccessible from the Internet but inaddressible as well. That's a feature not a bug. It's a feature I want for some of my subnets. When I get around to deploying IPv6 on those subnets it's a feature I will use. You don't have to like it. It's not your network.
What you are looking for is called SPI firewall. Customer CPE has it, Windows has it, Linux has it, FreeBSD has it. -- Gruß Marco Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
On Thu, Jun 18, 2026 at 7:29 AM Marco Moock via NANOG <nanog@lists.nanog.org> wrote:
Am 18.06.26 um 11:06 schrieb William Herrin via NANOG:
Hate on it all you want, 1:many NAT renders my internal network not just inaccessible from the Internet but inaddressible as well.
What you are looking for is called SPI firewall.
Hi Marco, I'm almost never looking for a stateful packet inspector that isn't doing NAT. Stateful gives it most of the same drawbacks of NAT without the benefit of making my internal network inaddressible from outside. But YMMV: a lot of folks don't have the comfort level with stateless packet filters that I do, and SPIs do offer some additional protection to hosts intended to be reached from the Internet. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/
Am 18.06.26 um 16:42 schrieb William Herrin:
I'm almost never looking for a stateful packet inspector that isn't doing NAT. Stateful gives it most of the same drawbacks of NAT without the benefit of making my internal network inaddressible from outside. But YMMV: a lot of folks don't have the comfort level with stateless packet filters that I do, and SPIs do offer some additional protection to hosts intended to be reached from the Internet.
If you really want, you can combine SPI firewalling with NAT66 (1:1 matching if you want). For me, NAT and the aspect that the machines are not addressable from the outside is a large disadvantage. I do whatever I can with IPv6. -- Gruß Marco Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
On Thu, Jun 18, 2026 at 8:11 AM Marco Moock via NANOG <nanog@lists.nanog.org> wrote:
Am 18.06.26 um 16:42 schrieb William Herrin:
I'm almost never looking for a stateful packet inspector that isn't doing NAT.
If you really want, you can combine SPI firewalling with NAT66 (1:1 matching if you want).
I struggle to imagine a scenario where I would want that.
For me, NAT and the aspect that the machines are not addressable from the outside is a large disadvantage.
For me, it's situational. When I intend for a machine to provide services to the Internet, I prefer that it be accesible from the Internet without the complication of a stateful middlebox or packet translation. When I don't, any additional protection I can get without causing a hassle to myself is a boon. Since I know that mistakes are common, including my own, I prefer protection mechanisms which have a tough time failing unnoticed. When that SPI firewall fails to open routing, there's nothing to notice. Every application that was working before is still working after. That scenario is literally impossible with a 1:many NAT firewall. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/
Ole Trøan did try to resolve multihoming in "Home networking" 14 years ago. Brian E. Carpenter did try to resolve multihoming in "Site Multihoming by IPv6 Intermediation" 20 years ago. Both failed for different reasons. Both were doing it outside of 6man WG. Ed/
-----Original Message----- From: Matthew Petach via NANOG <nanog@lists.nanog.org> Sent: Wednesday, June 17, 2026 18:29 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Marco Moock <mm@dorfdsl.de>; Matthew Petach <mpetach@netflight.com> Subject: Re: IPv4 flag day
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/64 HPVUSE2EXJH664UAY3T4YJX2G3VQET/
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/TXYK36S DIONPF72NKIEY6XHR7DDCBD7G/
On Tue, Jun 16, 2026 at 06:23:37PM -0700, Matthew Petach via NANOG wrote: [... lots of "NATv4 is simple, IPv6 is complex" elided...]
For small networks, IPv6 fails to provide any significant benefit beyond what people are already experiencing in IPv4 networks behind NAT devices, and we're collectively trying to gaslight each other and the rest of the world into thinking it does.
By "small networks" you really mean "any network where proxy access to the Internet is sufficient." There's a lot of those. Some of them are rather large. The devices behind the NAT aren't on the Internet -- the NAT is, and it proxies for them. NAT overload/IP masquerade/PAT all work with IPv6 too. So number your local LANs in ULA, and do that all you want. Modulo some address selection issues, this works quite well. So -- we have parity in IPv4/6 if we can just get an RFC out the door that defines how NAT should be done to avoid 20 years of creating middleware that takes care of corner cases.
I sincerely hope to be convinced otherwise. :/
I won't try to convince you of anything. I'll agree that you're right. We gave up trying to give every host a unique address -- proxies were sufficient for them to get to the services they really wanted. However -- we WILL run into a day in the future where the IPv4 address space isn't sufficient to number all of the required service/proxy endpoints. So we SHOULD be perfecting the alternatives.
John,
NAT overload/IP masquerade/PAT all work with IPv6 too. So number your local LANs in ULA, and do that all you want. Modulo some address selection issues, this works quite well.
So -- we have parity in IPv4/6 if we can just get an RFC out the door that defines how NAT should be done to avoid 20 years of creating middleware that takes care of corner cases.
I totally agree! This is the real gap I was alluding to. I believe that the path of least resistance for IPv6 in Enterprise space is to make IPv6 "feel the same as IPv4" for the average sysadmin. Tnx Arie On Tue, Jun 16, 2026 at 8:43 PM John Osmon via NANOG <nanog@lists.nanog.org> wrote:
On Tue, Jun 16, 2026 at 06:23:37PM -0700, Matthew Petach via NANOG wrote:
[... lots of "NATv4 is simple, IPv6 is complex" elided...]
For small networks, IPv6 fails to provide any significant benefit beyond what people are already experiencing in IPv4 networks behind NAT devices, and we're collectively trying to gaslight each other and the rest of the world into thinking it does.
By "small networks" you really mean "any network where proxy access to the Internet is sufficient." There's a lot of those. Some of them are rather large. The devices behind the NAT aren't on the Internet -- the NAT is, and it proxies for them.
NAT overload/IP masquerade/PAT all work with IPv6 too. So number your local LANs in ULA, and do that all you want. Modulo some address selection issues, this works quite well.
So -- we have parity in IPv4/6 if we can just get an RFC out the door that defines how NAT should be done to avoid 20 years of creating middleware that takes care of corner cases.
I sincerely hope to be convinced otherwise. :/
I won't try to convince you of anything. I'll agree that you're right.
We gave up trying to give every host a unique address -- proxies were sufficient for them to get to the services they really wanted.
However -- we WILL run into a day in the future where the IPv4 address space isn't sufficient to number all of the required service/proxy endpoints. So we SHOULD be perfecting the alternatives.
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/WG4UM4BP...
Am 17.06.26 um 03:23 schrieb Matthew Petach via NANOG:
Each router has a prefix from its upstream provider via DHCPv6-PD. Each downstream interface gets an address from that upstream's delegated prefix.
In that situation you can use stateful NAT66, like you do for IPv4. With all the disadvantages this has. -- Gruß Marco Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
I did believe too that the absence of redundancy for SMB/SOHO is the blocking factor for IPv6 deployment (and send a few messages here). I am not so sure now. Of course, 6man would not fix it - they could not find a consensus for much smaller things. But redundancy may not be needed in the future. The internet is monopolizing very fast. It would finish with 10 load balancer addresses (different 10 addresses for different countries) soon, 5 addresses would be OTTs and additional 5 would be CDN providers to host small businesses. Hosted businesses would not need internet connection redundancy anymore, CDN provider would do it for them. The Internet monopolization may help with IPv6 adoption. PS: Have you spotted how many abandoned web sites on the Internet? Eduard
-----Original Message----- From: Matthew Petach via NANOG <nanog@lists.nanog.org> Sent: Wednesday, June 17, 2026 04:24 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Matthew Petach <mpetach@netflight.com> Subject: Re: IPv4 flag day
On Tue, Jun 16, 2026 at 2:24 PM sronan--- via NANOG <nanog@lists.nanog.org> 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
I have been trying to figure this out for 20 years.
Please explain it to me like I'm a 30 year veteran of IPv4 and IPv6 networking, who has been using NAT on his IPv4 upstream connections for decades with failover that "just works".
Two residential upstream ISPs, let's call them Winfinity and BTT for the sake of obscurity.
Two routers. Each router is monitoring the upstream link. Each router is running NAT to its upstream network. Both routers are participating in VRRP. Default gateway (.1) address priority is tied to the upstream connectivity, with BTT connection having a default priority of 120 and Winfinity having a default priority of 100. Traffic flows through BTT router normally; if BTT connection goes away, health checking on the router decrements VRRP priority by 25, dropping it below that of Winfinity router, and default gateway flips to the other router. Connections drop, a second request goes through, connection re-establishes. Even devices that have static RFC1918 addresses assigned to them "just work" when traffic flips from one upstream to the other.
Then we get to IPv6.
Each router has a prefix from its upstream provider via DHCPv6-PD. Each downstream interface gets an address from that upstream's delegated prefix.
Each host now has prefix information coming from two different routers, and installs two different prefixes. Hosts that use SLAAC or DHCPv6 get addresses dynamically, one from each upstream router.
Devices that need static addresses like NFS servers have two addresses, one from each upstream provider's delegated prefix.
Default route information is handed out dynamically to autoconfiguring hosts via RAs, since DHCPv6 isn't allowed to pass along default route information.
For statically addressed hosts, a static default gateway can be configured to a VRRPv6 link-local v6 address, with all the chaos involved in having to statically assign link-local addresses.
Now, when BTT's link goes away, VRRPv6 can change priorities so that the default gateway flips to Winfinity's router. Yay!
Unfortunately, there's nothing that tells the downstream host "hey, stop using that address as a source address for connections". So, the host continues trying to use BTT's prefixed address as a source IP for connections, even though the default gateway is now going out through Winfinity. Winfinity, being a good network, sees what looks like IP spoofing going on, and drops the outbound packets.
Host keeps trying ineffectively to establish an outbound connection using the BTT prefix address, because there's no way to signal the statically addressed host "hey, stop using that prefix as a source address, use the other address you have instead" Eventually, after enough failures, the user gives up and turns off IPv6.
So.
Tell me again in simple terms a 30 year networking veteran can understand, how exactly you fail over from ISP A to ISP B in an IPv6 world without having your own provider-independent IPv6 block, your own ASN, and BGP sessions going to each upstream network?
I will of course slap my thigh and laugh heartily if you say "shim6" at any point in your explanation. ;P
If you say "NPTv6" (which I fully expect to be the only reasonable answer you might give), I will agree, but note that removes all the advantages normally claimed by IPv6, and puts us right back into the "might as well just stay with IPv4 forever" scenario--which is fundamentally what we're all dancing around. For small networks, IPv6 fails to provide any significant benefit beyond what people are already experiencing in IPv4 networks behind NAT devices, and we're collectively trying to gaslight each other and the rest of the world into thinking it does.
I sincerely hope to be convinced otherwise. :/
Thanks!
Matt _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/CVZPQR AI52OKYTOMFQTXD6BT44M2HMW4/
Am 17.06.26 um 08:46 schrieb Vasilenko Eduard via NANOG:
I did believe too that the absence of redundancy for SMB/SOHO is the blocking factor for IPv6 deployment (and send a few messages here).
No, it isn't. Changes are the blocking factors there. If something works and does its job, it will not be changed until it doesn't anymore. This applies to other protocols (e.g. TLS for HTTPS, SMTP, etc.) too. It also applies to operating system upgrade or firmware on networking devices. It will not be updated until a feature (or bugfix) is really necessary. BTDT. -- Gruß Marco Muell und Spam bitte an abfalleimer2002@stinkedores.dorfdsl.de
On Tue, Jun 16, 2026 at 4:21 PM Arie Vayner via NANOG <nanog@lists.nanog.org> wrote:
[...] 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.
Yes. And there are many issues with running IPv6 systems. One of the major problems is there are way too many bits, and they've created addresses which simply cannot be typed (practically). It is as if the designers of the protocol didn't learn from IPv4 and did not care at all about basic needs of operators. One of those needs is the capability to look at a System logging console, and see an address which can be remembered for 5 seconds and typed into a terminal in 5 seconds. In order to troubleshoot or diag some issue. To identify and group traffic. To add or remove a single host from a blocklist. Copy and paste is not always available and not always suitable. Neither are DNS nor reverse DNS mappings. In a number of important ways IPv6 was fatally deficient. I believe a flag day is out of the question. Perhaps some day a suitable protocol would be devised to take the place of V6.
Thanks, Arie -- -JA
I've always found this argument to be confusing to me, at best - Realistically, you only need to know what network segment you're working in, so the first half of the address doesn't change at all. And if you're using DHCPv6 and/or static addressing, well then.... prefix you already know, and the rest of the address is as short or long as you want it. Even so without that, it's still only half the address you need to know that differs. The 128-bit format is a wonder for handling things programmatically and design work as well, and isn't constrained to historical PDP-11 NIC/register limitations. "too many bits" has always been a "Can't understand breaking the address in half" kind of argument to me, and doing tricks like encoding VLAN IDs or site IDs (or both!) in addressing (first half) has been a godsend for troubleshooting and pinpointing where things are blindly. A lot of work I have done in the past 5 years or so has been reducing IPv4 on customer (not residential, though) networks, to reduce cost, complexity, and increase reliability, with just small edge translation points for V4 access. For software we develop and maintain, we've entirely removed NAT support/workarounds. Not worth maintaining. Tearing down my last STUN-type solution that was no longer needed by that last customer was a great thing - less code, less infrastructure, and just works without hacks. Network renumbering has been a breeze, too - if you've got privacy extensions off for internal infra (which, I would think, would be normal....) then an inventory of MAC addresses gets you right back to where you are, even though the second half of the address doesn't actually change, just the first half, and no endpoint host configuration work is needed in a proper setup. Hell, you can dual home and renumber over time/expiry instead of hard cuts, too! -----Original Message----- From: Jay Acuna via NANOG <nanog@lists.nanog.org> Sent: Tuesday, June 16, 2026 5:31 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Arie Vayner <ariev@vayner.net>; Jay Acuna <mysidia@gmail.com> Subject: Re: IPv4 flag day On Tue, Jun 16, 2026 at 4:21 PM Arie Vayner via NANOG <nanog@lists.nanog.org> wrote:
[...] 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.
Yes. And there are many issues with running IPv6 systems. One of the major problems is there are way too many bits, and they've created addresses which simply cannot be typed (practically). It is as if the designers of the protocol didn't learn from IPv4 and did not care at all about basic needs of operators. One of those needs is the capability to look at a System logging console, and see an address which can be remembered for 5 seconds and typed into a terminal in 5 seconds. In order to troubleshoot or diag some issue. To identify and group traffic. To add or remove a single host from a blocklist. Copy and paste is not always available and not always suitable. Neither are DNS nor reverse DNS mappings. In a number of important ways IPv6 was fatally deficient. I believe a flag day is out of the question. Perhaps some day a suitable protocol would be devised to take the place of V6.
Thanks, Arie -- -JA
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/WEPJRT6B...
And this hits the nail imo. Lets face it, IPv6 is bloody overengineered. What world needed in 1997 was IPv4 with just bigger address space. What have should be done is grab IPv4, extend its address space to 64bit and call it IPv6. Nothing more was needed. Adddress space should look sth like this: - loopback 0:0:0:1/48 - soft LL 0:0:1-ffff:0/32 (Link Local) - RFC1918 address space 0:1-ffff:0:0/16 Nice and easy, by having address at ::1:4 you immediatly know you are dealing with LL address. ::1:0:a means private address space. Anyone saying this is insignifcant, probably comes from hyperscalers where AI manage they networks. But this is not MAJORITY of Networks. Just go away. IPv4 was well established, pretty much most bugs and problems were fixed. It just worked nicely. The only problem was too small address space. If this would be delivered, I strongly think that in 2007, Internet and most enterprise would be IPv6. ---------- Original message ---------- From: Jay Acuna via NANOG <nanog@lists.nanog.org> To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Arie Vayner <ariev@vayner.net>, Jay Acuna <mysidia@gmail.com> Subject: Re: IPv4 flag day Date: Tue, 16 Jun 2026 16:30:35 -0500 On Tue, Jun 16, 2026 at 4:21˙˙PM Arie Vayner via NANOG <nanog@lists.nanog.org> wrote:
[...] 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.
Yes. And there are many issues with running IPv6 systems. One of the major problems is there are way too many bits, and they've created addresses which simply cannot be typed (practically). It is as if the designers of the protocol didn't learn from IPv4 and did not care at all about basic needs of operators. One of those needs is the capability to look at a System logging console, and see an address which can be remembered for 5 seconds and typed into a terminal in 5 seconds. In order to troubleshoot or diag some issue. To identify and group traffic. To add or remove a single host from a blocklist. Copy and paste is not always available and not always suitable. Neither are DNS nor reverse DNS mappings. In a number of important ways IPv6 was fatally deficient. I believe a flag day is out of the question. Perhaps some day a suitable protocol would be devised to take the place of V6.
Thanks, Arie -- -JA
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/WEPJRT6B...
Am 16.06.26 um 21:51 schrieb Arie Vayner via NANOG:
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.
Like any other mayor change, they postpone that until they are forced (by hard requirements) to implement it. This even happens for simple OS upgrades and features/protocols removed in that case. This about all the old MS authentication protocols, SMB versions, NIS in UNIX environments etc. -- Gruß Marco Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
Em ter., 16 de jun. de 2026 às 11:53, Brian Knight via NANOG < nanog@lists.nanog.org> escreveu:
Is NAT still such a severe problem that we needed a different protocol?
Yes! NAT is Operational Cancer! And improving NAT is the same as steroids for cancer! -- Douglas Fernando Fischer Engº de Controle e Automação
On 6/16/26 10:33, Saku Ytti via NANOG wrote:
'ello,
I've babbled about this before, but apparently I'm babbling about it again.
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.
I don't see any future where organically IPv4 dies in such a way that people offering services on the Internet are comfortable offering them IPv6 only, the long tail will be too expensive to ignore.
Dual stack adds complexity, cost, reduces quality and security. It is also blatantly an antitrust issue, as established players with access to large allocations can outcompete new entrants with no IPv4 allocation.
In practice I'm thinking about something where relevant players all sign an agreement to drop ipv4 at their edge in e..g 15 or 20 years. Creating clear business justification for people to implement IPv6 in their next upgrade cycle. Today if I'm an edge with the IPv4 addresses I need, I wouldn't consider IPv6, because that's just a cost to me, with no upside. I know I could get some transit shops to sign off on such an agreement, but no one cares about transit, this obviously doesn't work without Amazon and Facebook et.al.
Sure edges still can have IPv4, but that's like edge having IPX or AppleTalk, it'll be highly local issue, no one expects to reach anywhere with it, and anticipates to translate 100% of external traffic.
Amazon? Facebook? Google? Microsoft? Any appetite?
There were IPv6 Day and IPv6 Launch Day in 2011 and 2012. Why not some major players agree to switch ipv4 off for a day? Sure, it would be a mess, but wouldn't it be a useful one? -- Hrant Dadivanyan - hrant(at)dadivanyan.net /* "Feci quod potui, faciant meliora potentes." */
Only if you like being called before US congressional inquiries (as well as those from any Government run or regulated PTT)... On Tue, Jun 16, 2026 at 8:24 AM Hrant Dadivanyan via NANOG < nanog@lists.nanog.org> wrote:
There were IPv6 Day and IPv6 Launch Day in 2011 and 2012. Why not some major players agree to switch ipv4 off for a day? Sure, it would be a mess, but wouldn't it be a useful one?
-- Hrant Dadivanyan - hrant(at)dadivanyan.net /* "Feci quod potui, faciant meliora potentes." */
-- Jeff Shultz -- Like us on Social Media for News, Promotions, and other information!! <https://www.facebook.com/SCTCWEB/> <https://www.instagram.com/sctc_sctc/> <https://www.yelp.com/biz/sctc-stayton-3> <https://www.youtube.com/c/sctcvideos> _**** This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ****_
US Federal Government was supposed to be Dual-Stacked years ago and in fact should be running IPv6-Only already and already planned for replacement of anything they couldn't convert to IPv6-Only. So if you get brought before congress you can ask them why they had issues getting to your IPv6-Only service from their IPv6-Only network. It might have been caused by Cogent and Hurricane Electric, without finger pointing. David -- https://dprall.net On 6/16/2026 1:47 PM, Jeff Shultz via NANOG wrote:
Only if you like being called before US congressional inquiries (as well as those from any Government run or regulated PTT)...
On Tue, Jun 16, 2026 at 8:24 AM Hrant Dadivanyan via NANOG < nanog@lists.nanog.org> wrote:
There were IPv6 Day and IPv6 Launch Day in 2011 and 2012. Why not some major players agree to switch ipv4 off for a day? Sure, it would be a mess, but wouldn't it be a useful one?
-- Hrant Dadivanyan - hrant(at)dadivanyan.net /* "Feci quod potui, faciant meliora potentes." */
On Mon, Jun 15, 2026 at 11:33 PM Saku Ytti via NANOG <nanog@lists.nanog.org> wrote:
I don't see any future where organically IPv4 dies
I do. First, service providers get fully on board with native Ipv6. Once a customer deploys IPv6 at all, they want it from all their providers so that their users' software isn't using second-class connectivity. However slow the IPv6 customer deployments, it eventually passes a threshold where the disincentive to stay IPv4-only as a service provider can't be ignored. Meanwhile, smaller and newer ISPs have an IPv4 acquisition problem. They can solve that problem with CGNAT, but if they've deployed IPv6 they can also solve it with PLATs running 464XLAT. The latter means they don't have to dual-stack their network, so it's cheaper and less error-prone. As long as they can get a CPE router which can do CLAT. Which is not much of a thing. Yet. The customers of the 464XLAT folks will occasionally want a public IPv4 address, so they'll solve that by tunnelling a static address for an extra charge. And like has happened with AWS, that'll become the standard: IPv6 and RFC1918 included, public IPv4 for an additional fee. As this happens, native IPv4 peering will become more challenging. With folks winnowing IPv4 from their network cores in favor of 464xlat there will be fewer places to trade IPv4 traffic. In addition, CGNAT and 464XLAT PLATs are challenging to manage. If your traffic is 90% IPv6, maybe the PLAT is a good candidate for outsourcing. So you buy PLAT service from an IPv4 exchange (IXPs: new product opportunity alert). And so on and so forth. 464xlat's CLATs never leave the CPE the same way modern POTS terminals still support rotary dialing but the IPv4 network collapses into a small core like Usenet has, serviced by long IPv6 tunnels. When I peer into my crystal ball in 2026, that's what I see. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/
Soon enough all the client computers will have CLAT, so the CPE won't require it leaving the CPE IPv6-Only. IPv6-Mostly is being widely evangelized, with DHCP Option 108. The only client without CLAT widely available today is Windows, and it is out in Insider Preview with Fingers Crossed it comes to GA shortly. David -- https://dprall.net On 6/16/2026 2:05 PM, William Herrin via NANOG wrote:
On Mon, Jun 15, 2026 at 11:33 PM Saku Ytti via NANOG <nanog@lists.nanog.org> wrote:
I don't see any future where organically IPv4 dies
I do.
First, service providers get fully on board with native Ipv6. Once a customer deploys IPv6 at all, they want it from all their providers so that their users' software isn't using second-class connectivity. However slow the IPv6 customer deployments, it eventually passes a threshold where the disincentive to stay IPv4-only as a service provider can't be ignored.
Meanwhile, smaller and newer ISPs have an IPv4 acquisition problem. They can solve that problem with CGNAT, but if they've deployed IPv6 they can also solve it with PLATs running 464XLAT. The latter means they don't have to dual-stack their network, so it's cheaper and less error-prone. As long as they can get a CPE router which can do CLAT. Which is not much of a thing. Yet.
The customers of the 464XLAT folks will occasionally want a public IPv4 address, so they'll solve that by tunnelling a static address for an extra charge. And like has happened with AWS, that'll become the standard: IPv6 and RFC1918 included, public IPv4 for an additional fee.
As this happens, native IPv4 peering will become more challenging. With folks winnowing IPv4 from their network cores in favor of 464xlat there will be fewer places to trade IPv4 traffic. In addition, CGNAT and 464XLAT PLATs are challenging to manage. If your traffic is 90% IPv6, maybe the PLAT is a good candidate for outsourcing. So you buy PLAT service from an IPv4 exchange (IXPs: new product opportunity alert).
And so on and so forth. 464xlat's CLATs never leave the CPE the same way modern POTS terminals still support rotary dialing but the IPv4 network collapses into a small core like Usenet has, serviced by long IPv6 tunnels.
When I peer into my crystal ball in 2026, that's what I see.
Regards, Bill Herrin
On Tue, Jun 16, 2026 at 12:21 PM David Prall via NANOG <nanog@lists.nanog.org> wrote:
Soon enough all the client computers will have CLAT, so the CPE won't require it leaving the CPE IPv6-Only. IPv6-Mostly is being widely evangelized, with DHCP Option 108. The only client without CLAT widely available today is Windows, and it is out in Insider Preview with
The _legacy_ systems will be the last ones using IPv4. Which means no updates. Which means no CLAT software. If you want CLAT in those configurations, it'll have to be external. In the CPE router. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/
Am 16.06.26 um 23:54 schrieb William Herrin via NANOG:
The_legacy_ systems will be the last ones using IPv4. Which means no updates. Which means no CLAT software. If you want CLAT in those configurations, it'll have to be external. In the CPE router.
The current legacy systems will have issues using latest technology anyway. The operators of them run them to use legacy software/hardware. In case they need they will build bridges, but you do not want to have legacy (EoS) machines connected to the public internet. -- Gruß Marco Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
Hi David, IPv6-Mostly has been designed considering enterprise networks, not residencial ones. If you deploy IPv6-Mostly in residential networks, you will need the access link to keep dual-stack (so the ISP needs to keep CGN or keep getting sufficient IPv4 public addresses), because you don’t know if the residential can still have IPv4-only devices (older printers, smartTVs, IP phones, cameras, home automation, ….) that need to keep running. One additional issue is that those “local” devices, which only speak IPv4, now can’t communicate with the IPv6-Mostly enabled Windows (and other OSs) because they are configured (if the CPE supports also IPv6-Mostly), to run IPv6-only. So you can’t anymore print from your home to your own printer. Yes, it can be resolved in several ways, such as having a PLAT at the CPE, or having rules that allow the local traffic going to the printer to travel to the PLAT in the ISP, then travel back to the printer, etc. Not good solutions. The cost of implementing anything like that in CPEs is probably much higher than implementing CLAT, and with CLAT you have the advantage that you can get rid-off the CGN in the ISP, and instead use a less overloaded PLAT, which also requires much less public IPv4 addresses. And as more and more services in Internet enable dual-stack, less and less NAT64 traffic you will have (and you can even reduce the IPv4 public pools there). In enterprise networks (“managed” networks) the IT team can make sure that those old devices use the local PLAT, or have those devices in special network segments which have a front end with stateless NAT64, etc, even just port-proxy in windows/Linux can do that. There are several ways to fix that. The code for CLAT and PLAT is available in open source, multiple implementations. Is not a very complex code (at lest not the CLAT one). There are some vendors that have several CPEs with CLAT. The issue is that there hasn’t been sufficient market pressure to ask all the vendors to provide for existing devices a CLAT-enabled firmware. In my experience most of the time vendors do that if you pay for it (I’ve participated in a number of deployments doing that), but of course, they will not share that firmware in public, they just want money, which mainly will require you buy newer CPEs from them with the CLAT. T-Mobile for example, got CPEs with CLAT that provide broadband via 3G/4G/5G, but in general I don’t see other big players pushing the vendors for that. We really must change that if we want to move on. Why we want competition if we don’t ask them to support the standards? or we just believe the CPE is a disposable cost and because that, we spend more CapEx and OpEx in other parts of the network because the lack of vision when asking for CPEs? Regards, Jordi @jordipalet
El 16 jun 2026, a las 21:21, David Prall via NANOG <nanog@lists.nanog.org> escribió:
Soon enough all the client computers will have CLAT, so the CPE won't require it leaving the CPE IPv6-Only. IPv6-Mostly is being widely evangelized, with DHCP Option 108. The only client without CLAT widely available today is Windows, and it is out in Insider Preview with Fingers Crossed it comes to GA shortly.
David
On 6/16/2026 2:05 PM, William Herrin via NANOG wrote:
I don't see any future where organically IPv4 dies I do. First, service providers get fully on board with native Ipv6. Once a customer deploys IPv6 at all, they want it from all their providers so
On Mon, Jun 15, 2026 at 11:33 PM Saku Ytti via NANOG <nanog@lists.nanog.org> wrote: that their users' software isn't using second-class connectivity. However slow the IPv6 customer deployments, it eventually passes a threshold where the disincentive to stay IPv4-only as a service provider can't be ignored. Meanwhile, smaller and newer ISPs have an IPv4 acquisition problem. They can solve that problem with CGNAT, but if they've deployed IPv6 they can also solve it with PLATs running 464XLAT. The latter means they don't have to dual-stack their network, so it's cheaper and less error-prone. As long as they can get a CPE router which can do CLAT. Which is not much of a thing. Yet. The customers of the 464XLAT folks will occasionally want a public IPv4 address, so they'll solve that by tunnelling a static address for an extra charge. And like has happened with AWS, that'll become the standard: IPv6 and RFC1918 included, public IPv4 for an additional fee. As this happens, native IPv4 peering will become more challenging. With folks winnowing IPv4 from their network cores in favor of 464xlat there will be fewer places to trade IPv4 traffic. In addition, CGNAT and 464XLAT PLATs are challenging to manage. If your traffic is 90% IPv6, maybe the PLAT is a good candidate for outsourcing. So you buy PLAT service from an IPv4 exchange (IXPs: new product opportunity alert). And so on and so forth. 464xlat's CLATs never leave the CPE the same way modern POTS terminals still support rotary dialing but the IPv4 network collapses into a small core like Usenet has, serviced by long IPv6 tunnels. When I peer into my crystal ball in 2026, that's what I see. Regards, Bill Herrin
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/NPKI5WUD...
********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
On 2026-06-17 08:48, jordi.palet--- via NANOG wrote:
T-Mobile for example, got CPEs with CLAT that provide broadband via 3G/4G/5G, but in general I don’t see other big players pushing the vendors for that. We really must change that if we want to move on. Why we want competition if we don’t ask them to support the standards? or we just believe the CPE is a disposable cost and because that, we spend more CapEx and OpEx in other parts of the network because the lack of vision when asking for CPEs?
In France, new broadband deployments are done with custom CPEs supporting CLAT. Free is using MAP-E. Bouygues is using MAP-T. SFR should also start using MAP-T, but this is unclear (for me) if they are moving beyond the tests. And Orange started deploying DS-Lite. On the mobile front, I don't know exactly, but I suppose many are doing 464XLAT, which is what is supported on both iOS and Android. There is one exception that is still doing NAT44, but the function can be colocated with the UPF and does not need to be very distributed.
For some reason, many operators do not realize that 464XLAT is not just for mobile networks. They also miss that if they have a network that offers mobile and fix broadband, it make sense, if they are providing backup, to use 464XLAT in both networks, so having the same transition mechanism provides much better customer experience, flexibility for the operator and of course reduce CapEx and OpEx. I guess the main reason to use MAP-T/E is because, the ISP network don’t have state, but this is at the cost of needed to share pre-defined ports per customer, and making your addressing plan somehow depending on the protocol. This way the utilization of IPv4 public addresses is not the best. https://www.rfc-editor.org/info/rfc9313/ Of course MAP-T has 3 translations, so a big ugglier. Regards, Jordi @jordipalet
El 18 jun 2026, a las 8:07, Vincent Bernat <bernat@luffy.cx> escribió:
On 2026-06-17 08:48, jordi.palet--- via NANOG wrote:
T-Mobile for example, got CPEs with CLAT that provide broadband via 3G/4G/5G, but in general I don’t see other big players pushing the vendors for that. We really must change that if we want to move on. Why we want competition if we don’t ask them to support the standards? or we just believe the CPE is a disposable cost and because that, we spend more CapEx and OpEx in other parts of the network because the lack of vision when asking for CPEs?
In France, new broadband deployments are done with custom CPEs supporting CLAT. Free is using MAP-E. Bouygues is using MAP-T. SFR should also start using MAP-T, but this is unclear (for me) if they are moving beyond the tests. And Orange started deploying DS-Lite.
On the mobile front, I don't know exactly, but I suppose many are doing 464XLAT, which is what is supported on both iOS and Android. There is one exception that is still doing NAT44, but the function can be colocated with the UPF and does not need to be very distributed.
********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
I think I see a misalignment with reality:
Simple BGP config is not that demanding. If you're going to connect a device to the public internet with BGP, it should require a basic level of competence.
Yes, anyone using "BGP to connect to the Internet" is required to have some level of competence, agreed. BUT: we can't expect everyone who wants to connect to the Internet to have that level of competence. If someone's a graphic designer working from home, and they want resiliency with 2x ISPs, I don't think we can expect them to have (or be able to afford) the level of competency required to run BGP with 2 ISPs. Instead, I think a more realistic approach would be for them to go to their closest electronics retailer, buy a fancy "dual ISP" router, then just order 2 ISP services from whatever's available in their region, plug in, and forget about it. Unfortunately, getting things like NPTv6, or anything that the IPv6 standards/BCPs state today will really work with IPv6 for the above setup, and the end result will be that they will stay on IPv4, with a 2xWAN NAT setup. From my recent experience with 2 large ISPs providing services in my area, their IPv6 setups would not have worked together with NPTv6 (different pool sizes, one of them only supporting a single /64 and the other one requiring deep tweaking to get anything more than a /64 to work) Tnx Arie On Mon, Jun 22, 2026 at 5:19 AM Tom Beecher via NANOG <nanog@lists.nanog.org> wrote:
Is there any current effort underway to make BGP more accessible, user-friendly, or "plug and play?" Anything that might address some of the more technically demanding aspects of multihoming?
Simple BGP config is not that demanding. If you're going to connect a device to the public internet with BGP, it should require a basic level of competence.
CPE vendors might set up web pages that request IPs and an ASN for you.
Sets up ROAs, IRR, and the CPE, start to finish.
None of this stuff should be 'ez-mode' for the uninformed user. Heck, informed users make a mess of it a lot of the time.
Home install kits and plug and play doesn't work at a certain point. Stop trying to shoehorn it.
On Sun, Jun 21, 2026 at 11:23 PM Brian Knight via NANOG < nanog@lists.nanog.org> wrote:
Is there any current effort underway to make BGP more accessible, user-friendly, or "plug and play?" Anything that might address some of the more technically demanding aspects of multihoming?
Quick Google says no, but maybe someone has more awareness.
I'm pipe-dreaming BGP multihoming becoming as simple as connecting two Internet links to a CPE, with no reduction in MTU. No SD-WAN, no tunnels, no NAT. Works over any kind of link: 5G, wifi, GPON, cable, fiber, carrier pigeon.
CPE vendors might set up web pages that request IPs and an ASN for you. Sets up ROAs, IRR, and the CPE, start to finish.
Maybe there's a new protocol where the carrier auto-generates a BGP multihoming token and sends it to the user in the order docs. User sets the token on the CPE interface facing that provider. Successful negotiation lets the customer announce their prefix and ASN. CPE and carrier manage it all, no network staff needed.
-Brian
On 2026-06-21 19:29, Dorn Hetzel via NANOG wrote:
Sure, have every hotdog cart run BGP, pretty soon we'll need 64 bit AS numbers :)
On Sun, Jun 21, 2026 at 6:29 PM Mike Hammett via NANOG < nanog@lists.nanog.org> wrote:
Most pizza shops aren't going to be able to manage BGP.
----- Mike Hammett Intelligent Computing Solutions
Midwest Internet Exchange
The Brothers WISP
NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/7AMX6YN4... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/MIC6KX6A...
On Tue, 23 Jun 2026 at 04:15, Brian Knight via NANOG <nanog@lists.nanog.org> wrote:
I'm now convinced that the proverbial ship has sailed. NAT had to be developed for IPv6. It will be used. It is here to stay. The "NAT is cancer" statement is old hat and no longer relevant.
I have never deployed IPv6 NAT for multihoming, but I have deployed IPv4 NAT/PAT for it.
If deploying IPv6 NAT is as difficult as folks say, it's time to make it simpler so SMBs can do what they already know how to do.
They have few alternatives, and NAT is going to be among the least costly options.
I think it's entirely fair to want for A but know that B must be done. Like of course I always wanted that IPv6 would bring some brave new world of end-to-end Internet. But I want a lot of good things for this world, which are naive things to want under the incentives the world has. And in this case, not budging on our principles which cannot be achieved is causing tremendous harm. IPv4 market size is about size of Portugal or New Zealand, it is not a trivial force, to understand all the complex interactions it has to technology and economy is impossible, and we'll gain more and more understanding in coming decades and centuries what it truly did, but we can fairly assume that commanding majority of those impacts will be negative for any technical or economical goal we may have. -- ++ytti
I'm amazed anyone in this list would consider PAT in IPv6 as a preferred solution. If you need fast failover multihoming with consumer-class connections (ignoring the fact that connections will still break when failover occurs), then use NPT between the two providers. Pick your primary ISPs prefix as your internal prefix, NPT to the other one, no port translation needed. Or use ULA, whatever. This multihoming issue could have been solved with better rigor in a few places in the v6 standard, having two routers advertising their two prefixes and default route priorities directly to clients. No complicated multi-wan routers, pizza place just buys two basic consumer routers, plug them both into the same LAN switch, and bam you have two ISPs. Clients get addresses on both prefixes, and default routes to both routers. Router withdraws its default route when it loses the upstream connection, clients deprecate the route, existing connections will fail because there is no longer an upstream link (which will happen with NA(P)T anyway!). Transport protocols see and can use both addresses if they are multihoming aware. Source address selection (rfc6742 rule 5.5) tells clients to pick an address from the higher priority router as the source address, meaning the router advertisement priority is used by the network operator to prefer one ISP over the other. Client software can bind to a specific address if it must use one ISP. Unfortunately for us, rule 5.5 is optional and poorly implemented by OSes, so in reality this does not work that well. If that had been a requirement, it would have solved this issue without any packet mangling, and made transport layer support for multihoming significantly easier.
Gary Sparkes via NANOG wrote on 23/06/2026 03:54:
I'm now convinced that the proverbial ship has sailed. NAT had to be developed for IPv6. It will be used. It is here to stay. The "NAT is cancer" statement is old hat and no longer relevant.
And for those customers who do 1:many nat, my software just won't support them. It's simple enough.
Surely what you mean is: "They just won't support my software. It's simple enough"? Nick
BUT: we can't expect everyone who wants to connect to the Internet to have that level of competence. If someone's a graphic designer working from home, and they want resiliency with 2x ISPs, I don't think we can expect them to have (or be able to afford) the level of competency required to run BGP with 2 ISPs.
This is just the standard complexity vs cost question. If someone wants 2 upstreams , that's easy. If they expect it to function a certain way, that may require more complexity that has to be paid for. ( in equipment or expertise.) Or they can just swap cables and reboot something once in a while, and find that acceptable. On Mon, Jun 22, 2026 at 1:56 PM Arie Vayner <ariev@vayner.net> wrote:
I think I see a misalignment with reality:
Simple BGP config is not that demanding. If you're going to connect a device to the public internet with BGP, it should require a basic level of competence.
Yes, anyone using "BGP to connect to the Internet" is required to have some level of competence, agreed.
BUT: we can't expect everyone who wants to connect to the Internet to have that level of competence. If someone's a graphic designer working from home, and they want resiliency with 2x ISPs, I don't think we can expect them to have (or be able to afford) the level of competency required to run BGP with 2 ISPs.
Instead, I think a more realistic approach would be for them to go to their closest electronics retailer, buy a fancy "dual ISP" router, then just order 2 ISP services from whatever's available in their region, plug in, and forget about it.
Unfortunately, getting things like NPTv6, or anything that the IPv6 standards/BCPs state today will really work with IPv6 for the above setup, and the end result will be that they will stay on IPv4, with a 2xWAN NAT setup. From my recent experience with 2 large ISPs providing services in my area, their IPv6 setups would not have worked together with NPTv6 (different pool sizes, one of them only supporting a single /64 and the other one requiring deep tweaking to get anything more than a /64 to work)
Tnx Arie
On Mon, Jun 22, 2026 at 5:19 AM Tom Beecher via NANOG < nanog@lists.nanog.org> wrote:
Is there any current effort underway to make BGP more accessible, user-friendly, or "plug and play?" Anything that might address some of the more technically demanding aspects of multihoming?
Simple BGP config is not that demanding. If you're going to connect a device to the public internet with BGP, it should require a basic level of competence.
CPE vendors might set up web pages that request IPs and an ASN for you.
Sets up ROAs, IRR, and the CPE, start to finish.
None of this stuff should be 'ez-mode' for the uninformed user. Heck, informed users make a mess of it a lot of the time.
Home install kits and plug and play doesn't work at a certain point. Stop trying to shoehorn it.
On Sun, Jun 21, 2026 at 11:23 PM Brian Knight via NANOG < nanog@lists.nanog.org> wrote:
Is there any current effort underway to make BGP more accessible, user-friendly, or "plug and play?" Anything that might address some of the more technically demanding aspects of multihoming?
Quick Google says no, but maybe someone has more awareness.
I'm pipe-dreaming BGP multihoming becoming as simple as connecting two Internet links to a CPE, with no reduction in MTU. No SD-WAN, no tunnels, no NAT. Works over any kind of link: 5G, wifi, GPON, cable, fiber, carrier pigeon.
CPE vendors might set up web pages that request IPs and an ASN for you. Sets up ROAs, IRR, and the CPE, start to finish.
Maybe there's a new protocol where the carrier auto-generates a BGP multihoming token and sends it to the user in the order docs. User sets the token on the CPE interface facing that provider. Successful negotiation lets the customer announce their prefix and ASN. CPE and carrier manage it all, no network staff needed.
-Brian
On 2026-06-21 19:29, Dorn Hetzel via NANOG wrote:
Sure, have every hotdog cart run BGP, pretty soon we'll need 64 bit AS numbers :)
On Sun, Jun 21, 2026 at 6:29 PM Mike Hammett via NANOG < nanog@lists.nanog.org> wrote:
Most pizza shops aren't going to be able to manage BGP.
----- Mike Hammett Intelligent Computing Solutions
Midwest Internet Exchange
The Brothers WISP
NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/7AMX6YN4... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/MIC6KX6A...
But when something works with IPv4, we shouldn't expect that the user experience is reduced when moving to IPv6. Shane On Tue, Jun 23, 2026 at 11:28 AM Tom Beecher via NANOG < nanog@lists.nanog.org> wrote:
BUT: we can't expect everyone who wants to connect to the Internet to
have
that level of competence. If someone's a graphic designer working from home, and they want resiliency with 2x ISPs, I don't think we can expect them to have (or be able to afford) the level of competency required to run BGP with 2 ISPs.
This is just the standard complexity vs cost question.
If someone wants 2 upstreams , that's easy. If they expect it to function a certain way, that may require more complexity that has to be paid for. ( in equipment or expertise.) Or they can just swap cables and reboot something once in a while, and find that acceptable.
On Mon, Jun 22, 2026 at 1:56 PM Arie Vayner <ariev@vayner.net> wrote:
I think I see a misalignment with reality:
Simple BGP config is not that demanding. If you're going to connect a device to the public internet with BGP, it should require a basic level of competence.
Yes, anyone using "BGP to connect to the Internet" is required to have some level of competence, agreed.
BUT: we can't expect everyone who wants to connect to the Internet to have that level of competence. If someone's a graphic designer working from home, and they want resiliency with 2x ISPs, I don't think we can expect them to have (or be able to afford) the level of competency required to run BGP with 2 ISPs.
Instead, I think a more realistic approach would be for them to go to their closest electronics retailer, buy a fancy "dual ISP" router, then just order 2 ISP services from whatever's available in their region, plug in, and forget about it.
Unfortunately, getting things like NPTv6, or anything that the IPv6 standards/BCPs state today will really work with IPv6 for the above setup, and the end result will be that they will stay on IPv4, with a 2xWAN NAT setup. From my recent experience with 2 large ISPs providing services in my area, their IPv6 setups would not have worked together with NPTv6 (different pool sizes, one of them only supporting a single /64 and the other one requiring deep tweaking to get anything more than a /64 to work)
Tnx Arie
On Mon, Jun 22, 2026 at 5:19 AM Tom Beecher via NANOG < nanog@lists.nanog.org> wrote:
Is there any current effort underway to make BGP more accessible, user-friendly, or "plug and play?" Anything that might address some of the more technically demanding aspects of multihoming?
Simple BGP config is not that demanding. If you're going to connect a device to the public internet with BGP, it should require a basic level of competence.
CPE vendors might set up web pages that request IPs and an ASN for you.
Sets up ROAs, IRR, and the CPE, start to finish.
None of this stuff should be 'ez-mode' for the uninformed user. Heck, informed users make a mess of it a lot of the time.
Home install kits and plug and play doesn't work at a certain point. Stop trying to shoehorn it.
On Sun, Jun 21, 2026 at 11:23 PM Brian Knight via NANOG < nanog@lists.nanog.org> wrote:
Is there any current effort underway to make BGP more accessible, user-friendly, or "plug and play?" Anything that might address some of the more technically demanding aspects of multihoming?
Quick Google says no, but maybe someone has more awareness.
I'm pipe-dreaming BGP multihoming becoming as simple as connecting two Internet links to a CPE, with no reduction in MTU. No SD-WAN, no tunnels, no NAT. Works over any kind of link: 5G, wifi, GPON, cable, fiber, carrier pigeon.
CPE vendors might set up web pages that request IPs and an ASN for you. Sets up ROAs, IRR, and the CPE, start to finish.
Maybe there's a new protocol where the carrier auto-generates a BGP multihoming token and sends it to the user in the order docs. User sets the token on the CPE interface facing that provider. Successful negotiation lets the customer announce their prefix and ASN. CPE and carrier manage it all, no network staff needed.
-Brian
On 2026-06-21 19:29, Dorn Hetzel via NANOG wrote:
Sure, have every hotdog cart run BGP, pretty soon we'll need 64 bit AS numbers :)
On Sun, Jun 21, 2026 at 6:29 PM Mike Hammett via NANOG < nanog@lists.nanog.org> wrote:
Most pizza shops aren't going to be able to manage BGP.
----- Mike Hammett Intelligent Computing Solutions
Midwest Internet Exchange
The Brothers WISP
NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/7AMX6YN4...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/MIC6KX6A...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/7AJTPSWZ...
Tom,
If someone wants 2 upstreams , that's easy. If they expect it to function a certain way, that may require more complexity that has to be paid for. ( in equipment or expertise.) Or > they can just swap cables and reboot something once in a while, and find that acceptable.
I don't think this is a valid expectation. The reality is they just make it work with current products, over IPv4, and the IPv6 usage graph is stuck at 50% and doesn't really move up (at least not fast enough). Tnx Arie On Tue, Jun 23, 2026 at 8:28 AM Tom Beecher <beecher@beecher.cc> wrote:
BUT: we can't expect everyone who wants to connect to the Internet to have
that level of competence. If someone's a graphic designer working from home, and they want resiliency with 2x ISPs, I don't think we can expect them to have (or be able to afford) the level of competency required to run BGP with 2 ISPs.
This is just the standard complexity vs cost question.
If someone wants 2 upstreams , that's easy. If they expect it to function a certain way, that may require more complexity that has to be paid for. ( in equipment or expertise.) Or they can just swap cables and reboot something once in a while, and find that acceptable.
On Mon, Jun 22, 2026 at 1:56 PM Arie Vayner <ariev@vayner.net> wrote:
I think I see a misalignment with reality:
Simple BGP config is not that demanding. If you're going to connect a device to the public internet with BGP, it should require a basic level of competence.
Yes, anyone using "BGP to connect to the Internet" is required to have some level of competence, agreed.
BUT: we can't expect everyone who wants to connect to the Internet to have that level of competence. If someone's a graphic designer working from home, and they want resiliency with 2x ISPs, I don't think we can expect them to have (or be able to afford) the level of competency required to run BGP with 2 ISPs.
Instead, I think a more realistic approach would be for them to go to their closest electronics retailer, buy a fancy "dual ISP" router, then just order 2 ISP services from whatever's available in their region, plug in, and forget about it.
Unfortunately, getting things like NPTv6, or anything that the IPv6 standards/BCPs state today will really work with IPv6 for the above setup, and the end result will be that they will stay on IPv4, with a 2xWAN NAT setup. From my recent experience with 2 large ISPs providing services in my area, their IPv6 setups would not have worked together with NPTv6 (different pool sizes, one of them only supporting a single /64 and the other one requiring deep tweaking to get anything more than a /64 to work)
Tnx Arie
On Mon, Jun 22, 2026 at 5:19 AM Tom Beecher via NANOG < nanog@lists.nanog.org> wrote:
Is there any current effort underway to make BGP more accessible, user-friendly, or "plug and play?" Anything that might address some of the more technically demanding aspects of multihoming?
Simple BGP config is not that demanding. If you're going to connect a device to the public internet with BGP, it should require a basic level of competence.
CPE vendors might set up web pages that request IPs and an ASN for you.
Sets up ROAs, IRR, and the CPE, start to finish.
None of this stuff should be 'ez-mode' for the uninformed user. Heck, informed users make a mess of it a lot of the time.
Home install kits and plug and play doesn't work at a certain point. Stop trying to shoehorn it.
On Sun, Jun 21, 2026 at 11:23 PM Brian Knight via NANOG < nanog@lists.nanog.org> wrote:
Is there any current effort underway to make BGP more accessible, user-friendly, or "plug and play?" Anything that might address some of the more technically demanding aspects of multihoming?
Quick Google says no, but maybe someone has more awareness.
I'm pipe-dreaming BGP multihoming becoming as simple as connecting two Internet links to a CPE, with no reduction in MTU. No SD-WAN, no tunnels, no NAT. Works over any kind of link: 5G, wifi, GPON, cable, fiber, carrier pigeon.
CPE vendors might set up web pages that request IPs and an ASN for you. Sets up ROAs, IRR, and the CPE, start to finish.
Maybe there's a new protocol where the carrier auto-generates a BGP multihoming token and sends it to the user in the order docs. User sets the token on the CPE interface facing that provider. Successful negotiation lets the customer announce their prefix and ASN. CPE and carrier manage it all, no network staff needed.
-Brian
On 2026-06-21 19:29, Dorn Hetzel via NANOG wrote:
Sure, have every hotdog cart run BGP, pretty soon we'll need 64 bit AS numbers :)
On Sun, Jun 21, 2026 at 6:29 PM Mike Hammett via NANOG < nanog@lists.nanog.org> wrote:
Most pizza shops aren't going to be able to manage BGP.
----- Mike Hammett Intelligent Computing Solutions
Midwest Internet Exchange
The Brothers WISP
NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/7AMX6YN4... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/MIC6KX6A...
On Tue, 23 Jun 2026 at 20:54, Arie Vayner via NANOG <nanog@lists.nanog.org> wrote:
The reality is they just make it work with current products, over IPv4, and the IPv6 usage graph is stuck at 50% and doesn't really move up (at least not fast enough).
When measuring use, we shouldn't measure bytes moved per AFI. Because if you care about bytes moved, you can pick some big tech that loads their global caches over IPv6 and you might be confused to think that traction is good. We should be looking at SRC,DST pairs over all traffic, billion bytes is the same as 1 byte, the internet is still sometimes used for something else than looking at big tech ads, not much by byte count, but by SRC,DST count it is something. Transit shops see maybe 15% total IPv6, but this isn't 100% doing 15%, this is a couple shops doing very high %. At any rate, we are already very late, the IPv4 market exists, is non-trivial size and has already caused known and unknown damage to the economy. How many products never happened, because people didn't have CAPEX to acquire the IPv4 their idea needed and it didn't move further from internal dialogue? How many competitors didn't happen? For big tech nothing costs anything, they lay the fibers, because they can pay those with ads, unlike communication shops who cannot afford to build fiber, because margins aren't there without ads. Big tech buys IPv4 in the billions, because a billion is an atomic sum of money to them. -- ++ytti
If someone wants 2 upstreams , that's easy. If they expect it to function a certain way, that may require more complexity that has to be paid for. ( in equipment or expertise.) Or > they can just swap cables and reboot something once in a while, and find that acceptable.
I don't think this is a valid expectation.
The reality is they just make it work with current products, over IPv4, and the IPv6 usage graph is stuck at 50% and doesn't really move up (at least not fast enough).
I'm unclear what you mean 'just works' with current products. I'm also unclear what v4 / v6 usage %'s has to do with this subject ( single vs dual ISP/uplink). On Tue, Jun 23, 2026 at 12:28 PM Arie Vayner <ariev@vayner.net> wrote:
Tom,
If someone wants 2 upstreams , that's easy. If they expect it to function a certain way, that may require more complexity that has to be paid for. ( in equipment or expertise.) Or > they can just swap cables and reboot something once in a while, and find that acceptable.
I don't think this is a valid expectation.
The reality is they just make it work with current products, over IPv4, and the IPv6 usage graph is stuck at 50% and doesn't really move up (at least not fast enough).
Tnx Arie
On Tue, Jun 23, 2026 at 8:28 AM Tom Beecher <beecher@beecher.cc> wrote:
BUT: we can't expect everyone who wants to connect to the Internet to
have that level of competence. If someone's a graphic designer working from home, and they want resiliency with 2x ISPs, I don't think we can expect them to have (or be able to afford) the level of competency required to run BGP with 2 ISPs.
This is just the standard complexity vs cost question.
If someone wants 2 upstreams , that's easy. If they expect it to function a certain way, that may require more complexity that has to be paid for. ( in equipment or expertise.) Or they can just swap cables and reboot something once in a while, and find that acceptable.
On Mon, Jun 22, 2026 at 1:56 PM Arie Vayner <ariev@vayner.net> wrote:
I think I see a misalignment with reality:
Simple BGP config is not that demanding. If you're going to connect a device to the public internet with BGP, it should require a basic level of competence.
Yes, anyone using "BGP to connect to the Internet" is required to have some level of competence, agreed.
BUT: we can't expect everyone who wants to connect to the Internet to have that level of competence. If someone's a graphic designer working from home, and they want resiliency with 2x ISPs, I don't think we can expect them to have (or be able to afford) the level of competency required to run BGP with 2 ISPs.
Instead, I think a more realistic approach would be for them to go to their closest electronics retailer, buy a fancy "dual ISP" router, then just order 2 ISP services from whatever's available in their region, plug in, and forget about it.
Unfortunately, getting things like NPTv6, or anything that the IPv6 standards/BCPs state today will really work with IPv6 for the above setup, and the end result will be that they will stay on IPv4, with a 2xWAN NAT setup. From my recent experience with 2 large ISPs providing services in my area, their IPv6 setups would not have worked together with NPTv6 (different pool sizes, one of them only supporting a single /64 and the other one requiring deep tweaking to get anything more than a /64 to work)
Tnx Arie
On Mon, Jun 22, 2026 at 5:19 AM Tom Beecher via NANOG < nanog@lists.nanog.org> wrote:
Is there any current effort underway to make BGP more accessible, user-friendly, or "plug and play?" Anything that might address some of the more technically demanding aspects of multihoming?
Simple BGP config is not that demanding. If you're going to connect a device to the public internet with BGP, it should require a basic level of competence.
CPE vendors might set up web pages that request IPs and an ASN for you.
Sets up ROAs, IRR, and the CPE, start to finish.
None of this stuff should be 'ez-mode' for the uninformed user. Heck, informed users make a mess of it a lot of the time.
Home install kits and plug and play doesn't work at a certain point. Stop trying to shoehorn it.
On Sun, Jun 21, 2026 at 11:23 PM Brian Knight via NANOG < nanog@lists.nanog.org> wrote:
Is there any current effort underway to make BGP more accessible, user-friendly, or "plug and play?" Anything that might address some of the more technically demanding aspects of multihoming?
Quick Google says no, but maybe someone has more awareness.
I'm pipe-dreaming BGP multihoming becoming as simple as connecting two Internet links to a CPE, with no reduction in MTU. No SD-WAN, no tunnels, no NAT. Works over any kind of link: 5G, wifi, GPON, cable, fiber, carrier pigeon.
CPE vendors might set up web pages that request IPs and an ASN for you. Sets up ROAs, IRR, and the CPE, start to finish.
Maybe there's a new protocol where the carrier auto-generates a BGP multihoming token and sends it to the user in the order docs. User sets the token on the CPE interface facing that provider. Successful negotiation lets the customer announce their prefix and ASN. CPE and carrier manage it all, no network staff needed.
-Brian
On 2026-06-21 19:29, Dorn Hetzel via NANOG wrote:
Sure, have every hotdog cart run BGP, pretty soon we'll need 64 bit AS numbers :)
On Sun, Jun 21, 2026 at 6:29 PM Mike Hammett via NANOG < nanog@lists.nanog.org> wrote:
> Most pizza shops aren't going to be able to manage BGP. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP
NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/7AMX6YN4... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/MIC6KX6A...
On Thu, Jun 18, 2026 at 12:55 PM Arie Vayner <ariev@vayner.net> wrote:
Unless I'm missing something, the pwnat mechanism will actually work through any stateful packet inspection (be it NAT or just a firewall) that allows Traceroute to work.
Hi Arie, You're not missing anything. It's a novel mechanism for escalating a beachhead, but Gary hasn't explained why it wouldn't work just as well with any other firewall that allows internal machines to initiate outbound connections by default. Everybody needs ICMP destination unreachable messages from arbitrary sources to reach back to the origin. Path MTU discovery fails if they do not. With any kind of firewall. ICMP Time exceeded is not as crucial but traceroute breaks without it so most firewalls propagate it inward too. Interesting as it is, the thought experiment fails to support Gary's claim that NAT specifically makes a network vulnerable. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/
Does this assume that the firewall creating a mapping for ICMP also causes it to create a full mapping for any IP protocol (TCP, UDP, etc) ? On Thu, Jun 18, 2026 at 4:05 PM Gary Sparkes <gary@kisaracorporation.com> wrote:
ICMP Time Exceeded, not unreachable.
In this case we’re abusing that ICMP Time Exceeded packet to communicate to the host behind the NAT the client-side IP.
Then all the magic can light up between the two endpoints.
*From:* Dorn Hetzel <dorn@hetzel.org> *Sent:* Thursday, June 18, 2026 5:46 PM *To:* North American Network Operators Group <nanog@lists.nanog.org> *Cc:* Gary Sparkes <gary@kisaracorporation.com>; Arie Vayner < ariev@vayner.net> *Subject:* Re: IPv4 flag day
Do I misunderstand, or does it only allow inbound traffic from random hosts *as long as it meets the format of ICMP unreachable* and has the correct contents?
On Thu, Jun 18, 2026 at 3:34 PM Arie Vayner via NANOG < nanog@lists.nanog.org> wrote:
Unless I'm missing something, the pwnat mechanism will actually work through any stateful packet inspection (be it NAT or just a firewall) that allows Traceroute to work.
They basically take advantage of ICMP unreachable messages to sneak through the stateful inspection mechanism...
So a "malicious" host on your FW inside can basically punch through by creating this "ICMP" hole...
Interesting technique for sure.
On Thu, Jun 18, 2026, 11:44 AM Gary Sparkes via NANOG < nanog@lists.nanog.org> wrote:
Simply, the inbound firewall rules prevent it from working.
There's no NAT to bypass the firewall to allow the ingress.
You'd instead have to open the ingress port on the firewall to allow the traffic.
(It does work, as I noted, I've used it for a legitimate customer before)
In the non-NAT scenario, the port would have to be allowed through the firewall, or the device behind the NAT would have to connect to *me* at a point or infrastructure that I control.
Remember, I am effectively, an unknown address endpoint, *initiating* the connection to the NAT'd device that has no prior knowledge of my address.
-----Original Message----- From: William Herrin <bill@herrin.us> Sent: Thursday, June 18, 2026 2:37 PM To: Gary Sparkes <gary@kisaracorporation.com> Cc: North American Network Operators Group <nanog@lists.nanog.org> Subject: Re: IPv4 flag day
On Thu, Jun 18, 2026 at 11:18 AM Gary Sparkes < gary@kisaracorporation.com> wrote:
I never said the Pi wouldn't send outbound packets.
It's just sending ICMP echo packets to a destination that'll never respond and isn't owned or used by the attacker. Any arbitrary destination will work if you know what that is (and, since it's your payload, you configure that). In the "ready to connect" state, all you're seeing on your side is ICMP echos to X.X.X.X failing. I can then connect to your 1.2.3.4 from Y.Y.Y.Y over port XXXX.
Allowing me to establish ingress from any arbitrary Y.Y.Y.Y without any knowledge or control of X.X.X.X
So there never is, until I go to establish the connection FROM OUTSIDE THE NAT, a state between Y.Y.Y.Y and 1.2.3.4
Effectively, this turns into me establishing a connection from any arbitrary outside address, where I only need to know your external NAT IP, and no state had ever existed between us before.
Hi Gary,
That's pretty convoluted but let's say for the sake of the argument that it works. What stops it from working with the non-NAT firewall?
The claim you made against 1:many NAT was, "I can't imagine any case in where the ability to arbitrarily punch through your firewall (as an attacker) once I have any kind of foothold is a good feature." To sustain that claim as an argument against NAT (as opposed to an argument against outbound allow by default), you have to demonstrate an attack where you can punch through a 1:many NAT firewall but can't punch through a comparably configured non-NAT firewall.
Regards, Bill Herrin
-- For hire. https://bill.herrin.us/resume/ _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/TYNHRRA4... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/LYNHL7WX...
At the point notification (the “server” receives the time exceeded packet) it then starts slinging UDP packets in a fashion just like the client does to establish the holepunch. At least, for this specific example. Removes any kind of external resource or network control requirement. From: Dorn Hetzel <dorn@hetzel.org> Sent: Thursday, June 18, 2026 10:59 PM To: Gary Sparkes <gary@kisaracorporation.com> Cc: North American Network Operators Group <nanog@lists.nanog.org>; Arie Vayner <ariev@vayner.net> Subject: Re: IPv4 flag day Does this assume that the firewall creating a mapping for ICMP also causes it to create a full mapping for any IP protocol (TCP, UDP, etc) ? On Thu, Jun 18, 2026 at 4:05 PM Gary Sparkes <gary@kisaracorporation.com<mailto:gary@kisaracorporation.com>> wrote: ICMP Time Exceeded, not unreachable. In this case we’re abusing that ICMP Time Exceeded packet to communicate to the host behind the NAT the client-side IP. Then all the magic can light up between the two endpoints. From: Dorn Hetzel <dorn@hetzel.org<mailto:dorn@hetzel.org>> Sent: Thursday, June 18, 2026 5:46 PM To: North American Network Operators Group <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Cc: Gary Sparkes <gary@kisaracorporation.com<mailto:gary@kisaracorporation.com>>; Arie Vayner <ariev@vayner.net<mailto:ariev@vayner.net>> Subject: Re: IPv4 flag day Do I misunderstand, or does it only allow inbound traffic from random hosts *as long as it meets the format of ICMP unreachable* and has the correct contents? On Thu, Jun 18, 2026 at 3:34 PM Arie Vayner via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: Unless I'm missing something, the pwnat mechanism will actually work through any stateful packet inspection (be it NAT or just a firewall) that allows Traceroute to work. They basically take advantage of ICMP unreachable messages to sneak through the stateful inspection mechanism... So a "malicious" host on your FW inside can basically punch through by creating this "ICMP" hole... Interesting technique for sure. On Thu, Jun 18, 2026, 11:44 AM Gary Sparkes via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote:
Simply, the inbound firewall rules prevent it from working.
There's no NAT to bypass the firewall to allow the ingress.
You'd instead have to open the ingress port on the firewall to allow the traffic.
(It does work, as I noted, I've used it for a legitimate customer before)
In the non-NAT scenario, the port would have to be allowed through the firewall, or the device behind the NAT would have to connect to *me* at a point or infrastructure that I control.
Remember, I am effectively, an unknown address endpoint, *initiating* the connection to the NAT'd device that has no prior knowledge of my address.
-----Original Message----- From: William Herrin <bill@herrin.us<mailto:bill@herrin.us>> Sent: Thursday, June 18, 2026 2:37 PM To: Gary Sparkes <gary@kisaracorporation.com<mailto:gary@kisaracorporation.com>> Cc: North American Network Operators Group <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Subject: Re: IPv4 flag day
On Thu, Jun 18, 2026 at 11:18 AM Gary Sparkes <gary@kisaracorporation.com<mailto:gary@kisaracorporation.com>> wrote:
I never said the Pi wouldn't send outbound packets.
It's just sending ICMP echo packets to a destination that'll never respond and isn't owned or used by the attacker. Any arbitrary destination will work if you know what that is (and, since it's your payload, you configure that). In the "ready to connect" state, all you're seeing on your side is ICMP echos to X.X.X.X failing. I can then connect to your 1.2.3.4 from Y.Y.Y.Y over port XXXX.
Allowing me to establish ingress from any arbitrary Y.Y.Y.Y without any knowledge or control of X.X.X.X
So there never is, until I go to establish the connection FROM OUTSIDE THE NAT, a state between Y.Y.Y.Y and 1.2.3.4
Effectively, this turns into me establishing a connection from any arbitrary outside address, where I only need to know your external NAT IP, and no state had ever existed between us before.
Hi Gary,
That's pretty convoluted but let's say for the sake of the argument that it works. What stops it from working with the non-NAT firewall?
The claim you made against 1:many NAT was, "I can't imagine any case in where the ability to arbitrarily punch through your firewall (as an attacker) once I have any kind of foothold is a good feature." To sustain that claim as an argument against NAT (as opposed to an argument against outbound allow by default), you have to demonstrate an attack where you can punch through a 1:many NAT firewall but can't punch through a comparably configured non-NAT firewall.
Regards, Bill Herrin
-- For hire. https://bill.herrin.us/resume/ _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/TYNHRRA4...
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/LYNHL7WX...
My main point boils down to NAT extending and providing additional vectors and complexity above and beyond just a firewall. Heck, as a component alone it's a DoS vector as well. See: https://arxiv.org/html/2410.21984v1 This ONE technique we've been discussing - note that we've only been discussing one that I have experience with using for legitimate purposes - is neat in expanding the scope of attackability and flexibility. Not needing to control any aspect of network on any end at all. But it's not the only way. As for the beachhead, it could be as simple as a web page loading something in the background. Doesn't have to be fancy like a dedicated VPN appliance plugged into a person's desk. For ICMP, we really only need timeout exceeded and echo request/reply, packet too large isn't required (and that's what breaks PMTU) nor is dest unreach. With some kind of C&C infra, of course, it provides far more options. Game development libraries are especially useful as starting points here. Ancient Skype was my favorite example of easily getting around corporate firewalls in the past. If we want to get fancier, we can go this route if ALGs are in play - https://github.com/samyk/slipstream, for example. (mitigations and detections have since become available, this was in 2020, but it's still useful in some aspects) - article about this one: https://www.securityweek.com/nat-slipstreaming-visiting-malicious-site-can-e... Or this - https://samy.pl/natpin/ - (no idea if it still works, it's from 2010, but it was just a web page that'd port forward any arbitrary port back to the machine it ran on, written in just javascript) There are, of course, many ways to tighten and mitigate a portion of potential vectors, and not all apply to every situation (like the ALG route above). But, that's again, throwing more and more complexity and management on top of what a simple firewall would otherwise handle in a much cleaner, clearer, and safer way. And not all NAT implementations are created equal.... https://ieeexplore.ieee.org/document/11076087 Tl;dr https://weberblog.net/why-nat-has-nothing-to-do-with-security/ (I probably should note that all this only applies to PAT type NAT) All that being said, all types of NAT are useful and have advantages in plenty of scenarios and shouldn't be avoided, just approached and managed carefully as deployed. But removing NAT removes operational complexity and additional vectors. -----Original Message----- From: William Herrin via NANOG <nanog@lists.nanog.org> Sent: Thursday, June 18, 2026 10:29 PM To: Arie Vayner <ariev@vayner.net> Cc: North American Network Operators Group <nanog@lists.nanog.org>; William Herrin <bill@herrin.us> Subject: Re: IPv4 flag day On Thu, Jun 18, 2026 at 12:55 PM Arie Vayner <ariev@vayner.net> wrote:
Unless I'm missing something, the pwnat mechanism will actually work through any stateful packet inspection (be it NAT or just a firewall) that allows Traceroute to work.
Hi Arie, You're not missing anything. It's a novel mechanism for escalating a beachhead, but Gary hasn't explained why it wouldn't work just as well with any other firewall that allows internal machines to initiate outbound connections by default. Everybody needs ICMP destination unreachable messages from arbitrary sources to reach back to the origin. Path MTU discovery fails if they do not. With any kind of firewall. ICMP Time exceeded is not as crucial but traceroute breaks without it so most firewalls propagate it inward too. Interesting as it is, the thought experiment fails to support Gary's claim that NAT specifically makes a network vulnerable. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/4RW6QTMW...
Small business may have a small routed network (a few router hops), There is no mechanism to propagate PA address withdrawal through a few hops. By the way, it should not be RA lifetime because router may have a few connections to ISPs, not all down at the same time. It should be PIO (specific prefix) on the last hop. Eduard
-----Original Message----- From: Niels Bakker via NANOG <nanog@lists.nanog.org> Sent: Thursday, June 18, 2026 16:22 To: nanog@lists.nanog.org Cc: Niels Bakker <niels=nanog@bakker.net> Subject: Re: IPv4 flag day
* Matthew Petach [Wed 17 Jun 2026, 03:24 CEST]:
Unfortunately, there's nothing that tells the downstream host "hey, stop using that address as a source address for connections".
0 lifetime RAs.
-- Niels.
-- _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/YSMCSCI WCKRYITLTGQ6PJAOL5QCIMXK2/
Am 19.06.26 um 07:54 schrieb Vasilenko Eduard via NANOG:
Small business may have a small routed network (a few router hops), There is no mechanism to propagate PA address withdrawal through a few hops.
OSPF or RIP can be used. But the problem stays that if 2 prefixes are in use, there needs to be NAT to the ISP to avoid that the devices will unable to communicate. -- Gruß Marco Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
OSPF and RIP are not capable in principle to propagate address space for delegation. IPv6 source address is dynamic, PA (provider aggregated address space) may become invalid after 1 link down. Ed/
-----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org> Sent: Friday, June 19, 2026 09:02 To: nanog@lists.nanog.org Cc: Marco Moock <mm@dorfdsl.de> Subject: Re: IPv4 flag day
Am 19.06.26 um 07:54 schrieb Vasilenko Eduard via NANOG:
Small business may have a small routed network (a few router hops), There is no mechanism to propagate PA address withdrawal through a few hops.
OSPF or RIP can be used. But the problem stays that if 2 prefixes are in use, there needs to be NAT to the ISP to avoid that the devices will unable to communicate.
-- Gruß Marco
Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/XBJ57EE UKOERPPH25AVZZTIH5CFNOFFM/
Am 19.06.26 um 08:16 schrieb Vasilenko Eduard:
OSPF and RIP are not capable in principle to propagate address space for delegation. IPv6 source address is dynamic, PA (provider aggregated address space) may become invalid after 1 link down.
RIP/OSPF IIRC can also withdraw routes. Even if that is a crappy solution combined with DHCPv6-PD and dynamic prefixes. -- Gruß Marco Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
Yes, indeed, it is possible to give a hint to local router (for PIO withdrawal) from OSPF/RIP, especially if router participate in DHCP-PD and understand what particular prefix to monitor in OSPF. I believe that such solution was never documented and probably never implemented. It would have many proc and cons. It is very debatable. Ed/
-----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org> Sent: Friday, June 19, 2026 09:27 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Marco Moock <mm@dorfdsl.de> Subject: Re: IPv4 flag day
Am 19.06.26 um 08:16 schrieb Vasilenko Eduard:
OSPF and RIP are not capable in principle to propagate address space for delegation. IPv6 source address is dynamic, PA (provider aggregated address space) may become invalid after 1 link down.
RIP/OSPF IIRC can also withdraw routes. Even if that is a crappy solution combined with DHCPv6-PD and dynamic prefixes.
-- Gruß Marco
Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/CXAWD B42SX5JIZ3BFBAVOCNSIOPAOGTV/
Am 19.06.26 um 05:30 schrieb Gary Sparkes via NANOG:
For ICMP, we really only need timeout exceeded and echo request/reply, packet too large isn't required (and that's what breaks PMTU) nor is dest unreach.
Are there any reason to block ICMP dest unreachable? I never saw one. Breaking PMTU is a PITA - for both IPv6 and IPv4. -- Gruß Marco Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
I can't think of any reason to block any of these (dest unreach, echo req/rep, timeout exceed, or pkt too large) -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org> Sent: Friday, June 19, 2026 10:36 AM To: nanog@lists.nanog.org Cc: Marco Moock <mm@dorfdsl.de> Subject: Re: IPv4 flag day Am 19.06.26 um 05:30 schrieb Gary Sparkes via NANOG:
For ICMP, we really only need timeout exceeded and echo request/reply, packet too large isn't required (and that's what breaks PMTU) nor is dest unreach.
Are there any reason to block ICMP dest unreachable? I never saw one. Breaking PMTU is a PITA - for both IPv6 and IPv4. -- Gruß Marco Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/4CCLKQVM...
In my experience with MSP and enterprise people (though certainly not all), they're network incompetent. They can barely do flat IPv4 networks, much less a full IPv6 stack. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Saku Ytti via NANOG" <nanog@lists.nanog.org> To: "North American Network Operators Group" <nanog@lists.nanog.org> Cc: "Saku Ytti" <saku@ytti.fi> Sent: Tuesday, June 16, 2026 1:33:59 AM Subject: IPv4 flag day 'ello, I've babbled about this before, but apparently I'm babbling about it again. 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. I don't see any future where organically IPv4 dies in such a way that people offering services on the Internet are comfortable offering them IPv6 only, the long tail will be too expensive to ignore. Dual stack adds complexity, cost, reduces quality and security. It is also blatantly an antitrust issue, as established players with access to large allocations can outcompete new entrants with no IPv4 allocation. In practice I'm thinking about something where relevant players all sign an agreement to drop ipv4 at their edge in e..g 15 or 20 years. Creating clear business justification for people to implement IPv6 in their next upgrade cycle. Today if I'm an edge with the IPv4 addresses I need, I wouldn't consider IPv6, because that's just a cost to me, with no upside. I know I could get some transit shops to sign off on such an agreement, but no one cares about transit, this obviously doesn't work without Amazon and Facebook et.al. Sure edges still can have IPv4, but that's like edge having IPX or AppleTalk, it'll be highly local issue, no one expects to reach anywhere with it, and anticipates to translate 100% of external traffic. Amazon? Facebook? Google? Microsoft? Any appetite? -- ++ytti _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/E2XOPUM5...
On Sun, 21 Jun 2026 at 17:23, Mike Hammett <nanog@ics-il.net> wrote:
In my experience with MSP and enterprise people (though certainly not all), they're network incompetent. They can barely do flat IPv4 networks, much less a full IPv6 stack.
That's how the world works, things work exactly as poorly as the market allows. If suddenly edges have no alternative but IPv6, they will all manage to solve all their problems, poorly. And the world keeps on turning. -- ++ytti
Most pizza shops aren't going to be able to manage BGP. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "sronan--- via NANOG" <nanog@lists.nanog.org> To: nanog@lists.nanog.org Cc: "Arie Vayner" <ariev@vayner.net>, nanog@lists.nanog.org, sronan@ronan-online.com Sent: Tuesday, June 16, 2026 4:24:25 PM Subject: Re: IPv4 flag day 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 <nanog@lists.nanog.org> 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 <nanog@lists.nanog.org> 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 < nanog@lists.nanog.org> 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/nanog@lists.nanog.org/message/QEOMV5GN...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ABXC2CER...
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/BZ6LKHSD...
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/HZLJOUK3...
Sure, have every hotdog cart run BGP, pretty soon we'll need 64 bit AS numbers :) On Sun, Jun 21, 2026 at 6:29 PM Mike Hammett via NANOG < nanog@lists.nanog.org> wrote:
Most pizza shops aren't going to be able to manage BGP.
----- Mike Hammett Intelligent Computing Solutions
Midwest Internet Exchange
The Brothers WISP
----- Original Message ----- From: "sronan--- via NANOG" <nanog@lists.nanog.org> To: nanog@lists.nanog.org Cc: "Arie Vayner" <ariev@vayner.net>, nanog@lists.nanog.org, sronan@ronan-online.com Sent: Tuesday, June 16, 2026 4:24:25 PM Subject: Re: IPv4 flag day
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 < nanog@lists.nanog.org> 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 < nanog@lists.nanog.org> 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 < nanog@lists.nanog.org> 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/nanog@lists.nanog.org/message/QEOMV5GN...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ABXC2CER... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/BZ6LKHSD... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/HZLJOUK3...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/W3CJ2XL3...
Honestly, I'm surprised this hasn't been proposed or being worked on yet, because at some point (probably in my lifetime) it may become necessary. Though, AFAIK, we're still sub 500,000 for issued ASN range, out of the 4,000,000 so possible. But hobby ASNs and other usages are on the rise..... in some communities I see a lot of requests for help getting set up there, and most of those users are v6 only for obvious reasons.... -----Original Message----- From: Dorn Hetzel via NANOG <nanog@lists.nanog.org> Sent: Sunday, June 21, 2026 8:29 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Arie Vayner <ariev@vayner.net>; Dorn Hetzel <dorn@hetzel.org> Subject: Re: IPv4 flag day Sure, have every hotdog cart run BGP, pretty soon we'll need 64 bit AS numbers :) On Sun, Jun 21, 2026 at 6:29 PM Mike Hammett via NANOG < nanog@lists.nanog.org> wrote:
Most pizza shops aren't going to be able to manage BGP.
----- Mike Hammett Intelligent Computing Solutions
Midwest Internet Exchange
The Brothers WISP
----- Original Message ----- From: "sronan--- via NANOG" <nanog@lists.nanog.org> To: nanog@lists.nanog.org Cc: "Arie Vayner" <ariev@vayner.net>, nanog@lists.nanog.org, sronan@ronan-online.com Sent: Tuesday, June 16, 2026 4:24:25 PM Subject: Re: IPv4 flag day
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 < nanog@lists.nanog.org> 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 < nanog@lists.nanog.org> 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 < nanog@lists.nanog.org> 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/nanog@lists.nanog.org/message/QE OMV5GN4WLNYOH7QZWYP5E26ZJ5AO57/
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/AB XC2CERUCF64YKCK5YXOJTLPRJSTPBV/ _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/BZ 6LKHSDLZ3WOR4GW2B544OKLSHFBIIG/ _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/HZ LJOUK3CNBHHHS2KLRVNETDA3U7DNCZ/
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/W3 CJ2XL3YV6T5CI2HUOHBMZITT6NH22A/
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/EQX7WFQ5...
Don't you mean out of ~4,000,000,000 ? [4,294,967,296] ? On Sun, Jun 21, 2026 at 6:33 PM Gary Sparkes <gary@kisaracorporation.com> wrote:
Honestly, I'm surprised this hasn't been proposed or being worked on yet, because at some point (probably in my lifetime) it may become necessary. Though, AFAIK, we're still sub 500,000 for issued ASN range, out of the 4,000,000 so possible.
But hobby ASNs and other usages are on the rise..... in some communities I see a lot of requests for help getting set up there, and most of those users are v6 only for obvious reasons....
-----Original Message----- From: Dorn Hetzel via NANOG <nanog@lists.nanog.org> Sent: Sunday, June 21, 2026 8:29 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Arie Vayner <ariev@vayner.net>; Dorn Hetzel <dorn@hetzel.org> Subject: Re: IPv4 flag day
Sure, have every hotdog cart run BGP, pretty soon we'll need 64 bit AS numbers :)
On Sun, Jun 21, 2026 at 6:29 PM Mike Hammett via NANOG < nanog@lists.nanog.org> wrote:
Most pizza shops aren't going to be able to manage BGP.
----- Mike Hammett Intelligent Computing Solutions
Midwest Internet Exchange
The Brothers WISP
----- Original Message ----- From: "sronan--- via NANOG" <nanog@lists.nanog.org> To: nanog@lists.nanog.org Cc: "Arie Vayner" <ariev@vayner.net>, nanog@lists.nanog.org, sronan@ronan-online.com Sent: Tuesday, June 16, 2026 4:24:25 PM Subject: Re: IPv4 flag day
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 < nanog@lists.nanog.org> 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 < nanog@lists.nanog.org> 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 < nanog@lists.nanog.org> 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/nanog@lists.nanog.org/message/QE OMV5GN4WLNYOH7QZWYP5E26ZJ5AO57/
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/AB XC2CERUCF64YKCK5YXOJTLPRJSTPBV/ _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/BZ 6LKHSDLZ3WOR4GW2B544OKLSHFBIIG/ _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/HZ LJOUK3CNBHHHS2KLRVNETDA3U7DNCZ/
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/W3 CJ2XL3YV6T5CI2HUOHBMZITT6NH22A/
NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/EQX7WFQ5...
I may have missed a few zeros there :D I forget how large the reserved/non-issuable range is, that’s why I dropped out the 249 million part From: Dorn Hetzel <dorn@hetzel.org> Sent: Sunday, June 21, 2026 8:34 PM To: Gary Sparkes <gary@kisaracorporation.com> Cc: North American Network Operators Group <nanog@lists.nanog.org>; Arie Vayner <ariev@vayner.net> Subject: Re: IPv4 flag day Don't you mean out of ~4,000,000,000 ? [4,294,967,296] ? On Sun, Jun 21, 2026 at 6:33 PM Gary Sparkes <gary@kisaracorporation.com<mailto:gary@kisaracorporation.com>> wrote: Honestly, I'm surprised this hasn't been proposed or being worked on yet, because at some point (probably in my lifetime) it may become necessary. Though, AFAIK, we're still sub 500,000 for issued ASN range, out of the 4,000,000 so possible. But hobby ASNs and other usages are on the rise..... in some communities I see a lot of requests for help getting set up there, and most of those users are v6 only for obvious reasons.... -----Original Message----- From: Dorn Hetzel via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Sent: Sunday, June 21, 2026 8:29 PM To: North American Network Operators Group <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Cc: Arie Vayner <ariev@vayner.net<mailto:ariev@vayner.net>>; Dorn Hetzel <dorn@hetzel.org<mailto:dorn@hetzel.org>> Subject: Re: IPv4 flag day Sure, have every hotdog cart run BGP, pretty soon we'll need 64 bit AS numbers :) On Sun, Jun 21, 2026 at 6:29 PM Mike Hammett via NANOG < nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote:
Most pizza shops aren't going to be able to manage BGP.
----- Mike Hammett Intelligent Computing Solutions
Midwest Internet Exchange
The Brothers WISP
----- Original Message ----- From: "sronan--- via NANOG" <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> To: nanog@lists.nanog.org<mailto:nanog@lists.nanog.org> Cc: "Arie Vayner" <ariev@vayner.net<mailto:ariev@vayner.net>>, nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>, sronan@ronan-online.com<mailto:sronan@ronan-online.com> Sent: Tuesday, June 16, 2026 4:24:25 PM Subject: Re: IPv4 flag day
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 < nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> 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 < nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> 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 < nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> 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/nanog@lists.nanog.org/message/QE OMV5GN4WLNYOH7QZWYP5E26ZJ5AO57/
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/AB XC2CERUCF64YKCK5YXOJTLPRJSTPBV/ _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/BZ 6LKHSDLZ3WOR4GW2B544OKLSHFBIIG/ _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/HZ LJOUK3CNBHHHS2KLRVNETDA3U7DNCZ/
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/W3 CJ2XL3YV6T5CI2HUOHBMZITT6NH22A/
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/EQX7WFQ5...
Is there any current effort underway to make BGP more accessible, user-friendly, or "plug and play?" Anything that might address some of the more technically demanding aspects of multihoming? Quick Google says no, but maybe someone has more awareness. I'm pipe-dreaming BGP multihoming becoming as simple as connecting two Internet links to a CPE, with no reduction in MTU. No SD-WAN, no tunnels, no NAT. Works over any kind of link: 5G, wifi, GPON, cable, fiber, carrier pigeon. CPE vendors might set up web pages that request IPs and an ASN for you. Sets up ROAs, IRR, and the CPE, start to finish. Maybe there's a new protocol where the carrier auto-generates a BGP multihoming token and sends it to the user in the order docs. User sets the token on the CPE interface facing that provider. Successful negotiation lets the customer announce their prefix and ASN. CPE and carrier manage it all, no network staff needed. -Brian On 2026-06-21 19:29, Dorn Hetzel via NANOG wrote:
Sure, have every hotdog cart run BGP, pretty soon we'll need 64 bit AS numbers :)
On Sun, Jun 21, 2026 at 6:29 PM Mike Hammett via NANOG < nanog@lists.nanog.org> wrote:
Most pizza shops aren't going to be able to manage BGP.
----- Mike Hammett Intelligent Computing Solutions
Midwest Internet Exchange
The Brothers WISP
Don't think we want to specifically design for FIB and RIB creep. Multihoming is scarcely needed, if we get our ducks in a row. Non-content sharing sites can use QUIC to do location/identifier separation, some implementations do, but usually only rehoming between A, B instead of A, B any-order, but this is implementation detail, protocol does support it. Content sharing sites can use more advanced records than A/AAAA which in a single query give client hints about redundancy and multipaths, like SVCB, or something new. Having said that, this shouldn't be read as relevant to IPV6 single stack. While it may be a real problem, we need not couple it to IPv4->IPv6 transition, IPv6 transition can take IPv4 playbook, warts and all, as-is, and these other discussions can advance decoupled from it. On Mon, 22 Jun 2026 at 06:23, Brian Knight via NANOG <nanog@lists.nanog.org> wrote:
Is there any current effort underway to make BGP more accessible, user-friendly, or "plug and play?" Anything that might address some of the more technically demanding aspects of multihoming?
Quick Google says no, but maybe someone has more awareness.
I'm pipe-dreaming BGP multihoming becoming as simple as connecting two Internet links to a CPE, with no reduction in MTU. No SD-WAN, no tunnels, no NAT. Works over any kind of link: 5G, wifi, GPON, cable, fiber, carrier pigeon.
CPE vendors might set up web pages that request IPs and an ASN for you. Sets up ROAs, IRR, and the CPE, start to finish.
Maybe there's a new protocol where the carrier auto-generates a BGP multihoming token and sends it to the user in the order docs. User sets the token on the CPE interface facing that provider. Successful negotiation lets the customer announce their prefix and ASN. CPE and carrier manage it all, no network staff needed.
-Brian
On 2026-06-21 19:29, Dorn Hetzel via NANOG wrote:
Sure, have every hotdog cart run BGP, pretty soon we'll need 64 bit AS numbers :)
On Sun, Jun 21, 2026 at 6:29 PM Mike Hammett via NANOG < nanog@lists.nanog.org> wrote:
Most pizza shops aren't going to be able to manage BGP.
----- Mike Hammett Intelligent Computing Solutions
Midwest Internet Exchange
The Brothers WISP
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/7AMX6YN4...
-- ++ytti
Are you trolling now, right? Because I cant imagine the havoc this would create on DFZ. Its already mess, due to 32bit ASNs. Spammers and abusers love those. They buy 32bit, lend some /24 space, announce, do whatever they want and then just go away and move to new ranges. Now imagine every person and their dog running BGP? Im multihomed (on IPv4 for obvious reasons) and I do NOT need bgp. Why should I? This stuff is needed to tie ISPs together, not users. And NAT works great here. I have 2 defaults, some policy routing to direct given traffic where I need and 2 VPN connections. I do NOT do LB because I care more about RTT that raw bandwidth, so setup is a bit simpler. With (good) IPv6 implementation, I would still use PAT to multihome. Thats how single individuals should do, no need to waste IPs. There are ready to use routers that support this setup. I never used one but I suspect they works okey, any comments? As for SMB multihome, they should use NAT 1:1 (stateless) to translate RFC1918 -> Internet. In case of IPv6, address space is big, so they can grab big enough junks of address space from every ISP they multihome and arrange correct NAT rules + FW to do so. No need for ASN, no need for BGP and all that stuff.. Simple and elegant. The problem is that current IPv6 is fucked up overengineered crap. They tought about IoT and other nonse, instead to deliver simple protocol w/ larger address space. I would like that someone would just get new protocol to migrate to IPv4. Unfortunately, it wont happen I think, IPv6 is too much deployed. Too much money was poured to it... ---------- Original message ---------- From: Brian Knight via NANOG <nanog@lists.nanog.org> To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Brian Knight <ml@knight-networks.com> Subject: BGP user friendliness (was Re: IPv4 flag day) Date: Sun, 21 Jun 2026 22:22:55 -0500 Is there any current effort underway to make BGP more accessible, user-friendly, or "plug and play?" Anything that might address some of the more technically demanding aspects of multihoming? Quick Google says no, but maybe someone has more awareness. I'm pipe-dreaming BGP multihoming becoming as simple as connecting two Internet links to a CPE, with no reduction in MTU. No SD-WAN, no tunnels, no NAT. Works over any kind of link: 5G, wifi, GPON, cable, fiber, carrier pigeon. CPE vendors might set up web pages that request IPs and an ASN for you. Sets up ROAs, IRR, and the CPE, start to finish. Maybe there's a new protocol where the carrier auto-generates a BGP multihoming token and sends it to the user in the order docs. User sets the token on the CPE interface facing that provider. Successful negotiation lets the customer announce their prefix and ASN. CPE and carrier manage it all, no network staff needed. -Brian On 2026-06-21 19:29, Dorn Hetzel via NANOG wrote:
Sure, have every hotdog cart run BGP, pretty soon we'll need 64 bit AS numbers :)
On Sun, Jun 21, 2026 at 6:29PM Mike Hammett via NANOG < nanog@lists.nanog.org> wrote:
Most pizza shops aren't going to be able to manage BGP.
----- Mike Hammett Intelligent Computing Solutions
Midwest Internet Exchange
The Brothers WISP
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/7AMX6YN4...
With (good) IPv6 implementation, I would still use PAT to multihome. Thats how single individuals should do, no need to waste IPs. There are ready to use routers that support this setup. I never used one but I suspect they works okey, any comments? PAT if you can avoid it? Are you sure you're sane? -----Original Message----- From: borg--- via NANOG <nanog@lists.nanog.org> Sent: Monday, June 22, 2026 2:45 AM To: Brian Knight via NANOG <nanog@lists.nanog.org> Cc: borg@uu3.net Subject: Re: BGP user friendliness (was Re: IPv4 flag day) Are you trolling now, right? Because I cant imagine the havoc this would create on DFZ. Its already mess, due to 32bit ASNs. Spammers and abusers love those. They buy 32bit, lend some /24 space, announce, do whatever they want and then just go away and move to new ranges. Now imagine every person and their dog running BGP? Im multihomed (on IPv4 for obvious reasons) and I do NOT need bgp. Why should I? This stuff is needed to tie ISPs together, not users. And NAT works great here. I have 2 defaults, some policy routing to direct given traffic where I need and 2 VPN connections. I do NOT do LB because I care more about RTT that raw bandwidth, so setup is a bit simpler. With (good) IPv6 implementation, I would still use PAT to multihome. Thats how single individuals should do, no need to waste IPs. There are ready to use routers that support this setup. I never used one but I suspect they works okey, any comments? As for SMB multihome, they should use NAT 1:1 (stateless) to translate RFC1918 -> Internet. In case of IPv6, address space is big, so they can grab big enough junks of address space from every ISP they multihome and arrange correct NAT rules + FW to do so. No need for ASN, no need for BGP and all that stuff.. Simple and elegant. The problem is that current IPv6 is fucked up overengineered crap. They tought about IoT and other nonse, instead to deliver simple protocol w/ larger address space. I would like that someone would just get new protocol to migrate to IPv4. Unfortunately, it wont happen I think, IPv6 is too much deployed. Too much money was poured to it... ---------- Original message ---------- From: Brian Knight via NANOG <nanog@lists.nanog.org> To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Brian Knight <ml@knight-networks.com> Subject: BGP user friendliness (was Re: IPv4 flag day) Date: Sun, 21 Jun 2026 22:22:55 -0500 Is there any current effort underway to make BGP more accessible, user-friendly, or "plug and play?" Anything that might address some of the more technically demanding aspects of multihoming? Quick Google says no, but maybe someone has more awareness. I'm pipe-dreaming BGP multihoming becoming as simple as connecting two Internet links to a CPE, with no reduction in MTU. No SD-WAN, no tunnels, no NAT. Works over any kind of link: 5G, wifi, GPON, cable, fiber, carrier pigeon. CPE vendors might set up web pages that request IPs and an ASN for you. Sets up ROAs, IRR, and the CPE, start to finish. Maybe there's a new protocol where the carrier auto-generates a BGP multihoming token and sends it to the user in the order docs. User sets the token on the CPE interface facing that provider. Successful negotiation lets the customer announce their prefix and ASN. CPE and carrier manage it all, no network staff needed. -Brian On 2026-06-21 19:29, Dorn Hetzel via NANOG wrote:
Sure, have every hotdog cart run BGP, pretty soon we'll need 64 bit AS numbers :)
On Sun, Jun 21, 2026 at 6:29PM Mike Hammett via NANOG < nanog@lists.nanog.org> wrote:
Most pizza shops aren't going to be able to manage BGP.
----- Mike Hammett Intelligent Computing Solutions
Midwest Internet Exchange
The Brothers WISP
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/7AMX6YN4... _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/MLCNLRSV...
Well, Yeah, I might look "insane" to other people because I still follow UNIX philosophy and KISS. I also want flexibility. If you do not want PAT, then go ahead, use NAT or route public IPs directly. What I care is to have choice how to run my networks. When NAT first appeard, it was like wow! I can now share my expensive internet connection with neighbors. Then, ISPs started to do CGNAT and so we broke e2e, and so its cursed now. But CGNAT should never ever appear.. ---------- Original message ---------- From: Gary Sparkes <gary@kisaracorporation.com> To: North American Network Operators Group <nanog@lists.nanog.org> Cc: "borg@uu3.net" <borg@uu3.net> Subject: RE: BGP user friendliness (was Re: IPv4 flag day) Date: Mon, 22 Jun 2026 07:28:12 +0000 With (good) IPv6 implementation, I would still use PAT to multihome. Thats how single individuals should do, no need to waste IPs. There are ready to use routers that support this setup. I never used one but I suspect they works okey, any comments? PAT if you can avoid it? Are you sure you're sane? -----Original Message----- From: borg--- via NANOG <nanog@lists.nanog.org> Sent: Monday, June 22, 2026 2:45 AM To: Brian Knight via NANOG <nanog@lists.nanog.org> Cc: borg@uu3.net Subject: Re: BGP user friendliness (was Re: IPv4 flag day) Are you trolling now, right? Because I cant imagine the havoc this would create on DFZ. Its already mess, due to 32bit ASNs. Spammers and abusers love those. They buy 32bit, lend some /24 space, announce, do whatever they want and then just go away and move to new ranges. Now imagine every person and their dog running BGP? Im multihomed (on IPv4 for obvious reasons) and I do NOT need bgp. Why should I? This stuff is needed to tie ISPs together, not users. And NAT works great here. I have 2 defaults, some policy routing to direct given traffic where I need and 2 VPN connections. I do NOT do LB because I care more about RTT that raw bandwidth, so setup is a bit simpler. With (good) IPv6 implementation, I would still use PAT to multihome. Thats how single individuals should do, no need to waste IPs. There are ready to use routers that support this setup. I never used one but I suspect they works okey, any comments? As for SMB multihome, they should use NAT 1:1 (stateless) to translate RFC1918 -> Internet. In case of IPv6, address space is big, so they can grab big enough junks of address space from every ISP they multihome and arrange correct NAT rules + FW to do so. No need for ASN, no need for BGP and all that stuff.. Simple and elegant. The problem is that current IPv6 is fucked up overengineered crap. They tought about IoT and other nonse, instead to deliver simple protocol w/ larger address space. I would like that someone would just get new protocol to migrate to IPv4. Unfortunately, it wont happen I think, IPv6 is too much deployed. Too much money was poured to it... ---------- Original message ---------- From: Brian Knight via NANOG <nanog@lists.nanog.org> To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Brian Knight <ml@knight-networks.com> Subject: BGP user friendliness (was Re: IPv4 flag day) Date: Sun, 21 Jun 2026 22:22:55 -0500 Is there any current effort underway to make BGP more accessible, user-friendly, or "plug and play?" Anything that might address some of the more technically demanding aspects of multihoming? Quick Google says no, but maybe someone has more awareness. I'm pipe-dreaming BGP multihoming becoming as simple as connecting two Internet links to a CPE, with no reduction in MTU. No SD-WAN, no tunnels, no NAT. Works over any kind of link: 5G, wifi, GPON, cable, fiber, carrier pigeon. CPE vendors might set up web pages that request IPs and an ASN for you. Sets up ROAs, IRR, and the CPE, start to finish. Maybe there's a new protocol where the carrier auto-generates a BGP multihoming token and sends it to the user in the order docs. User sets the token on the CPE interface facing that provider. Successful negotiation lets the customer announce their prefix and ASN. CPE and carrier manage it all, no network staff needed. -Brian On 2026-06-21 19:29, Dorn Hetzel via NANOG wrote:
Sure, have every hotdog cart run BGP, pretty soon we'll need 64 bit AS numbers :)
On Sun, Jun 21, 2026 at 6:29PM Mike Hammett via NANOG < nanog@lists.nanog.org> wrote:
Most pizza shops aren't going to be able to manage BGP.
----- Mike Hammett Intelligent Computing Solutions
Midwest Internet Exchange
The Brothers WISP
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/7AMX6YN4... _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/MLCNLRSV...
Things I precisely advise my clients that we will not support. There is no reason to support or promote PAT. (My code breaks with it, since I removed PAT support) Except if you want to live in V4 land. At this point, we are happy to turn off V4. (For machining etc) Gary Sparkes IT Integration and Consulting Services Kisara Development O: +1 (646) 506-3097 C: +1 (646) 943-0977 gary@kisaracorporation.com Out of Office: None -----Original Message----- From: borg@uu3.net <borg@uu3.net> Sent: Monday, June 22, 2026 4:00 AM To: Gary Sparkes <gary@kisaracorporation.com> Cc: North American Network Operators Group <nanog@lists.nanog.org> Subject: RE: BGP user friendliness (was Re: IPv4 flag day) Well, Yeah, I might look "insane" to other people because I still follow UNIX philosophy and KISS. I also want flexibility. If you do not want PAT, then go ahead, use NAT or route public IPs directly. What I care is to have choice how to run my networks. When NAT first appeard, it was like wow! I can now share my expensive internet connection with neighbors. Then, ISPs started to do CGNAT and so we broke e2e, and so its cursed now. But CGNAT should never ever appear.. ---------- Original message ---------- From: Gary Sparkes <gary@kisaracorporation.com> To: North American Network Operators Group <nanog@lists.nanog.org> Cc: "borg@uu3.net" <borg@uu3.net> Subject: RE: BGP user friendliness (was Re: IPv4 flag day) Date: Mon, 22 Jun 2026 07:28:12 +0000 With (good) IPv6 implementation, I would still use PAT to multihome. Thats how single individuals should do, no need to waste IPs. There are ready to use routers that support this setup. I never used one but I suspect they works okey, any comments? PAT if you can avoid it? Are you sure you're sane? -----Original Message----- From: borg--- via NANOG <nanog@lists.nanog.org> Sent: Monday, June 22, 2026 2:45 AM To: Brian Knight via NANOG <nanog@lists.nanog.org> Cc: borg@uu3.net Subject: Re: BGP user friendliness (was Re: IPv4 flag day) Are you trolling now, right? Because I cant imagine the havoc this would create on DFZ. Its already mess, due to 32bit ASNs. Spammers and abusers love those. They buy 32bit, lend some /24 space, announce, do whatever they want and then just go away and move to new ranges. Now imagine every person and their dog running BGP? Im multihomed (on IPv4 for obvious reasons) and I do NOT need bgp. Why should I? This stuff is needed to tie ISPs together, not users. And NAT works great here. I have 2 defaults, some policy routing to direct given traffic where I need and 2 VPN connections. I do NOT do LB because I care more about RTT that raw bandwidth, so setup is a bit simpler. With (good) IPv6 implementation, I would still use PAT to multihome. Thats how single individuals should do, no need to waste IPs. There are ready to use routers that support this setup. I never used one but I suspect they works okey, any comments? As for SMB multihome, they should use NAT 1:1 (stateless) to translate RFC1918 -> Internet. In case of IPv6, address space is big, so they can grab big enough junks of address space from every ISP they multihome and arrange correct NAT rules + FW to do so. No need for ASN, no need for BGP and all that stuff.. Simple and elegant. The problem is that current IPv6 is fucked up overengineered crap. They tought about IoT and other nonse, instead to deliver simple protocol w/ larger address space. I would like that someone would just get new protocol to migrate to IPv4. Unfortunately, it wont happen I think, IPv6 is too much deployed. Too much money was poured to it... ---------- Original message ---------- From: Brian Knight via NANOG <nanog@lists.nanog.org> To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Brian Knight <ml@knight-networks.com> Subject: BGP user friendliness (was Re: IPv4 flag day) Date: Sun, 21 Jun 2026 22:22:55 -0500 Is there any current effort underway to make BGP more accessible, user-friendly, or "plug and play?" Anything that might address some of the more technically demanding aspects of multihoming? Quick Google says no, but maybe someone has more awareness. I'm pipe-dreaming BGP multihoming becoming as simple as connecting two Internet links to a CPE, with no reduction in MTU. No SD-WAN, no tunnels, no NAT. Works over any kind of link: 5G, wifi, GPON, cable, fiber, carrier pigeon. CPE vendors might set up web pages that request IPs and an ASN for you. Sets up ROAs, IRR, and the CPE, start to finish. Maybe there's a new protocol where the carrier auto-generates a BGP multihoming token and sends it to the user in the order docs. User sets the token on the CPE interface facing that provider. Successful negotiation lets the customer announce their prefix and ASN. CPE and carrier manage it all, no network staff needed. -Brian On 2026-06-21 19:29, Dorn Hetzel via NANOG wrote:
Sure, have every hotdog cart run BGP, pretty soon we'll need 64 bit AS numbers :)
On Sun, Jun 21, 2026 at 6:29PM Mike Hammett via NANOG < nanog@lists.nanog.org> wrote:
Most pizza shops aren't going to be able to manage BGP.
----- Mike Hammett Intelligent Computing Solutions
Midwest Internet Exchange
The Brothers WISP
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/7AMX6YN4... _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/MLCNLRSV...
IMHO: NPTv6 (network prefix translation) is much better. Anyone could use ULA (/48 from fd00::/8) on site and translate it to PA addresses from any number of carriers. Ed/
-----Original Message----- From: Gary Sparkes via NANOG <nanog@lists.nanog.org> Sent: Monday, June 22, 2026 12:56 To: borg@uu3.net Cc: North American Network Operators Group <nanog@lists.nanog.org>; Gary Sparkes <gary@kisaracorporation.com> Subject: RE: BGP user friendliness (was Re: IPv4 flag day)
Things I precisely advise my clients that we will not support.
There is no reason to support or promote PAT. (My code breaks with it, since I removed PAT support)
Except if you want to live in V4 land.
At this point, we are happy to turn off V4. (For machining etc)
Gary Sparkes IT Integration and Consulting Services Kisara Development O: +1 (646) 506-3097 C: +1 (646) 943-0977 gary@kisaracorporation.com Out of Office: None
-----Original Message----- From: borg@uu3.net <borg@uu3.net> Sent: Monday, June 22, 2026 4:00 AM To: Gary Sparkes <gary@kisaracorporation.com> Cc: North American Network Operators Group <nanog@lists.nanog.org> Subject: RE: BGP user friendliness (was Re: IPv4 flag day)
Well, Yeah, I might look "insane" to other people because I still follow UNIX philosophy and KISS. I also want flexibility.
If you do not want PAT, then go ahead, use NAT or route public IPs directly. What I care is to have choice how to run my networks.
When NAT first appeard, it was like wow! I can now share my expensive internet connection with neighbors. Then, ISPs started to do CGNAT and so we broke e2e, and so its cursed now. But CGNAT should never ever appear..
---------- Original message ----------
From: Gary Sparkes <gary@kisaracorporation.com> To: North American Network Operators Group <nanog@lists.nanog.org> Cc: "borg@uu3.net" <borg@uu3.net> Subject: RE: BGP user friendliness (was Re: IPv4 flag day) Date: Mon, 22 Jun 2026 07:28:12 +0000
With (good) IPv6 implementation, I would still use PAT to multihome. Thats how single individuals should do, no need to waste IPs. There are ready to use routers that support this setup. I never used one but I suspect they works okey, any comments?
PAT if you can avoid it? Are you sure you're sane?
-----Original Message----- From: borg--- via NANOG <nanog@lists.nanog.org> Sent: Monday, June 22, 2026 2:45 AM To: Brian Knight via NANOG <nanog@lists.nanog.org> Cc: borg@uu3.net Subject: Re: BGP user friendliness (was Re: IPv4 flag day)
Are you trolling now, right? Because I cant imagine the havoc this would create on DFZ.
Its already mess, due to 32bit ASNs. Spammers and abusers love those. They buy 32bit, lend some /24 space, announce, do whatever they want and then just go away and move to new ranges.
Now imagine every person and their dog running BGP?
Im multihomed (on IPv4 for obvious reasons) and I do NOT need bgp. Why should I? This stuff is needed to tie ISPs together, not users. And NAT works great here. I have 2 defaults, some policy routing to direct given traffic where I need and 2 VPN connections. I do NOT do LB because I care more about RTT that raw bandwidth, so setup is a bit simpler.
With (good) IPv6 implementation, I would still use PAT to multihome. Thats how single individuals should do, no need to waste IPs. There are ready to use routers that support this setup. I never used one but I suspect they works okey, any comments?
As for SMB multihome, they should use NAT 1:1 (stateless) to translate RFC1918 -> Internet. In case of IPv6, address space is big, so they can grab big enough junks of address space from every ISP they multihome and arrange correct NAT rules + FW to do so. No need for ASN, no need for BGP and all that stuff.. Simple and elegant.
The problem is that current IPv6 is fucked up overengineered crap. They tought about IoT and other nonse, instead to deliver simple protocol w/ larger address space.
I would like that someone would just get new protocol to migrate to IPv4. Unfortunately, it wont happen I think, IPv6 is too much deployed. Too much money was poured to it...
---------- Original message ----------
From: Brian Knight via NANOG <nanog@lists.nanog.org> To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Brian Knight <ml@knight-networks.com> Subject: BGP user friendliness (was Re: IPv4 flag day) Date: Sun, 21 Jun 2026 22:22:55 -0500
Is there any current effort underway to make BGP more accessible, user- friendly, or "plug and play?" Anything that might address some of the more technically demanding aspects of multihoming?
Quick Google says no, but maybe someone has more awareness.
I'm pipe-dreaming BGP multihoming becoming as simple as connecting two Internet links to a CPE, with no reduction in MTU. No SD-WAN, no tunnels, no NAT. Works over any kind of link: 5G, wifi, GPON, cable, fiber, carrier pigeon.
CPE vendors might set up web pages that request IPs and an ASN for you. Sets up ROAs, IRR, and the CPE, start to finish.
Maybe there's a new protocol where the carrier auto-generates a BGP multihoming token and sends it to the user in the order docs. User sets the token on the CPE interface facing that provider. Successful negotiation lets the customer announce their prefix and ASN. CPE and carrier manage it all, no network staff needed.
-Brian
On 2026-06-21 19:29, Dorn Hetzel via NANOG wrote:
Sure, have every hotdog cart run BGP, pretty soon we'll need 64 bit AS numbers :)
On Sun, Jun 21, 2026 at 6:29PM Mike Hammett via NANOG < nanog@lists.nanog.org> wrote:
Most pizza shops aren't going to be able to manage BGP.
----- Mike Hammett Intelligent Computing Solutions
Midwest Internet Exchange
The Brothers WISP
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/7AMX6Y N4MRTN7UQ5CQFNYI3KJCKKFJMZ/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/MLCNLR SVPV27OAWXJHBQ22W5GPYL2DR7/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/NXC5CG 3WDJYWHCTUPPC64HIQFCJCS2SK/
If you cannot support PAT then you are doing it wrong. Sorry. Its okey that FTP doesnt work correctly (need hacks) with PAT. Its bloody old protocol. But if someone after 2000 doing a protocol and it cannot cope with NAT/PAT, he is just silly. From what side we have huge centralization, cloud services etc, with doesnt care because there is huge classification for server (cloud) and client (enduser). PAT/NAT whatever it doesnt matter, connection goes from client -> server. If you cannot multiplex over single connection instruct client to make secondary connection to server. Its not rocket science really. Simple stuff... ---------- Original message ---------- From: Gary Sparkes <gary@kisaracorporation.com> To: "borg@uu3.net" <borg@uu3.net> Cc: North American Network Operators Group <nanog@lists.nanog.org> Subject: RE: BGP user friendliness (was Re: IPv4 flag day) Date: Mon, 22 Jun 2026 09:55:38 +0000 Things I precisely advise my clients that we will not support. There is no reason to support or promote PAT. (My code breaks with it, since I removed PAT support) Except if you want to live in V4 land. At this point, we are happy to turn off V4. (For machining etc) Gary Sparkes IT Integration and Consulting Services Kisara Development O: +1 (646) 506-3097 C: +1 (646) 943-0977 gary@kisaracorporation.com Out of Office: None -----Original Message----- From: borg@uu3.net <borg@uu3.net> Sent: Monday, June 22, 2026 4:00 AM To: Gary Sparkes <gary@kisaracorporation.com> Cc: North American Network Operators Group <nanog@lists.nanog.org> Subject: RE: BGP user friendliness (was Re: IPv4 flag day) Well, Yeah, I might look "insane" to other people because I still follow UNIX philosophy and KISS. I also want flexibility. If you do not want PAT, then go ahead, use NAT or route public IPs directly. What I care is to have choice how to run my networks. When NAT first appeard, it was like wow! I can now share my expensive internet connection with neighbors. Then, ISPs started to do CGNAT and so we broke e2e, and so its cursed now. But CGNAT should never ever appear.. ---------- Original message ---------- From: Gary Sparkes <gary@kisaracorporation.com> To: North American Network Operators Group <nanog@lists.nanog.org> Cc: "borg@uu3.net" <borg@uu3.net> Subject: RE: BGP user friendliness (was Re: IPv4 flag day) Date: Mon, 22 Jun 2026 07:28:12 +0000 With (good) IPv6 implementation, I would still use PAT to multihome. Thats how single individuals should do, no need to waste IPs. There are ready to use routers that support this setup. I never used one but I suspect they works okey, any comments? PAT if you can avoid it? Are you sure you're sane? -----Original Message----- From: borg--- via NANOG <nanog@lists.nanog.org> Sent: Monday, June 22, 2026 2:45 AM To: Brian Knight via NANOG <nanog@lists.nanog.org> Cc: borg@uu3.net Subject: Re: BGP user friendliness (was Re: IPv4 flag day) Are you trolling now, right? Because I cant imagine the havoc this would create on DFZ. Its already mess, due to 32bit ASNs. Spammers and abusers love those. They buy 32bit, lend some /24 space, announce, do whatever they want and then just go away and move to new ranges. Now imagine every person and their dog running BGP? Im multihomed (on IPv4 for obvious reasons) and I do NOT need bgp. Why should I? This stuff is needed to tie ISPs together, not users. And NAT works great here. I have 2 defaults, some policy routing to direct given traffic where I need and 2 VPN connections. I do NOT do LB because I care more about RTT that raw bandwidth, so setup is a bit simpler. With (good) IPv6 implementation, I would still use PAT to multihome. Thats how single individuals should do, no need to waste IPs. There are ready to use routers that support this setup. I never used one but I suspect they works okey, any comments? As for SMB multihome, they should use NAT 1:1 (stateless) to translate RFC1918 -> Internet. In case of IPv6, address space is big, so they can grab big enough junks of address space from every ISP they multihome and arrange correct NAT rules + FW to do so. No need for ASN, no need for BGP and all that stuff.. Simple and elegant. The problem is that current IPv6 is fucked up overengineered crap. They tought about IoT and other nonse, instead to deliver simple protocol w/ larger address space. I would like that someone would just get new protocol to migrate to IPv4. Unfortunately, it wont happen I think, IPv6 is too much deployed. Too much money was poured to it... ---------- Original message ---------- From: Brian Knight via NANOG <nanog@lists.nanog.org> To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Brian Knight <ml@knight-networks.com> Subject: BGP user friendliness (was Re: IPv4 flag day) Date: Sun, 21 Jun 2026 22:22:55 -0500 Is there any current effort underway to make BGP more accessible, user-friendly, or "plug and play?" Anything that might address some of the more technically demanding aspects of multihoming? Quick Google says no, but maybe someone has more awareness. I'm pipe-dreaming BGP multihoming becoming as simple as connecting two Internet links to a CPE, with no reduction in MTU. No SD-WAN, no tunnels, no NAT. Works over any kind of link: 5G, wifi, GPON, cable, fiber, carrier pigeon. CPE vendors might set up web pages that request IPs and an ASN for you. Sets up ROAs, IRR, and the CPE, start to finish. Maybe there's a new protocol where the carrier auto-generates a BGP multihoming token and sends it to the user in the order docs. User sets the token on the CPE interface facing that provider. Successful negotiation lets the customer announce their prefix and ASN. CPE and carrier manage it all, no network staff needed. -Brian On 2026-06-21 19:29, Dorn Hetzel via NANOG wrote:
Sure, have every hotdog cart run BGP, pretty soon we'll need 64 bit AS numbers :)
On Sun, Jun 21, 2026 at 6:29PM Mike Hammett via NANOG < nanog@lists.nanog.org> wrote:
Most pizza shops aren't going to be able to manage BGP.
----- Mike Hammett Intelligent Computing Solutions
Midwest Internet Exchange
The Brothers WISP
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/7AMX6YN4... _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/MLCNLRSV...
Is there any current effort underway to make BGP more accessible, user-friendly, or "plug and play?" Anything that might address some of the more technically demanding aspects of multihoming?
Simple BGP config is not that demanding. If you're going to connect a device to the public internet with BGP, it should require a basic level of competence. CPE vendors might set up web pages that request IPs and an ASN for you.
Sets up ROAs, IRR, and the CPE, start to finish.
None of this stuff should be 'ez-mode' for the uninformed user. Heck, informed users make a mess of it a lot of the time. Home install kits and plug and play doesn't work at a certain point. Stop trying to shoehorn it. On Sun, Jun 21, 2026 at 11:23 PM Brian Knight via NANOG < nanog@lists.nanog.org> wrote:
Is there any current effort underway to make BGP more accessible, user-friendly, or "plug and play?" Anything that might address some of the more technically demanding aspects of multihoming?
Quick Google says no, but maybe someone has more awareness.
I'm pipe-dreaming BGP multihoming becoming as simple as connecting two Internet links to a CPE, with no reduction in MTU. No SD-WAN, no tunnels, no NAT. Works over any kind of link: 5G, wifi, GPON, cable, fiber, carrier pigeon.
CPE vendors might set up web pages that request IPs and an ASN for you. Sets up ROAs, IRR, and the CPE, start to finish.
Maybe there's a new protocol where the carrier auto-generates a BGP multihoming token and sends it to the user in the order docs. User sets the token on the CPE interface facing that provider. Successful negotiation lets the customer announce their prefix and ASN. CPE and carrier manage it all, no network staff needed.
-Brian
On 2026-06-21 19:29, Dorn Hetzel via NANOG wrote:
Sure, have every hotdog cart run BGP, pretty soon we'll need 64 bit AS numbers :)
On Sun, Jun 21, 2026 at 6:29 PM Mike Hammett via NANOG < nanog@lists.nanog.org> wrote:
Most pizza shops aren't going to be able to manage BGP.
----- Mike Hammett Intelligent Computing Solutions
Midwest Internet Exchange
The Brothers WISP
NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/7AMX6YN4...
Most pizza shops aren't going to be able to manage BGP.
Nor should they. Stop trying to over-engineer solutions. Not everything needs hyper performant connectivity with sub second failover. On Sun, Jun 21, 2026 at 8:29 PM Mike Hammett via NANOG < nanog@lists.nanog.org> wrote:
Most pizza shops aren't going to be able to manage BGP.
----- Mike Hammett Intelligent Computing Solutions
Midwest Internet Exchange
The Brothers WISP
----- Original Message ----- From: "sronan--- via NANOG" <nanog@lists.nanog.org> To: nanog@lists.nanog.org Cc: "Arie Vayner" <ariev@vayner.net>, nanog@lists.nanog.org, sronan@ronan-online.com Sent: Tuesday, June 16, 2026 4:24:25 PM Subject: Re: IPv4 flag day
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 < nanog@lists.nanog.org> 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 < nanog@lists.nanog.org> 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 < nanog@lists.nanog.org> 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/nanog@lists.nanog.org/message/QEOMV5GN...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ABXC2CER... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/BZ6LKHSD... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/HZLJOUK3...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/W3CJ2XL3...
I wasn't advocating that they do, but to Shane's message about not buying Internet from anyone who doesn't support BGP. If it's not in the customer's requirements, then whether they do it or not is irrelevant. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Tom Beecher" <beecher@beecher.cc> To: "North American Network Operators Group" <nanog@lists.nanog.org> Cc: "Arie Vayner" <ariev@vayner.net>, "Mike Hammett" <nanog@ics-il.net> Sent: Monday, June 22, 2026 7:28:54 AM Subject: Re: IPv4 flag day Most pizza shops aren't going to be able to manage BGP. Nor should they. Stop trying to over-engineer solutions. Not everything needs hyper performant connectivity with sub second failover. On Sun, Jun 21, 2026 at 8:29 PM Mike Hammett via NANOG < nanog@lists.nanog.org > wrote: Most pizza shops aren't going to be able to manage BGP. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "sronan--- via NANOG" < nanog@lists.nanog.org > To: nanog@lists.nanog.org Cc: "Arie Vayner" < ariev@vayner.net >, nanog@lists.nanog.org , sronan@ronan-online.com Sent: Tuesday, June 16, 2026 4:24:25 PM Subject: Re: IPv4 flag day 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 < nanog@lists.nanog.org > 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 < nanog@lists.nanog.org > 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 < nanog@lists.nanog.org > 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/nanog@lists.nanog.org/message/QEOMV5GN...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ABXC2CER...
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/BZ6LKHSD...
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/HZLJOUK3... _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/W3CJ2XL3...
Tom Beecher via NANOG wrote on 22/06/2026 13:28:
Nor should they. Stop trying to over-engineer solutions. Not everything needs hyper performant connectivity with sub second failover.
no-one is going to get bgp based provider resilience with sub-second failover. 60-90 seconds would be a more realistic expectation for global convergence due to lots of providers having slow control planes / high churn and non-zero mrai. That's quite apart from the technical complication of bgp. And the general cost to other peoples' FIBs and control planes. NAT can be tuned far faster than BGP could ever successfully fail over, at the expense of session termination and the very minor nuisance of header address translation. It would be silly for most organisations to do anything other than some NAT variant. This is independent of address family. Nick
I could support it. I did in the past. IPv6 gave me and my customers no need to support it. If you onboared with me, it's without NAT. Gary Sparkes IT Integration and Consulting Services Kisara Development O: +1 (646) 506-3097 C: +1 (646) 943-0977 gary@kisaracorporation.com Out of Office: None -----Original Message----- From: borg--- via NANOG <nanog@lists.nanog.org> Sent: Monday, June 22, 2026 7:13 AM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: borg@uu3.net Subject: RE: BGP user friendliness (was Re: IPv4 flag day) If you cannot support PAT then you are doing it wrong. Sorry. Its okey that FTP doesnt work correctly (need hacks) with PAT. Its bloody old protocol. But if someone after 2000 doing a protocol and it cannot cope with NAT/PAT, he is just silly.
From what side we have huge centralization, cloud services etc, with doesnt care because there is huge classification for server (cloud) and client (enduser). PAT/NAT whatever it doesnt matter, connection goes from client -> server. If you cannot multiplex over single connection instruct client to make secondary connection to server. Its not rocket science really. Simple stuff...
---------- Original message ---------- From: Gary Sparkes <gary@kisaracorporation.com> To: "borg@uu3.net" <borg@uu3.net> Cc: North American Network Operators Group <nanog@lists.nanog.org> Subject: RE: BGP user friendliness (was Re: IPv4 flag day) Date: Mon, 22 Jun 2026 09:55:38 +0000 Things I precisely advise my clients that we will not support. There is no reason to support or promote PAT. (My code breaks with it, since I removed PAT support) Except if you want to live in V4 land. At this point, we are happy to turn off V4. (For machining etc) Gary Sparkes IT Integration and Consulting Services Kisara Development O: +1 (646) 506-3097 C: +1 (646) 943-0977 gary@kisaracorporation.com Out of Office: None -----Original Message----- From: borg@uu3.net <borg@uu3.net> Sent: Monday, June 22, 2026 4:00 AM To: Gary Sparkes <gary@kisaracorporation.com> Cc: North American Network Operators Group <nanog@lists.nanog.org> Subject: RE: BGP user friendliness (was Re: IPv4 flag day) Well, Yeah, I might look "insane" to other people because I still follow UNIX philosophy and KISS. I also want flexibility. If you do not want PAT, then go ahead, use NAT or route public IPs directly. What I care is to have choice how to run my networks. When NAT first appeard, it was like wow! I can now share my expensive internet connection with neighbors. Then, ISPs started to do CGNAT and so we broke e2e, and so its cursed now. But CGNAT should never ever appear.. ---------- Original message ---------- From: Gary Sparkes <gary@kisaracorporation.com> To: North American Network Operators Group <nanog@lists.nanog.org> Cc: "borg@uu3.net" <borg@uu3.net> Subject: RE: BGP user friendliness (was Re: IPv4 flag day) Date: Mon, 22 Jun 2026 07:28:12 +0000 With (good) IPv6 implementation, I would still use PAT to multihome. Thats how single individuals should do, no need to waste IPs. There are ready to use routers that support this setup. I never used one but I suspect they works okey, any comments? PAT if you can avoid it? Are you sure you're sane? -----Original Message----- From: borg--- via NANOG <nanog@lists.nanog.org> Sent: Monday, June 22, 2026 2:45 AM To: Brian Knight via NANOG <nanog@lists.nanog.org> Cc: borg@uu3.net Subject: Re: BGP user friendliness (was Re: IPv4 flag day) Are you trolling now, right? Because I cant imagine the havoc this would create on DFZ. Its already mess, due to 32bit ASNs. Spammers and abusers love those. They buy 32bit, lend some /24 space, announce, do whatever they want and then just go away and move to new ranges. Now imagine every person and their dog running BGP? Im multihomed (on IPv4 for obvious reasons) and I do NOT need bgp. Why should I? This stuff is needed to tie ISPs together, not users. And NAT works great here. I have 2 defaults, some policy routing to direct given traffic where I need and 2 VPN connections. I do NOT do LB because I care more about RTT that raw bandwidth, so setup is a bit simpler. With (good) IPv6 implementation, I would still use PAT to multihome. Thats how single individuals should do, no need to waste IPs. There are ready to use routers that support this setup. I never used one but I suspect they works okey, any comments? As for SMB multihome, they should use NAT 1:1 (stateless) to translate RFC1918 -> Internet. In case of IPv6, address space is big, so they can grab big enough junks of address space from every ISP they multihome and arrange correct NAT rules + FW to do so. No need for ASN, no need for BGP and all that stuff.. Simple and elegant. The problem is that current IPv6 is fucked up overengineered crap. They tought about IoT and other nonse, instead to deliver simple protocol w/ larger address space. I would like that someone would just get new protocol to migrate to IPv4. Unfortunately, it wont happen I think, IPv6 is too much deployed. Too much money was poured to it... ---------- Original message ---------- From: Brian Knight via NANOG <nanog@lists.nanog.org> To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Brian Knight <ml@knight-networks.com> Subject: BGP user friendliness (was Re: IPv4 flag day) Date: Sun, 21 Jun 2026 22:22:55 -0500 Is there any current effort underway to make BGP more accessible, user-friendly, or "plug and play?" Anything that might address some of the more technically demanding aspects of multihoming? Quick Google says no, but maybe someone has more awareness. I'm pipe-dreaming BGP multihoming becoming as simple as connecting two Internet links to a CPE, with no reduction in MTU. No SD-WAN, no tunnels, no NAT. Works over any kind of link: 5G, wifi, GPON, cable, fiber, carrier pigeon. CPE vendors might set up web pages that request IPs and an ASN for you. Sets up ROAs, IRR, and the CPE, start to finish. Maybe there's a new protocol where the carrier auto-generates a BGP multihoming token and sends it to the user in the order docs. User sets the token on the CPE interface facing that provider. Successful negotiation lets the customer announce their prefix and ASN. CPE and carrier manage it all, no network staff needed. -Brian On 2026-06-21 19:29, Dorn Hetzel via NANOG wrote:
Sure, have every hotdog cart run BGP, pretty soon we'll need 64 bit AS numbers :)
On Sun, Jun 21, 2026 at 6:29PM Mike Hammett via NANOG < nanog@lists.nanog.org> wrote:
Most pizza shops aren't going to be able to manage BGP.
----- Mike Hammett Intelligent Computing Solutions
Midwest Internet Exchange
The Brothers WISP
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/7AMX6YN4... _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/MLCNLRSV... _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/LNDP555G...
Fair enough. My reply was un-nescessarilly loud then given my misunderstanding, so I will eat my shit sandwich and apologize. On Mon, Jun 22, 2026 at 8:42 AM Mike Hammett <nanog@ics-il.net> wrote:
I wasn't advocating that they do, but to Shane's message about not buying Internet from anyone who doesn't support BGP. If it's not in the customer's requirements, then whether they do it or not is irrelevant.
----- Mike Hammett Intelligent Computing Solutions
Midwest Internet Exchange
The Brothers WISP
----- Original Message ----- From: "Tom Beecher" <beecher@beecher.cc> To: "North American Network Operators Group" <nanog@lists.nanog.org> Cc: "Arie Vayner" <ariev@vayner.net>, "Mike Hammett" <nanog@ics-il.net> Sent: Monday, June 22, 2026 7:28:54 AM Subject: Re: IPv4 flag day
Most pizza shops aren't going to be able to manage BGP.
Nor should they. Stop trying to over-engineer solutions. Not everything needs hyper performant connectivity with sub second failover.
On Sun, Jun 21, 2026 at 8:29 PM Mike Hammett via NANOG < nanog@lists.nanog.org > wrote:
Most pizza shops aren't going to be able to manage BGP.
----- Mike Hammett Intelligent Computing Solutions
Midwest Internet Exchange
The Brothers WISP
----- Original Message ----- From: "sronan--- via NANOG" < nanog@lists.nanog.org > To: nanog@lists.nanog.org Cc: "Arie Vayner" < ariev@vayner.net >, nanog@lists.nanog.org , sronan@ronan-online.com Sent: Tuesday, June 16, 2026 4:24:25 PM Subject: Re: IPv4 flag day
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 < nanog@lists.nanog.org > 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 < nanog@lists.nanog.org > 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 < nanog@lists.nanog.org > 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/nanog@lists.nanog.org/message/QEOMV5GN...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ABXC2CER... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/BZ6LKHSD... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/HZLJOUK3...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/W3CJ2XL3...
No problem. I know you well enough to assume it was a misunderstanding than normal. In a sea of NANOG hostilities, apologies are nice. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Tom Beecher" <beecher@beecher.cc> To: "Mike Hammett" <nanog@ics-il.net> Cc: "Arie Vayner" <ariev@vayner.net>, "North American Network Operators Group" <nanog@lists.nanog.org> Sent: Monday, June 22, 2026 8:43:04 AM Subject: Re: IPv4 flag day Fair enough. My reply was un-nescessarilly loud then given my misunderstanding, so I will eat my shit sandwich and apologize. On Mon, Jun 22, 2026 at 8:42 AM Mike Hammett < nanog@ics-il.net > wrote: I wasn't advocating that they do, but to Shane's message about not buying Internet from anyone who doesn't support BGP. If it's not in the customer's requirements, then whether they do it or not is irrelevant. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Tom Beecher" < beecher@beecher.cc > To: "North American Network Operators Group" < nanog@lists.nanog.org > Cc: "Arie Vayner" < ariev@vayner.net >, "Mike Hammett" < nanog@ics-il.net > Sent: Monday, June 22, 2026 7:28:54 AM Subject: Re: IPv4 flag day Most pizza shops aren't going to be able to manage BGP. Nor should they. Stop trying to over-engineer solutions. Not everything needs hyper performant connectivity with sub second failover. On Sun, Jun 21, 2026 at 8:29 PM Mike Hammett via NANOG < nanog@lists.nanog.org > wrote: Most pizza shops aren't going to be able to manage BGP. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "sronan--- via NANOG" < nanog@lists.nanog.org > To: nanog@lists.nanog.org Cc: "Arie Vayner" < ariev@vayner.net >, nanog@lists.nanog.org , sronan@ronan-online.com Sent: Tuesday, June 16, 2026 4:24:25 PM Subject: Re: IPv4 flag day 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 < nanog@lists.nanog.org > 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 < nanog@lists.nanog.org > 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 < nanog@lists.nanog.org > 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/nanog@lists.nanog.org/message/QEOMV5GN...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ABXC2CER...
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/BZ6LKHSD...
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/HZLJOUK3... _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/W3CJ2XL3...
On 22/06/2026 08:45, borg--- via NANOG wrote:
Are you trolling now, right? Because I cant imagine the havoc this would create on DFZ.
Its already mess, due to 32bit ASNs. Spammers and abusers love those. They buy 32bit, lend some /24 space, announce, do whatever they want and then just go away and move to new ranges.
Now imagine every person and their dog running BGP?
any idea which RIR is the most used by abusers of this type? perhaps not using Spamhaus DROP as a metric, even though, why not? ;) Radu
Hmm, I personaly dont do any stats per RIR, so no clue. From what I gathered, its not really RIR specific. It comes from all over the world. If anything, some countries have more of those that others, but what is the reason? Law? Easy money to shaddy company? No clue either.. ---------- Original message ---------- From: Radu Anghel via NANOG <nanog@lists.nanog.org> To: nanog@lists.nanog.org Cc: Radu Anghel <radu.anghel@xindi.ro> Subject: Re: BGP user friendliness (was Re: IPv4 flag day) Date: Mon, 22 Jun 2026 16:10:59 +0200 On 22/06/2026 08:45, borg--- via NANOG wrote:
Are you trolling now, right? Because I cant imagine the havoc this would create on DFZ.
Its already mess, due to 32bit ASNs. Spammers and abusers love those. They buy 32bit, lend some /24 space, announce, do whatever they want and then just go away and move to new ranges.
Now imagine every person and their dog running BGP?
any idea which RIR is the most used by abusers of this type? perhaps not using Spamhaus DROP as a metric, even though, why not? ;) Radu _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GJM6LZN6...
So, to summarize the responses so far: * We don't want uninformed users to multihome using BGP because it is difficult (which is a very fair statement) * We want them to use NAT44 or NAT66 or NPT or PAT * Servers in IP ranges that need to be multihomed could also use QUIC or DNS to provide multipath connections I know from experience that VPN tunnels (or SD-WAN) are another option. I'm not necessarily advocating that world + dog use BGP for multihoming. I'm making the point that true multihoming is out of reach for many small shops. And that's by design. No one is working to make using BGP easier. I'm now convinced that the proverbial ship has sailed. NAT had to be developed for IPv6. It will be used. It is here to stay. The "NAT is cancer" statement is old hat and no longer relevant. I have never deployed IPv6 NAT for multihoming, but I have deployed IPv4 NAT/PAT for it. If deploying IPv6 NAT is as difficult as folks say, it's time to make it simpler so SMBs can do what they already know how to do. They have few alternatives, and NAT is going to be among the least costly options. -Brian On 2026-06-21 22:22, Brian Knight via NANOG wrote:
Is there any current effort underway to make BGP more accessible, user-friendly, or "plug and play?" Anything that might address some of the more technically demanding aspects of multihoming?
Quick Google says no, but maybe someone has more awareness.
I'm pipe-dreaming BGP multihoming becoming as simple as connecting two Internet links to a CPE, with no reduction in MTU. No SD-WAN, no tunnels, no NAT. Works over any kind of link: 5G, wifi, GPON, cable, fiber, carrier pigeon.
CPE vendors might set up web pages that request IPs and an ASN for you. Sets up ROAs, IRR, and the CPE, start to finish.
Maybe there's a new protocol where the carrier auto-generates a BGP multihoming token and sends it to the user in the order docs. User sets the token on the CPE interface facing that provider. Successful negotiation lets the customer announce their prefix and ASN. CPE and carrier manage it all, no network staff needed.
-Brian
I'm now convinced that the proverbial ship has sailed. NAT had to be developed for IPv6. It will be used. It is here to stay. The "NAT is cancer" statement is old hat and no longer relevant.
And for those customers who do 1:many nat, my software just won't support them. It's simple enough. NPT/1:1 NAT is fine. PAT 1:many is not. The "NAT is cancer" statement is entirely relevant. NPT for SMB stuff is braindead simple - click a few checkboxes. That's the 1:1 scenario that just works and doesn't require extra code (outside of external address detection) to support unlike 1:many PAT. -----Original Message----- From: Brian Knight via NANOG <nanog@lists.nanog.org> Sent: Monday, June 22, 2026 9:15 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Brian Knight <ml@knight-networks.com> Subject: Re: BGP user friendliness (was Re: IPv4 flag day) So, to summarize the responses so far: * We don't want uninformed users to multihome using BGP because it is difficult (which is a very fair statement) * We want them to use NAT44 or NAT66 or NPT or PAT * Servers in IP ranges that need to be multihomed could also use QUIC or DNS to provide multipath connections I know from experience that VPN tunnels (or SD-WAN) are another option. I'm not necessarily advocating that world + dog use BGP for multihoming. I'm making the point that true multihoming is out of reach for many small shops. And that's by design. No one is working to make using BGP easier. I'm now convinced that the proverbial ship has sailed. NAT had to be developed for IPv6. It will be used. It is here to stay. The "NAT is cancer" statement is old hat and no longer relevant. I have never deployed IPv6 NAT for multihoming, but I have deployed IPv4 NAT/PAT for it. If deploying IPv6 NAT is as difficult as folks say, it's time to make it simpler so SMBs can do what they already know how to do. They have few alternatives, and NAT is going to be among the least costly options. -Brian On 2026-06-21 22:22, Brian Knight via NANOG wrote:
Is there any current effort underway to make BGP more accessible, user-friendly, or "plug and play?" Anything that might address some of the more technically demanding aspects of multihoming?
Quick Google says no, but maybe someone has more awareness.
I'm pipe-dreaming BGP multihoming becoming as simple as connecting two Internet links to a CPE, with no reduction in MTU. No SD-WAN, no tunnels, no NAT. Works over any kind of link: 5G, wifi, GPON, cable, fiber, carrier pigeon.
CPE vendors might set up web pages that request IPs and an ASN for you. Sets up ROAs, IRR, and the CPE, start to finish.
Maybe there's a new protocol where the carrier auto-generates a BGP multihoming token and sends it to the user in the order docs. User sets the token on the CPE interface facing that provider. Successful negotiation lets the customer announce their prefix and ASN. CPE and carrier manage it all, no network staff needed.
-Brian
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/RFEJ4FRN...
participants (39)
-
Aaron C. de Bruyn -
andrew＠apalrd.net -
Arie Vayner -
Bill Woodcock -
borg＠uu3.net -
Brandon Butterworth -
Brandon Jackson -
Brian Knight -
Ca By -
Daniel Seagraves -
David Prall -
Dorn Hetzel -
Douglas Fischer -
Gary Sparkes -
Hrant Dadivanyan -
Jay Acuna -
Jeff Shultz -
Joe Maimon -
John Curran -
John Osmon -
jordi.palet＠consulintel.es -
Laszlo H -
Lu Heng -
Marco Moock -
Matthew Petach -
Mikael Abrahamsson -
Mike Hammett -
Nick Hilliard -
Niels Bakker -
Pedro Prado -
Radu Anghel -
Randy Bush -
Saku Ytti -
Shane Ronan -
sronan＠ronan-online.com -
Tom Beecher -
Vasilenko Eduard -
Vincent Bernat -
William Herrin