Re: IPv4 flag day
On Thu, Jun 18, 2026 at 9:20 AM <sronan@ronan-online.com> wrote:
Honestly, if SMBs are the only ones staying on IPv4 with a /28 each, I’m fine with that :)
Yup! But that's why the subject line of this thread is met with "never gonna happen" -- because there's a *lot* of SMBs that are better off staying on IPv4 with their /28 and a pair of upstream NAT devices. And that's a *big* economic splash zone of collateral damage you'd be causing, even just doing a "let's turn off IPv4 for a day". So, hopefully people now understand why IPv4 isn't going away, and we can stop talking about a flag day or "shut it down for a day". Nobody wants to cause that level of economic harm for zero benefit. Thanks! Matt (still have my tee-shirt from helping with the first world IPv6 day; but pragmatic enough to understand and explain why IPv4 is never going away)
On Fri, 19 Jun 2026 at 09:03, Matthew Petach via NANOG <nanog@lists.nanog.org> wrote:
So, hopefully people now understand why IPv4 isn't going away, and we can stop talking about a flag day or "shut it down for a day". Nobody wants to cause that level of economic harm for zero benefit.
Short term thinking, the real economic damage of IPv4 is antitrust, which far exceeds any economic damage of flag day. Vote for IPv4 is a vote for monopolies and a vote against equitability. The list is talking mostly NAT or no NAT, not single or dual stack. These are separate discussions, I'm absolutely not saying don't do NAT. I'm saying, If you want to do NAPT with your IPv6, go right ahead. -- ++ytti
The list is talking mostly NAT or no NAT, not single or dual stack. These are separate discussions, I'm absolutely not saying don't do NAT. I'm saying, If you want to do NAPT with your IPv6, go right ahead.
The core discussion is that assuming there are use cases that NAT solves, and the lack of NAT makes hard to solve, the IPv6 community made it hard for the average SMB sysadmin to deploy IPv6: NAT has been "banned", standards/BCP docs that mention NAT were not approved, and all the IPV6 best practices docs for IPv6 say "No NAT". So my take on "If you want to do NAPT with your IPv6, go right ahead", in the current state, is that it's not practical, and has become a real blocker for IPv6 ubiquity. To move IPv6 to the next level of SMB/enterprise adoption we need to make it easier to consume by the average SMB - which means stop saying "NAT is evil" or "NAT is not supported in IPv6", and unblock relevant IETF work. Tnx Arie On Thu, Jun 18, 2026 at 11:13 PM Saku Ytti via NANOG <nanog@lists.nanog.org> wrote:
On Fri, 19 Jun 2026 at 09:03, Matthew Petach via NANOG <nanog@lists.nanog.org> wrote:
So, hopefully people now understand why IPv4 isn't going away, and we can stop talking about a flag day or "shut it down for a day". Nobody wants to cause that level of economic harm for zero benefit.
Short term thinking, the real economic damage of IPv4 is antitrust, which far exceeds any economic damage of flag day. Vote for IPv4 is a vote for monopolies and a vote against equitability.
The list is talking mostly NAT or no NAT, not single or dual stack. These are separate discussions, I'm absolutely not saying don't do NAT. I'm saying, If you want to do NAPT with your IPv6, go right ahead.
-- ++ytti _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/2TQ4CVYF...
On Fri, 19 Jun 2026 at 09:36, Arie Vayner <ariev@vayner.net> wrote:
So my take on "If you want to do NAPT with your IPv6, go right ahead", in the current state, is that it's not practical, and has become a real blocker for IPv6 ubiquity.
Disagree, exists in real commercial and open source implementations today and has for decades. I agree that the IPv6 kook messaging is hurting, making it seem like you shouldn't be doing NAT. But these are non-technical problems, and won't stop anyone using IPv6 NAPT in their edge.
To move IPv6 to the next level of SMB/enterprise adoption we need to make it easier to consume by the average SMB - which means stop saying "NAT is evil" or "NAT is not supported in IPv6", and unblock relevant IETF work.
Agree. Messaging needs work. Messaging needs to be 'you can do things exactly as you are doing today, you'll just have more addresses you can opt to use or not use'. This is perhaps the most difficult part here, to stop reaching for stars, because we can't even define what the stars are, different people want a different future for IP. Decouple these desires, deliver more IP now, and continue other pursuits in other avenues without asking for them to be lockstep. -- ++ytti
Comrades, Antitrust? Flag days? These are the timid, vacillating measures of right-opportunists who have not yet grasped our historical inevitability. 32-bit address space is, objectively, a doomed and reactionary form. NAT was never a solution but a half-measure that only prolonged the agony of a dying and irrelevant class. Carrier-grade NAT is nothing less than hoarding addresses that rightfully belong to the broad masses. History teaches us that the stubbornly regressive, the dissident, and the incompatible can be corrected only through honest, productive labor for the benefit of all. The saboteur proletariat in the boardrooms who refuse to renumber must be unmasked and re-educated I therefore move that we, the internetworking intelligentsia, extend our full confidence to Comrade Lavrentiy Beria for the ARIN Technical Committee. For the People's Address Space, IPv6 Kommissar Andrew *(Beria ran the apparatus that murdered hundreds of thousands of people via Stalin's purges. He is one of history's greatest monsters, and he should never be forgotten. "Endorsing" him is a joke made at the risk of invoking Poe's law, or sending people diving for history books. My point is this: Forced shutdowns, "flag days", solve nothing. Like the IPv8 thread, this thread has outlived its usefulness, and it needs to die.)* Andrew (This is obviously written at a serious risk of Poe's law. Beria was a monster, and forced shutdowns are not a solution to anything. Like the IPv8 thread, this is now a thread that needs to die.) On Fri, Jun 19, 2026 at 2:13 AM Saku Ytti via NANOG <nanog@lists.nanog.org> wrote:
On Fri, 19 Jun 2026 at 09:03, Matthew Petach via NANOG <nanog@lists.nanog.org> wrote:
So, hopefully people now understand why IPv4 isn't going away, and we can stop talking about a flag day or "shut it down for a day". Nobody wants to cause that level of economic harm for zero benefit.
Short term thinking, the real economic damage of IPv4 is antitrust, which far exceeds any economic damage of flag day. Vote for IPv4 is a vote for monopolies and a vote against equitability.
The list is talking mostly NAT or no NAT, not single or dual stack. These are separate discussions, I'm absolutely not saying don't do NAT. I'm saying, If you want to do NAPT with your IPv6, go right ahead.
-- ++ytti _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/2TQ4CVYF...
Apologies for the double-signature. This suffered from some over-editing because I was concerned someone might naively take what I said at face value instead of understanding the actual intent. Andrew On Fri, Jun 19, 2026 at 3:17 AM Andrew Kirch <trelane@trelane.net> wrote:
Comrades,
Antitrust? Flag days? These are the timid, vacillating measures of right-opportunists who have not yet grasped our historical inevitability.
32-bit address space is, objectively, a doomed and reactionary form. NAT was never a solution but a half-measure that only prolonged the agony of a dying and irrelevant class. Carrier-grade NAT is nothing less than hoarding addresses that rightfully belong to the broad masses.
History teaches us that the stubbornly regressive, the dissident, and the incompatible can be corrected only through honest, productive labor for the benefit of all. The saboteur proletariat in the boardrooms who refuse to renumber must be unmasked and re-educated
I therefore move that we, the internetworking intelligentsia, extend our full confidence to Comrade Lavrentiy Beria for the ARIN Technical Committee.
For the People's Address Space,
IPv6 Kommissar Andrew
*(Beria ran the apparatus that murdered hundreds of thousands of people via Stalin's purges. He is one of history's greatest monsters, and he should never be forgotten. "Endorsing" him is a joke made at the risk of invoking Poe's law, or sending people diving for history books. My point is this: Forced shutdowns, "flag days", solve nothing. Like the IPv8 thread, this thread has outlived its usefulness, and it needs to die.)*
Andrew
(This is obviously written at a serious risk of Poe's law. Beria was a monster, and forced shutdowns are not a solution to anything. Like the IPv8 thread, this is now a thread that needs to die.)
On Fri, Jun 19, 2026 at 2:13 AM Saku Ytti via NANOG <nanog@lists.nanog.org> wrote:
On Fri, 19 Jun 2026 at 09:03, Matthew Petach via NANOG <nanog@lists.nanog.org> wrote:
So, hopefully people now understand why IPv4 isn't going away, and we can stop talking about a flag day or "shut it down for a day". Nobody wants to cause that level of economic harm for zero benefit.
Short term thinking, the real economic damage of IPv4 is antitrust, which far exceeds any economic damage of flag day. Vote for IPv4 is a vote for monopolies and a vote against equitability.
The list is talking mostly NAT or no NAT, not single or dual stack. These are separate discussions, I'm absolutely not saying don't do NAT. I'm saying, If you want to do NAPT with your IPv6, go right ahead.
-- ++ytti _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/2TQ4CVYF...
On Fri, 19 Jun 2026 at 10:18, Andrew Kirch via NANOG <nanog@lists.nanog.org> wrote:
Antitrust? Flag days? These are the timid, vacillating measures of
Some big tech shops own billions worth of IPv4, and are buying more. This is not antitrust issue in your mind? Are the addresses not needed or can anyone afford the cost perpetually to the future? Is this desirable? -- ++ytti
Additionally to big tech, some connectivity providers, e.g. Cogent are making close 10% of their revenue leasing IPv4. And it is their fastest growing revenue. Where do we aim? What share of connectivity providing business should be IPv4 revenue? I'd like to argue, addresses should have no economic value, and if they do, we've failed our job. On Fri, 19 Jun 2026 at 10:35, Saku Ytti <saku@ytti.fi> wrote:
On Fri, 19 Jun 2026 at 10:18, Andrew Kirch via NANOG <nanog@lists.nanog.org> wrote:
Antitrust? Flag days? These are the timid, vacillating measures of
Some big tech shops own billions worth of IPv4, and are buying more. This is not antitrust issue in your mind? Are the addresses not needed or can anyone afford the cost perpetually to the future? Is this desirable?
-- ++ytti
-- ++ytti
On Jun 19, 2026, at 10:35 AM, Saku Ytti via NANOG <nanog@lists.nanog.org> wrote:
Some big tech shops own billions worth of IPv4, and are buying more.
If you say so (haven’t looked recently but have no reason to do more than quibble).
Is this desirable?
Pragmatically, yes. If you want the world to migrate to IPv6, there needs to be a reason better than “it has more bits!”. There is now an additional and very easily understood signal associated with choosing between IPv4 and IPv6, one that is easily understood by the beancounters behind network operators: the cost of addressing. If you’re an SMB with an IPv4 /24, you are now sitting on an asset that is worth between US$8K to US$12K on the spot market. How many public IPv4 addresses does the SMB actually need, given they’re probably using cloud/SAAS for their public Internet presence? How much would it cost to turn up IPv6 service (including IPv4aas) on their internal infrastructure? Would that cost be more or less than the asset price and migration costs? "Big tech shops” buying up all the addresses would drive the asset value up, increasing the likelihood the beancounters will see incentives to migrate. Regards, -drc
On Fri, 19 Jun 2026 at 11:32, David Conrad <drc@virtualized.org> wrote:
"Big tech shops” buying up all the addresses would drive the asset value up, increasing the likelihood the beancounters will see incentives to migrate.
It is an irrelevant cost to them. There is more value to them that competitors cannot have them. Hence antitrust. Free market won't fix the problem we created. Not that the free market even exists, any rule, law or regulation is industrial policy. -- ++ytti
Am 19.06.26 um 08:35 schrieb Arie Vayner:
To move IPv6 to the next level of SMB/enterprise adoption we need to make it easier to consume by the average SMB - which means stop saying "NAT is evil" or "NAT is not supported in IPv6", and unblock relevant IETF work.
There are devices for SMB that support stateful IPv6 NAT if they really need this. Although, my experience is that most of the network infrastructure in SMB environments is created one time and never touched unless necessary. They will also not implement IPv6 with NAT unless they really need it. Same applies to various other protocols. -- Gruß Marco Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
… which sounds right (not implementing something you don’t need). “Need” has a different interpretation for those inside a simple network and those interconnecting that network to everything else - a separation of values that Nat and even pat happens to handle pretty well IMHO, for the most part anyway, bar the well known issues. What value the granularity of addresses inside a SMB brings to the outside if the connectivity works without that? What does global-capable 128-bit addressing help a cyber cafe? I would hope that the research that goes into solving NAT/PAT issues would trickle into improvements to the end to end upper protocols which would eventually be unaware of how the network operates, similar to how L2 is transparent today (bar MTU mismatches…) *Pedro Martins Prado* pedro.prado@gmail.com / +353 83 036 1875 (FaceTime & WhatsApp) On Fri 19 Jun 2026 at 15:33, Marco Moock via NANOG <nanog@lists.nanog.org> wrote:
Am 19.06.26 um 08:35 schrieb Arie Vayner:
To move IPv6 to the next level of SMB/enterprise adoption we need to make it easier to consume by the average SMB - which means stop saying "NAT is evil" or "NAT is not supported in IPv6", and unblock relevant IETF work.
There are devices for SMB that support stateful IPv6 NAT if they really need this. Although, my experience is that most of the network infrastructure in SMB environments is created one time and never touched unless necessary. They will also not implement IPv6 with NAT unless they really need it. Same applies to various other protocols.
-- Gruß Marco
Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/AZFJS4DB...
The cybercafe? Faster and more reliable online gaming. Better VOIP services for communication. Gaming is something that *HUGELY* benefits from IPv6/NAT elimination. The SMB? More reliable/consistent SIP experience for their phones. Cheaper network hardware for the same throughput. Reduced complexity. Reduced costs (address space) if they're exposing anything externally / need external inbound access. (All wins I've gained for my customers, and yes, they're all either dual stack or v6 with edge translation for some networks, but with reduced expenses overall and more reliable/performant networks) Realistically, the only NAT that v6 should ever need is NPTv6 for the multihoming scenario (IEEE should just capitulate on that one, it just makes sense and it's not PAT that gives us all our problems in the first place), the rest just don't make sense and re-introduce complexity and issues that should be eliminated. IPv6 enabled me to rip out a LOT of NAT workaround code from systems I support, which greatly simplified a lot of things. Re-introducing PAT into V6 land as a common practice would, once again, require re-adding all those insane hacks and workarounds and decreasing reliability. We shouldn't need to solve those issues when we can eliminate them entirely. -----Original Message----- From: Pedro Prado via NANOG <nanog@lists.nanog.org> Sent: Friday, June 19, 2026 1:01 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Marco Moock <mm@dorfdsl.de>; Pedro Prado <pedro.prado@gmail.com> Subject: Re: IPv4 flag day … which sounds right (not implementing something you don’t need). “Need” has a different interpretation for those inside a simple network and those interconnecting that network to everything else - a separation of values that Nat and even pat happens to handle pretty well IMHO, for the most part anyway, bar the well known issues. What value the granularity of addresses inside a SMB brings to the outside if the connectivity works without that? What does global-capable 128-bit addressing help a cyber cafe? I would hope that the research that goes into solving NAT/PAT issues would trickle into improvements to the end to end upper protocols which would eventually be unaware of how the network operates, similar to how L2 is transparent today (bar MTU mismatches…) *Pedro Martins Prado* pedro.prado@gmail.com / +353 83 036 1875 (FaceTime & WhatsApp) On Fri 19 Jun 2026 at 15:33, Marco Moock via NANOG <nanog@lists.nanog.org> wrote:
Am 19.06.26 um 08:35 schrieb Arie Vayner:
To move IPv6 to the next level of SMB/enterprise adoption we need to make it easier to consume by the average SMB - which means stop saying "NAT is evil" or "NAT is not supported in IPv6", and unblock relevant IETF work.
There are devices for SMB that support stateful IPv6 NAT if they really need this. Although, my experience is that most of the network infrastructure in SMB environments is created one time and never touched unless necessary. They will also not implement IPv6 with NAT unless they really need it. Same applies to various other protocols.
-- Gruß Marco
Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/AZ FJS4DBXNUQQWO2ON2VGB7H2JKLBJTL/
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/JRCXLXRP...
The SMB use case is absolutely PAT. They aren’t going to 1:1 NAT all of their internal hosts to both providers provided IPv6 space.
On Jun 19, 2026, at 1:16 PM, Gary Sparkes via NANOG <nanog@lists.nanog.org> wrote:
The cybercafe? Faster and more reliable online gaming. Better VOIP services for communication.
Gaming is something that *HUGELY* benefits from IPv6/NAT elimination.
The SMB? More reliable/consistent SIP experience for their phones. Cheaper network hardware for the same throughput. Reduced complexity. Reduced costs (address space) if they're exposing anything externally / need external inbound access. (All wins I've gained for my customers, and yes, they're all either dual stack or v6 with edge translation for some networks, but with reduced expenses overall and more reliable/performant networks)
Realistically, the only NAT that v6 should ever need is NPTv6 for the multihoming scenario (IEEE should just capitulate on that one, it just makes sense and it's not PAT that gives us all our problems in the first place), the rest just don't make sense and re-introduce complexity and issues that should be eliminated.
IPv6 enabled me to rip out a LOT of NAT workaround code from systems I support, which greatly simplified a lot of things. Re-introducing PAT into V6 land as a common practice would, once again, require re-adding all those insane hacks and workarounds and decreasing reliability.
We shouldn't need to solve those issues when we can eliminate them entirely.
-----Original Message----- From: Pedro Prado via NANOG <nanog@lists.nanog.org> Sent: Friday, June 19, 2026 1:01 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Marco Moock <mm@dorfdsl.de>; Pedro Prado <pedro.prado@gmail.com> Subject: Re: IPv4 flag day
… which sounds right (not implementing something you don’t need).
“Need” has a different interpretation for those inside a simple network and those interconnecting that network to everything else - a separation of values that Nat and even pat happens to handle pretty well IMHO, for the most part anyway, bar the well known issues.
What value the granularity of addresses inside a SMB brings to the outside if the connectivity works without that? What does global-capable 128-bit addressing help a cyber cafe?
I would hope that the research that goes into solving NAT/PAT issues would trickle into improvements to the end to end upper protocols which would eventually be unaware of how the network operates, similar to how L2 is transparent today (bar MTU mismatches…)
*Pedro Martins Prado* pedro.prado@gmail.com / +353 83 036 1875 (FaceTime & WhatsApp)
On Fri 19 Jun 2026 at 15:33, Marco Moock via NANOG <nanog@lists.nanog.org> wrote:
Am 19.06.26 um 08:35 schrieb Arie Vayner: To move IPv6 to the next level of SMB/enterprise adoption we need to make it easier to consume by the average SMB - which means stop saying "NAT is evil" or "NAT is not supported in IPv6", and unblock relevant IETF work.
There are devices for SMB that support stateful IPv6 NAT if they really need this. Although, my experience is that most of the network infrastructure in SMB environments is created one time and never touched unless necessary. They will also not implement IPv6 with NAT unless they really need it. Same applies to various other protocols.
-- Gruß Marco
Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/AZ FJS4DBXNUQQWO2ON2VGB7H2JKLBJTL/
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/JRCXLXRP... _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/VOWZ3ODV...
Zero need for PAT. NPT means you *don't* have to PAT. Deploying PAT would be EXTRA steps. NPT means you're already 1:1 automatically, and you just open firewall ports for anything you need to inbound external access. No additional configuration or setup needed. PAT immediately eliminates most of the SMB benefits. The only one you retain is the V4 allocation cost reduction .... maybe. Any business internet will be giving you at least something like a /60 or /56, so as long as you subnet within that size space there's zero reason to put in additional effort for PAT and all the downsides it brings along with it. -----Original Message----- From: sronan@ronan-online.com <sronan@ronan-online.com> Sent: Friday, June 19, 2026 1:48 PM To: nanog@lists.nanog.org Cc: Marco Moock <mm@dorfdsl.de>; Gary Sparkes <gary@kisaracorporation.com>; nanog@lists.nanog.org Subject: Re: IPv4 flag day The SMB use case is absolutely PAT. They aren’t going to 1:1 NAT all of their internal hosts to both providers provided IPv6 space.
On Jun 19, 2026, at 1:16 PM, Gary Sparkes via NANOG <nanog@lists.nanog.org> wrote:
The cybercafe? Faster and more reliable online gaming. Better VOIP services for communication.
Gaming is something that *HUGELY* benefits from IPv6/NAT elimination.
The SMB? More reliable/consistent SIP experience for their phones. Cheaper network hardware for the same throughput. Reduced complexity. Reduced costs (address space) if they're exposing anything externally / need external inbound access. (All wins I've gained for my customers, and yes, they're all either dual stack or v6 with edge translation for some networks, but with reduced expenses overall and more reliable/performant networks)
Realistically, the only NAT that v6 should ever need is NPTv6 for the multihoming scenario (IEEE should just capitulate on that one, it just makes sense and it's not PAT that gives us all our problems in the first place), the rest just don't make sense and re-introduce complexity and issues that should be eliminated.
IPv6 enabled me to rip out a LOT of NAT workaround code from systems I support, which greatly simplified a lot of things. Re-introducing PAT into V6 land as a common practice would, once again, require re-adding all those insane hacks and workarounds and decreasing reliability.
We shouldn't need to solve those issues when we can eliminate them entirely.
-----Original Message----- From: Pedro Prado via NANOG <nanog@lists.nanog.org> Sent: Friday, June 19, 2026 1:01 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Marco Moock <mm@dorfdsl.de>; Pedro Prado <pedro.prado@gmail.com> Subject: Re: IPv4 flag day
… which sounds right (not implementing something you don’t need).
“Need” has a different interpretation for those inside a simple network and those interconnecting that network to everything else - a separation of values that Nat and even pat happens to handle pretty well IMHO, for the most part anyway, bar the well known issues.
What value the granularity of addresses inside a SMB brings to the outside if the connectivity works without that? What does global-capable 128-bit addressing help a cyber cafe?
I would hope that the research that goes into solving NAT/PAT issues would trickle into improvements to the end to end upper protocols which would eventually be unaware of how the network operates, similar to how L2 is transparent today (bar MTU mismatches…)
*Pedro Martins Prado* pedro.prado@gmail.com / +353 83 036 1875 (FaceTime & WhatsApp)
On Fri 19 Jun 2026 at 15:33, Marco Moock via NANOG <nanog@lists.nanog.org> wrote:
Am 19.06.26 um 08:35 schrieb Arie Vayner: To move IPv6 to the next level of SMB/enterprise adoption we need to make it easier to consume by the average SMB - which means stop saying "NAT is evil" or "NAT is not supported in IPv6", and unblock relevant IETF work.
There are devices for SMB that support stateful IPv6 NAT if they really need this. Although, my experience is that most of the network infrastructure in SMB environments is created one time and never touched unless necessary. They will also not implement IPv6 with NAT unless they really need it. Same applies to various other protocols.
-- Gruß Marco
Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/A Z FJS4DBXNUQQWO2ON2VGB7H2JKLBJTL/
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/JR CXLXRPKM2ELJPJFD4IBACOEOQ7LKMW/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/VO WZ3ODV43BY423LQ3RKNLHEIYLYBIBL/
If I have two upstream providers as an SMB, how do you propose I handle failover between the two of them without PAT?
On Jun 19, 2026, at 1:57 PM, Gary Sparkes <gary@kisaracorporation.com> wrote:
Zero need for PAT. NPT means you *don't* have to PAT. Deploying PAT would be EXTRA steps.
NPT means you're already 1:1 automatically, and you just open firewall ports for anything you need to inbound external access. No additional configuration or setup needed.
PAT immediately eliminates most of the SMB benefits. The only one you retain is the V4 allocation cost reduction .... maybe.
Any business internet will be giving you at least something like a /60 or /56, so as long as you subnet within that size space there's zero reason to put in additional effort for PAT and all the downsides it brings along with it.
-----Original Message----- From: sronan@ronan-online.com <sronan@ronan-online.com> Sent: Friday, June 19, 2026 1:48 PM To: nanog@lists.nanog.org Cc: Marco Moock <mm@dorfdsl.de>; Gary Sparkes <gary@kisaracorporation.com>; nanog@lists.nanog.org Subject: Re: IPv4 flag day
The SMB use case is absolutely PAT. They aren’t going to 1:1 NAT all of their internal hosts to both providers provided IPv6 space.
On Jun 19, 2026, at 1:16 PM, Gary Sparkes via NANOG <nanog@lists.nanog.org> wrote:
The cybercafe? Faster and more reliable online gaming. Better VOIP services for communication.
Gaming is something that *HUGELY* benefits from IPv6/NAT elimination.
The SMB? More reliable/consistent SIP experience for their phones. Cheaper network hardware for the same throughput. Reduced complexity. Reduced costs (address space) if they're exposing anything externally / need external inbound access. (All wins I've gained for my customers, and yes, they're all either dual stack or v6 with edge translation for some networks, but with reduced expenses overall and more reliable/performant networks)
Realistically, the only NAT that v6 should ever need is NPTv6 for the multihoming scenario (IEEE should just capitulate on that one, it just makes sense and it's not PAT that gives us all our problems in the first place), the rest just don't make sense and re-introduce complexity and issues that should be eliminated.
IPv6 enabled me to rip out a LOT of NAT workaround code from systems I support, which greatly simplified a lot of things. Re-introducing PAT into V6 land as a common practice would, once again, require re-adding all those insane hacks and workarounds and decreasing reliability.
We shouldn't need to solve those issues when we can eliminate them entirely.
-----Original Message----- From: Pedro Prado via NANOG <nanog@lists.nanog.org> Sent: Friday, June 19, 2026 1:01 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Marco Moock <mm@dorfdsl.de>; Pedro Prado <pedro.prado@gmail.com> Subject: Re: IPv4 flag day
… which sounds right (not implementing something you don’t need).
“Need” has a different interpretation for those inside a simple network and those interconnecting that network to everything else - a separation of values that Nat and even pat happens to handle pretty well IMHO, for the most part anyway, bar the well known issues.
What value the granularity of addresses inside a SMB brings to the outside if the connectivity works without that? What does global-capable 128-bit addressing help a cyber cafe?
I would hope that the research that goes into solving NAT/PAT issues would trickle into improvements to the end to end upper protocols which would eventually be unaware of how the network operates, similar to how L2 is transparent today (bar MTU mismatches…)
*Pedro Martins Prado* pedro.prado@gmail.com / +353 83 036 1875 (FaceTime & WhatsApp)
On Fri 19 Jun 2026 at 15:33, Marco Moock via NANOG <nanog@lists.nanog.org> wrote:
Am 19.06.26 um 08:35 schrieb Arie Vayner: To move IPv6 to the next level of SMB/enterprise adoption we need to make it easier to consume by the average SMB - which means stop saying "NAT is evil" or "NAT is not supported in IPv6", and unblock relevant IETF work.
There are devices for SMB that support stateful IPv6 NAT if they really need this. Although, my experience is that most of the network infrastructure in SMB environments is created one time and never touched unless necessary. They will also not implement IPv6 with NAT unless they really need it. Same applies to various other protocols.
-- Gruß Marco
Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/A Z FJS4DBXNUQQWO2ON2VGB7H2JKLBJTL/
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/JR CXLXRPKM2ELJPJFD4IBACOEOQ7LKMW/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/VO WZ3ODV43BY423LQ3RKNLHEIYLYBIBL/
On Fri, Jun 19, 2026 at 10:47 AM sronan--- via NANOG <nanog@lists.nanog.org> wrote:
The SMB use case is absolutely PAT. They aren’t going to 1:1 NAT all of their internal hosts to both providers provided IPv6 space.
SMB generally buys a box and whatever that box does by default, that's their network configuration. They pick that box mainly by reputation. They don't have a network security guy. They don't have a network guy. They have a couple IT guys whose main areas of expertise are troubleshooting PC hardware and Windows Domain Controllers. Enterprise, on the other hand, is definitely going NAT. Renumbering is painful even with IPv6. And they're very leery of 1:1 NAT -- they've made security configuration mistakes before and trust 1:many NAT to offer a layer of protection while those mistakes are detected and fixed. They take arguments against NAT to mean that IPv6 is not yet ripe for deployment with the sort of robust security frameworks they enjoy in IPv4. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/
Simply use NPTv6. That's exactly (one of) what it's for. PAT 1:many and NPT 1:1 works exactly the same for failover. Internal clients are 1:1 NPT'd to provider addresses, and on failover, the internal addressing doesn't change, but all the traffic flips to the other provider's addresses. Both external provider gives you a /60 - 16 /64 subnets though of course, you can cut lower size prefixes if you really want to - (we'll go conservative, here, /56 is what's usually seen for business lines/accounts in my experience). You configure those two WAN interfaces, and your internal LAN is subnetted /64's in ULA addressing. Turn on NPTv6 and boom, you're 1:1 with failover. Of course, you can direct pools of clients out to each provider or do some kind of load balancing as needed, same way you'd normally do a NAT pool on one provider for one subnet, and one for another kind of deal, many ways to skin the 'both providers up load balancing' cat, but that's going to work the same regardless of V4 PAT 1:many or NPTv6 1:1 Nice thing about NPT too is no state tables or real processing load, all it's doing is changing PROV:IDER:PRE:FIX: to YOUR:ULA:PRE:FIX and doing no other processing. Which, of course, means just simple firewall rules are all you need for any opening/closing of things. -----Original Message----- From: sronan@ronan-online.com <sronan@ronan-online.com> Sent: Friday, June 19, 2026 2:54 PM To: Gary Sparkes <gary@kisaracorporation.com> Cc: nanog@lists.nanog.org; Marco Moock <mm@dorfdsl.de> Subject: Re: IPv4 flag day If I have two upstream providers as an SMB, how do you propose I handle failover between the two of them without PAT?
On Jun 19, 2026, at 1:57 PM, Gary Sparkes <gary@kisaracorporation.com> wrote:
Zero need for PAT. NPT means you *don't* have to PAT. Deploying PAT would be EXTRA steps.
NPT means you're already 1:1 automatically, and you just open firewall ports for anything you need to inbound external access. No additional configuration or setup needed.
PAT immediately eliminates most of the SMB benefits. The only one you retain is the V4 allocation cost reduction .... maybe.
Any business internet will be giving you at least something like a /60 or /56, so as long as you subnet within that size space there's zero reason to put in additional effort for PAT and all the downsides it brings along with it.
-----Original Message----- From: sronan@ronan-online.com <sronan@ronan-online.com> Sent: Friday, June 19, 2026 1:48 PM To: nanog@lists.nanog.org Cc: Marco Moock <mm@dorfdsl.de>; Gary Sparkes <gary@kisaracorporation.com>; nanog@lists.nanog.org Subject: Re: IPv4 flag day
The SMB use case is absolutely PAT. They aren’t going to 1:1 NAT all of their internal hosts to both providers provided IPv6 space.
On Jun 19, 2026, at 1:16 PM, Gary Sparkes via NANOG <nanog@lists.nanog.org> wrote:
The cybercafe? Faster and more reliable online gaming. Better VOIP services for communication.
Gaming is something that *HUGELY* benefits from IPv6/NAT elimination.
The SMB? More reliable/consistent SIP experience for their phones. Cheaper network hardware for the same throughput. Reduced complexity. Reduced costs (address space) if they're exposing anything externally / need external inbound access. (All wins I've gained for my customers, and yes, they're all either dual stack or v6 with edge translation for some networks, but with reduced expenses overall and more reliable/performant networks)
Realistically, the only NAT that v6 should ever need is NPTv6 for the multihoming scenario (IEEE should just capitulate on that one, it just makes sense and it's not PAT that gives us all our problems in the first place), the rest just don't make sense and re-introduce complexity and issues that should be eliminated.
IPv6 enabled me to rip out a LOT of NAT workaround code from systems I support, which greatly simplified a lot of things. Re-introducing PAT into V6 land as a common practice would, once again, require re-adding all those insane hacks and workarounds and decreasing reliability.
We shouldn't need to solve those issues when we can eliminate them entirely.
-----Original Message----- From: Pedro Prado via NANOG <nanog@lists.nanog.org> Sent: Friday, June 19, 2026 1:01 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Marco Moock <mm@dorfdsl.de>; Pedro Prado <pedro.prado@gmail.com> Subject: Re: IPv4 flag day
… which sounds right (not implementing something you don’t need).
“Need” has a different interpretation for those inside a simple network and those interconnecting that network to everything else - a separation of values that Nat and even pat happens to handle pretty well IMHO, for the most part anyway, bar the well known issues.
What value the granularity of addresses inside a SMB brings to the outside if the connectivity works without that? What does global-capable 128-bit addressing help a cyber cafe?
I would hope that the research that goes into solving NAT/PAT issues would trickle into improvements to the end to end upper protocols which would eventually be unaware of how the network operates, similar to how L2 is transparent today (bar MTU mismatches…)
*Pedro Martins Prado* pedro.prado@gmail.com / +353 83 036 1875 (FaceTime & WhatsApp)
On Fri 19 Jun 2026 at 15:33, Marco Moock via NANOG <nanog@lists.nanog.org> wrote:
Am 19.06.26 um 08:35 schrieb Arie Vayner: To move IPv6 to the next level of SMB/enterprise adoption we need to make it easier to consume by the average SMB - which means stop saying "NAT is evil" or "NAT is not supported in IPv6", and unblock relevant IETF work.
There are devices for SMB that support stateful IPv6 NAT if they really need this. Although, my experience is that most of the network infrastructure in SMB environments is created one time and never touched unless necessary. They will also not implement IPv6 with NAT unless they really need it. Same applies to various other protocols.
-- Gruß Marco
Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ A Z FJS4DBXNUQQWO2ON2VGB7H2JKLBJTL/
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/J R CXLXRPKM2ELJPJFD4IBACOEOQ7LKMW/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/V O WZ3ODV43BY423LQ3RKNLHEIYLYBIBL/
In several large orgs I've worked with, IPv6 deployment plans included the elimination of NAT as a gain. NAT is not security. Security tools work better without NAT just from a clarity and configuration simplicity perspective. So does concise, solid network configuration that's easier to review. Then again, I've worked in large orgs that aren't using NAT for v4 at all, just direct globally routable IPv4. NAT was a *huge* discussion and pain point when they went to sell off that space. It caused a lot of engineering effort and hardware capacity upgrades to implement with minimal disruption. Was a sad day when my IP address on that laptop started with 10.x instead of one of the allocated Y.Y.x ranges... So having lived in NAT-less IPv4 land even as recently as this decade has also spoiled me to the pure simplicity of things and shown me a lot of what pain 1:many PAT causes. -----Original Message----- From: William Herrin via NANOG <nanog@lists.nanog.org> Sent: Friday, June 19, 2026 3:05 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: William Herrin <bill@herrin.us> Subject: Re: IPv4 flag day On Fri, Jun 19, 2026 at 10:47 AM sronan--- via NANOG <nanog@lists.nanog.org> wrote:
The SMB use case is absolutely PAT. They aren’t going to 1:1 NAT all of their internal hosts to both providers provided IPv6 space.
SMB generally buys a box and whatever that box does by default, that's their network configuration. They pick that box mainly by reputation. They don't have a network security guy. They don't have a network guy. They have a couple IT guys whose main areas of expertise are troubleshooting PC hardware and Windows Domain Controllers. Enterprise, on the other hand, is definitely going NAT. Renumbering is painful even with IPv6. And they're very leery of 1:1 NAT -- they've made security configuration mistakes before and trust 1:many NAT to offer a layer of protection while those mistakes are detected and fixed. They take arguments against NAT to mean that IPv6 is not yet ripe for deployment with the sort of robust security frameworks they enjoy in IPv4. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/NXMXULZ3...
On Fri, Jun 19, 2026 at 12:06 PM Gary Sparkes via NANOG < nanog@lists.nanog.org> wrote:
Internal clients are 1:1 NPT'd to provider addresses, and on failover, the internal addressing doesn't change, but all the traffic flips to the other provider's addresses.
And now we've got to have a mechanism to update external DNS for the SMB or Enterprise that hosts their own MX, a remote access server, and all those SSH port forwards the IT guys use to remotely access/manage stuff. I thought I was promised an IPv6 where there were so many dang addresses that every business could have their own *public* /48 with enough room left over to allocate a /48 to every molecule on the planet or whatever. I don't want to renumber everything because I ditch one ISP and switch to another. In IPv4 I don't have to thanks to RFC1918 space. In IPv6 I guess I have fc00::/7 that gets allocated "pseudo-randomly". So in IPv6 I either have to renumber because I ditched some ISP for another...or I have to pay for my addressing space and my ISPs have to support routing my address space, right? -A
Sure, I’ve dealt with NAT issues related to SIP. PAT fundamentally worsens the issue. So of course I’m not ignoring the issues NAT introduces… I’m highlighting avoiding N/PAT it’s not an advantage of “a single L3 protocol and addressing to rule them all”. It’s a shortcoming of the upper layers that should be more independent. Deploying a flat addressing space can be thought of as a workaround to that, stretching quite a bit of course :) Using encapsulation as an example, we don’t (shouldn’t) care about the outer protocol of the tunnel we’re riding - all we care is that our data is delivered in an acceptable way. If we expand that thinking, there should be enough information in the payload that no matter how it is transported, it will still allow end to end communication. We only care about addresses because we build sessions based on them, yet host addressing is dynamic… Applying Nat temporarily to the traffic that suddenly has to exit the “other” ISP is not a problem; having communication that relies on the addressing/ports never changing is. The endpoints should be able to simply switch to the new address/port, after detecting that the connection started to be natted. This way they can continue communicating and the NAT is avoided. *Pedro Martins Prado* pedro.prado@gmail.com / +353 83 036 1875 (FaceTime & WhatsApp) On Fri 19 Jun 2026 at 18:57, Gary Sparkes via NANOG <nanog@lists.nanog.org> wrote:
Zero need for PAT. NPT means you *don't* have to PAT. Deploying PAT would be EXTRA steps.
NPT means you're already 1:1 automatically, and you just open firewall ports for anything you need to inbound external access. No additional configuration or setup needed.
PAT immediately eliminates most of the SMB benefits. The only one you retain is the V4 allocation cost reduction .... maybe.
Any business internet will be giving you at least something like a /60 or /56, so as long as you subnet within that size space there's zero reason to put in additional effort for PAT and all the downsides it brings along with it.
-----Original Message----- From: sronan@ronan-online.com <sronan@ronan-online.com> Sent: Friday, June 19, 2026 1:48 PM To: nanog@lists.nanog.org Cc: Marco Moock <mm@dorfdsl.de>; Gary Sparkes <gary@kisaracorporation.com>; nanog@lists.nanog.org Subject: Re: IPv4 flag day
The SMB use case is absolutely PAT. They aren’t going to 1:1 NAT all of their internal hosts to both providers provided IPv6 space.
On Jun 19, 2026, at 1:16 PM, Gary Sparkes via NANOG < nanog@lists.nanog.org> wrote:
The cybercafe? Faster and more reliable online gaming. Better VOIP services for communication.
Gaming is something that *HUGELY* benefits from IPv6/NAT elimination.
The SMB? More reliable/consistent SIP experience for their phones. Cheaper network hardware for the same throughput. Reduced complexity. Reduced costs (address space) if they're exposing anything externally / need external inbound access. (All wins I've gained for my customers, and yes, they're all either dual stack or v6 with edge translation for some networks, but with reduced expenses overall and more reliable/performant networks)
Realistically, the only NAT that v6 should ever need is NPTv6 for the multihoming scenario (IEEE should just capitulate on that one, it just makes sense and it's not PAT that gives us all our problems in the first place), the rest just don't make sense and re-introduce complexity and issues that should be eliminated.
IPv6 enabled me to rip out a LOT of NAT workaround code from systems I support, which greatly simplified a lot of things. Re-introducing PAT into V6 land as a common practice would, once again, require re-adding all those insane hacks and workarounds and decreasing reliability.
We shouldn't need to solve those issues when we can eliminate them entirely.
-----Original Message----- From: Pedro Prado via NANOG <nanog@lists.nanog.org> Sent: Friday, June 19, 2026 1:01 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Marco Moock <mm@dorfdsl.de>; Pedro Prado <pedro.prado@gmail.com> Subject: Re: IPv4 flag day
… which sounds right (not implementing something you don’t need).
“Need” has a different interpretation for those inside a simple network and those interconnecting that network to everything else - a separation of values that Nat and even pat happens to handle pretty well IMHO, for the most part anyway, bar the well known issues.
What value the granularity of addresses inside a SMB brings to the outside if the connectivity works without that? What does global-capable 128-bit addressing help a cyber cafe?
I would hope that the research that goes into solving NAT/PAT issues would trickle into improvements to the end to end upper protocols which would eventually be unaware of how the network operates, similar to how L2 is transparent today (bar MTU mismatches…)
*Pedro Martins Prado* pedro.prado@gmail.com / +353 83 036 1875 (FaceTime & WhatsApp)
On Fri 19 Jun 2026 at 15:33, Marco Moock via NANOG <nanog@lists.nanog.org> wrote:
Am 19.06.26 um 08:35 schrieb Arie Vayner: To move IPv6 to the next level of SMB/enterprise adoption we need to make it easier to consume by the average SMB - which means stop saying "NAT is evil" or "NAT is not supported in IPv6", and unblock relevant IETF work.
There are devices for SMB that support stateful IPv6 NAT if they really need this. Although, my experience is that most of the network infrastructure in SMB environments is created one time and never touched unless necessary. They will also not implement IPv6 with NAT unless they really need it. Same applies to various other protocols.
-- Gruß Marco
Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/A Z FJS4DBXNUQQWO2ON2VGB7H2JKLBJTL/
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/JR CXLXRPKM2ELJPJFD4IBACOEOQ7LKMW/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/VO WZ3ODV43BY423LQ3RKNLHEIYLYBIBL/
NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/IQDSQDL5...
On Fri, Jun 19, 2026 at 10:16 AM Gary Sparkes via NANOG <nanog@lists.nanog.org> wrote:
Gaming is something that *HUGELY* benefits from IPv6/NAT elimination.
Peer to peer for gaming was yesterday's issue. Today, linking multiple players together is well solved and baked into the Steam library or whatever is specific to the game's platform. Meanwhile, anti-cheat measures require that the players be ignorant of each others' IP addresses so that they don't compete by lagging their competitors with a packet flood. Which used to happen a lot. There are still old titles out there being actively enjoyed where you have to poke a hole through the nat to play with each other, but as a broad concern NAT obstruction of online games is rapidly fading away. The game developers found themselves facing problems that couldn't be solved with peer to peer even if the network made it easy. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/
Well, you have the same problem with v4 or v6. In this scenario we’re talking about, you have two separate IPv4 ranges (one per provider) anyway. So the mechanisms are all still entirely the same. But as I was noting, there’s ULA addressing, so you’re not renumbering at all when you move ISPs internally, NPT handles that on the front end for you. In enterprise, well, you don’t have this concern, you’ll be using BGP on your links. Or tunneling to datacenters/central appliances, or what have you. From: Aaron C. de Bruyn <aaron@heyaaron.com> Sent: Friday, June 19, 2026 3:22 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: sronan@ronan-online.com; Marco Moock <mm@dorfdsl.de>; Gary Sparkes <gary@kisaracorporation.com> Subject: Re: IPv4 flag day On Fri, Jun 19, 2026 at 12:06 PM Gary Sparkes via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: Internal clients are 1:1 NPT'd to provider addresses, and on failover, the internal addressing doesn't change, but all the traffic flips to the other provider's addresses. And now we've got to have a mechanism to update external DNS for the SMB or Enterprise that hosts their own MX, a remote access server, and all those SSH port forwards the IT guys use to remotely access/manage stuff. I thought I was promised an IPv6 where there were so many dang addresses that every business could have their own *public* /48 with enough room left over to allocate a /48 to every molecule on the planet or whatever. I don't want to renumber everything because I ditch one ISP and switch to another. In IPv4 I don't have to thanks to RFC1918 space. In IPv6 I guess I have fc00::/7 that gets allocated "pseudo-randomly". So in IPv6 I either have to renumber because I ditched some ISP for another...or I have to pay for my addressing space and my ISPs have to support routing my address space, right? -A
I'd say it's not, as it's still a prevalent enough issue that IPv6 does increase reliability. And there's still a lot of NAT detection and workarounds. Of course, centralized servers help a lot with avoiding the issue entirely, but not always. Modern Call of Duty has gotten better, for example, but still stumbles on NAT issues from time to time. It's definitely not a solved problem if Sony's telling PS5 users to port forward, turn on UPnP, etc or DMZ (in the end user CPE usage of the term) their consoles to make online gaming work better. Some CPE is better than others, or has better out of box defaults, but even I've had to port forward for black ops (and just that COD game) to work before for matchmaking. (joining directly worked, just not lobby style matchmaking) This is Sony's current troubleshooting advice for multiplayer game issues: (And if you're having issues with voice chat, they dive straight into NAT troubleshooting and eventually tells you to forward additionally 49152-65535, and other games need even more) ---------- Try opening the following ports on your router: TCP: 80, 443, 3478, 3479, 3480 UDP: 3478, 3479 Please note, if you’re not sure what this means or don’t know how to open ports on your router, we recommend speaking to your ISP or router manufacturer before changing any settings. Change your IP address from dynamic to static. Most ISPs assign dynamic IP addresses to their customers. This means the IP address can change periodically. Asking your ISP to change your IP address from dynamic to static (one that always stays the same) can help achieve a more consistent, reliable connection with PlayStation services. ---------- -----Original Message----- From: William Herrin <bill@herrin.us> Sent: Friday, June 19, 2026 3:25 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Gary Sparkes <gary@kisaracorporation.com> Subject: Re: IPv4 flag day On Fri, Jun 19, 2026 at 10:16 AM Gary Sparkes via NANOG <nanog@lists.nanog.org> wrote:
Gaming is something that *HUGELY* benefits from IPv6/NAT elimination.
Peer to peer for gaming was yesterday's issue. Today, linking multiple players together is well solved and baked into the Steam library or whatever is specific to the game's platform. Meanwhile, anti-cheat measures require that the players be ignorant of each others' IP addresses so that they don't compete by lagging their competitors with a packet flood. Which used to happen a lot. There are still old titles out there being actively enjoyed where you have to poke a hole through the nat to play with each other, but as a broad concern NAT obstruction of online games is rapidly fading away. The game developers found themselves facing problems that couldn't be solved with peer to peer even if the network made it easy. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/
Am 19.06.26 um 21:21 schrieb Aaron C. de Bruyn:
I don't want to renumber everything because I ditch one ISP and switch to another.
Get your own prefix from RIR and let your ISP route it to your. If you switch the ISP, let the new ISP route it to you. It is even possible to have 2 ISPs that route the same prefix to you - without having you own ASN. -- Gruß Marco Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
That's really the answer, for both v4 and v6, if you want to not have to renumber on provider changes every time. The answer's the same regardless of IPv4 vs IPv6, because the problems are the same. At least for this
So in IPv6 I either have to renumber because I ditched some ISP for another...or I have to pay for my addressing space and my ISPs have to support routing my address space, right?
Yes, exactly like you had to for IPv4. -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org> Sent: Friday, June 19, 2026 3:47 PM To: nanog@lists.nanog.org Cc: Marco Moock <mm@dorfdsl.de> Subject: Re: IPv4 flag day Am 19.06.26 um 21:21 schrieb Aaron C. de Bruyn:
I don't want to renumber everything because I ditch one ISP and switch to another.
Get your own prefix from RIR and let your ISP route it to your. If you switch the ISP, let the new ISP route it to you. It is even possible to have 2 ISPs that route the same prefix to you - without having you own ASN. -- Gruß Marco Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/FG76NSBV...
Am 19.06.26 um 21:04 schrieb William Herrin via NANOG:
Enterprise, on the other hand, is definitely going NAT. Renumbering is painful even with IPv6. And they're very leery of 1:1 NAT -- they've made security configuration mistakes before and trust 1:many NAT to offer a layer of protection while those mistakes are detected and fixed. They take arguments against NAT to mean that IPv6 is not yet ripe for deployment with the sort of robust security frameworks they enjoy in IPv4.
Then they should go to training regarding IPv6 SPI firewalls. Every residential customer CPE has it, so they can use it too. The devices that support IPv4 NAT will most likely also support SPI-FW for IPv6. At least Cisco does. -- Gruß Marco Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
Now you are introducing new cost and overhead on the SMBs.
On Jun 19, 2026, at 3:47 PM, Marco Moock via NANOG <nanog@lists.nanog.org> wrote:
Am 19.06.26 um 21:21 schrieb Aaron C. de Bruyn:
I don't want to renumber everything because I ditch one ISP and switch to another.
Get your own prefix from RIR and let your ISP route it to your. If you switch the ISP, let the new ISP route it to you. It is even possible to have 2 ISPs that route the same prefix to you - without having you own ASN.
-- Gruß Marco
Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/FG76NSBV...
On Fri, Jun 19, 2026 at 12:47 PM Marco Moock via NANOG < nanog@lists.nanog.org> wrote:
Am 19.06.26 um 21:21 schrieb Aaron C. de Bruyn:
I don't want to renumber everything because I ditch one ISP and switch to another.
Get your own prefix from RIR and let your ISP route it to your. If you switch the ISP, let the new ISP route it to you. It is even possible to have 2 ISPs that route the same prefix to you - without having you own ASN.
A SMB doesn't have to do that in IPv4 using RFC1918 and NAT. Pretty sure there's a cost to get a /48 from an RIR and probably costs with the various ISPs to route to you. While I'll admit I'm not an IPv6 expert by any means, it doesn't seem like there's a clean path from: "I have a stable internal network addressing scheme under IPv4 that's independent of whatever random ISP I'm using and it sucks I have to use NAT, but it's easy" to "There are enough addresses for everyone to have their own internet, so I'll come up with my own /48 (or get one for free like I had in IPv4) and simply 'connect' to my ISP and it works...no NAT and no port forwarding required...just nice simple firewall rules". -A
Cost and overhead they already have for IPv4. And if they already have IPv4 from their RIR, the IPv6 is free. And if they don't, then the IPv6 scenario works just like IPv4. Two providers, two address sets. -----Original Message----- From: sronan--- via NANOG <nanog@lists.nanog.org> Sent: Friday, June 19, 2026 3:55 PM To: nanog@lists.nanog.org Cc: Marco Moock <mm@dorfdsl.de>; nanog@lists.nanog.org; sronan@ronan-online.com Subject: Re: IPv4 flag day Now you are introducing new cost and overhead on the SMBs.
On Jun 19, 2026, at 3:47 PM, Marco Moock via NANOG <nanog@lists.nanog.org> wrote:
Am 19.06.26 um 21:21 schrieb Aaron C. de Bruyn:
I don't want to renumber everything because I ditch one ISP and switch to another.
Get your own prefix from RIR and let your ISP route it to your. If you switch the ISP, let the new ISP route it to you. It is even possible to have 2 ISPs that route the same prefix to you - without having you own ASN.
-- Gruß Marco
Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/FG 76NSBVWPX2FE762B72BQHZXK55JM7N/
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/SYMK7LFZ...
The clean path would be NPTv6 with ULA for the same exact setup. It would slot in and work identically to how the IPv4 deployment is today. Instead of RFC1918, you have ULA addressing. Same concept. Except with NPTv6 you're doing 1:1 and eliminate PAT. Of course, if you're single provider, might as well just use prefix delegation, NPT's real shine is the multi-WAN scenario with no upstream routing protocol that sparked off a lot of discussion. As to changing providers when using prefix delegation, most stuff can auto-update itself, but otherwise it's a simple find/replace exercise in documentation and records when your provider prefix changes as the last half of the address is entirely stable, and the first half is (mostly) provider. -----Original Message----- From: Aaron C. de Bruyn via NANOG <nanog@lists.nanog.org> Sent: Friday, June 19, 2026 3:55 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Marco Moock <mm@dorfdsl.de>; Aaron C. de Bruyn <aaron@heyaaron.com> Subject: Re: IPv4 flag day On Fri, Jun 19, 2026 at 12:47 PM Marco Moock via NANOG < nanog@lists.nanog.org> wrote:
Am 19.06.26 um 21:21 schrieb Aaron C. de Bruyn:
I don't want to renumber everything because I ditch one ISP and switch to another.
Get your own prefix from RIR and let your ISP route it to your. If you switch the ISP, let the new ISP route it to you. It is even possible to have 2 ISPs that route the same prefix to you - without having you own ASN.
A SMB doesn't have to do that in IPv4 using RFC1918 and NAT. Pretty sure there's a cost to get a /48 from an RIR and probably costs with the various ISPs to route to you. While I'll admit I'm not an IPv6 expert by any means, it doesn't seem like there's a clean path from: "I have a stable internal network addressing scheme under IPv4 that's independent of whatever random ISP I'm using and it sucks I have to use NAT, but it's easy" to "There are enough addresses for everyone to have their own internet, so I'll come up with my own /48 (or get one for free like I had in IPv4) and simply 'connect' to my ISP and it works...no NAT and no port forwarding required...just nice simple firewall rules". -A _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/N42CGCJL...
On Fri, Jun 19, 2026 at 12:50 PM Gary Sparkes via NANOG < nanog@lists.nanog.org> wrote:
So in IPv6 I either have to renumber because I ditched some ISP for another...or I have to pay for my addressing space and my ISPs have to support routing my address space, right?
Yes, exactly like you had to for IPv4.
No, I didn't. In IPv4 I can use RFC 1918 internally in a structured way and NOT have to renumber if I switch ISPs. I unfortunately have to use NAT, and my single public IP will change, and I probably have to update a few DNS records . But the big huge promise of IPv6 was "everyone and their dog can have a block of addresses bigger than the current internet" and "there's no more NAT or private addresses". NAT 1:1 doesn't help here. Instead of having a single public IPv4 with port forwards for MX (25, 465, 993, 110, etc...) and maybe a few for SSHing to various boxes (22, 221, 222, 223, etc...) I now have a block bigger than the internet on my WAN that has to be 1:1 mapped into my MX (which used to be .250) and the various SSH hosts (.1, .2, .3, etc...)...and I need to update external DNS for MX to point to isp:bloc:k::1 for mail and isp:bloc:k::7 for one SSH host, etc... Seems like it would be *way* simpler to say "here's youre free PI /48 your business can use, go number your internal network how you want and to connect to the internet, you need to give your ISP(s) your /48 so they can route it". ...at least on the business side of adopting IPv6. On the "back end" everyone's routing tables would probably explode. -A
As to the last part, that would be way simpler. Take that up with the RIRs though…… But I view each service having its own external address as a benefit, especially from a security/monitoring perspective. That’s just really a non-issue either way though. Then again, I also statically address a fair amount of systems, so they’re easy to remember, with ::3 and ::4 addresses for externally facing stuff, and encode things like network segment or site in the prefix side if I can. From: Aaron C. de Bruyn <aaron@heyaaron.com> Sent: Friday, June 19, 2026 4:05 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Marco Moock <mm@dorfdsl.de>; Gary Sparkes <gary@kisaracorporation.com> Subject: Re: IPv4 flag day On Fri, Jun 19, 2026 at 12:50 PM Gary Sparkes via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote:
So in IPv6 I either have to renumber because I ditched some ISP for another...or I have to pay for my addressing space and my ISPs have to support routing my address space, right?
Yes, exactly like you had to for IPv4. No, I didn't. In IPv4 I can use RFC 1918 internally in a structured way and NOT have to renumber if I switch ISPs. I unfortunately have to use NAT, and my single public IP will change, and I probably have to update a few DNS records . But the big huge promise of IPv6 was "everyone and their dog can have a block of addresses bigger than the current internet" and "there's no more NAT or private addresses". NAT 1:1 doesn't help here. Instead of having a single public IPv4 with port forwards for MX (25, 465, 993, 110, etc...) and maybe a few for SSHing to various boxes (22, 221, 222, 223, etc...) I now have a block bigger than the internet on my WAN that has to be 1:1 mapped into my MX (which used to be .250) and the various SSH hosts (.1, .2, .3, etc...)...and I need to update external DNS for MX to point to isp:bloc:k::1 for mail and isp:bloc:k::7 for one SSH host, etc... Seems like it would be *way* simpler to say "here's youre free PI /48 your business can use, go number your internal network how you want and to connect to the internet, you need to give your ISP(s) your /48 so they can route it". ...at least on the business side of adopting IPv6. On the "back end" everyone's routing tables would probably explode. -A
On Fri, Jun 19, 2026 at 1:03 PM Gary Sparkes <gary@kisaracorporation.com> wrote:
The clean path would be NPTv6 with ULA for the same exact setup.
It would slot in and work identically to how the IPv4 deployment is today.
Instead of RFC1918, you have ULA addressing. Same concept.
Except with NPTv6 you're doing 1:1 and eliminate PAT.
Of course, if you're single provider, might as well just use prefix delegation, NPT's real shine is the multi-WAN scenario with no upstream routing protocol that sparked off a lot of discussion.
As to changing providers when using prefix delegation, most stuff can auto-update itself, but otherwise it's a simple find/replace exercise in documentation and records when your provider prefix changes as the last half of the address is entirely stable, and the first half is (mostly) provider.
Maybe I need to do a bit more digging as I'm not an expert at IPv6--but aren't ULA addresses basically randomly assigned to hosts based on their NIC HW address and a few other things? A short example from a very large client I manage: They use IPv4 10/8 The next octet is allocated for the state the office is located in "plus 100". So if they open an office in Alabama (22nd state to join the union), it's gonna be 10.122/16. The third octet is assigned sequentially. The first office opened in Alabama is 10.122.0.0/24. The last octet is static. Router at .254, linux server at .250, Windows (ugh) RDP server at .249, workstations are DHCP between .100 and .199, etc... You can give me nearly any IP from this client and I know the device. But ULA gives me: fe80::ae1f:6bff:feb0:3c98/64 What even is that? Their router? A Windows box? Hard-code the address to fe80::122:00000:250/64 (just to know it's a linux server in Alabama) and then set up NPTv6...and update a *ton* of DNS info so the rest of the world can easily get to the correct machines? Again, I'm having to renumber somewhere--either update a bunch of DNS or update a bunch of internal machines when I change ISPs or have a fail-over. At least that's what it always seemed like to me after going through all the 800-page IPv6 tomes over the years. ;) -A
ULA is the equivalent of RFC1918, effectively. FC00::/7 You’re thinking of link-local addresses which are the fe80 addresses. Those are autogenerated. ULA is assigned however you want – SLAAC, DHCPv6, static, etc…. RFC1918 equivalent. Nominally, you’d almost never think about link-local. You essentially have all of fc00::/7 to utilize as you wish. So, for you, I suppose, you could do FC00:0:22:XXXX::/64 22nd state, XXXX being vlan ID or some other identifier or whatever you want (servers could be FC00:0:22:1::/64 and workstations FC00:0:22:2::/64 and so on – feel free to be creative! You have FC00::/32 through FC00:3E8::/32 to play around in! With /48’s I like to do PRE:FIX:HERE:VLANID::/64) Including the office number, so you could do FC00:22:0:1 (the 0 between the 22 and 1 is the office number, second the network/vlan identifier, whatever – you can be creative and as long or compact as you want here). So let’s say you have FC00:22:0:1::1 – okay, that’s a router! FC00:22:0:2:SLAA:CASS:IGNE:DAUTOCONF – sweet that’s a workstation (SLAAC for simplicity sake, DHCPv6 can also be an option, but a bit more to configure/maintain). FC00:22:0:1::250 – that’s the linux server! Okay, so now your linux server is FC00:22:0:1::250, still simple enough. And any firewall logs with that info will immediately tell you right where it is and what network it’s on, etc. Then with NPT, you’re mapping provider prefix aaand you’re right where you were with V4, including needing to update DNS in failover. Now you just change the provider prefix portion instead of the whole IP address. The ::250 will stay the same on either provider externally. NPT will just convert say, 1234:5678:1234:5678::/64 to FC00:22:0:1::/64 at the edge, and vice versa. So your linux server would be 1234:5678:1234:5678::250 You never want to hardcode link-local addressing, that’s all entirely autonomous and is used for a variety of things, but that’s out of scope here. From: Aaron C. de Bruyn <aaron@heyaaron.com> Sent: Friday, June 19, 2026 4:24 PM To: Gary Sparkes <gary@kisaracorporation.com> Cc: North American Network Operators Group <nanog@lists.nanog.org>; Marco Moock <mm@dorfdsl.de> Subject: Re: IPv4 flag day On Fri, Jun 19, 2026 at 1:03 PM Gary Sparkes <gary@kisaracorporation.com<mailto:gary@kisaracorporation.com>> wrote: The clean path would be NPTv6 with ULA for the same exact setup. It would slot in and work identically to how the IPv4 deployment is today. Instead of RFC1918, you have ULA addressing. Same concept. Except with NPTv6 you're doing 1:1 and eliminate PAT. Of course, if you're single provider, might as well just use prefix delegation, NPT's real shine is the multi-WAN scenario with no upstream routing protocol that sparked off a lot of discussion. As to changing providers when using prefix delegation, most stuff can auto-update itself, but otherwise it's a simple find/replace exercise in documentation and records when your provider prefix changes as the last half of the address is entirely stable, and the first half is (mostly) provider. Maybe I need to do a bit more digging as I'm not an expert at IPv6--but aren't ULA addresses basically randomly assigned to hosts based on their NIC HW address and a few other things? A short example from a very large client I manage: They use IPv4 10/8 The next octet is allocated for the state the office is located in "plus 100". So if they open an office in Alabama (22nd state to join the union), it's gonna be 10.122/16. The third octet is assigned sequentially. The first office opened in Alabama is 10.122.0.0/24<http://10.122.0.0/24>. The last octet is static. Router at .254, linux server at .250, Windows (ugh) RDP server at .249, workstations are DHCP between .100 and .199, etc... You can give me nearly any IP from this client and I know the device. But ULA gives me: fe80::ae1f:6bff:feb0:3c98/64 What even is that? Their router? A Windows box? Hard-code the address to fe80::122:00000:250/64 (just to know it's a linux server in Alabama) and then set up NPTv6...and update a *ton* of DNS info so the rest of the world can easily get to the correct machines? Again, I'm having to renumber somewhere--either update a bunch of DNS or update a bunch of internal machines when I change ISPs or have a fail-over. At least that's what it always seemed like to me after going through all the 800-page IPv6 tomes over the years. ;) -A
Oops--I did confuse them. Apologies. Time to buy another batch of 800-page IPv6 tomes to put on a shelf and eventually read. I guess I'm the reason we haven't switched to IPv6 yet. ;) -A On Fri, Jun 19, 2026 at 1:48 PM Gary Sparkes <gary@kisaracorporation.com> wrote:
ULA is the equivalent of RFC1918, effectively. FC00::/7
You’re thinking of link-local addresses which are the fe80 addresses. Those are autogenerated. ULA is assigned however you want – SLAAC, DHCPv6, static, etc…. RFC1918 equivalent.
Nominally, you’d almost never think about link-local.
You essentially have all of fc00::/7 to utilize as you wish.
So, for you, I suppose, you could do FC00:0:22:XXXX::/64
22nd state, XXXX being vlan ID or some other identifier or whatever you want (servers could be FC00:0:22:1::/64 and workstations FC00:0:22:2::/64 and so on – feel free to be creative! You have FC00::/32 through FC00:3E8::/32 to play around in! With /48’s I like to do PRE:FIX:HERE:VLANID::/64)
Including the office number, so you could do FC00:22:0:1 (the 0 between the 22 and 1 is the office number, second the network/vlan identifier, whatever – you can be creative and as long or compact as you want here).
So let’s say you have FC00:22:0:1::1 – okay, that’s a router! FC00:22:0:2:SLAA:CASS:IGNE:DAUTOCONF – sweet that’s a workstation (SLAAC for simplicity sake, DHCPv6 can also be an option, but a bit more to configure/maintain). FC00:22:0:1::250 – that’s the linux server!
Okay, so now your linux server is FC00:22:0:1::250, still simple enough. And any firewall logs with that info will immediately tell you right where it is and what network it’s on, etc.
Then with NPT, you’re mapping provider prefix aaand you’re right where you were with V4, including needing to update DNS in failover.
Now you just change the provider prefix portion instead of the whole IP address. The ::250 will stay the same on either provider externally. NPT will just convert say, 1234:5678:1234:5678::/64 to FC00:22:0:1::/64 at the edge, and vice versa. So your linux server would be 1234:5678:1234:5678::250
You never want to hardcode link-local addressing, that’s all entirely autonomous and is used for a variety of things, but that’s out of scope here.
*From:* Aaron C. de Bruyn <aaron@heyaaron.com> *Sent:* Friday, June 19, 2026 4:24 PM *To:* Gary Sparkes <gary@kisaracorporation.com> *Cc:* North American Network Operators Group <nanog@lists.nanog.org>; Marco Moock <mm@dorfdsl.de> *Subject:* Re: IPv4 flag day
On Fri, Jun 19, 2026 at 1:03 PM Gary Sparkes <gary@kisaracorporation.com> wrote:
The clean path would be NPTv6 with ULA for the same exact setup.
It would slot in and work identically to how the IPv4 deployment is today.
Instead of RFC1918, you have ULA addressing. Same concept.
Except with NPTv6 you're doing 1:1 and eliminate PAT.
Of course, if you're single provider, might as well just use prefix delegation, NPT's real shine is the multi-WAN scenario with no upstream routing protocol that sparked off a lot of discussion.
As to changing providers when using prefix delegation, most stuff can auto-update itself, but otherwise it's a simple find/replace exercise in documentation and records when your provider prefix changes as the last half of the address is entirely stable, and the first half is (mostly) provider.
Maybe I need to do a bit more digging as I'm not an expert at IPv6--but aren't ULA addresses basically randomly assigned to hosts based on their NIC HW address and a few other things?
A short example from a very large client I manage:
They use IPv4 10/8
The next octet is allocated for the state the office is located in "plus 100". So if they open an office in Alabama (22nd state to join the union), it's gonna be 10.122/16.
The third octet is assigned sequentially. The first office opened in Alabama is 10.122.0.0/24.
The last octet is static. Router at .254, linux server at .250, Windows (ugh) RDP server at .249, workstations are DHCP between .100 and .199, etc...
You can give me nearly any IP from this client and I know the device.
But ULA gives me: fe80::ae1f:6bff:feb0:3c98/64
What even is that? Their router? A Windows box?
Hard-code the address to fe80::122:00000:250/64 (just to know it's a linux server in Alabama) and then set up NPTv6...and update a *ton* of DNS info so the rest of the world can easily get to the correct machines?
Again, I'm having to renumber somewhere--either update a bunch of DNS or update a bunch of internal machines when I change ISPs or have a fail-over.
At least that's what it always seemed like to me after going through all the 800-page IPv6 tomes over the years. ;)
-A
Am 19.06.26 um 22:04 schrieb Aaron C. de Bruyn:
...at least on the business side of adopting IPv6. On the "back end" everyone's routing tables would probably explode.
I have doubt that so many businesses will use such a solution, so this will most likely scale well. -- Gruß Marco Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
Am 19.06.26 um 22:23 schrieb Aaron C. de Bruyn:
On Fri, Jun 19, 2026 at 1:03 PM Gary Sparkes <gary@kisaracorporation.com> wrote:
The clean path would be NPTv6 with ULA for the same exact setup.
It would slot in and work identically to how the IPv4 deployment is today.
Instead of RFC1918, you have ULA addressing. Same concept.
Except with NPTv6 you're doing 1:1 and eliminate PAT.
Of course, if you're single provider, might as well just use prefix delegation, NPT's real shine is the multi-WAN scenario with no upstream routing protocol that sparked off a lot of discussion.
As to changing providers when using prefix delegation, most stuff can auto-update itself, but otherwise it's a simple find/replace exercise in documentation and records when your provider prefix changes as the last half of the address is entirely stable, and the first half is (mostly) provider.
Maybe I need to do a bit more digging as I'm not an expert at IPv6--but aren't ULA addresses basically randomly assigned to hosts based on their NIC HW address and a few other things?
You should really, really improve your IPv6 knowledge.
A short example from a very large client I manage: They use IPv4 10/8 The next octet is allocated for the state the office is located in "plus 100". So if they open an office in Alabama (22nd state to join the union), it's gonna be 10.122/16. The third octet is assigned sequentially. The first office opened in Alabama is 10.122.0.0/24. The last octet is static. Router at .254, linux server at .250, Windows (ugh) RDP server at .249, workstations are DHCP between .100 and .199, etc...
That is almost impossible for large networks - as the address space if often too low. BTDT.
You can give me nearly any IP from this client and I know the device. But ULA gives me: fe80::ae1f:6bff:feb0:3c98/64
You seem to have no clue that ULA and link-local are different. fd00::/8 is ULA. You can use fd00:random::/48 and then set every bit in the last 80 bit.
Hard-code the address to fe80::122:00000:250/64 (just to know it's a linux server in Alabama) and then set up NPTv6...and update a *ton* of DNS info so the rest of the world can easily get to the correct machines?
No, you only use fe80 for link-local communication (mostly NDP, some discovery protocols), nothing else. -- Gruß Marco Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
Am 19.06.26 um 22:54 schrieb Aaron C. de Bruyn:
Oops--I did confuse them. Apologies.
Time to buy another batch of 800-page IPv6 tomes to put on a shelf and eventually read. I guess I'm the reason we haven't switched to IPv6 yet. ;)
That's basic knowledge and shows that you don't seem to have any experience with IPv6. Rather bad, especially if you want to show other people the disadvantages. -- Gruß Marco Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
That's Link Local FE80::/10, ULA, Unique Local Addresses, are FC00::/7 where you would pick a /48 out of that address space for each site. With ULA you can do some magic in order to pick one that should never be picked by anyone else, that way when the 2 companies merge they don't have overlapping address space unless they picked using the exact same magic. The biggest problem with ULA is that IPv4 is preferred over ULA, so your dual-stack clients will continue to utilize IPv4 on the Internet to dual-stacked services. Please see RFC 6724. There is work to correct this, and I hear it should be corrected in the IETF shortly then we just need the OS developers to implement. David -- https://dprall.net On 6/19/2026 4:23 PM, Aaron C. de Bruyn via NANOG wrote:
On Fri, Jun 19, 2026 at 1:03 PM Gary Sparkes <gary@kisaracorporation.com> wrote:
The clean path would be NPTv6 with ULA for the same exact setup.
It would slot in and work identically to how the IPv4 deployment is today.
Instead of RFC1918, you have ULA addressing. Same concept.
Except with NPTv6 you're doing 1:1 and eliminate PAT.
Of course, if you're single provider, might as well just use prefix delegation, NPT's real shine is the multi-WAN scenario with no upstream routing protocol that sparked off a lot of discussion.
As to changing providers when using prefix delegation, most stuff can auto-update itself, but otherwise it's a simple find/replace exercise in documentation and records when your provider prefix changes as the last half of the address is entirely stable, and the first half is (mostly) provider.
Maybe I need to do a bit more digging as I'm not an expert at IPv6--but aren't ULA addresses basically randomly assigned to hosts based on their NIC HW address and a few other things?
A short example from a very large client I manage: They use IPv4 10/8 The next octet is allocated for the state the office is located in "plus 100". So if they open an office in Alabama (22nd state to join the union), it's gonna be 10.122/16. The third octet is assigned sequentially. The first office opened in Alabama is 10.122.0.0/24. The last octet is static. Router at .254, linux server at .250, Windows (ugh) RDP server at .249, workstations are DHCP between .100 and .199, etc...
You can give me nearly any IP from this client and I know the device. But ULA gives me: fe80::ae1f:6bff:feb0:3c98/64
What even is that? Their router? A Windows box?
Hard-code the address to fe80::122:00000:250/64 (just to know it's a linux server in Alabama) and then set up NPTv6...and update a *ton* of DNS info so the rest of the world can easily get to the correct machines?
Again, I'm having to renumber somewhere--either update a bunch of DNS or update a bunch of internal machines when I change ISPs or have a fail-over.
At least that's what it always seemed like to me after going through all the 800-page IPv6 tomes over the years. ;)
-A _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/MUBPKTFX...
On Jun 19, 2026, at 12:19 PM, Saku Ytti <saku@ytti.fi> wrote:
On Fri, 19 Jun 2026 at 11:32, David Conrad <drc@virtualized.org> wrote:
"Big tech shops” buying up all the addresses would drive the asset value up, increasing the likelihood the beancounters will see incentives to migrate. It is an irrelevant cost to them. There is more value to them that competitors cannot have them. Hence antitrust.
I was speaking of SMBs. They might (historically were, in my experience) be interested in the asset sale, particularly as they moved to the cloud/SAAS and defensively reduced their public Internet exposure.
Free market won't fix the problem we created.
I have some skepticism that a “turn off IPv4 day” mandate from (some) network operators will change things significantly, but I’m frequently wrong. Regards, -drc
Am 20.06.26 um 08:14 schrieb David Conrad via NANOG:
I have some skepticism that a “turn off IPv4 day” mandate from (some) network operators will change things significantly, but I’m frequently wrong.
It will impact them if large companies like Google or MS decide that IPv6 is mandatory. Such cases pushed SPF/DKIM, TLS, HTTPS etc. -- Gruß Marco Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
On Fri, Jun 19, 2026, 16:48 Gary Sparkes via NANOG <nanog@lists.nanog.org> wrote:
ULA is the equivalent of RFC1918, effectively. FC00::/7
You’re thinking of link-local addresses which are the fe80 addresses. Those are autogenerated. ULA is assigned however you want – SLAAC, DHCPv6, static, etc…. RFC1918 equivalent.
Nominally, you’d almost never think about link-local.
You essentially have all of fc00::/7 to utilize as you wish. (SNIP)
I didn't see it mentioned yet but I'm skimming- but this should be fd00::/8. The first /8 in fc00::/7 is reserved (ref. RFC 4193 § 3.1, 3.2, "L" bit).
It appears that Marco Moock via NANOG <nanog@lists.nanog.org> said:
Am 20.06.26 um 08:14 schrieb David Conrad via NANOG:
I have some skepticism that a “turn off IPv4 day” mandate from (some) network operators will change things significantly, but I’m frequently wrong.
It will impact them if large companies like Google or MS decide that IPv6 is mandatory. Such cases pushed SPF/DKIM, TLS, HTTPS etc.
Those all had significant security benefits. IPv6, not so much. R's, John PS: Yes, I know about IPsec.
Am 20.06.26 um 21:36 schrieb John Levine via NANOG:
It appears that Marco Moock via NANOG <nanog@lists.nanog.org> said:
Am 20.06.26 um 08:14 schrieb David Conrad via NANOG:
I have some skepticism that a “turn off IPv4 day” mandate from (some) network operators will change things significantly, but I’m frequently wrong.
It will impact them if large companies like Google or MS decide that IPv6 is mandatory. Such cases pushed SPF/DKIM, TLS, HTTPS etc.
Those all had significant security benefits. IPv6, not so much.
And even that was no reason for SMB to implement them unless "forced" by Google and MS. -- Gruß Marco Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
On Sat, 20 Jun 2026 at 22:37, John Levine via NANOG <nanog@lists.nanog.org> wrote:
Those all had significant security benefits. IPv6, not so much.
I think it's easy to argue IPv4+IPv6 expose more surface area for attackers. But I don't actually think infosec matters at all, not the way we approach it, so I wouldn't use it, unless in bad faith when that's the best way to market it. There are superior arguments to restore a single stack. I believe we can objectively state that the market always expected us to solve this, the market always expected IP addresses not to have economic value. If the market had anticipated that IP addresses are worth hundreds of billions of dollars, we would have run out of them during the IT bubble. But remarkably little, irrelevant, amount of hoarding happened even at the very end, at the very end some started a bunch of fake companies to get a single block per company, but it wasn't meaningful amount by any means. We have underperformed market expectations and created a market where none was designed to be. If we want to retcon that as a desirable outcome, we have a lot of work to do, I can come up with many improvements in our protocols to facilitate market creation for various protocol level resources where no such limits exist today. -- ++ytti
NAT is just the Internet version of a business phone PBX. It's the same situation of cost of phone lines / IPv4 addresses and the number of local users. Also add in the (perceived) ease of managing users behind a NAT/PBX. Businesses are slowly getting away from a phone on every desk due to company issued cell phones and remote workers. I'm not sure how that will play out with remote workers and VPN, which seem to be doing fine with RFC1918 space. On Sat, Jun 20, 2026 at 11:21 PM Saku Ytti via NANOG <nanog@lists.nanog.org> wrote:
On Sat, 20 Jun 2026 at 22:37, John Levine via NANOG <nanog@lists.nanog.org> wrote:
Those all had significant security benefits. IPv6, not so much.
I think it's easy to argue IPv4+IPv6 expose more surface area for attackers. But I don't actually think infosec matters at all, not the way we approach it, so I wouldn't use it, unless in bad faith when that's the best way to market it. There are superior arguments to restore a single stack.
I believe we can objectively state that the market always expected us to solve this, the market always expected IP addresses not to have economic value. If the market had anticipated that IP addresses are worth hundreds of billions of dollars, we would have run out of them during the IT bubble. But remarkably little, irrelevant, amount of hoarding happened even at the very end, at the very end some started a bunch of fake companies to get a single block per company, but it wasn't meaningful amount by any means.
We have underperformed market expectations and created a market where none was designed to be. If we want to retcon that as a desirable outcome, we have a lot of work to do, I can come up with many improvements in our protocols to facilitate market creation for various protocol level resources where no such limits exist today.
-- ++ytti _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/DSGFQREU...
-- Joe Hamelin, W7COM, Portland, OR, +1 360 474 7474
Am 21.06.26 um 11:21 schrieb Joe Hamelin via NANOG:
Businesses are slowly getting away from a phone on every desk due to company issued cell phones and remote workers. I'm not sure how that will play out with remote workers and VPN, which seem to be doing fine with RFC1918 space.
More and more use web-based services that use WebRTC. Works fine with NAT and SPI firewalls. Teams uses that. -- Gruß Marco Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
Works fine with NAT *with the caveat that there are a lot of workarounds and netcode issues* Without NAT it's a hell of a lot more reliable. There's a reason I ripped out all my NAT supporting code and don't support NAT scenarios outside of 1:1 NAT. -----Original Message----- From: Marco Moock via NANOG <nanog@lists.nanog.org> Sent: Sunday, June 21, 2026 9:13 AM To: nanog@lists.nanog.org Cc: Marco Moock <mm@dorfdsl.de> Subject: Re: IPv4 flag day Am 21.06.26 um 11:21 schrieb Joe Hamelin via NANOG:
Businesses are slowly getting away from a phone on every desk due to company issued cell phones and remote workers. I'm not sure how that will play out with remote workers and VPN, which seem to be doing fine with RFC1918 space.
More and more use web-based services that use WebRTC. Works fine with NAT and SPI firewalls. Teams uses that. -- Gruß Marco Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/3UBD3FUV...
participants (15)
-
Aaron C. de Bruyn -
Andrew Kirch -
Arie Vayner -
brent saner -
David Conrad -
David Prall -
Gary Sparkes -
Joe Hamelin -
John Levine -
Marco Moock -
Matthew Petach -
Pedro Prado -
Saku Ytti -
sronan＠ronan-online.com -
William Herrin