I might note that one of the qualified facilitators on the list recently "sold" me a block where the original entity which obtained it in the 1990s was still announcing it to all of their peers and trantsi after the wire transfer had been done, the ARIN process was done/ticket closed, and the block resided with my AS. It took a significant amount of badgering the original block holder (an entity with which we had no pre-existing relationship or direct contacts into their engineering department) to get them to withdraw the announcement, which we did independently of the broker and quicker than they responded to us. So my message would be to do your own due diligence and investigation of IP space and don't trust what the "broker" tells you. On Sun, Jan 7, 2024 at 8:50 PM John Curran <jcurran@arin.net> wrote:

On Jan 7, 2024, at 7:46 PM, KARIM MEKKAOUI <amekkaoui@mektel.ca> wrote:

Hi Nanog Community

Any idea please on the best way to buy IPv4 blocs and what is the price?

Karim -

Many folks make use of a broker for the purpose of finding an IPv4 address block – ARIN refers to organizations that aid others with transfers of address blocks as “facilitators”.

As a result of community concerns regarding less than stellar performance of some ARIN-listed facilitators, we recently relaunched the ARIN facilitator program with significantly more robust legal, accountability and transparency requirements – https://www.arin.net/resources/registry/transfers/facilitators/#qualified-fa...

This has resulted in a significant reduction in the number of organizations listed by ARIN as Qualified Facilitators, but there are plenty that meet the higher operational and customer satisfaction criteria and can be found here – https://www.arin.net/resources/registry/transfers/facilitators/qualifiedfaci... – any of them should be able to do a credible job in helping you obtain an IPv4 address block from the marketplace.

Best wishes, /John

John Curran President and CEO American Registry for Internet Numbers

I have used Eddie at iptrading several times over the yearsfor IP block purchases and never had this sort of issue, so would count this as a recommendation. Regards, Eddie Stauble eddie@iptrading.com <mailto:eddie@iptrading.com> 855-IPTRADE (855-478-7233) Ext 107 Direct: 754-227-8423 <https://iptrading.com/> From: NANOG <nanog-bounces+tony=wicks.co.nz@nanog.org> On Behalf Of John Curran Sent: Monday, January 8, 2024 7:46 PM To: Eric Kuhnke <eric.kuhnke@gmail.com> Cc: nanog@nanog.org list <nanog@nanog.org> Subject: Re: IPv4 address block On Jan 7, 2024, at 9:04 PM, Eric Kuhnke <eric.kuhnke@gmail.com <mailto:eric.kuhnke@gmail.com> > wrote: I might note that one of the qualified facilitators on the list recently "sold" me a block where the original entity which obtained it in the 1990s was still announcing it to all of their peers and trantsi after the wire transfer had been done, the ARIN process was done/ticket closed, and the block resided with my AS. Interesting. If you believe that the qualified facilitator failed in their duty to you (more specifically, if they did not live up to an aspect of the code of conduct – https://www.arin.net/resources/registry/transfers/facilitators/codeofconduct...) then please drop ARIN a message with the specifics to facilitator-support@arin.net <mailto:facilitator-support@arin.net> It took a significant amount of badgering the original block holder (an entity with which we had no pre-existing relationship or direct contacts into their engineering department) to get them to withdraw the announcement, which we did independently of the broker and quicker than they responded to us. So my message would be to do your own due diligence and investigation of IP space and don't trust what the "broker" tells you. Absolutely - always a good idea. Thanks for feedback! /John John Curran President and CEO American Registry for Internet Numbers

No, Eddies is NOT me, I included his details to be helpful to the OP…. From: Ben Cox <ben@benjojo.co.uk> Sent: Tuesday, January 9, 2024 9:27 AM To: Tony Wicks <tony@wicks.co.nz> Cc: North American Network Operators' Group <nanog@nanog.org> Subject: Re: IPv4 address block Hey Tony/Eddie I think your choice of email signature may have given away the game a little bit here Regards Ben Cartwright-Cox On Mon, Jan 8, 2024, 20:00 Tony Wicks <tony@wicks.co.nz <mailto:tony@wicks.co.nz> > wrote: I have used Eddie at iptrading several times over the yearsfor IP block purchases and never had this sort of issue, so would count this as a recommendation. Regards, Eddie Stauble eddie@iptrading.com <mailto:eddie@iptrading.com> 855-IPTRADE (855-478-7233) Ext 107 Direct: 754-227-8423 <https://iptrading.com/> <https://iptrading.com/> From: NANOG <nanog-bounces+tony=wicks.co.nz@nanog.org> On Behalf Of John Curran Sent: Monday, January 8, 2024 7:46 PM To: Eric Kuhnke <eric.kuhnke@gmail.com> Cc: nanog@nanog.org list <nanog@nanog.org> Subject: Re: IPv4 address block <https://iptrading.com/> <https://iptrading.com/> On Jan 7, 2024, at 9:04 PM, Eric Kuhnke <eric.kuhnke@gmail.com> wrote: <https://iptrading.com/> <https://iptrading.com/> I might note that one of the qualified facilitators on the list recently "sold" me a block where the original entity which obtained it in the 1990s was still announcing it to all of their peers and trantsi after the wire transfer had been done, the ARIN process was done/ticket closed, and the block resided with my AS. <https://iptrading.com/> <https://iptrading.com/> Interesting. If you believe that the qualified facilitator failed in their duty to you (more specifically, if they did not live up to an aspect of the code of conduct – https://www.arin.net/resources/registry/transfers/facilitators/codeofconduct...) then please drop ARIN a message with the specifics to facilitator-support@arin.net <https://iptrading.com/> <https://iptrading.com/> It took a significant amount of badgering the original block holder (an entity with which we had no pre-existing relationship or direct contacts into their engineering department) to get them to withdraw the announcement, which we did independently of the broker and quicker than they responded to us. So my message would be to do your own due diligence and investigation of IP space and don't trust what the "broker" tells you. <https://iptrading.com/> <https://iptrading.com/> Absolutely - always a good idea. <https://iptrading.com/> <https://iptrading.com/> Thanks for feedback! <https://iptrading.com/> /John <https://iptrading.com/> <https://iptrading.com/> John Curran <https://iptrading.com/> President and CEO <https://iptrading.com/> American Registry for Internet Numbers <https://iptrading.com/> <https://iptrading.com/> <https://iptrading.com/> <https://iptrading.com/>

😊 All good, when I looked back at the email it does look somewhat disingenuous, I should have really put, here is his details if the OP wants them. From: Ben Cox <ben@benjojo.co.uk> Sent: Tuesday, January 9, 2024 10:07 AM To: Tony Wicks <tony@wicks.co.nz> Cc: Ben Cox <ben@benjojo.co.uk>; North American Network Operators' Group <nanog@nanog.org> Subject: {Disarmed} Re: {Disarmed} RE: IPv4 address block Ah, apologies on my part Tony, it did look at lot like a signature block and thus a amusing sock puppet SNAFU On Mon, Jan 8, 2024, 20:54 Tony Wicks <tony@wicks.co.nz <mailto:tony@wicks.co.nz> > wrote: No, Eddies is NOT me, I included his details to be helpful to the OP…. From: Ben Cox <ben@benjojo.co.uk <mailto:ben@benjojo.co.uk> > Sent: Tuesday, January 9, 2024 9:27 AM To: Tony Wicks <tony@wicks.co.nz <mailto:tony@wicks.co.nz> > Cc: North American Network Operators' Group <nanog@nanog.org <mailto:nanog@nanog.org> > Subject: Re: IPv4 address block Hey Tony/Eddie I think your choice of email signature may have given away the game a little bit here Regards Ben Cartwright-Cox On Mon, Jan 8, 2024, 20:00 Tony Wicks <tony@wicks.co.nz <mailto:tony@wicks.co.nz> > wrote: I have used Eddie at iptrading several times over the yearsfor IP block purchases and never had this sort of issue, so would count this as a recommendation. Regards, Eddie Stauble eddie@iptrading.com <mailto:eddie@iptrading.com> 855-IPTRADE (855-478-7233) Ext 107 Direct: 754-227-8423 <https://iptrading.com/> From: NANOG <nanog-bounces+tony=wicks.co.nz@nanog.org> On Behalf Of John Curran Sent: Monday, January 8, 2024 7:46 PM To: Eric Kuhnke <eric.kuhnke@gmail.com> Cc: nanog@nanog.org list <nanog@nanog.org> Subject: Re: IPv4 address block <https://iptrading.com/> <https://iptrading.com/> MailScanner has detected a possible fraud attempt from "iptrading.com" claiming to be MailScanner has detected a possible fraud attempt from "iptrading.com" claiming to be On Jan 7, 2024, at 9:04 PM, Eric Kuhnke <eric.kuhnke@gmail.com> wrote: <https://iptrading.com/> <https://iptrading.com/> I might note that one of the qualified facilitators on the list recently "sold" me a block where the original entity which obtained it in the 1990s was still announcing it to all of their peers and trantsi after the wire transfer had been done, the ARIN process was done/ticket closed, and the block resided with my AS. <https://iptrading.com/> <https://iptrading.com/> MailScanner has detected a possible fraud attempt from "iptrading.com" claiming to be MailScanner has detected a possible fraud attempt from "iptrading.com" claiming to be Interesting. If you believe that the qualified facilitator failed in their duty to you (more specifically, if they did not live up to an aspect of the code of conduct – https://www.arin.net/resources/registry/transfers/facilitators/codeofconduct...) then please drop ARIN a message with the specifics to facilitator-support@arin.net <https://iptrading.com/> <https://iptrading.com/> It took a significant amount of badgering the original block holder (an entity with which we had no pre-existing relationship or direct contacts into their engineering department) to get them to withdraw the announcement, which we did independently of the broker and quicker than they responded to us. So my message would be to do your own due diligence and investigation of IP space and don't trust what the "broker" tells you. <https://iptrading.com/> <https://iptrading.com/> Absolutely - always a good idea. <https://iptrading.com/> <https://iptrading.com/> Thanks for feedback! <https://iptrading.com/> /John <https://iptrading.com/> <https://iptrading.com/> John Curran <https://iptrading.com/> President and CEO <https://iptrading.com/> American Registry for Internet Numbers <https://iptrading.com/> <https://iptrading.com/> <https://iptrading.com/> <https://iptrading.com/>

On Wed, Jan 10, 2024 at 07:35:01AM -0500, Abraham Y. Chen wrote:

Hi, Karim:

1)?????? If you have control of your own equipment (I presume that your business includes IAP - Internet Access Provider, since you are asking to buy IPv4 blocks.), you can get a large block of reserved IPv4 address _/*for free*/_ by _/*disabling*/_ the program codes in your current facility that has been */_disabling_/* the use of 240/4 netblock.

As you state yourself this could be considered "unorthodox, if not controversial". Alas in network operations 'unorthodox' usually means 'breaks something'. Which is exactly why you may avoid this, see also: https://theinternetprotocolblog.wordpress.com/2019/10/06/some-notes-on-ipv4-... cheers Enno Please

have a look at the below whitepaper. Utilized according to the outlined disciplines, this is a practically unlimited resources. It has been known that multi-national conglomerates have been using it without announcement. So, you can do so stealthily according to the proposed mechanism which establishes uniform practices, just as well.

https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf

2)?????? Being an unorthodox solution, if not controversial, please follow up with me offline. Unless, other NANOGers express their interests.

Regards,

Abe (2024-01-10 07:34 EST)

On 2024-01-07 22:46, KARIM MEKKAOUI wrote:

...

Hi Nanog Community

Any idea please on the best way to buy IPv4 blocs and what is the price?

Thank you

KARIM

-- This email has been checked for viruses by Avast antivirus software. www.avast.com

-- Enno Rey Cell: +49 173 6745902 Twitter: @Enno_Insinuator IPv6 Blog: https://theinternetprotocolblog.wordpress.com

I shouldn't probably go down this path... as I know this has been discussed but I'm hoping that this might make a difference. Abraham, Even if 240/4 is "fixed", your EzIP scheme will require some sort of NAT box between the 240/4 addressed devices and the non-EzIP internet. That NAT box will have to remain in place until such time as every single publically addressed device on the public internet has been updated to support EzIP. In addition, protocols such as DNS, SIP, and others which pass around addresses will need to be updated to be able to pass the full EzIP addressing around so endpoints can properly insert the EzIP header, and so on. The point I'm trying to make is that, at this point, deploying EzIP as an end to end address exhaustion solution has MORE challenges that simply deploying IPv6 would. This is because, just like EzIP, deploying IPv6 requires a NAT box of some sort to be put in place until the last IPv4 device is turned off. But unlike EzIP, almost every new device coming out supports IPv6 out of the box. All of the technical standards work has already been done. Thus, the only meaningful barrier to IPv6 at this point is convincing people to use it, not convincing people to use it PLUS convincing the tech companies to support it, and doing protocol changes like you would with EzIP. I applaud your attempt at a unique solution but I really feel that ship has sailed, at least for an EzIP type of solution. Maybe something like this would have better received years ago, but at this point IPv6 is a much more logical path forward. I do wonder, however, if some of your concepts might be able to be applied to the IPv6 transition. I have some ideas here, but most, if not all, of them are only partially cooked but some have similar approaches as EzIP but with an actual IPv6 packet inside. On Wed, Jan 10, 2024, 7:11 PM Abraham Y. Chen <aychen@avinta.com> wrote:

Hi, Enno:

0) Thanks for your comments referring to historical efforts.

1) However, the "IPv4 Unicast Extension Project" that your paper cited does not make any specific recommendation about how to utilize the 240/4 netblock uniformly across the entire Internet. Our proposal, EzIP outlines a scheme that makes a clear use of the 240/4 by the general public, basically discouraging disparate private usages. We were very much lost with what has been going on with the 240/4 netblock, because there was no information about who were using it for what. The RIPE-Lab report clarified the fact that it has been fragmented due to unannounced activities by multi-national conglomerates and likely nerds, while under the cover of "Reserved for Future Use".

2) " As you state yourself this could be considered "unorthodox, if not controversial". ... usually means 'breaks something' ":

I am afraid that you read into my diplomatic expression too far.

A. The first step of the EzIP proposal is to enhance the CG-NAT by providing it with a much larger netblock, as I presume that Karim is looking for. Such process (disabling the program code that has been disabling the use of 240/4) does not need any running code to prove it. To be blunt, anyone who claims that this will be a real task only shows that he does not know his own code.

B. The second EzIP step is to utilize RFC791 for setting up end-to-end links which the Internet has not been able to deliver. This is because the current predominant CG-NAT based CDN business is a master-slave model which does not support it. However, this capability is like international postal or telephony services that are not daily needs for everyone. So, it should be treated as a premium service that can be built up with time base on demand.

Let's not mixing B. with A. as a one-shot job in this discussion.

Regards,

Abe (2024-01-10 22:10 EST)

On 2024-01-10 07:57, Enno Rey via NANOG wrote:

On Wed, Jan 10, 2024 at 07:35:01AM -0500, Abraham Y. Chen wrote:

Hi, Karim:

1)?????? If you have control of your own equipment (I presume that your business includes IAP - Internet Access Provider, since you are asking to buy IPv4 blocks.), you can get a large block of reserved IPv4 address _/*for free*/_ by _/*disabling*/_ the program codes in your current facility that has been */_disabling_/* the use of 240/4 netblock.

As you state yourself this could be considered "unorthodox, if not controversial". Alas in network operations 'unorthodox' usually means 'breaks something'. Which is exactly why you may avoid this, see also: https://theinternetprotocolblog.wordpress.com/2019/10/06/some-notes-on-ipv4-...

cheers

Enno

Please

have a look at the below whitepaper. Utilized according to the outlined disciplines, this is a practically unlimited resources. It has been known that multi-national conglomerates have been using it without announcement. So, you can do so stealthily according to the proposed mechanism which establishes uniform practices, just as well. https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf

2)?????? Being an unorthodox solution, if not controversial, please follow up with me offline. Unless, other NANOGers express their interests.

Regards,

Abe (2024-01-10 07:34 EST)

On 2024-01-07 22:46, KARIM MEKKAOUI wrote:

Hi Nanog Community

Any idea please on the best way to buy IPv4 blocs and what is the price?

Thank you

KARIM

-- This email has been checked for viruses by Avast antivirus software.www.avast.com

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virus-free.www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> <#m_-2040759016673337921_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Not going to lie, EzIP just seems to be some version of destination/source NAT on steroids. Regards, Christopher Hawker On Fri, 12 Jan 2024 at 14:36, Abraham Y. Chen <aychen@avinta.com> wrote:

Hi, Forrest:

0) Thanks for your in-depth analysis.

1) However, my apologies for not presenting the EzIP concept clearer. That is, one way to look at the EzIP scheme is to substitute the current 100.64/10 netblock in the CG-NAT with 240/4. Everything else in the current CG-NAT setup stays unchanged. This makes each CG-NAT cluster 64 fold bigger. And, various capabilities become available.

Regards,

Abe (2024-01-11 22:35)

On 2024-01-11 02:02, Forrest Christian (List Account) wrote:

I shouldn't probably go down this path... as I know this has been discussed but I'm hoping that this might make a difference.

Abraham,

Even if 240/4 is "fixed", your EzIP scheme will require some sort of NAT box between the 240/4 addressed devices and the non-EzIP internet. That NAT box will have to remain in place until such time as every single publically addressed device on the public internet has been updated to support EzIP. In addition, protocols such as DNS, SIP, and others which pass around addresses will need to be updated to be able to pass the full EzIP addressing around so endpoints can properly insert the EzIP header, and so on.

The point I'm trying to make is that, at this point, deploying EzIP as an end to end address exhaustion solution has MORE challenges that simply deploying IPv6 would. This is because, just like EzIP, deploying IPv6 requires a NAT box of some sort to be put in place until the last IPv4 device is turned off. But unlike EzIP, almost every new device coming out supports IPv6 out of the box. All of the technical standards work has already been done. Thus, the only meaningful barrier to IPv6 at this point is convincing people to use it, not convincing people to use it PLUS convincing the tech companies to support it, and doing protocol changes like you would with EzIP.

I applaud your attempt at a unique solution but I really feel that ship has sailed, at least for an EzIP type of solution. Maybe something like this would have better received years ago, but at this point IPv6 is a much more logical path forward.

I do wonder, however, if some of your concepts might be able to be applied to the IPv6 transition. I have some ideas here, but most, if not all, of them are only partially cooked but some have similar approaches as EzIP but with an actual IPv6 packet inside.

On Wed, Jan 10, 2024, 7:11 PM Abraham Y. Chen <aychen@avinta.com> wrote:

...

Hi, Enno:

0) Thanks for your comments referring to historical efforts.

1) However, the "IPv4 Unicast Extension Project" that your paper cited does not make any specific recommendation about how to utilize the 240/4 netblock uniformly across the entire Internet. Our proposal, EzIP outlines a scheme that makes a clear use of the 240/4 by the general public, basically discouraging disparate private usages. We were very much lost with what has been going on with the 240/4 netblock, because there was no information about who were using it for what. The RIPE-Lab report clarified the fact that it has been fragmented due to unannounced activities by multi-national conglomerates and likely nerds, while under the cover of "Reserved for Future Use".

2) " As you state yourself this could be considered "unorthodox, if not controversial". ... usually means 'breaks something' ":

I am afraid that you read into my diplomatic expression too far.

A. The first step of the EzIP proposal is to enhance the CG-NAT by providing it with a much larger netblock, as I presume that Karim is looking for. Such process (disabling the program code that has been disabling the use of 240/4) does not need any running code to prove it. To be blunt, anyone who claims that this will be a real task only shows that he does not know his own code.

B. The second EzIP step is to utilize RFC791 for setting up end-to-end links which the Internet has not been able to deliver. This is because the current predominant CG-NAT based CDN business is a master-slave model which does not support it. However, this capability is like international postal or telephony services that are not daily needs for everyone. So, it should be treated as a premium service that can be built up with time base on demand.

Let's not mixing B. with A. as a one-shot job in this discussion.

Regards,

Abe (2024-01-10 22:10 EST)

On 2024-01-10 07:57, Enno Rey via NANOG wrote:

On Wed, Jan 10, 2024 at 07:35:01AM -0500, Abraham Y. Chen wrote:

Hi, Karim:

1)?????? If you have control of your own equipment (I presume that your business includes IAP - Internet Access Provider, since you are asking to buy IPv4 blocks.), you can get a large block of reserved IPv4 address _/*for free*/_ by _/*disabling*/_ the program codes in your current facility that has been */_disabling_/* the use of 240/4 netblock.

As you state yourself this could be considered "unorthodox, if not controversial". Alas in network operations 'unorthodox' usually means 'breaks something'. Which is exactly why you may avoid this, see also: https://theinternetprotocolblog.wordpress.com/2019/10/06/some-notes-on-ipv4-...

cheers

Enno

Please

have a look at the below whitepaper. Utilized according to the outlined disciplines, this is a practically unlimited resources. It has been known that multi-national conglomerates have been using it without announcement. So, you can do so stealthily according to the proposed mechanism which establishes uniform practices, just as well. https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf

2)?????? Being an unorthodox solution, if not controversial, please follow up with me offline. Unless, other NANOGers express their interests.

Regards,

Abe (2024-01-10 07:34 EST)

On 2024-01-07 22:46, KARIM MEKKAOUI wrote:

Hi Nanog Community

Any idea please on the best way to buy IPv4 blocs and what is the price?

Thank you

KARIM

-- This email has been checked for viruses by Avast antivirus software.www.avast.com

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virus-free.www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> <#m_-3759812132042785637_m_-2040759016673337921_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

"Source NAT changes the source address in IP header of a packet. It may also change the source port in the TCP/UDP headers. The typical usage is to change the a private (rfc1918) address/port into a public address/port for packets leaving your network." "Destination NAT changes the destination address in IP header of a packet. It may also change the destination port in the TCP/UDP headers.The typical usage of this is to redirect incoming packets with a destination of a public address/port to a private IP address/port inside your network." Source: https://serverfault.com/questions/119365/what-is-the-difference-between-a-so... Regards, Christopher Hawker On Fri, 12 Jan 2024 at 23:17, Abraham Y. Chen <aychen@avinta.com> wrote:

Hi, Christopher:

1) " destination/source NAT ":

I am not sure about this terminology. Could you please elaborate? If you are referring EzIP being a bigger CG-NAT, it is exactly correct. That is, the first step of EzIP implementation is just to give CG-NAT a larger netblock to work with, so that the chore of dynamic address assignment to the client may be avoided.

Regards,

Abe (2024-01-12 07:16)

On 2024-01-11 22:46, Christopher Hawker wrote:

Not going to lie, EzIP just seems to be some version of destination/source NAT on steroids.

Regards, Christopher Hawker

On Fri, 12 Jan 2024 at 14:36, Abraham Y. Chen <aychen@avinta.com> wrote:

...

Hi, Forrest:

0) Thanks for your in-depth analysis.

1) However, my apologies for not presenting the EzIP concept clearer. That is, one way to look at the EzIP scheme is to substitute the current 100.64/10 netblock in the CG-NAT with 240/4. Everything else in the current CG-NAT setup stays unchanged. This makes each CG-NAT cluster 64 fold bigger. And, various capabilities become available.

Regards,

Abe (2024-01-11 22:35)

On 2024-01-11 02:02, Forrest Christian (List Account) wrote:

I shouldn't probably go down this path... as I know this has been discussed but I'm hoping that this might make a difference.

Abraham,

Even if 240/4 is "fixed", your EzIP scheme will require some sort of NAT box between the 240/4 addressed devices and the non-EzIP internet. That NAT box will have to remain in place until such time as every single publically addressed device on the public internet has been updated to support EzIP. In addition, protocols such as DNS, SIP, and others which pass around addresses will need to be updated to be able to pass the full EzIP addressing around so endpoints can properly insert the EzIP header, and so on.

The point I'm trying to make is that, at this point, deploying EzIP as an end to end address exhaustion solution has MORE challenges that simply deploying IPv6 would. This is because, just like EzIP, deploying IPv6 requires a NAT box of some sort to be put in place until the last IPv4 device is turned off. But unlike EzIP, almost every new device coming out supports IPv6 out of the box. All of the technical standards work has already been done. Thus, the only meaningful barrier to IPv6 at this point is convincing people to use it, not convincing people to use it PLUS convincing the tech companies to support it, and doing protocol changes like you would with EzIP.

I applaud your attempt at a unique solution but I really feel that ship has sailed, at least for an EzIP type of solution. Maybe something like this would have better received years ago, but at this point IPv6 is a much more logical path forward.

I do wonder, however, if some of your concepts might be able to be applied to the IPv6 transition. I have some ideas here, but most, if not all, of them are only partially cooked but some have similar approaches as EzIP but with an actual IPv6 packet inside.

...

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virus-free.www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> <#m_7003280393758044796_m_-3759812132042785637_m_-2040759016673337921_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

The problem isn't the quantity of "inside" CG-NAT address space. It's the existence of CG-NAT at all. It doesn't matter if the available space is a /12 or a /4, you still need something to translate it to the public internet. The existence of that CG-NAT box is a thorn in every provider's side and every provider that has one wants to make it go away as quickly as possible. The quickest and most straightforward way to eliminate the need for any CG-NAT is to move to a bigger address space. As I pointed out, IPv6 is already ready and proven to work so moving to IPv6 is a straightforward process technically. What isn't straightforward is convincing IPv4 users to move. Until the cost (or pain) to stay on IPv4 is greater than the cost to move, we're going to see continued resistance to doing so. On Thu, Jan 11, 2024, 7:36 PM Abraham Y. Chen <aychen@avinta.com> wrote:

Hi, Forrest:

0) Thanks for your in-depth analysis.

1) However, my apologies for not presenting the EzIP concept clearer. That is, one way to look at the EzIP scheme is to substitute the current 100.64/10 netblock in the CG-NAT with 240/4. Everything else in the current CG-NAT setup stays unchanged. This makes each CG-NAT cluster 64 fold bigger. And, various capabilities become available.

Regards,

Abe (2024-01-11 22:35)

On 2024-01-11 02:02, Forrest Christian (List Account) wrote:

I shouldn't probably go down this path... as I know this has been discussed but I'm hoping that this might make a difference.

Abraham,

Even if 240/4 is "fixed", your EzIP scheme will require some sort of NAT box between the 240/4 addressed devices and the non-EzIP internet. That NAT box will have to remain in place until such time as every single publically addressed device on the public internet has been updated to support EzIP. In addition, protocols such as DNS, SIP, and others which pass around addresses will need to be updated to be able to pass the full EzIP addressing around so endpoints can properly insert the EzIP header, and so on.

The point I'm trying to make is that, at this point, deploying EzIP as an end to end address exhaustion solution has MORE challenges that simply deploying IPv6 would. This is because, just like EzIP, deploying IPv6 requires a NAT box of some sort to be put in place until the last IPv4 device is turned off. But unlike EzIP, almost every new device coming out supports IPv6 out of the box. All of the technical standards work has already been done. Thus, the only meaningful barrier to IPv6 at this point is convincing people to use it, not convincing people to use it PLUS convincing the tech companies to support it, and doing protocol changes like you would with EzIP.

I applaud your attempt at a unique solution but I really feel that ship has sailed, at least for an EzIP type of solution. Maybe something like this would have better received years ago, but at this point IPv6 is a much more logical path forward.

I do wonder, however, if some of your concepts might be able to be applied to the IPv6 transition. I have some ideas here, but most, if not all, of them are only partially cooked but some have similar approaches as EzIP but with an actual IPv6 packet inside.

On Wed, Jan 10, 2024, 7:11 PM Abraham Y. Chen <aychen@avinta.com> wrote:

...

Hi, Enno:

0) Thanks for your comments referring to historical efforts.

1) However, the "IPv4 Unicast Extension Project" that your paper cited does not make any specific recommendation about how to utilize the 240/4 netblock uniformly across the entire Internet. Our proposal, EzIP outlines a scheme that makes a clear use of the 240/4 by the general public, basically discouraging disparate private usages. We were very much lost with what has been going on with the 240/4 netblock, because there was no information about who were using it for what. The RIPE-Lab report clarified the fact that it has been fragmented due to unannounced activities by multi-national conglomerates and likely nerds, while under the cover of "Reserved for Future Use".

2) " As you state yourself this could be considered "unorthodox, if not controversial". ... usually means 'breaks something' ":

I am afraid that you read into my diplomatic expression too far.

A. The first step of the EzIP proposal is to enhance the CG-NAT by providing it with a much larger netblock, as I presume that Karim is looking for. Such process (disabling the program code that has been disabling the use of 240/4) does not need any running code to prove it. To be blunt, anyone who claims that this will be a real task only shows that he does not know his own code.

B. The second EzIP step is to utilize RFC791 for setting up end-to-end links which the Internet has not been able to deliver. This is because the current predominant CG-NAT based CDN business is a master-slave model which does not support it. However, this capability is like international postal or telephony services that are not daily needs for everyone. So, it should be treated as a premium service that can be built up with time base on demand.

Let's not mixing B. with A. as a one-shot job in this discussion.

Regards,

Abe (2024-01-10 22:10 EST)

On 2024-01-10 07:57, Enno Rey via NANOG wrote:

On Wed, Jan 10, 2024 at 07:35:01AM -0500, Abraham Y. Chen wrote:

Hi, Karim:

1)?????? If you have control of your own equipment (I presume that your business includes IAP - Internet Access Provider, since you are asking to buy IPv4 blocks.), you can get a large block of reserved IPv4 address _/*for free*/_ by _/*disabling*/_ the program codes in your current facility that has been */_disabling_/* the use of 240/4 netblock.

As you state yourself this could be considered "unorthodox, if not controversial". Alas in network operations 'unorthodox' usually means 'breaks something'. Which is exactly why you may avoid this, see also: https://theinternetprotocolblog.wordpress.com/2019/10/06/some-notes-on-ipv4-...

cheers

Enno

Please

have a look at the below whitepaper. Utilized according to the outlined disciplines, this is a practically unlimited resources. It has been known that multi-national conglomerates have been using it without announcement. So, you can do so stealthily according to the proposed mechanism which establishes uniform practices, just as well. https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf

2)?????? Being an unorthodox solution, if not controversial, please follow up with me offline. Unless, other NANOGers express their interests.

Regards,

Abe (2024-01-10 07:34 EST)

On 2024-01-07 22:46, KARIM MEKKAOUI wrote:

Hi Nanog Community

Any idea please on the best way to buy IPv4 blocs and what is the price?

Thank you

KARIM

-- This email has been checked for viruses by Avast antivirus software.www.avast.com

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virus-free.www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> <#m_4344191822884267435_m_-2040759016673337921_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

A couple of points: 1) There is less work needed to support IPv6 than your proposed solution. I'm not taking about 230/4. I'm talking about your EzIP overlay. 2) Assume that Google decided that they would no longer support IPv4 for any of their services at a specific date a couple of years in the future. That is, you either needed an IPv6 address or you couldn't reach Google, youtube, Gmail and the rest of the public services. I bet that in this scenario every eyeball provider in the country all of a sudden would be extremely motivated to deploy IPv6, even if the IPv4 providers end up natting their IPv4 customers to IPv6. I really expect something like this to be the next part of the end game for IPv4. Or stated differently: at some point someone with enough market power is going to basically say "enough is enough" and make the decision for the rest of us that IPv4 is effectively done on the public internet. The large tech companies all have a history of sunsetting things when it becomes a bigger problem to support than it's worth. Try getting a modern browser that works on 32 bit windows. Same with encryption protocols, Java in the browser, Shockwave and flash, and on and on. I see no reason why IPv4 should be any different. On Fri, Jan 12, 2024, 3:42 PM Abraham Y. Chen <aychen@avinta.com> wrote:

Hi, Forrest:

0) You put out more than one topic, all at one time. Allow me to address each briefly.

1) " The existence of that CG-NAT box is a thorn in every provider's side and every provider that has one wants to make it go away as quickly as possible. ":

The feeling and desire are undeniable facts. However, the existing configuration was evolved from various considerations through a long time. There is a tremendous inertia accumulated on it. There is no magic bullet to get rid of it quickly. We must study carefully to evolve it further incrementally. Otherwise, an even bigger headache or disaster will happen.

2) " The quickest and most straightforward way to eliminate the need for any CG-NAT is to move to a bigger address space. ":

The obvious answer was IPv6. However, its performance after near two decades of deployment has not been convincing. EzIP is an alternative, requiring hardly any development, to address this need immediately.

3) " Until the cost (or pain) to stay on IPv4 is greater than the cost to move, we're going to see continued resistance to doing so. ":

This strategy is easily said than done. It reminds me of my system planning work for the old AT&T. At that time, Bell Operating Companies (BOCs) could be coerced to upgrade their facility by just gradually raising the cost of owning the old equipment by assuming fewer would be be used, while the newer version would cost less because growing number of deployments. Looking at resultant financial forecast, the BOC decisions were easy. Originally trained as a hardware radio engineer, I was totally stunned. But, it worked well under the regulated monopoly environment.

Fast forward by half a century, the Internet promotes distributed approaches. Few things can be controlled by limited couple parties. The decision of go or no-go is made by parties in the field who have their own respective considerations. Accumulated, they set the direction of the Internet. In this case, IPv6 has had the opportunity of over four decades of planning and nearly two decades of deployment. Its future growth rate is set by its own performance merits. No one can force its rate by persuasion tactic of any kind. Hoping so is wishful thinking which contributes to wasteful activities. So, we need realistic planning. Regards,

Abe (2024-01-12 18:42)

On 2024-01-12 01:34, Forrest Christian (List Account) wrote:

The problem isn't the quantity of "inside" CG-NAT address space. It's the existence of CG-NAT at all.

It doesn't matter if the available space is a /12 or a /4, you still need something to translate it to the public internet. The existence of that CG-NAT box is a thorn in every provider's side and every provider that has one wants to make it go away as quickly as possible.

The quickest and most straightforward way to eliminate the need for any CG-NAT is to move to a bigger address space. As I pointed out, IPv6 is already ready and proven to work so moving to IPv6 is a straightforward process technically. What isn't straightforward is convincing IPv4 users to move. Until the cost (or pain) to stay on IPv4 is greater than the cost to move, we're going to see continued resistance to doing so.

On Thu, Jan 11, 2024, 7:36 PM Abraham Y. Chen <aychen@avinta.com> wrote:

...

Hi, Forrest:

0) Thanks for your in-depth analysis.

1) However, my apologies for not presenting the EzIP concept clearer. That is, one way to look at the EzIP scheme is to substitute the current 100.64/10 netblock in the CG-NAT with 240/4. Everything else in the current CG-NAT setup stays unchanged. This makes each CG-NAT cluster 64 fold bigger. And, various capabilities become available.

Regards,

Abe (2024-01-11 22:35)

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virus-free.www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> <#m_-2264817505018915121_m_-871507042037526857_m_-3709659627675338528_m_5461191486991014945_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

My position is a bit more subtle than I stated. I tend to forget I can and should be more nuanced on this particular list. First, there is very little cost to any large tech company to state a date that they expect to turn off IPv4 for certain services. "To get our free xyz service after January 1, 2028, you'll need to be on a provider that supports IPv6". The tech companies can then push out that deadline if they don't see enough adoption as the deadline approaches. There are, of course, risks related to consumers switching to other alternatives prior to the date and also various other reputation and legal risks. But I suspect that can be managed in a way that minimizes the risks. But the point here is that the setting of a possible IPv4 shutoff date is likely to accelerate IPv6 adoption even if they never actually shut off IPv4. I guess if one was to abstract the above out at a very high level it would be to say that about the easiest way that I can see to further accelerate IPv6 adoption is to either start to provide certain desirable services only over IPv6 or at least threaten to do so. The Googles of the world just happen to be in the best position to do just that and may have a financial motivation to do so (if they can do so without negatively impacting their bottom line). On Sat, Jan 13, 2024, 12:42 AM Giorgio Bonfiglio <me@grg.pw> wrote:

2) Assume that Google decided that they would no longer support IPv4 for any of their services at a specific date a couple of years in the future. […] I really expect something like this to be the next part of the end game for IPv4.

...

It’s never gonna happen … why would Google, or any other internet property, launch something which artificially cuts the potential revenue pool to IPv6-ready customers?

I’m with you it would be amazing and a strong driver, but it’s just not in the realm of possibility…

For the record, folks, I long ago just sent Abraham's mail into spam, for me, and just the backscatter from that conversation this week was bad for my blood pressure. I know he sincerely believes in his concept(s), and I don't, nor am I going to waste further time arguing with him. It's hard enough to stay rational facing the enormous difficulties of merely shifting 240/4 from reserved to unicast in the iana registry. Anyway, nice subject change! <rant> On Sat, Jan 13, 2024 at 11:59 AM Giorgio Bonfiglio via NANOG <nanog@nanog.org> wrote:

[I’m gonna change subject to this sub thread since it makes sense… as opposed to the other 15 subject line changes this thread has seen so far]

First, there is very little cost to any large tech company to state a date that they expect to turn off IPv4 for certain services. "To get our free xyz service after January 1, 2028, you'll need to be on a provider that supports IPv6". The tech companies can then push out that deadline if they don't see enough adoption as the deadline approaches.

2128 seems more likely. And it would be funnier if a bunch of companies did announce that as a date.

You’re suggesting they should bluff, essentially - this is great!

I kind of view the RDOF debacle as of this nature - state a major policy goal, promise enormous funding for it, watch companies pre-invest to get on top of the requirement - then pull the rug out from everyone by inventing insane requirements post-hoc and not distributing the funds. Suggesting anyone do the same to support IPv6 kind of rubs me the wrong way in the same way.

There are, of course, risks related to consumers switching to other alternatives prior to the date and also various other reputation and legal risks.

In pre-history, and I forget when it was, someone put an enormous stash of pr0n out there on ipv6 only. Didn't help.

Exactly, which is why this won’t happen until the $$ saving due to abandoning v4 outweighs the risks above.

2128. Among other things, have you seen the k8 mess lately?

I guess if one was to abstract the above out at a very high level it would be to say that about the easiest way that I can see to further accelerate IPv6 adoption is to either start to provide certain desirable services only over IPv6 or at least threaten to do so.

Did you consider a legislative / government level incentive? The EU just forced all mobile devices sold in the area to have an USB-C port, why not enforcing a requirement for IPv6 on all broadband and mobile connections?

I certainly now think some government involvement is necessary. I would have liked an ipv6 requirement to emerge for BEAD funding, but most of the lobbying dollars have merely been spent on getting fiber thoroughly subsidized, instead of routers that run modern software, have bufferbloat fixes and ipv6. $.30/house verses $30k/mile. If only a few states distributing that 70B tied an IPv6 requirement onto it it would help. Please bug your local broadband offices? In doing up the recent bufferbloat.net FCC filing (which we have discussed here), we formed a mailing list that several prominent figures joined. Example: https://lists.bufferbloat.net/pipermail/nnagain/2023-November/000345.html It was news to that layer that A) we were out of IPv4 and B) the government had 10 /8s they were not using and C) 1/16 of the original internet was still unallocated due to internal infighting amongst the calcified institutions of the internet and D) IPv6 was not being deployed by default, still, in many places, in the USA, and other nations "were ahead". Some of the arguments we made towards not being able to cross the "digital divide" without better numbering (be it ipv4 or ipv6) seemed to resonate, but it is still early days, more people should reach out to their state broadband offices on these issues, if I can stress that again! It was news to several legal interns in broadband regulation that I have met recently, exactly what a packet was. There is a long way to go here towards coherent regulation. Perhaps by 2228? While I was glad to have reached across the net/gov isle last year to have made this attempt, I would much rather go back to shipping the next million subscribers for libreqos than fight much more at this level. If everyone here made one phone call to their local broadband office, or (better) showed up at one of the rather nice parties the fiber industry is perpetually throwing for them - it would help more than all the discussion on this mailing list to date to push things forward.

Or at least a mechanism to clearly identify dual stack broadband offerings vs v4 only?

The FCC broadband labels thing is still mostly a joke. But feedback is still being solicited.

US is also mandating a v6 support requirement for gov-contracts - why not extending?

Ultimately - the commercial world can create incentives, but lawmakers can enforce.

I think even the plausible threat of regulation would create incentives. I also think the plausible threat of one of the agencies that are supposedly being stewards of the internet to start making plans for 240/4 to become public would spur the googles and amazons of the world to get off of it and more onto v6.

The Googles of the world just happen to be in the best position to do just that and may have a financial motivation to do so (if they can do so without negatively impacting their bottom line).

I do not agree that anyone has an incentive to shift their traffic exclusively to ipv6, I mostly point out that ipv6 along the edge needs to deploy somehow.

On Sat, Jan 13, 2024, 12:42 AM Giorgio Bonfiglio <me@grg.pw> wrote:

...

2) Assume that Google decided that they would no longer support IPv4 for any of their services at a specific date a couple of years in the future. […] I really expect something like this to be the next part of the end game for IPv4.

It’s never gonna happen … why would Google, or any other internet property, launch something which artificially cuts the potential revenue pool to IPv6-ready customers?

I’m with you it would be amazing and a strong driver, but it’s just not in the realm of possibility…

-- 40 years of net history, a couple songs: https://www.youtube.com/watch?v=D9RGX6QFm5E Dave Täht CSO, LibreQos

Ok you've triggered me on your point 2. I'll address the elephant in the room. IPv4 is never ever going away. Right now consumer services are mostly (mobile, wireless, landline, wide generalization) are IPv6 capable. Most consumer applications are ipv6 capable, Google, Facebook, etc.There is light at the very end of the tunnel that suggests that one day we won't have to deploy CGNAT444 for our consumers to get to content, we may only have to do NAT64 for them to get to the remaining Ipv4 Internet. We're still working hard on removing our reliance on genuine ipv4 ranges to satisfy our customer needs, It's still a long way off, but it's coming. Here's the current problem. Enterprise doesn't need ipv6 or want ipv6. You might be able to get away with giving CGNAT to your consumers, but your enterprise customer will not accept this. How will they terminate their remote users? How will they do B2B with out inbound NAT? Yes, there are solutions, but if you don't need to, why? They pay good money, why can't they have real ipv4? All their internal networks are IPv4 rfc1918. They are happy with NAT. Their application service providers are ipv4 only. Looking at the services I access for work things like SAP, SerivceNow, Office386, Sharepoint, Okta, Dayforce, Xero, and I'm sure many more, none can not be accessed on ipv6 alone.. Their internal network lifecycle is 10+ years. They have no interest in trying new things or making new technology work without a solid financial reason and there is none for them implementing ipv6. And guess where all the IP addresses we're getting back from our consumers are going? Straight to our good margin enterprise customers and their application service providers. Consumer CGNAT isn't solving problems, it's creating more. The end of IPv4 isn't nigh, it's just privileged only. PS When you solve that problem in 50 years time, I'll be one of those old fogey's keeping an IPv4 service alive as an example of "the old Internet" for those young whippersnappers to be amazed by. Regards, Brett On Sat, Jan 13, 2024 at 7:31 PM Forrest Christian (List Account) < lists@packetflux.com> wrote:

A couple of points:

1) There is less work needed to support IPv6 than your proposed solution. I'm not taking about 230/4. I'm talking about your EzIP overlay.

2) Assume that Google decided that they would no longer support IPv4 for any of their services at a specific date a couple of years in the future. That is, you either needed an IPv6 address or you couldn't reach Google, youtube, Gmail and the rest of the public services. I bet that in this scenario every eyeball provider in the country all of a sudden would be extremely motivated to deploy IPv6, even if the IPv4 providers end up natting their IPv4 customers to IPv6. I really expect something like this to be the next part of the end game for IPv4.

Or stated differently: at some point someone with enough market power is going to basically say "enough is enough" and make the decision for the rest of us that IPv4 is effectively done on the public internet. The large tech companies all have a history of sunsetting things when it becomes a bigger problem to support than it's worth. Try getting a modern browser that works on 32 bit windows. Same with encryption protocols, Java in the browser, Shockwave and flash, and on and on.

I see no reason why IPv4 should be any different.

On Fri, Jan 12, 2024, 3:42 PM Abraham Y. Chen <aychen@avinta.com> wrote:

...

Hi, Forrest:

0) You put out more than one topic, all at one time. Allow me to address each briefly.

1) " The existence of that CG-NAT box is a thorn in every provider's side and every provider that has one wants to make it go away as quickly as possible. ":

The feeling and desire are undeniable facts. However, the existing configuration was evolved from various considerations through a long time. There is a tremendous inertia accumulated on it. There is no magic bullet to get rid of it quickly. We must study carefully to evolve it further incrementally. Otherwise, an even bigger headache or disaster will happen.

2) " The quickest and most straightforward way to eliminate the need for any CG-NAT is to move to a bigger address space. ":

The obvious answer was IPv6. However, its performance after near two decades of deployment has not been convincing. EzIP is an alternative, requiring hardly any development, to address this need immediately.

3) " Until the cost (or pain) to stay on IPv4 is greater than the cost to move, we're going to see continued resistance to doing so. ":

This strategy is easily said than done. It reminds me of my system planning work for the old AT&T. At that time, Bell Operating Companies (BOCs) could be coerced to upgrade their facility by just gradually raising the cost of owning the old equipment by assuming fewer would be be used, while the newer version would cost less because growing number of deployments. Looking at resultant financial forecast, the BOC decisions were easy. Originally trained as a hardware radio engineer, I was totally stunned. But, it worked well under the regulated monopoly environment.

Fast forward by half a century, the Internet promotes distributed approaches. Few things can be controlled by limited couple parties. The decision of go or no-go is made by parties in the field who have their own respective considerations. Accumulated, they set the direction of the Internet. In this case, IPv6 has had the opportunity of over four decades of planning and nearly two decades of deployment. Its future growth rate is set by its own performance merits. No one can force its rate by persuasion tactic of any kind. Hoping so is wishful thinking which contributes to wasteful activities. So, we need realistic planning. Regards,

Abe (2024-01-12 18:42)

On 2024-01-12 01:34, Forrest Christian (List Account) wrote:

The problem isn't the quantity of "inside" CG-NAT address space. It's the existence of CG-NAT at all.

It doesn't matter if the available space is a /12 or a /4, you still need something to translate it to the public internet. The existence of that CG-NAT box is a thorn in every provider's side and every provider that has one wants to make it go away as quickly as possible.

The quickest and most straightforward way to eliminate the need for any CG-NAT is to move to a bigger address space. As I pointed out, IPv6 is already ready and proven to work so moving to IPv6 is a straightforward process technically. What isn't straightforward is convincing IPv4 users to move. Until the cost (or pain) to stay on IPv4 is greater than the cost to move, we're going to see continued resistance to doing so.

On Thu, Jan 11, 2024, 7:36 PM Abraham Y. Chen <aychen@avinta.com> wrote:

...

Hi, Forrest:

0) Thanks for your in-depth analysis.

1) However, my apologies for not presenting the EzIP concept clearer. That is, one way to look at the EzIP scheme is to substitute the current 100.64/10 netblock in the CG-NAT with 240/4. Everything else in the current CG-NAT setup stays unchanged. This makes each CG-NAT cluster 64 fold bigger. And, various capabilities become available.

Regards,

Abe (2024-01-11 22:35)

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virus-free.www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> <#m_814193715557979764_m_-2264817505018915121_m_-871507042037526857_m_-3709659627675338528_m_5461191486991014945_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Hi, Forrest: 1)    I have a question:     If I subscribe to IPv6, can I contact another similar subscriber to communicate (voice and data) directly between two homes in private like the dial-up modem operations in the PSTN? If so, is it available anywhere right now? Regards, Abe (2024-01-15 15:20)

Let me start with I think we're largely on the same page here.

The transition I see happening next is that the consumer traffic largely moves to IPv6 with no CG-NAT.  That is, if you're at home or on your phone watching video or doing social media or using whatever app is all the rage it's going to be over IPv6.

My point was largely that I believe that at some point the big consumer (not business) focused companies are going to realize they can use market forces to encourage the remaining IPv4-only eyeball networks to transition to support IPv6 connections from their customers.  I don't know if the timeframe is next year or 20 years from now,  but I do know the tech companies are very good at looking at the costs of maintaining backwards compatibility with old tech and figuring out ways to shed those costs when they no longer make sense. If they can utilize various forms of pressure to make this happen quicker, I fully expect them to do so.

Inside a business network,  or even at home,  it wouldn't surprise me if we're both long gone before IPv4 is eradicated.   I know there is going to be a lot of IPv4 in my network for years to come just because of product lifecycles.

As far as "CG-NAT-like" technologies go (meaning NAT in a provider's network), they're unfortunately going to be with us for a long time since customers seem to want to be able to reach everything regardless of the IPv4 or IPv6 status of the customer or endpoint.   I also expect that most service providers with business customers are going to be carrying both IPv4 and IPv6 for a long time, not to mention doing a fair bit of translation in both directions.

I won't go deeply into the whole IPv4 vs IPv6 discussion for a business customer's "public address" because the topic is far too nuanced for an email to cover them accurately.   Suffice it to say that I don't disagree that business today largely wants IPv4, but some seem to be becoming aware of what IPv6 can do and are looking to have both options available to them, at least outside the firewall.

On Sat, Jan 13, 2024, 2:04 AM Brett O'Hara <brett@fj.com.au> wrote:

Ok you've triggered me on your point 2.  I'll address the elephant in the room.

IPv4 is never ever going away.

Right now consumer services are mostly (mobile, wireless, landline, wide generalization) are IPv6 capable.  Most consumer applications are ipv6 capable, Google, Facebook, etc.There is light at the very end of the tunnel that suggests that one day we won't have to deploy CGNAT444 for our consumers to get to content, we may only have to do NAT64 for them to get to the remaining Ipv4 Internet.  We're still working hard on removing our reliance on genuine ipv4 ranges to satisfy our customer needs, It's still a long way off, but it's coming.

Here's the current problem.  Enterprise doesn't need ipv6 or want ipv6.  You might be able to get away with giving CGNAT to your consumers, but your enterprise customer will not accept this. How will they terminate their remote users?  How will they do B2B with out inbound NAT?  Yes, there are solutions, but if you don't need to, why?  They pay good money, why can't they have real ipv4?  All their internal networks are IPv4 rfc1918.  They are happy with NAT.  Their application service providers are ipv4 only. Looking at the services I access for work things like SAP, SerivceNow, Office386, Sharepoint, Okta, Dayforce, Xero, and I'm sure many more, none can not be accessed on ipv6 alone..  Their internal network lifecycle is 10+ years.  They have no interest in trying new things or making new technology work without a solid financial reason and there is none for them implementing ipv6.   And guess where all the IP addresses we're getting back from our consumers are going?  Straight to our good margin enterprise customers and their application service providers.  Consumer CGNAT isn't solving problems, it's creating more.

The end of IPv4 isn't nigh, it's just privileged only.

PS When you solve that problem in 50 years time, I'll be one of those old fogey's keeping an IPv4 service alive as an example of "the old Internet" for those young whippersnappers to be amazed by.

Regards,    Brett

-- This email has been checked for viruses by Avast antivirus software. www.avast.com

On Mon, Jan 15, 2024, 1:21 PM Abraham Y. Chen <aychen@avinta.com> wrote:

If I subscribe to IPv6, can I contact another similar subscriber to communicate (voice and data) directly between two homes in private like the dial-up modem operations in the PSTN? If so, is it available anywhere right now?

Yes, if you have IPv6 service and I have IPv6 service, our IPv6 devices can talk directly to each other without needing any VPN or similar. And yes, this is available today. Note that just like the PSTN you might not want to do this without encryption and taking other security/safety steps. (Like the PSTN, the internet can be tapped).

Any host connected to a reasonably well peered ISP (e.g. NOT Cogent) with IPv6 should be able to communicate with any other such host so long as the administrative policies on both sides permit it. I have no difficulty directly reaching a variety of IPv6 hosts from the /48 in my home. However, it’s not like dial-up modem operations in the PSTN in that IP is an inherently connectionless packet switched service while modems were an inherently circuit switched connection oriented service. However, it does work like IPv4 used to work before NAT made everything horrible. Owen

On Jan 15, 2024, at 12:20, Abraham Y. Chen <aychen@avinta.com> wrote:

Hi, Forrest:

1) I have a question:

If I subscribe to IPv6, can I contact another similar subscriber to communicate (voice and data) directly between two homes in private like the dial-up modem operations in the PSTN? If so, is it available anywhere right now?

Regards,

Abe (2024-01-15 15:20)

...

Let me start with I think we're largely on the same page here.

The transition I see happening next is that the consumer traffic largely moves to IPv6 with no CG-NAT. That is, if you're at home or on your phone watching video or doing social media or using whatever app is all the rage it's going to be over IPv6.

My point was largely that I believe that at some point the big consumer (not business) focused companies are going to realize they can use market forces to encourage the remaining IPv4-only eyeball networks to transition to support IPv6 connections from their customers. I don't know if the timeframe is next year or 20 years from now, but I do know the tech companies are very good at looking at the costs of maintaining backwards compatibility with old tech and figuring out ways to shed those costs when they no longer make sense. If they can utilize various forms of pressure to make this happen quicker, I fully expect them to do so.

Inside a business network, or even at home, it wouldn't surprise me if we're both long gone before IPv4 is eradicated. I know there is going to be a lot of IPv4 in my network for years to come just because of product lifecycles.

As far as "CG-NAT-like" technologies go (meaning NAT in a provider's network), they're unfortunately going to be with us for a long time since customers seem to want to be able to reach everything regardless of the IPv4 or IPv6 status of the customer or endpoint. I also expect that most service providers with business customers are going to be carrying both IPv4 and IPv6 for a long time, not to mention doing a fair bit of translation in both directions.

I won't go deeply into the whole IPv4 vs IPv6 discussion for a business customer's "public address" because the topic is far too nuanced for an email to cover them accurately. Suffice it to say that I don't disagree that business today largely wants IPv4, but some seem to be becoming aware of what IPv6 can do and are looking to have both options available to them, at least outside the firewall.

On Sat, Jan 13, 2024, 2:04 AM Brett O'Hara <brett@fj.com.au <mailto:brett@fj.com.au>> wrote:

...

Ok you've triggered me on your point 2. I'll address the elephant in the room.

IPv4 is never ever going away.

Right now consumer services are mostly (mobile, wireless, landline, wide generalization) are IPv6 capable. Most consumer applications are ipv6 capable, Google, Facebook, etc.There is light at the very end of the tunnel that suggests that one day we won't have to deploy CGNAT444 for our consumers to get to content, we may only have to do NAT64 for them to get to the remaining Ipv4 Internet. We're still working hard on removing our reliance on genuine ipv4 ranges to satisfy our customer needs, It's still a long way off, but it's coming.

Here's the current problem. Enterprise doesn't need ipv6 or want ipv6. You might be able to get away with giving CGNAT to your consumers, but your enterprise customer will not accept this. How will they terminate their remote users? How will they do B2B with out inbound NAT? Yes, there are solutions, but if you don't need to, why? They pay good money, why can't they have real ipv4? All their internal networks are IPv4 rfc1918. They are happy with NAT. Their application service providers are ipv4 only. Looking at the services I access for work things like SAP, SerivceNow, Office386, Sharepoint, Okta, Dayforce, Xero, and I'm sure many more, none can not be accessed on ipv6 alone.. Their internal network lifecycle is 10+ years. They have no interest in trying new things or making new technology work without a solid financial reason and there is none for them implementing ipv6. And guess where all the IP addresses we're getting back from our consumers are going? Straight to our good margin enterprise customers and their application service providers. Consumer CGNAT isn't solving problems, it's creating more.

The end of IPv4 isn't nigh, it's just privileged only.

PS When you solve that problem in 50 years time, I'll be one of those old fogey's keeping an IPv4 service alive as an example of "the old Internet" for those young whippersnappers to be amazed by.

Regards, Brett

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virus-free.www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> <x-msg://12/#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

+1 From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei.com@nanog.org] On Behalf Of Brett O'Hara Sent: Saturday, January 13, 2024 1:04 PM To: Forrest Christian (List Account) <lists@packetflux.com> Cc: Chen, Abraham Y. <AYChen@alum.mit.edu>; NANOG <nanog@nanog.org> Subject: Re: One Can't Have It Both Ways Re: Streamline the CG-NAT Re: EzIP Re: IPv4 address block Ok you've triggered me on your point 2. I'll address the elephant in the room. IPv4 is never ever going away. Right now consumer services are mostly (mobile, wireless, landline, wide generalization) are IPv6 capable. Most consumer applications are ipv6 capable, Google, Facebook, etc.There is light at the very end of the tunnel that suggests that one day we won't have to deploy CGNAT444 for our consumers to get to content, we may only have to do NAT64 for them to get to the remaining Ipv4 Internet. We're still working hard on removing our reliance on genuine ipv4 ranges to satisfy our customer needs, It's still a long way off, but it's coming. Here's the current problem. Enterprise doesn't need ipv6 or want ipv6. You might be able to get away with giving CGNAT to your consumers, but your enterprise customer will not accept this. How will they terminate their remote users? How will they do B2B with out inbound NAT? Yes, there are solutions, but if you don't need to, why? They pay good money, why can't they have real ipv4? All their internal networks are IPv4 rfc1918. They are happy with NAT. Their application service providers are ipv4 only. Looking at the services I access for work things like SAP, SerivceNow, Office386, Sharepoint, Okta, Dayforce, Xero, and I'm sure many more, none can not be accessed on ipv6 alone.. Their internal network lifecycle is 10+ years. They have no interest in trying new things or making new technology work without a solid financial reason and there is none for them implementing ipv6. And guess where all the IP addresses we're getting back from our consumers are going? Straight to our good margin enterprise customers and their application service providers. Consumer CGNAT isn't solving problems, it's creating more. The end of IPv4 isn't nigh, it's just privileged only. PS When you solve that problem in 50 years time, I'll be one of those old fogey's keeping an IPv4 service alive as an example of "the old Internet" for those young whippersnappers to be amazed by. Regards, Brett On Sat, Jan 13, 2024 at 7:31 PM Forrest Christian (List Account) <lists@packetflux.com<mailto:lists@packetflux.com>> wrote: A couple of points: 1) There is less work needed to support IPv6 than your proposed solution. I'm not taking about 230/4. I'm talking about your EzIP overlay. 2) Assume that Google decided that they would no longer support IPv4 for any of their services at a specific date a couple of years in the future. That is, you either needed an IPv6 address or you couldn't reach Google, youtube, Gmail and the rest of the public services. I bet that in this scenario every eyeball provider in the country all of a sudden would be extremely motivated to deploy IPv6, even if the IPv4 providers end up natting their IPv4 customers to IPv6. I really expect something like this to be the next part of the end game for IPv4. Or stated differently: at some point someone with enough market power is going to basically say "enough is enough" and make the decision for the rest of us that IPv4 is effectively done on the public internet. The large tech companies all have a history of sunsetting things when it becomes a bigger problem to support than it's worth. Try getting a modern browser that works on 32 bit windows. Same with encryption protocols, Java in the browser, Shockwave and flash, and on and on. I see no reason why IPv4 should be any different. On Fri, Jan 12, 2024, 3:42 PM Abraham Y. Chen <aychen@avinta.com<mailto:aychen@avinta.com>> wrote: Hi, Forrest: 0) You put out more than one topic, all at one time. Allow me to address each briefly. 1) " The existence of that CG-NAT box is a thorn in every provider's side and every provider that has one wants to make it go away as quickly as possible. ": The feeling and desire are undeniable facts. However, the existing configuration was evolved from various considerations through a long time. There is a tremendous inertia accumulated on it. There is no magic bullet to get rid of it quickly. We must study carefully to evolve it further incrementally. Otherwise, an even bigger headache or disaster will happen. 2) " The quickest and most straightforward way to eliminate the need for any CG-NAT is to move to a bigger address space. ": The obvious answer was IPv6. However, its performance after near two decades of deployment has not been convincing. EzIP is an alternative, requiring hardly any development, to address this need immediately. 3) " Until the cost (or pain) to stay on IPv4 is greater than the cost to move, we're going to see continued resistance to doing so. ": This strategy is easily said than done. It reminds me of my system planning work for the old AT&T. At that time, Bell Operating Companies (BOCs) could be coerced to upgrade their facility by just gradually raising the cost of owning the old equipment by assuming fewer would be be used, while the newer version would cost less because growing number of deployments. Looking at resultant financial forecast, the BOC decisions were easy. Originally trained as a hardware radio engineer, I was totally stunned. But, it worked well under the regulated monopoly environment. Fast forward by half a century, the Internet promotes distributed approaches. Few things can be controlled by limited couple parties. The decision of go or no-go is made by parties in the field who have their own respective considerations. Accumulated, they set the direction of the Internet. In this case, IPv6 has had the opportunity of over four decades of planning and nearly two decades of deployment. Its future growth rate is set by its own performance merits. No one can force its rate by persuasion tactic of any kind. Hoping so is wishful thinking which contributes to wasteful activities. So, we need realistic planning. Regards, Abe (2024-01-12 18:42) On 2024-01-12 01:34, Forrest Christian (List Account) wrote: The problem isn't the quantity of "inside" CG-NAT address space. It's the existence of CG-NAT at all. It doesn't matter if the available space is a /12 or a /4, you still need something to translate it to the public internet. The existence of that CG-NAT box is a thorn in every provider's side and every provider that has one wants to make it go away as quickly as possible. The quickest and most straightforward way to eliminate the need for any CG-NAT is to move to a bigger address space. As I pointed out, IPv6 is already ready and proven to work so moving to IPv6 is a straightforward process technically. What isn't straightforward is convincing IPv4 users to move. Until the cost (or pain) to stay on IPv4 is greater than the cost to move, we're going to see continued resistance to doing so. On Thu, Jan 11, 2024, 7:36 PM Abraham Y. Chen <aychen@avinta.com<mailto:aychen@avinta.com>> wrote: Hi, Forrest: 0) Thanks for your in-depth analysis. 1) However, my apologies for not presenting the EzIP concept clearer. That is, one way to look at the EzIP scheme is to substitute the current 100.64/10 netblock in the CG-NAT with 240/4. Everything else in the current CG-NAT setup stays unchanged. This makes each CG-NAT cluster 64 fold bigger. And, various capabilities become available. Regards, Abe (2024-01-11 22:35) [https://s-install.avcdn.net/ipm/preview/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virus-free.www.avast.com<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>

Hi, Forrest: 1)    Re: Ur. Pt. 1): The initial deployment of EzIP overlay is only applying 240/4 to existing (IPv4 based) CG-NAT facility to become the overlaying RAN, plus upgrading RG-NATs (Routing / Residential NATs) to OpenWrt. So that none of the on-premises IoTs will sense any changes. I don't see how an upgrade of such equipment to IPv6 could be simpler and less work. Please elaborate. 2)    Re: Ur. Pt. 2):     Since the RAN still appear to be the original CG-NAT to the Internet through the same IPv4 link to the Internet core, services from Google, YouTube, etc. will not know something has changed either. 3)    " ... someone with enough market power is going to basically say "enough is enough"  ...  ":     We need to look at this transition with a "Divide and Conquer" perspective. That is, the CG-NAT and consequently the RAN are part of IAP (Internet Access Provider) facility. While Google, YouTube, etc. are ICPs (Internet Content Providers). Relatively speaking, the IAP is like the hardware part of a system, while ICP is the software. They are two separate parts when combined will provide the service that customers want. Normally, these two parts are separate businesses, although some may be under the same owner in some situations. The scenario that you are proposing is like back to the old Bell System days when AT&T decided everything. I am sure that Internet players will try very hard to avoid being labelled as such. Regards, Abe (2024-01-15 00:02) On 2024-01-13 03:30, Forrest Christian (List Account) wrote:

A couple of points:

1) There is less work needed to support IPv6 than your proposed solution.  I'm not taking about 230/4.  I'm talking about your EzIP overlay.

2) Assume that Google decided that they would no longer support IPv4 for any of their services at a specific date a couple of years in the future.  That is,  you either needed an IPv6 address or you couldn't reach Google, youtube, Gmail and the rest of the public services.  I bet that in this scenario every eyeball provider in the country all of a sudden would be extremely motivated to deploy IPv6, even if the IPv4 providers end up natting their IPv4 customers to IPv6.  I really expect something like this to be the next part of the end game for IPv4.

Or stated differently: at some point someone with enough market power is going to basically say "enough is enough" and make the decision for the rest of us that IPv4 is effectively done on the public internet.   The large tech companies all have a history of sunsetting things when it becomes a bigger problem to support than it's worth.  Try getting a modern browser that works on 32 bit windows.   Same with encryption protocols, Java in the browser,  Shockwave and flash, and on and on.

I see no reason why IPv4 should be any different.

On Fri, Jan 12, 2024, 3:42 PM Abraham Y. Chen <aychen@avinta.com> wrote:

Hi, Forrest:

0)    You put out more than one topic, all at one time. Allow me to address each briefly.

1)   "  The existence of that CG-NAT box is a thorn in every provider's side and every provider that has one wants to make it go away as quickly as possible.   ":

    The feeling and desire are undeniable facts. However, the existing configuration was evolved from various considerations through a long time. There is a tremendous inertia accumulated on it. There is no magic bullet to get rid of it quickly. We must study carefully to evolve it further incrementally. Otherwise, an even bigger headache or disaster will happen.

2) "  The quickest and most straightforward way to eliminate the need for any CG-NAT is to move to a bigger address space.  ":

    The obvious answer was IPv6. However, its performance after near two decades of deployment has not been convincing. EzIP is an alternative, requiring hardly any development, to address this need immediately.

3) "  Until the cost (or pain) to stay on IPv4 is greater than the cost to move,  we're going to see continued resistance to doing so.   ":

    This strategy is easily said than done. It reminds me of my system planning work for the old AT&T. At that time, Bell Operating Companies(BOCs) could be coerced to upgrade their facility by just gradually raising the cost of owning the old equipment by assuming fewer would be be used, while the newer version would cost less because growing number of deployments. Looking at resultant financial forecast, the BOC decisions were easy. Originally trained as a hardware radio engineer, I was totally stunned. But, it worked well under the regulated monopoly environment.

    Fast forward by half a century, the Internet promotes distributed approaches. Few things can be controlled by limited couple parties. The decision of go or no-go is made by parties in the field who have their own respective considerations. Accumulated, they set the direction of the Internet. In this case, IPv6 has had the opportunity of over four decades of planning and nearly two decades of deployment. Its future growth rate is set by its own performance merits. No one can force its rate by persuasion tactic of any kind. Hoping so is wishful thinking which contributes to wasteful activities. So, we need realistic planning.

Regards,

Abe (2024-01-12 18:42)

On 2024-01-12 01:34, Forrest Christian (List Account) wrote:

...

The problem isn't the quantity of "inside" CG-NAT address space.  It's the existence of CG-NAT at all.

It doesn't matter if the available space is a /12 or a /4, you still need something to translate it to the public internet.   The existence of that CG-NAT box is a thorn in every provider's side and every provider that has one wants to make it go away as quickly as possible.

The quickest and most straightforward way to eliminate the need for any CG-NAT is to move to a bigger address space.  As I pointed out, IPv6 is already ready and proven to work so moving to IPv6 is a straightforward process technically.  What isn't straightforward is convincing IPv4 users to move.  Until the cost (or pain) to stay on IPv4 is greater than the cost to move,  we're going to see continued resistance to doing so.

On Thu, Jan 11, 2024, 7:36 PM Abraham Y. Chen <aychen@avinta.com> wrote:

Hi, Forrest:

0)    Thanks for your in-depth analysis.

1)     However, my apologies for not presenting the EzIP concept clearer. That is, one way to look at the EzIP scheme is to substitute the current 100.64/10  netblock in the CG-NAT with 240/4. Everything else in the current CG-NAT setup stays unchanged. This makes each CG-NAT cluster 64 fold bigger. And, various capabilities become available.

Regards,

Abe (2024-01-11 22:35)

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virus-free.www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>

<#m_-2264817505018915121_m_-871507042037526857_m_-3709659627675338528_m_5461191486991014945_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

-- This email has been checked for viruses by Avast antivirus software. www.avast.com

Hi, Sronan: 1)     “Radio Access Network”:     Thanks for bringing this up. Being an RF engineer by training, I am aware of this terminology. However, how specific is its claimed applicable domain? 2)    I went to search on an acronym site and found a long list of expressions that abbreviate to RAN. It starts with Royal Australian Navy and Rainforest Action Network as the third. Then, Return Authorization Number is the fourth: https://www.acronymfinder.com/RAN.html 3)    In fact, "Regional Area Network" is about twentieth on it! So, unless there is some kind of Registered Trademark conflict, this probably is on my low priority to-do list for the time being. 4)     Of course, if you have any alternative to suggest, my ears are all yours. Regards, Abe (2024-01-15 18:48) On 2024-01-15 17:14, sronan@ronan-online.com wrote:

Please don’t use the term RAN, this acronym already has a very specific definition in the telecom/network space as “Radio Access Network.”

Shane

...

On Jan 15, 2024, at 5:12 PM, Abraham Y. Chen <aychen@avinta.com> wrote:

 Hi, Forrest:

1)    Re: Ur. Pt. 1):    The initial deployment of EzIP overlay is only applying 240/4 to existing (IPv4 based) CG-NAT facility to become the overlaying RAN, plus upgrading RG-NATs (Routing / Residential NATs) to OpenWrt. So that none of the on-premises IoTs will sense any changes. I don't see how an upgrade of such equipment to IPv6 could be simpler and less work. Please elaborate.

2)    Re: Ur. Pt. 2):     Since the RAN still appear to be the original CG-NAT to the Internet through the same IPv4 link to the Internet core, services from Google, YouTube, etc. will not know something has changed either.

3)    " ... someone with enough market power is going to basically say "enough is enough"  ...  ":

    We need to look at this transition with a "Divide and Conquer" perspective. That is, the CG-NAT and consequently the RAN are part of IAP (Internet Access Provider) facility. While Google, YouTube, etc. are ICPs (Internet Content Providers). Relatively speaking, the IAP is like the hardware part of a system, while ICP is the software. They are two separate parts when combined will provide the service that customers want. Normally, these two parts are separate businesses, although some may be under the same owner in some situations. The scenario that you are proposing is like back to the old Bell System days when AT&T decided everything. I am sure that Internet players will try very hard to avoid being labelled as such.

Regards,

Abe (2024-01-15 00:02)

On 2024-01-13 03:30, Forrest Christian (List Account) wrote:

...

A couple of points:

1) There is less work needed to support IPv6 than your proposed solution.  I'm not taking about 230/4.  I'm talking about your EzIP overlay.

2) Assume that Google decided that they would no longer support IPv4 for any of their services at a specific date a couple of years in the future. That is,  you either needed an IPv6 address or you couldn't reach Google, youtube, Gmail and the rest of the public services.  I bet that in this scenario every eyeball provider in the country all of a sudden would be extremely motivated to deploy IPv6, even if the IPv4 providers end up natting their IPv4 customers to IPv6. I really expect something like this to be the next part of the end game for IPv4.

Or stated differently: at some point someone with enough market power is going to basically say "enough is enough" and make the decision for the rest of us that IPv4 is effectively done on the public internet.   The large tech companies all have a history of sunsetting things when it becomes a bigger problem to support than it's worth.  Try getting a modern browser that works on 32 bit windows.   Same with encryption protocols, Java in the browser,  Shockwave and flash, and on and on.

I see no reason why IPv4 should be any different.

On Fri, Jan 12, 2024, 3:42 PM Abraham Y. Chen <aychen@avinta.com> wrote:

Hi, Forrest:

0)    You put out more than one topic, all at one time. Allow me to address each briefly.

1)   "  The existence of that CG-NAT box is a thorn in every provider's side and every provider that has one wants to make it go away as quickly as possible.   ":

    The feeling and desire are undeniable facts. However, the existing configuration was evolved from various considerations through a long time. There is a tremendous inertia accumulated on it. There is no magic bullet to get rid of it quickly. We must study carefully to evolve it further incrementally. Otherwise, an even bigger headache or disaster will happen.

2) "  The quickest and most straightforward way to eliminate the need for any CG-NAT is to move to a bigger address space.  ":

    The obvious answer was IPv6. However, its performance after near two decades of deployment has not been convincing. EzIP is an alternative, requiring hardly any development, to address this need immediately.

3) "  Until the cost (or pain) to stay on IPv4 is greater than the cost to move,  we're going to see continued resistance to doing so.   ":

    This strategy is easily said than done. It reminds me of my system planning work for the old AT&T. At that time, Bell Operating Companies(BOCs) could be coerced to upgrade their facility by just gradually raising the cost of owning the old equipment by assuming fewer would be be used, while the newer version would cost less because growing number of deployments. Looking at resultant financial forecast, the BOC decisions were easy. Originally trained as a hardware radio engineer, I was totally stunned. But, it worked well under the regulated monopoly environment.

    Fast forward by half a century, the Internet promotes distributed approaches. Few things can be controlled by limited couple parties. The decision of go or no-go is made by parties in the field who have their own respective considerations. Accumulated, they set the direction of the Internet. In this case, IPv6 has had the opportunity of over four decades of planning and nearly two decades of deployment. Its future growth rate is set by its own performance merits. No one can force its rate by persuasion tactic of any kind. Hoping so is wishful thinking which contributes to wasteful activities. So, we need realistic planning.

Regards,

Abe (2024-01-12 18:42)

On 2024-01-12 01:34, Forrest Christian (List Account) wrote:

...

The problem isn't the quantity of "inside" CG-NAT address space.  It's the existence of CG-NAT at all.

It doesn't matter if the available space is a /12 or a /4, you still need something to translate it to the public internet.   The existence of that CG-NAT box is a thorn in every provider's side and every provider that has one wants to make it go away as quickly as possible.

The quickest and most straightforward way to eliminate the need for any CG-NAT is to move to a bigger address space.  As I pointed out, IPv6 is already ready and proven to work so moving to IPv6 is a straightforward process technically.  What isn't straightforward is convincing IPv4 users to move.  Until the cost (or pain) to stay on IPv4 is greater than the cost to move,  we're going to see continued resistance to doing so.

On Thu, Jan 11, 2024, 7:36 PM Abraham Y. Chen <aychen@avinta.com> wrote:

Hi, Forrest:

0)    Thanks for your in-depth analysis.

1)     However, my apologies for not presenting the EzIP concept clearer. That is, one way to look at the EzIP scheme is to substitute the current 100.64/10 netblock in the CG-NAT with 240/4. Everything else in the current CG-NAT setup stays unchanged. This makes each CG-NAT cluster 64 fold bigger. And, various capabilities become available.

Regards,

Abe (2024-01-11 22:35)

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virus-free.www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>

<#m_-2264817505018915121_m_-871507042037526857_m_-3709659627675338528_m_5461191486991014945_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

-- This email has been checked for viruses by Avast antivirus software. www.avast.com

From what I gather, "EzIP" is just a fancy name for repurposing the 240/4 address space as RFC6598 shared address space for service providers and adding another gateway into a network to make it look like a new technology, nothing more. It does absolutely nothing more than what is already available and in use today. It's a solid NO from me, in case it's not already clear.

Regards, Christopher Hawker On Tue, 16 Jan 2024 at 11:16, <sronan@ronan-online.com> wrote:

The reality is your whole concept for EzIP is so impractical and so unlikely to be implemented by any service provider with half a clue, that I’m not sure why I would even try to explain to you why a Radio Access Network is relevant to the Internet. You obviously have decided you are smarter than everyone else on NANOG.

Shane

On Jan 15, 2024, at 6:46 PM, Abraham Y. Chen <aychen@avinta.com> wrote:

 Hi, Sronan:

1) “Radio Access Network”:

Thanks for bringing this up. Being an RF engineer by training, I am aware of this terminology. However, how specific is its claimed applicable domain?

2) I went to search on an acronym site and found a long list of expressions that abbreviate to RAN. It starts with Royal Australian Navy and Rainforest Action Network as the third. Then, Return Authorization Number is the fourth:

https://www.acronymfinder.com/RAN.html

3) In fact, "Regional Area Network" is about twentieth on it! So, unless there is some kind of Registered Trademark conflict, this probably is on my low priority to-do list for the time being. 4) Of course, if you have any alternative to suggest, my ears are all yours.

Regards,

Abe (2024-01-15 18:48)

On 2024-01-15 17:14, sronan@ronan-online.com wrote:

Please don’t use the term RAN, this acronym already has a very specific definition in the telecom/network space as “Radio Access Network.”

Shane

On Jan 15, 2024, at 5:12 PM, Abraham Y. Chen <aychen@avinta.com> <aychen@avinta.com> wrote:

 Hi, Forrest:

1) Re: Ur. Pt. 1): The initial deployment of EzIP overlay is only applying 240/4 to existing (IPv4 based) CG-NAT facility to become the overlaying RAN, plus upgrading RG-NATs (Routing / Residential NATs) to OpenWrt. So that none of the on-premises IoTs will sense any changes. I don't see how an upgrade of such equipment to IPv6 could be simpler and less work. Please elaborate.

2) Re: Ur. Pt. 2): Since the RAN still appear to be the original CG-NAT to the Internet through the same IPv4 link to the Internet core, services from Google, YouTube, etc. will not know something has changed either.

3) " ... someone with enough market power is going to basically say "enough is enough" ... ":

We need to look at this transition with a "Divide and Conquer" perspective. That is, the CG-NAT and consequently the RAN are part of IAP (Internet Access Provider) facility. While Google, YouTube, etc. are ICPs (Internet Content Providers). Relatively speaking, the IAP is like the hardware part of a system, while ICP is the software. They are two separate parts when combined will provide the service that customers want. Normally, these two parts are separate businesses, although some may be under the same owner in some situations. The scenario that you are proposing is like back to the old Bell System days when AT&T decided everything. I am sure that Internet players will try very hard to avoid being labelled as such.

Regards,

Abe (2024-01-15 00:02)

On 2024-01-13 03:30, Forrest Christian (List Account) wrote:

A couple of points:

1) There is less work needed to support IPv6 than your proposed solution. I'm not taking about 230/4. I'm talking about your EzIP overlay.

2) Assume that Google decided that they would no longer support IPv4 for any of their services at a specific date a couple of years in the future. That is, you either needed an IPv6 address or you couldn't reach Google, youtube, Gmail and the rest of the public services. I bet that in this scenario every eyeball provider in the country all of a sudden would be extremely motivated to deploy IPv6, even if the IPv4 providers end up natting their IPv4 customers to IPv6. I really expect something like this to be the next part of the end game for IPv4.

Or stated differently: at some point someone with enough market power is going to basically say "enough is enough" and make the decision for the rest of us that IPv4 is effectively done on the public internet. The large tech companies all have a history of sunsetting things when it becomes a bigger problem to support than it's worth. Try getting a modern browser that works on 32 bit windows. Same with encryption protocols, Java in the browser, Shockwave and flash, and on and on.

I see no reason why IPv4 should be any different.

On Fri, Jan 12, 2024, 3:42 PM Abraham Y. Chen <aychen@avinta.com> wrote:

...

Hi, Forrest:

0) You put out more than one topic, all at one time. Allow me to address each briefly.

1) " The existence of that CG-NAT box is a thorn in every provider's side and every provider that has one wants to make it go away as quickly as possible. ":

The feeling and desire are undeniable facts. However, the existing configuration was evolved from various considerations through a long time. There is a tremendous inertia accumulated on it. There is no magic bullet to get rid of it quickly. We must study carefully to evolve it further incrementally. Otherwise, an even bigger headache or disaster will happen.

2) " The quickest and most straightforward way to eliminate the need for any CG-NAT is to move to a bigger address space. ":

The obvious answer was IPv6. However, its performance after near two decades of deployment has not been convincing. EzIP is an alternative, requiring hardly any development, to address this need immediately.

3) " Until the cost (or pain) to stay on IPv4 is greater than the cost to move, we're going to see continued resistance to doing so. ":

This strategy is easily said than done. It reminds me of my system planning work for the old AT&T. At that time, Bell Operating Companies (BOCs) could be coerced to upgrade their facility by just gradually raising the cost of owning the old equipment by assuming fewer would be be used, while the newer version would cost less because growing number of deployments. Looking at resultant financial forecast, the BOC decisions were easy. Originally trained as a hardware radio engineer, I was totally stunned. But, it worked well under the regulated monopoly environment.

Fast forward by half a century, the Internet promotes distributed approaches. Few things can be controlled by limited couple parties. The decision of go or no-go is made by parties in the field who have their own respective considerations. Accumulated, they set the direction of the Internet. In this case, IPv6 has had the opportunity of over four decades of planning and nearly two decades of deployment. Its future growth rate is set by its own performance merits. No one can force its rate by persuasion tactic of any kind. Hoping so is wishful thinking which contributes to wasteful activities. So, we need realistic planning. Regards,

Abe (2024-01-12 18:42)

On 2024-01-12 01:34, Forrest Christian (List Account) wrote:

The problem isn't the quantity of "inside" CG-NAT address space. It's the existence of CG-NAT at all.

It doesn't matter if the available space is a /12 or a /4, you still need something to translate it to the public internet. The existence of that CG-NAT box is a thorn in every provider's side and every provider that has one wants to make it go away as quickly as possible.

The quickest and most straightforward way to eliminate the need for any CG-NAT is to move to a bigger address space. As I pointed out, IPv6 is already ready and proven to work so moving to IPv6 is a straightforward process technically. What isn't straightforward is convincing IPv4 users to move. Until the cost (or pain) to stay on IPv4 is greater than the cost to move, we're going to see continued resistance to doing so.

On Thu, Jan 11, 2024, 7:36 PM Abraham Y. Chen <aychen@avinta.com> wrote:

...

Hi, Forrest:

0) Thanks for your in-depth analysis.

1) However, my apologies for not presenting the EzIP concept clearer. That is, one way to look at the EzIP scheme is to substitute the current 100.64/10 netblock in the CG-NAT with 240/4. Everything else in the current CG-NAT setup stays unchanged. This makes each CG-NAT cluster 64 fold bigger. And, various capabilities become available.

Regards,

Abe (2024-01-11 22:35)

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virus-free.www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> <#m_9148722380134320577_m_-2264817505018915121_m_-871507042037526857_m_-3709659627675338528_m_5461191486991014945_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

It was always about using 240/4 as shared service provider space, just a roundabout way of doing it. You can call a horse a horse, or you can call it "an animal that pulls a wagon which carries people and items from A to B". At the end of the day, it's still a horse. Regards, Christopher Hawker On Tue, 16 Jan 2024 at 14:00, Brandon Jackson <bjackson@napshome.net> wrote:

If I remember correctly, quite a few years ago, "EzIP" was something else entirely.

I vaguely remember them talking about having some kind of extended IPv4 address or to use an extension header or something like that. It was something that would essentially require the entire Internet to be reworked in order to work. Kind of like this, but even more so because these modified bastardized packets would be sent across the DFZ.

And it seems now it's morphed into simply opening up and reusing 240/4

Brandon Jackson bjackson@napshome.net

On Mon, Jan 15, 2024, 19:47 Christopher Hawker <chris@thesysadmin.au> wrote:

...

From what I gather, "EzIP" is just a fancy name for repurposing the 240/4 address space as RFC6598 shared address space for service providers and adding another gateway into a network to make it look like a new technology, nothing more. It does absolutely nothing more than what is already available and in use today. It's a solid NO from me, in case it's not already clear.

Regards, Christopher Hawker

On Tue, 16 Jan 2024 at 11:16, <sronan@ronan-online.com> wrote:

...

The reality is your whole concept for EzIP is so impractical and so unlikely to be implemented by any service provider with half a clue, that I’m not sure why I would even try to explain to you why a Radio Access Network is relevant to the Internet. You obviously have decided you are smarter than everyone else on NANOG.

Shane

On Jan 15, 2024, at 6:46 PM, Abraham Y. Chen <aychen@avinta.com> wrote:

 Hi, Sronan:

1) “Radio Access Network”:

Thanks for bringing this up. Being an RF engineer by training, I am aware of this terminology. However, how specific is its claimed applicable domain?

2) I went to search on an acronym site and found a long list of expressions that abbreviate to RAN. It starts with Royal Australian Navy and Rainforest Action Network as the third. Then, Return Authorization Number is the fourth:

https://www.acronymfinder.com/RAN.html

3) In fact, "Regional Area Network" is about twentieth on it! So, unless there is some kind of Registered Trademark conflict, this probably is on my low priority to-do list for the time being. 4) Of course, if you have any alternative to suggest, my ears are all yours.

Regards,

Abe (2024-01-15 18:48)

On 2024-01-15 17:14, sronan@ronan-online.com wrote:

Please don’t use the term RAN, this acronym already has a very specific definition in the telecom/network space as “Radio Access Network.”

Shane

On Jan 15, 2024, at 5:12 PM, Abraham Y. Chen <aychen@avinta.com> <aychen@avinta.com> wrote:

 Hi, Forrest:

1) Re: Ur. Pt. 1): The initial deployment of EzIP overlay is only applying 240/4 to existing (IPv4 based) CG-NAT facility to become the overlaying RAN, plus upgrading RG-NATs (Routing / Residential NATs) to OpenWrt. So that none of the on-premises IoTs will sense any changes. I don't see how an upgrade of such equipment to IPv6 could be simpler and less work. Please elaborate.

2) Re: Ur. Pt. 2): Since the RAN still appear to be the original CG-NAT to the Internet through the same IPv4 link to the Internet core, services from Google, YouTube, etc. will not know something has changed either.

3) " ... someone with enough market power is going to basically say "enough is enough" ... ":

We need to look at this transition with a "Divide and Conquer" perspective. That is, the CG-NAT and consequently the RAN are part of IAP (Internet Access Provider) facility. While Google, YouTube, etc. are ICPs (Internet Content Providers). Relatively speaking, the IAP is like the hardware part of a system, while ICP is the software. They are two separate parts when combined will provide the service that customers want. Normally, these two parts are separate businesses, although some may be under the same owner in some situations. The scenario that you are proposing is like back to the old Bell System days when AT&T decided everything. I am sure that Internet players will try very hard to avoid being labelled as such.

Regards,

Abe (2024-01-15 00:02)

On 2024-01-13 03:30, Forrest Christian (List Account) wrote:

A couple of points:

1) There is less work needed to support IPv6 than your proposed solution. I'm not taking about 230/4. I'm talking about your EzIP overlay.

2) Assume that Google decided that they would no longer support IPv4 for any of their services at a specific date a couple of years in the future. That is, you either needed an IPv6 address or you couldn't reach Google, youtube, Gmail and the rest of the public services. I bet that in this scenario every eyeball provider in the country all of a sudden would be extremely motivated to deploy IPv6, even if the IPv4 providers end up natting their IPv4 customers to IPv6. I really expect something like this to be the next part of the end game for IPv4.

Or stated differently: at some point someone with enough market power is going to basically say "enough is enough" and make the decision for the rest of us that IPv4 is effectively done on the public internet. The large tech companies all have a history of sunsetting things when it becomes a bigger problem to support than it's worth. Try getting a modern browser that works on 32 bit windows. Same with encryption protocols, Java in the browser, Shockwave and flash, and on and on.

I see no reason why IPv4 should be any different.

On Fri, Jan 12, 2024, 3:42 PM Abraham Y. Chen <aychen@avinta.com> wrote:

...

Hi, Forrest:

0) You put out more than one topic, all at one time. Allow me to address each briefly.

1) " The existence of that CG-NAT box is a thorn in every provider's side and every provider that has one wants to make it go away as quickly as possible. ":

The feeling and desire are undeniable facts. However, the existing configuration was evolved from various considerations through a long time. There is a tremendous inertia accumulated on it. There is no magic bullet to get rid of it quickly. We must study carefully to evolve it further incrementally. Otherwise, an even bigger headache or disaster will happen.

2) " The quickest and most straightforward way to eliminate the need for any CG-NAT is to move to a bigger address space. ":

The obvious answer was IPv6. However, its performance after near two decades of deployment has not been convincing. EzIP is an alternative, requiring hardly any development, to address this need immediately.

3) " Until the cost (or pain) to stay on IPv4 is greater than the cost to move, we're going to see continued resistance to doing so. ":

This strategy is easily said than done. It reminds me of my system planning work for the old AT&T. At that time, Bell Operating Companies (BOCs) could be coerced to upgrade their facility by just gradually raising the cost of owning the old equipment by assuming fewer would be be used, while the newer version would cost less because growing number of deployments. Looking at resultant financial forecast, the BOC decisions were easy. Originally trained as a hardware radio engineer, I was totally stunned. But, it worked well under the regulated monopoly environment.

Fast forward by half a century, the Internet promotes distributed approaches. Few things can be controlled by limited couple parties. The decision of go or no-go is made by parties in the field who have their own respective considerations. Accumulated, they set the direction of the Internet. In this case, IPv6 has had the opportunity of over four decades of planning and nearly two decades of deployment. Its future growth rate is set by its own performance merits. No one can force its rate by persuasion tactic of any kind. Hoping so is wishful thinking which contributes to wasteful activities. So, we need realistic planning. Regards,

Abe (2024-01-12 18:42)

On 2024-01-12 01:34, Forrest Christian (List Account) wrote:

The problem isn't the quantity of "inside" CG-NAT address space. It's the existence of CG-NAT at all.

It doesn't matter if the available space is a /12 or a /4, you still need something to translate it to the public internet. The existence of that CG-NAT box is a thorn in every provider's side and every provider that has one wants to make it go away as quickly as possible.

The quickest and most straightforward way to eliminate the need for any CG-NAT is to move to a bigger address space. As I pointed out, IPv6 is already ready and proven to work so moving to IPv6 is a straightforward process technically. What isn't straightforward is convincing IPv4 users to move. Until the cost (or pain) to stay on IPv4 is greater than the cost to move, we're going to see continued resistance to doing so.

On Thu, Jan 11, 2024, 7:36 PM Abraham Y. Chen <aychen@avinta.com> wrote:

...

Hi, Forrest:

0) Thanks for your in-depth analysis.

1) However, my apologies for not presenting the EzIP concept clearer. That is, one way to look at the EzIP scheme is to substitute the current 100.64/10 netblock in the CG-NAT with 240/4. Everything else in the current CG-NAT setup stays unchanged. This makes each CG-NAT cluster 64 fold bigger. And, various capabilities become available.

Regards,

Abe (2024-01-11 22:35)

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virus-free.www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> <#m_1923872705776870626_m_2399351866883432329_m_9148722380134320577_m_-2264817505018915121_m_-871507042037526857_m_-3709659627675338528_m_5461191486991014945_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Interesting and thank you for sharing. KARIM From: Abraham Y. Chen <aychen@avinta.com> Sent: January 10, 2024 7:35 AM To: KARIM MEKKAOUI <amekkaoui@mektel.ca> Cc: nanog@nanog.org; Chen, Abraham Y. <AYChen@alum.MIT.edu> Subject: 202401100645.AYC Re: IPv4 address block Importance: High Hi, Karim: 1) If you have control of your own equipment (I presume that your business includes IAP - Internet Access Provider, since you are asking to buy IPv4 blocks.), you can get a large block of reserved IPv4 address for free by disabling the program codes in your current facility that has been disabling the use of 240/4 netblock. Please have a look at the below whitepaper. Utilized according to the outlined disciplines, this is a practically unlimited resources. It has been known that multi-national conglomerates have been using it without announcement. So, you can do so stealthily according to the proposed mechanism which establishes uniform practices, just as well. https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf 2) Being an unorthodox solution, if not controversial, please follow up with me offline. Unless, other NANOGers express their interests. Regards, Abe (2024-01-10 07:34 EST) On 2024-01-07 22:46, KARIM MEKKAOUI wrote: Hi Nanog Community Any idea please on the best way to buy IPv4 blocs and what is the price? Thank you KARIM [https://s-install.avcdn.net/ipm/preview/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virus-free.www.avast.com<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>

Tom Beecher wrote on 10/01/2024 15:12:

( Unless people are transferring RFC1918 space these days, in which case who wants to make me an offer for 10/8? )

I'm taking bids on 256.0.0.0/8, which is every bit as publicly routable as 240/4. Nick

There's a whole bunch of software out there that makes certain assumptions about allowable ranges. That is, they've been compiled with a header that defines ..

Of course correct. It really depends on the vendor / software / versions in an environment. A lot of vendors removed that years ago, because frankly a lot of large networks have been using 240/4 as pseudo RFC1918 for years. Others have worked with smaller vendors and open source projects to do the same. It's consistently a topic in the debates about 240/4 reclassification. On Wed, Jan 10, 2024 at 10:45 AM Michael Butler <imb@protected-networks.net> wrote:

On 1/10/24 10:12, Tom Beecher wrote:

...

Karim-

Please be cautious about this advice, and understand the full context.

240/4 is still classified as RESERVED space. While you would certainly be able to use it on internal networks if your equipment supports it, you cannot use it as publicly routable space. There have been many proposals over the years to reclassify 240/4, but that has not happened, and is unlikely to at any point in the foreseeable future.

While you may be able to get packets from point A to B in a private setting, using them might also be .. a challenge.

There's a whole bunch of software out there that makes certain assumptions about allowable ranges. That is, they've been compiled with a header that defines ..

#define IN_BADCLASS(i) (((in_addr_t)(i) & 0xf0000000) == 0xf0000000)

Michael

Dave Taht wrote on 11/01/2024 09:40:

240/4 is intensely routable and actually used in routers along hops inside multiple networkstoday, but less so as a destination.

240/4 is fine for private use, but the OP needed publicly routable IP addresses, which 240/4 are definitely not. Nick

There really is no reason for 240/4 to remain "reserved". I share Dave's views, I would like to see 240/4 reclassified as unicast space and 2 x /8s delegated to each RIR with the /8s for AFRINIC to be held until their issues have been resolved. Reclassifying this space, would add 10+ years onto the free pool for each RIR. Looking at the APNIC free pool, I would estimate there is about 1/6th of a /8 pool available for delegation, another 1/6th reserved. Reclassification would see available pool volumes return to pre-2010 levels. https://www.apnic.net/manage-ip/ipv4-exhaustion/ In the IETF draft that was co-authored by Dave as part of the IPv4 Unicast Extensions Project, a very strong case was presented to convert this space. https://www.ietf.org/archive/id/draft-schoen-intarea-unicast-240-00.html Regards, Christopher Hawker On Thu, 11 Jan 2024 at 20:40, Dave Taht <dave.taht@gmail.com> wrote:

On Wed, Jan 10, 2024 at 11:06 AM Tom Beecher <beecher@beecher.cc> wrote:

...

...

There's a whole bunch of software out there that makes certain assumptions about allowable ranges. That is, they've been compiled with a header that defines ..

Of course correct. It really depends on the vendor / software / versions in an environment. A lot of vendors removed that years ago, because frankly a lot of large networks have been using 240/4 as pseudo RFC1918 for years. Others have worked with smaller vendors and open source projects to do the same.

It's consistently a topic in the debates about 240/4 reclassification.

There's debates still? I gave up. After making 240/4 and 0/8 work across all of linux and BSD and all the daemons besides bird (which refused the patch , I took so much flack that I decided I would just work on other things. So much of that flack was BS - like if you kill the checks in the OS the world will end - that didn't happen. Linux has had these two address ranges just work for over 5 years now.

240/4 is intensely routable and actually used in routers along hops inside multiple networks today, but less so as a destination.

I would really like, one day, to see it move from reserved to unicast status, officially. I would have loved it if 0/8 was used by a space RIR, behind CGNAT, for starters, but with a plan towards making it routable. I am not holding my breath.

The principal accomplishment of the whole unicast extensions project was to save a nanosecond across all the servers in the world on every packet by killing the useless 0/8 check. That patch paid for itself the first weekend after that linux kernel deployed. It is the simplest, most elegant, and most controversial patch I have ever written.

https://news.ycombinator.com/item?id=20430096

...

On Wed, Jan 10, 2024 at 10:45 AM Michael Butler <

imb@protected-networks.net> wrote:

...

...

On 1/10/24 10:12, Tom Beecher wrote:

...

Karim-

Please be cautious about this advice, and understand the full context.

240/4 is still classified as RESERVED space. While you would certainly be able to use it on internal networks if your equipment supports it, you cannot use it as publicly routable space. There have been many proposals over the years to reclassify 240/4, but that has not

happened,

...

...

and is unlikely to at any point in the foreseeable future.

While you may be able to get packets from point A to B in a private setting, using them might also be .. a challenge.

There's a whole bunch of software out there that makes certain assumptions about allowable ranges. That is, they've been compiled with a header that defines ..

#define IN_BADCLASS(i) (((in_addr_t)(i) & 0xf0000000) == 0xf0000000)

Michael

-- 40 years of net history, a couple songs: https://www.youtube.com/watch?v=D9RGX6QFm5E Dave Täht CSO, LibreQos

Saku Ytti <saku@ytti.fi> writes:

We don't need to extend IPv4, we need to figure out why we are in this dual-stack mess, which was never intended, and how to get out of it.

Few have figured out how to reliably deliver IPv4 over a IPv6 network, and customers need IPv4 more than they need IPv6. There is no easy way for an ISP to provide a /48 with an IPv4 /32 on top, either using tunnelling or translation, and have the majority of CPEs just work. DNS64 and NAT64 are successful for mobile operators, and handsets generally handle everything seamlessly. The wired world is not so lucky.

We don't need to extend IPv4, we need to figure out why we are in this dual-stack mess, which was never intended, and how to get out of it.

it was intended. it was the original transition plan. like many things about ipv6, it could have been a bit better thought out. randy

On 12/01/24 06:41, Giorgio Bonfiglio via NANOG wrote:

...

...

We don't need to extend IPv4, we need to figure out why we are in this dual-stack mess, which was never intended, and how to get out of it.

it was intended. it was the original transition plan. like many things about ipv6, it could have been a bit better thought out.

What was not intended though was the transition period to last for 30 years and counting… If things go reasonably well we’re gonna be dual stack for another 20, at least.

I like your optimism...

Hi, Randy: 1)    " ... dual-stack mess ... it was intended. it was the original transition plan. ":     Perhaps you are too young to realize that the original IPv6 plan was not designed to be backward compatible to IPv4, and Dual-Stack was developed (through some iterations) to bridge the transition between IPv4 and IPv6? You may want to spend a few moments to read some history on this. Regards, Abe (2024-01-12 17:34) On 2024-01-12 00:11, Randy Bush wrote:

...

We don't need to extend IPv4, we need to figure out why we are in this dual-stack mess, which was never intended, and how to get out of it. it was intended. it was the original transition plan. like many things about ipv6, it could have been a bit better thought out.

randy

-- This email has been checked for viruses by Avast antivirus software. www.avast.com

Is that a faux pas? On 13 January 2024 9:15:11 am ACDT, Randy Bush <randy@psg.com> wrote:

...

Perhaps you are too young to realize that the original IPv6 plan was not designed to be backward compatible to IPv4, and Dual-Stack was developed (through some iterations) to bridge the transition between IPv4 and IPv6? You may want to spend a few moments to read some history on this.

ROFL!!! if there is anything you can do to make me that young, you could have a very lucrative career outside of the internet.

hint: unfortunately i already had grey hair in the '90s and was in the room for all this, and spent a few decades managing to get some of the worst stupidities (TLA, NLA, ...) pulled out of the spec. at iij, we rolled ipv6 on the backbone in 1997.

randy

I go into my cave to finish the todo list for the week, and I come out to see Mr. Chen : - Telling Randy Bush he should "read some history" on IPv6 - Implying that Vint Cerf ever said anything about EzIP

Fairly impressive sequence of self ownage.

but it sure is a change to have a n00b troll. i was really looking forward to it making me young. sigh. randy

Implementing EzIP, as Forrest mentioned 3 days ago, has far more challenges than implementing IPv6. It will also cause far more incompatibilities when it comes to routing traffic between a network which has implemented it and one that hasn't. It also sounds like another version of NAT, non-routable addresses behind a box which allows other networks to access it via a gateway. The implementation of IPv6 can be done within weeks for smaller organisations and networks and in less than a year for larger organisations, and the best part is that virtually every hardware vendor already supports it. The majority of our problems can be solved by using existing protocols, in my view we don't need another. If anything it only detracts from what we should be working towards. Further, over the last three days you've changed the subject line of the thread at least 12 times. Can you please stop changing it because every time you do, it starts a new thread and makes it rather difficult to keep track of the discussion. I also don't believe I'm the first one to raise this either. https://i.imgur.com/7WIzwEP.png Regards, Christopher Hawker On Sat, 13 Jan 2024 at 23:35, Abraham Y. Chen <aychen@avinta.com> wrote:

Hi, Tom:

1) " ... Implying that Vint Cerf ever said anything about EzIP ... ":

FYI - Please see the below copy of a partial eMail thread. Bold, red colored and Italicized letters are to focus on the topic.

***********

InternetPolicy@eList.ISOC.org eMail thread

On 2021-10-18 16:34, Abraham Y. Chen wrote:

Dear Vint:

Yes, this is one perspective for visualizing the EzIP proposal.

Thanks,

Abe (2021-10-18 16:33 EDT)

Re: [Internet Policy] 202110180800.AYC Re: Platform self-regulation

On 2021-10-18 10:39, *vinton cerf* wrote:

sounds like *eZIP* is basically an *overlay* network.

*v*

On Mon, Oct 18, 2021 at 8:33 AM Abraham Y. Chen via InternetPolicy < internetpolicy@elists.isoc.org> wrote:

Hi, Scott:

0) Thanks for your research.

1) Both SCION (based on my best understanding) and our work named EzIP (phonetic for Easy IPv4) are technical solutions for improving the Internet from its foundation level (the architecture). There are many implications with such schemes including social and legal if one looks into them.

2) As I responded to Gene's questions (See my eMail with subject line tag: "202110171756.AYC"), the SCION approach implements certain restrictions ......

************

2) Prior to the above, we were quite unsure about what our team was doing. So, I purposely avoided having any contact with Vint. We had been describing the EzIP's RANs (Regional Area Networks) as "kites floating in the air over an geographic area anchored by an IPv4 address based cord". Although visually clear, it was too wordy. By using one concise word, *overlay*, Vint eloquently classified the EzIP network in terminology sense. It opened our eyes about what were the implications of EzIP and what could be the interactions with respect to the existing Internet, because EzIP was a non-interfering enhancement to an existing system which was a text book case of systems engineering.

Hope the above clears the air.

Regards,

Abe (2024-01-13 07:34)

On 2024-01-12 19:24, Tom Beecher wrote:

I go into my cave to finish the todo list for the week, and I come out to see Mr. Chen : - Telling Randy Bush he should "read some history" on IPv6 - Implying that Vint Cerf ever said anything about EzIP

Fairly impressive sequence of self ownage.

On Fri, Jan 12, 2024 at 5:46 PM Randy Bush <randy@psg.com> wrote:

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virus-free.www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> <#m_-4880440387061228082_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Vint told you the same thing other people have been telling you for years. You don't seem to name drop anyone else. Weird. Respectfully, you have no credibility in this area. I happened to notice this gem re-reading your draft last night, A.1.1. T1a Initiates a Session Request towards T4a

T1a sends a session request to SPR4 that serves T4a by a plain IP packet with header as in Figure 5, to RG1. There is no TCP port number in this IP header yet.

That's a curious statement there at the end. Let's continue though. A.1.2. RG1 Forwards the Packet to SPR1

RG1, allowing be masqueraded by T1a, relays the packet toward SPR1 by assigning the TCP Source port number, 3N, to T1a, with a header as in Figure 6,. Note that the suffix "N" denotes the actual TCP port number assigned by the RG1's RG-NAT. This could assume multiple values, each represents a separate communications session that T1a is engaged in. A corresponding entry is created in the RG1 state table for handling the reply packet from the Destination site. Since T4a's TCP port number is not known yet, it is filled with all 1's.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 |Version|IHL (6)|Type of Service| Total Length (24) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Source Host Number (240.0.0.0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Destination Host Number (69.41.190.148) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Source Port (3N) | Destination Port (All 1's) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 6 TCP/IP Header: From RG1 to SPR1

Wait a second.. what is a 'TCP/IP header'? A.1.5. T4a Replies to SPR4

T4a interchanges the Source and Destination identifications in the incoming TCP/IP packet to create a header as in Figure 9, for the reply packet to SPR4.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 |Version|IHL (6)|Type of Service| Total Length (24) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Source Host Number (240.0.0.10) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Destination Host Number (69.41.190.110) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Source Port (10C) | Destination Port (0C) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 9 TCP/IP Header: From T4a to SPR4

Oh my.. you actually meant it. The draft authors don't appear to understand that TCP headers and IP headers **are not the same thing**. I would suggest reviewing RFC 791 ( IPv4 ) , and RFC 793 / 9293 ( TCP, original and updated ). On Sat, Jan 13, 2024 at 7:35 AM Abraham Y. Chen <aychen@avinta.com> wrote:

Hi, Tom:

1) " ... Implying that Vint Cerf ever said anything about EzIP ... ":

FYI - Please see the below copy of a partial eMail thread. Bold, red colored and Italicized letters are to focus on the topic.

***********

InternetPolicy@eList.ISOC.org eMail thread

On 2021-10-18 16:34, Abraham Y. Chen wrote:

Dear Vint:

Yes, this is one perspective for visualizing the EzIP proposal.

Thanks,

Abe (2021-10-18 16:33 EDT)

Re: [Internet Policy] 202110180800.AYC Re: Platform self-regulation

On 2021-10-18 10:39, *vinton cerf* wrote:

sounds like *eZIP* is basically an *overlay* network.

*v*

On Mon, Oct 18, 2021 at 8:33 AM Abraham Y. Chen via InternetPolicy < internetpolicy@elists.isoc.org> wrote:

Hi, Scott:

0) Thanks for your research.

1) Both SCION (based on my best understanding) and our work named EzIP (phonetic for Easy IPv4) are technical solutions for improving the Internet from its foundation level (the architecture). There are many implications with such schemes including social and legal if one looks into them.

2) As I responded to Gene's questions (See my eMail with subject line tag: "202110171756.AYC"), the SCION approach implements certain restrictions ......

************

2) Prior to the above, we were quite unsure about what our team was doing. So, I purposely avoided having any contact with Vint. We had been describing the EzIP's RANs (Regional Area Networks) as "kites floating in the air over an geographic area anchored by an IPv4 address based cord". Although visually clear, it was too wordy. By using one concise word, *overlay*, Vint eloquently classified the EzIP network in terminology sense. It opened our eyes about what were the implications of EzIP and what could be the interactions with respect to the existing Internet, because EzIP was a non-interfering enhancement to an existing system which was a text book case of systems engineering.

Hope the above clears the air.

Regards,

Abe (2024-01-13 07:34)

On 2024-01-12 19:24, Tom Beecher wrote:

I go into my cave to finish the todo list for the week, and I come out to see Mr. Chen : - Telling Randy Bush he should "read some history" on IPv6 - Implying that Vint Cerf ever said anything about EzIP

Fairly impressive sequence of self ownage.

On Fri, Jan 12, 2024 at 5:46 PM Randy Bush <randy@psg.com> wrote:

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virus-free.www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> <#m_9068981657915465318_m_898116838406432442_m_-7063806684299367540_m_-462970855676450446_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Hi, Warren: 1)    "  not intended to be endorsement…":     Fully agreed. 2)    "Implying that it is is disingenuous…   ":     Again, I fully agree. 3)    Note that I only stated "It opened our eyes about what were the implications of EzIP ...   ". It was an education moment that was more than we could expect. Regards, Abe (2024-01-15 17:04) On 2024-01-13 19:50, Warren Kumari wrote:

On Sat, Jan 13, 2024 at 9:48 AM, Tom Beecher <beecher@beecher.cc> wrote:

Vint told you the same thing other people have been telling you for years. You don't seem to name drop anyone else. Weird.

Indeed — Vint made an observation, but this was not intended to be endorsement…

Implying that it is is disingenuous…

W

Respectfully, you have no credibility in this area. I happened to notice this gem re-reading your draft last night,

A.1.1. T1a Initiates a Session Request towards T4a

T1a sends a session request to SPR4 that serves T4a by a plain IP packet with header as in Figure 5, to RG1. There is no TCP port number in this IP header yet.

That's a curious statement there at the end. Let's continue though.

A.1.2. RG1 Forwards the Packet to SPR1

RG1, allowing be masqueraded by T1a, relays the packet toward SPR1 by assigning the TCP Source port number, 3N, to T1a, with a header as in Figure 6,. Note that the suffix "N" denotes the actual TCP port number assigned by the RG1's RG-NAT. This could assume multiple values, each represents a separate communications session that T1a is engaged in. A corresponding entry is created in the RG1 state table for handling the reply packet from the Destination site. Since T4a's TCP port number is not known yet, it is filled with all 1's.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 |Version|IHL (6)|Type of Service| Total Length (24) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Source Host Number (240.0.0.0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Destination Host Number (69.41.190.148) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Source Port (3N) | Destination Port (All 1's) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 6 TCP/IP Header: From RG1 to SPR1

Wait a second.. what is a 'TCP/IP header'?

A.1.5. T4a Replies to SPR4

T4a interchanges the Source and Destination identifications in the incoming TCP/IP packet to create a header as in Figure 9, for the reply packet to SPR4.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 |Version|IHL (6)|Type of Service| Total Length (24) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Source Host Number (240.0.0.10) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Destination Host Number (69.41.190.110) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Source Port (10C) | Destination Port (0C) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 9 TCP/IP Header: From T4a to SPR4

Oh my.. you actually meant it.

The draft authors don't appear to understand that TCP headers and IP headers **are not the same thing**.

I would suggest reviewing RFC 791 ( IPv4 ) , and RFC 793 / 9293 ( TCP, original and updated ).

On Sat, Jan 13, 2024 at 7:35 AM Abraham Y. Chen <aychen@avinta.com <mailto:aychen@avinta.com>> wrote:

Hi, Tom:

1)        " ...  Implying that Vint Cerf ever said anything about EzIP ... ":

    FYI - Please see the below copy of a partial eMail thread. Bold, red colored and Italicized letters are to focus on the topic.

***********

InternetPolicy@eList.ISOC.org <mailto:InternetPolicy@eList.ISOC.org>eMail thread

On 2021-10-18 16:34, Abraham Y. Chen wrote:

Dear Vint:

Yes, this is one perspective for visualizing the EzIP proposal.

Thanks,

Abe (2021-10-18 16:33 EDT)

 Re: [Internet Policy] 202110180800.AYC Re: Platform self-regulation

 On 2021-10-18 10:39, */vinton cerf/* wrote:

sounds like /*eZIP*/is basically an */overlay/*network.

/*v*/

On Mon, Oct 18, 2021 at 8:33 AM Abraham Y. Chen via InternetPolicy <internetpolicy@elists.isoc.org <mailto:internetpolicy@elists.isoc.org>> wrote:

Hi, Scott:

 0)    Thanks for your research.

 1)    Both SCION (based on my best understanding) and our work named EzIP (phonetic for Easy IPv4) are technical solutions for improving the Internet from its foundation level (the architecture). There are many implications with such schemes including social and legal if one looks into them.

 2)    As I responded to Gene's questions (See my eMail with subject line tag: "202110171756.AYC"), the SCION approach implements certain restrictions ......

************

2)    Prior to the above, we were quite unsure about what our team was doing. So, I purposely avoided having any contact with Vint. We had been describing the EzIP's RANs (Regional Area Networks) as "kites floating in the air over an geographic area anchored by an IPv4 address based cord". Although visually clear, it was too wordy. By using one concise word, */overlay/*, Vint eloquently classified the EzIP network in terminology sense. It opened our eyes about what were the implications of EzIP and what could be the interactions with respect to the existing Internet, because EzIP was a non-interfering enhancement to an existing system which was a text book case of systems engineering.

Hope the above clears the air.

Regards,

Abe (2024-01-13 07:34)

On 2024-01-12 19:24, Tom Beecher wrote:

...

I go into my cave to finish the todo list for the week, and I come out to see Mr. Chen : - Telling Randy Bush he should "read some history" on IPv6 - Implying that Vint Cerf ever said anything about EzIP

Fairly impressive sequence of self ownage.

On Fri, Jan 12, 2024 at 5:46 PM Randy Bush <randy@psg.com <mailto:randy@psg.com>> wrote:

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virus-free.www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>

-- This email has been checked for viruses by Avast antivirus software. www.avast.com

Yo Abraham! On Sat, 13 Jan 2024 07:35:09 -0500 "Abraham Y. Chen" <aychen@avinta.com> wrote:

    FYI - Please see the below copy of a partial eMail thread. Bold, red colored and Italicized letters are to focus on the topic.

Uh, you realize many of us never see your red or italics? RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin

It appears that Randy Bush <randy@psg.com> said:

...

Some of us still use pine$B!D(B

i thought most pine users had moved to mutt

Some, but pine (now called alpine) is still actively maintained and does some things better than mutt, particularly if you want to keep track of multiple inboxes on different servers.

randy, who uses wanderlust under emacs :)

Hi, Randy: 1)   " ... unfortunately i already had grey hair in the '90s and was in the room for all this,  ...  ":     My apologies! For an uninitiated, I misread your message as if IPv6 was originally designed with a plan to assure smooth transition from IPv4. Regards, Abe (2024-01-14 23:17) On 2024-01-12 17:45, Randy Bush wrote:

...

Perhaps you are too young to realize that the original IPv6 plan was not designed to be backward compatible to IPv4, and Dual-Stack was developed (through some iterations) to bridge the transition between IPv4 and IPv6? You may want to spend a few moments to read some history on this. ROFL!!! if there is anything you can do to make me that young, you could have a very lucrative career outside of the internet.

hint: unfortunately i already had grey hair in the '90s and was in the room for all this, and spent a few decades managing to get some of the worst stupidities (TLA, NLA, ...) pulled out of the spec. at iij, we rolled ipv6 on the backbone in 1997.

randy

-- This email has been checked for viruses by Avast antivirus software. www.avast.com

Hi, Christopher" 1)    "  IPv6 is designed to replace IPv4.  ":     Correct. But, this is not like Ten Commandments that God gave to his children. Even such had not worked out in most cases. In real life, technical backward compatibility is the only known approach to achieve graceful replacement of the old. Failing to observe such discipline, one should not blame others for the disappointment in the transition. I am an outsider to the Internet development history. But, the overall appearance at this moment is that somehow IPv6 design failed to properly execute the backward compatibility requirement. So, IPv6 replacing IPv4 is not given. 2)    Allow me to share with you an almost parallel event in the PSTN, to illustrate how tough is to achieve the replacement of a working service, even under an environment with very strict backward compatibility disicpline:     A.    The Decadic (rotary) Dialing (DD) technique worked well on the telephone loop to a certain limit of distance for many years that enabled the automatic telephone switching systems. But, it could not go beyond the CO (Central Office).     B.    So, Bell Labs studied the use of DTMF (Dual Tone Multi-Frequency) or commonly known as Touch-Tone as trademarked in US, etc. The work started in mid 1940s.     c.    By late 1960s, working demos became available. During the mid-1970s, it was deployed across the Bell System (and beyond upon requests from other countries).     D.    With end-to-end signally capability of the DTMF signalling, a lot of services such as remote purchase, airline status checking , etc.,grew drastically.     E.    However, DTMF was a complete technology from Decadic Dialing and most phones in the field were still the latter type. COs had to install dual function line cards on the loop that subscriber liked to enjoy the DTMF capability. Obviously, the dual function line cards costed more than that of the basic DD version.     F.    Initially, AT&T offered the DTMF service for free (well, covered by the rental of the new phone) to encourage that adoption. Then, they raised the monthly service rate for lines still requiring DD receiver hoping to gracefully forcing the subscribes to wean from using DD phones.     G.    Guess what, the inertia of the huge DD phones out there in the field accumulated through near one century made the strategy impossible. That is, many subscribers would rather to pay one extra dollar or so a month to enjoy having the old DD phone around, either to avoid paying a new DTMF phone or just for the antique look of the DD phone. This also created a nightmare of three types (DD, DTMF and combined) line cards in the CO.     H.    As this went on, a version of phone with DTMF dial pad but sending out DD pulses appeared on the open market (thanks to the deregulation / break up the Bell System). Such novelty phones really gave phone companies a hard time about the transition plan.     I.    In the meantime, IC technology advanced to have single chip capable of both dialing techniques (even further integrated other traditional line card functions onto the same chip) making the transition plan moot.     J    Nowadays, almost every line card type chip handles DTMF as advertised. But, if you try a DD phone on it, chances are, it works anyway!     K. You may see some parallelism between the above and the current IPv4 / IPv6 transition issues. Regards, Abe (2024-01-15 12:37) On 2024-01-15 00:15, Christopher Hawker wrote:

To my knowledge IPv6 is designed to replace IPv4. Anyone, feel free to correct me if I'm wrong. There are just short of 4.3 billion IPv4 addresses, where the number of IPv6 addresses is 39 digits long.

Regards, Christopher Hawker

On Mon, 15 Jan 2024 at 15:18, Abraham Y. Chen <aychen@avinta.com> wrote:

Hi, Randy:

1)   " ... unfortunately i already had grey hair in the '90s and was in the room for all this, ...  ":

    My apologies! For an uninitiated, I misread your message as if IPv6 was originally designed with a plan to assure smooth transition from IPv4.

Regards,

Abe (2024-01-14 23:17)

On 2024-01-12 17:45, Randy Bush wrote:

...

...

Perhaps you are too young to realize that the original IPv6 plan was not designed to be backward compatible to IPv4, and Dual-Stack was developed (through some iterations) to bridge the transition between IPv4 and IPv6? You may want to spend a few moments to read some history on this.

ROFL!!! if there is anything you can do to make me that young, you could have a very lucrative career outside of the internet.

hint: unfortunately i already had grey hair in the '90s and was in the room for all this, and spent a few decades managing to get some of the worst stupidities (TLA, NLA, ...) pulled out of the spec. at iij, we rolled ipv6 on the backbone in 1997.

randy

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virus-free.www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>

<#m_854094815002427858_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

-- This email has been checked for viruses by Avast antivirus software. www.avast.com

Yes, some folks made Bell very umm... blue at times. Indeed I remember a Touch Tone fee on our bills until the 90's.  In fact, at one point I couldn't believe it was still a charge, as rotary phones had largely been replaced either as a choice or through attrition. Consumers WANTED Touch Tone.  There didn't NEED to be a "strategy" to eliminate pulse dialing, as it cost the Baby Bells nothing to support it.  After deregulation the appearance of 3rd party devices with a DTMF pad and a pule/tone switch wasn't to help customers work around this "scheme" of AT&T.  The 3rd parties, in general, wanted to produce inexpensive sets that featured a pulse option for those people/areas stuck in the past.  You couldn't do that inexpensively trying to replicate the clunky rotary dial, and again, no one/few WANTed them. I get the whole desire to promote EzIP as the greatest thing since NAT itself, but fabricating a bizarre hot take on the implementation of Touch Tone/DTMF as an attempted parallel to IPv6 vs IPv4 is kinda "out there".  The *corrected* history of Jay's actual does draw parallels, but more as a tale of how some people will do anything to save $1 (a month) even if the tech is highly beneficial. Danny Messano On Jan 15, 2024 at 14:12 -0500, Jay Hennigan <jay@west.net>, wrote:

On 1/15/24 09:37, Abraham Y. Chen wrote:

...

2)    Allow me to share with you an almost parallel event in the PSTN, to illustrate how tough is to achieve the replacement of a working service, even under an environment with very strict backward compatibility disicpline:

    A.    The Decadic (rotary) Dialing (DD) technique worked well on the telephone loop to a certain limit of distance for many years that enabled the automatic telephone switching systems. But, it could not go beyond the CO (Central Office).

    B.    So, Bell Labs studied the use of DTMF (Dual Tone Multi-Frequency) or commonly known as Touch-Tone as trademarked in US, etc. The work started in mid 1940s.

Actually, Bell had a multifrequency interoffice signaling system long before Touch-Tone was introduced to the public. Many of us old-timers were *very* familiar with this, much to the discontent of the Bell System.

...

    F.    Initially, AT&T offered the DTMF service for free (well, covered by the rental of the new phone) to encourage that adoption. Then, they raised the monthly service rate for lines still requiring DD receiver hoping to gracefully forcing the subscribes to wean from using DD phones.

In the early days of deployment, DTMF was not free. It was typically $1 more per month. IIRC, there was at one time an upcharge for 12-button vs. 10-button Touch-Tone pads. I have never seen a tariff with an upcharge for pulse dialing.

...

    G.    Guess what, the inertia of the huge DD phones out there in the field accumulated through near one century made the strategy impossible. That is, many subscribers would rather to pay one extra dollar or so a month to enjoy having the old DD phone around, either to avoid paying a new DTMF phone or just for the antique look of the DD phone. This also created a nightmare of three types (DD, DTMF and combined) line cards in the CO.

With step-by-step, XY, or panel offices the DTMF receiver was an add-on that buffered the digits and outpulsed them at rotary dial speed. Pulse dialing always worked. Crossbar was also an add-on but with a crossbar marker the delay of converting to pulse was avoided. By the time ESS came around both pulse and DTMF were built in.

Again, when and where was there ever an upcharge for pulse dialing?

...

    H.    As this went on, a version of phone with DTMF dial pad but sending out DD pulses appeared on the open market (thanks to the deregulation / break up the Bell System). Such novelty phones really gave phone companies a hard time about the transition plan.

The purpose of these phones was actually the opposite. It allowed a "modern" keypad-equipped phone to function on older lines not equipped with a Touch-Tone receiver. In GTE territory with Strowger switching, the digits from DTMF phones were buffered in the CO and outpulsed as rotary dialing. Bang out the number with Touch-Tone and you could hear the tick-tick of the digits being sent while you waited.

These days people get upset with post-dial delay of more than a couple of seconds. It used to be substantially more, especially with interoffice calls.

...

    I.    In the meantime, IC technology advanced to have single chip capable of both dialing techniques (even further integrated other traditional line card functions onto the same chip) making the transition plan moot.

TTBOMK, every common BORSCHT chip accepts both.

...

    J    Nowadays, almost every line card type chip handles DTMF as advertised. But, if you try a DD phone on it, chances are, it works anyway!

Yes, because TTBOMK, telco central offices have always accepted pulse dialing and still do. SIP ATAs, on the other hand, mostly don't, with the exception of some older Grandstream units.

-- Jay Hennigan - jay@west.net Network Engineering - CCIE #7880 503 897-8550 - WB6RDV

Hi, Owen: 0)   Thanks for sorting out my vague memory, citing some consumer electronics evolution history and an excellent overview of the current IPv4/IPv6 landscape. 1)    I believe that consumer electronics including PC related products and services are in a separate category from the IPv4 to IPv6 transition considerations. The latter is part of global communications systems that backward compatibility should be regarded a given requirement. The former normally plays out by free market force such as consumer preference which are highly influenced by marketing banners and changes with time. (For example, the vacuum tube stereo amplifiers and vinyl records recently came back in force, after so many years of obsolescent. However, going either direction was not a concern of most, except a few audio enthusiasts.)  Maintaining smooth daily operation of the latter while going through the evolution is very important for everyone. Short of such, the process will be frustratingly hard to predict. 2)   " ....  In the case of the DTMF transition, ...  AT&T could simply have shipped replacement phones with instructions for returning the older phone and done a retrofit operation if they really wanted to drive the transition.":     Correct, because back then, the station instruments were on long term lease from Bell Operating Companies. Even so, CO equipment readiness and the economics (Although DTMF shortened each subscriber dialing session almost by ~90% which was a big operation saving for the COs, subscriber could not sense, therefore did not care for the upgrade from DD.)  of such a big replacement process had to be carefully considered. With the break-up of the Bell System and the consequent abundance of CPE products on the market, the window of opportunity went by before anyone realized. 3)    The diversity of the Internet constituencies as you outlined make the transition from IPv4 to IPv6 an even more challenging event. I believe that the current general consensus of coexistence with Dual-Stack bridging the two should have settled the debates.  From now on, everyone should focus on his own passion. The continued efforts of persuading others to move one way or the other are counter-productive from an overall perspective. Regards, Abe (2024-01-19 12:20) On 2024-01-19 05:26, Owen DeLong wrote:

...

On Jan 15, 2024, at 09:37, Abraham Y. Chen <aychen@avinta.com> wrote:

Hi, Christopher"

1)    "  IPv6 is designed to replace IPv4.  ":

    Correct. But, this is not like Ten Commandments that God gave to his children. Even such had not worked out in most cases. In real life, technical backward compatibility is the only known approach to achieve graceful replacement of the old. Failing to observe such discipline, one should not blame others for the disappointment in the transition. I am an outsider to the Internet development history. But, the overall appearance at this moment is that somehow IPv6 design failed to properly execute the backward compatibility requirement. So, IPv6 replacing IPv4 is not given.

This isn’t entirely true… Cassette tapes were not particularly backwards compatible with LPs or 8-tracks. CDs were not backwards compatible with LPs, Casettes, or 8-tracks. iPods/etc. were not backwards compatible with any of the above.

USB-C is not backwards compatible with Lightning is not backwards compatible with Dock.

What I think has been shown is that the new needs to provide something compelling to the user being forced to migrate in order to motivate them to suffer the cost and inconvenience. Unfortunately, between NAT and Microsoft, instead of demand for an end-to-end network solution, we have consumers that have come to accept, nay expect the degraded level of service that is Windows and the Natternet that we have today. Application developers have all coded to this lowest possible state of network capability, and even written code which breaks absent NAT in some cases (I’m pointing at you Philips Hue).

For a little while, there was a bunch of free porn available on IPv6-only that some hoped would drive IPv6 adoption. Unfortunately, all it really drove was a large number of IPv4-only free porn sites.

Other apps that were supposed to be v6-only and thus drive adoption included IPSEC (rapidly back ported as a terrible hack on v4, not only reducing the incentive to migrate to v6, but giving IPSEC a horrible reputation for complexity and dysfunction in the process because of how hacky the v4 implementation has to be) and DHCP-PD (which remains IPv6-only, but failure to put forth standard mechanisms for the DHCP server to communicate the necessary delegation data to the router that need to forward the delegated prefixes reduced the utility of that particular solution so far).

...

2)    Allow me to share with you an almost parallel event in the PSTN, to illustrate how tough is to achieve the replacement of a working service, even under an environment with very strict backward compatibility disicpline:

    A.    The Decadic (rotary) Dialing (DD) technique worked well on the telephone loop to a certain limit of distance for many years that enabled the automatic telephone switching systems. But, it could not go beyond the CO (Central Office).

    B.    So, Bell Labs studied the use of DTMF (Dual Tone Multi-Frequency) or commonly known as Touch-Tone as trademarked in US, etc. The work started in mid 1940s.

    c.    By late 1960s, working demos became available. During the mid-1970s, it was deployed across the Bell System (and beyond upon requests from other countries).

    D.    With end-to-end signally capability of the DTMF signalling, a lot of services such as remote purchase, airline status checking , etc.,grew drastically.

    E.    However, DTMF was a complete technology from Decadic Dialing and most phones in the field were still the latter type. COs had to install dual function line cards on the loop that subscriber liked to enjoy the DTMF capability. Obviously, the dual function line cards costed more than that of the basic DD version.

    F.    Initially, AT&T offered the DTMF service for free (well, covered by the rental of the new phone) to encourage that adoption. Then, they raised the monthly service rate for lines still requiring DD receiver hoping to gracefully forcing the subscribes to wean from using DD phones.

Actually, I recall that if you wanted DTMF capability on your line, you had to pay extra for a time, then when they decided to deprecate DD, they dropped that surcharge. I don’t remember ever having to pay extra for DD, but I do remember getting notices telling me that they were turning off “pulse dialing” as of some particular date.

This led to amusing solutions like phones you could buy at Radio Shack and similar with an easily accessible switch that allowed you to call whatever service you wanted using pulse dialing, then flip the switch and use DTMF to talk to said service.

...

    G.    Guess what, the inertia of the huge DD phones out there in the field accumulated through near one century made the strategy impossible. That is, many subscribers would rather to pay one extra dollar or so a month to enjoy having the old DD phone around, either to avoid paying a new DTMF phone or just for the antique look of the DD phone. This also created a nightmare of three types (DD, DTMF and combined) line cards in the CO.

    H.    As this went on, a version of phone with DTMF dial pad but sending out DD pulses appeared on the open market (thanks to the deregulation / break up the Bell System). Such novelty phones really gave phone companies a hard time about the transition plan.

The Carterfone decision was one of the best things to ever happen to the telephone system in the united states. The courts do occasionally get something right.

...

    I.    In the meantime, IC technology advanced to have single chip capable of both dialing techniques (even further integrated other traditional line card functions onto the same chip) making the transition plan moot.

    J    Nowadays, almost every line card type chip handles DTMF as advertised. But, if you try a DD phone on it, chances are, it works anyway!

    K. You may see some parallelism between the above and the current IPv4 / IPv6 transition issues.

Some, but not a lot. In the case of the DTMF transition, the network and handsets were all under the central control of a single provider at a time when they could have forced the change if they really wanted to. After all, nobody was going to cancel their phone service altogether (or such a small fraction of subscribers as to count as a rounding error anyway) over the issue and AT&T could simply have shipped replacement phones with instructions for returning the older phone and done a retrofit operation if they really wanted to drive the transition.

For better (mostly) and worse (sometimes), there is no such central organization in control of the internet. Instead, there are multiple competing interest groups with various incentives in different directions around whether or not to adopt IPv6.

Enterprise is mostly disincentivized because most enterprises don’t really want an end-to-end internet and prefer the degraded state of their users that exists at this time. While that same degraded service can be provided in IPv6, if you don’t want the advantages of IPv6 and an end-to-end network, there’s really little advantage and a lot of cost to implementing it in an enterprise scenario. Google’s dug in stance on DHCPv6 on Android is definitely not helping that situation.

Content providers mostly don’t care, though the larger ones recognize the necessity and the most advanced ones have actually implemented v6-only networks with v4 translators at the edge where necessary.

CDNs are providing a great service and mostly dual-stacking the consumer-facing side of their services while offering to reach origin content via either protocol, thus allowing content providers to operate mono stack in either protocol while reaching customers over both protocols.

Eyeball ISPs vary, with the largest ones being very motivated to get their customers dependence on v4 reduced as much as possible.

Universities are a mixed bag, some pushing forward ahead of the game and many thinking “We’ve got enough IPv4 addresses for our needs for the next 200 years, what do we need with this v6 stuff?”

Backbone providers are mostly dual-stack and mostly don’t care. Running 2 stacks isn’t significantly worse than running 1 stack for most of them.

Mobile operators (cellular) are in the same boat with the larger eyeball ISPs.

Consumers mostly don’t want to know that IP, whether v4 or v6 exists, they just want their MTyouTickBookTwit. If the porn and the cat videos keep working, they don’t care what protocol it’s delivered over.

I’m sure there are constituencies I’ve left out here, but I think this covers most cases.

Owen

...

Regards,

Abe (2024-01-15 12:37)

On 2024-01-15 00:15, Christopher Hawker wrote:

...

To my knowledge IPv6 is designed to replace IPv4. Anyone, feel free to correct me if I'm wrong. There are just short of 4.3 billion IPv4 addresses, where the number of IPv6 addresses is 39 digits long.

Regards, Christopher Hawker

On Mon, 15 Jan 2024 at 15:18, Abraham Y. Chen <aychen@avinta.com> wrote:

Hi, Randy:

1)   " ... unfortunately i already had grey hair in the '90s and was in the room for all this, ...  ":

    My apologies! For an uninitiated, I misread your message as if IPv6 was originally designed with a plan to assure smooth transition from IPv4.

Regards,

Abe (2024-01-14 23:17)

On 2024-01-12 17:45, Randy Bush wrote:

...

...

Perhaps you are too young to realize that the original IPv6 plan was not designed to be backward compatible to IPv4, and Dual-Stack was developed (through some iterations) to bridge the transition between IPv4 and IPv6? You may want to spend a few moments to read some history on this.

ROFL!!! if there is anything you can do to make me that young, you could have a very lucrative career outside of the internet.

hint: unfortunately i already had grey hair in the '90s and was in the room for all this, and spent a few decades managing to get some of the worst stupidities (TLA, NLA, ...) pulled out of the spec. at iij, we rolled ipv6 on the backbone in 1997.

randy

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virus-free.www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>

<x-msg://17/#m_854094815002427858_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

-- This email has been checked for viruses by Avast antivirus software. www.avast.com

On Jan 19, 2024, at 09:21, Charles Polisher <chas@chasmo.org> wrote:

Owen DeLong wrote:

...

Some, but not a lot. In the case of the DTMF transition, the network and handsets were all under the central control of a single provider at a time when they could have forced the change if they really wanted to. After all, nobody was going to cancel their phone service altogether (or such a small fraction of subscribers as to count as a rounding error anyway) over the issue and AT&T could simply have shipped replacement phones with instructions for returning the older phone and done a retrofit operation if they really wanted to drive the transition.

True, yet there's a missing piece to that description: ROI. In the regulated environment with a mandated X% Return On Invest- ment (X ≈ 15 IIRC) a bigger expense pie was a better pie because a bigger expense pie meant a bigger return. This was an inexorable force that influenced every substantive decision. An expanding rate base was the One True Path to advancing against the demon competitors: AT&T and other RBOCs.

You’re missing the fact that this particular set of events predates the formation of RBOCS or competitors in general. There was AT&T, there was GTE, and there were a handful of other ILECs sprinkled around the country, but each had 100% territorial exclusivity and monopoly and AT&T at the time was pretty much the only LD carrier, period.

In the Bell System setting, before and after Divestiture, a perpetual and costly migration from IPv4 to IPv6 with all the attendant cost burdens would have been well tolerated, even welcomed, in the "C Suite" anyways.

Absolutely, I’m actually surprised that the DTMF forced conversion and its attendant cost wasn’t foisted on the unsuspecting public, TBH. I really don’t understand how AT&T missed that opportunity. Sure, it would have lowered costs long term to a small extent, but the handset replacement process alone would have been a huge cost for several years. Let’s face it, those old AT&T phones were rock solid and in a pinch you could use one as a forging hammer. ;-) Owen

Wow... There is some serious learning about the internet to be done here! When Randy was deploying IPv6 across the IIJ backbone, I was running around in kindergarten. I didn't even know what the internet was back then. Amazing what can happen in 26 years... Regards, Christopher Hawker On Sat, 13 Jan 2024 at 09:35, Abraham Y. Chen <aychen@avinta.com> wrote:

Hi, Randy:

1) " ... dual-stack mess ... it was intended. it was the original transition plan. ":

Perhaps you are too young to realize that the original IPv6 plan was not designed to be backward compatible to IPv4, and Dual-Stack was developed (through some iterations) to bridge the transition between IPv4 and IPv6? You may want to spend a few moments to read some history on this.

Regards,

Abe (2024-01-12 17:34)

On 2024-01-12 00:11, Randy Bush wrote:

We don't need to extend IPv4, we need to figure out why we are in this dual-stack mess, which was never intended, and how to get out of it.

it was intended. it was the original transition plan. like many things about ipv6, it could have been a bit better thought out.

randy

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virus-free.www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> <#m_-2764172948748324147_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Christopher Hawker wrote on 11/01/2024 10:54:

Reclassifying this space, would add 10+ years onto the free pool for each RIR

on this point: prior to RIR depletion, the annual global run-rate on /8s measured by IANA was ~13 per annum. So that suggests that 240/4 would provide a little more than 1Y of consumption, assuming no demand back-pressure, which seems an unlikely assumption. Nick

+1 to the Christopher comment

On 11-Jan-2024, at 16:24, chris@thesysadmin.au wrote:

There really is no reason for 240/4 to remain "reserved". I share Dave's views, I would like to see 240/4 reclassified as unicast space and 2 x /8s delegated to each RIR with the /8s for AFRINIC to be held until their issues have been resolved.

Reclassifying this space, would add 10+ years onto the free pool for each RIR. Looking at the APNIC free pool, I would estimate there is about 1/6th of a /8 pool available for delegation, another 1/6th reserved. Reclassification would see available pool volumes return to pre-2010 levels.

https://www.apnic.net/manage-ip/ipv4-exhaustion/

In the IETF draft that was co-authored by Dave as part of the IPv4 Unicast Extensions Project, a very strong case was presented to convert this space.

https://www.ietf.org/archive/id/draft-schoen-intarea-unicast-240-00.html

Regards, Christopher Hawker

On Thu, 11 Jan 2024 at 20:40, Dave Taht <dave.taht@gmail.com <mailto:dave.taht@gmail.com>> wrote:

...

On Wed, Jan 10, 2024 at 11:06 AM Tom Beecher <beecher@beecher.cc <mailto:beecher@beecher.cc>> wrote:

...

...

There's a whole bunch of software out there that makes certain assumptions about allowable ranges. That is, they've been compiled with a header that defines ..

Of course correct. It really depends on the vendor / software / versions in an environment. A lot of vendors removed that years ago, because frankly a lot of large networks have been using 240/4 as pseudo RFC1918 for years. Others have worked with smaller vendors and open source projects to do the same.

It's consistently a topic in the debates about 240/4 reclassification.

There's debates still? I gave up. After making 240/4 and 0/8 work across all of linux and BSD and all the daemons besides bird (which refused the patch , I took so much flack that I decided I would just work on other things. So much of that flack was BS - like if you kill the checks in the OS the world will end - that didn't happen. Linux has had these two address ranges just work for over 5 years now.

240/4 is intensely routable and actually used in routers along hops inside multiple networks today, but less so as a destination.

I would really like, one day, to see it move from reserved to unicast status, officially. I would have loved it if 0/8 was used by a space RIR, behind CGNAT, for starters, but with a plan towards making it routable. I am not holding my breath.

The principal accomplishment of the whole unicast extensions project was to save a nanosecond across all the servers in the world on every packet by killing the useless 0/8 check. That patch paid for itself the first weekend after that linux kernel deployed. It is the simplest, most elegant, and most controversial patch I have ever written.

https://news.ycombinator.com/item?id=20430096

...

On Wed, Jan 10, 2024 at 10:45 AM Michael Butler <imb@protected-networks.net <mailto:imb@protected-networks.net>> wrote:

...

On 1/10/24 10:12, Tom Beecher wrote:

...

Karim-

Please be cautious about this advice, and understand the full context.

240/4 is still classified as RESERVED space. While you would certainly be able to use it on internal networks if your equipment supports it, you cannot use it as publicly routable space. There have been many proposals over the years to reclassify 240/4, but that has not happened, and is unlikely to at any point in the foreseeable future.

While you may be able to get packets from point A to B in a private setting, using them might also be .. a challenge.

There's a whole bunch of software out there that makes certain assumptions about allowable ranges. That is, they've been compiled with a header that defines ..

#define IN_BADCLASS(i) (((in_addr_t)(i) & 0xf0000000) == 0xf0000000)

Michael

-- 40 years of net history, a couple songs: https://www.youtube.com/watch?v=D9RGX6QFm5E Dave Täht CSO, LibreQos

On Thu, Jan 11, 2024 at 12:26 PM Tom Beecher <beecher@beecher.cc> wrote:

Christopher-

...

Reclassifying this space, would add 10+ years onto the free pool for each RIR. Looking at the APNIC free pool, I would estimate there is about 1/6th of a /8 pool available for delegation, another 1/6th reserved. Reclassification would see available pool volumes return to pre-2010 levels.

Citing Nick Hilliard from another reply, this is an incorrect statement.

...

on this point: prior to RIR depletion, the annual global run-rate on /8s measured by IANA was ~13 per annum. So that suggests that 240/4 would provide a little more than 1Y of consumption, assuming no demand back-pressure, which seems an unlikely assumption.

...

I share Dave's views, I would like to see 240/4 reclassified as unicast space and 2 x /8s delegated to each RIR with the /8s for AFRINIC to be held until their issues have been resolved.

This has been discussed at great length at IETF. The consensus on the question has been consistent for many years now; doing work to free up 12-ish months of space doesn't make much sense

Thought that 12 month argument was purest BS in light of all the events since 2011. We have been "out" of IPv4 space for many years now, and there is a functioning market for IPv4 space that seems to be serving the purpose. 240/4 is only marginally useful today, but useful it is.

when IPv6 exists, along with plenty of transition/translation mechanisms. Unless someone is able to present new arguments that change the current consensus, it's not going to happen.

Instead, bigcos like google and amazon have been able to squat on 240/4 and take advantage of it for 5+ years now. I do kind of hope others are using it up in the same ways they are. Consensus, no. Just the few, like my team, that looked clearly at the future internet's needs getting shouted down by those in power over there. We cited many other arguments in favor of opening it up. There are rumblings far outside the realm of the ietf. I was once naive enough to consider the internet a vast, global, shared, and beloved space with resources that needed to be conserved and spread to and for all mankind. And while I still do feel that, our existing bureaucracies and gatekeepers have seemingly infinite power to say no, to even simple improvements to how the internet could work. There is no reason whatsoever for 240/4 to remain "reserved". There are plausible debates as to how it should be used, but rfc1918-style only benefits the few.

On Thu, Jan 11, 2024 at 5:54 AM Christopher Hawker <chris@thesysadmin.au> wrote:

...

There really is no reason for 240/4 to remain "reserved". I share Dave's views, I would like to see 240/4 reclassified as unicast space and 2 x /8s delegated to each RIR with the /8s for AFRINIC to be held until their issues have been resolved.

Reclassifying this space, would add 10+ years onto the free pool for each RIR. Looking at the APNIC free pool, I would estimate there is about 1/6th of a /8 pool available for delegation, another 1/6th reserved. Reclassification would see available pool volumes return to pre-2010 levels.

https://www.apnic.net/manage-ip/ipv4-exhaustion/

In the IETF draft that was co-authored by Dave as part of the IPv4 Unicast Extensions Project, a very strong case was presented to convert this space.

https://www.ietf.org/archive/id/draft-schoen-intarea-unicast-240-00.html

Regards, Christopher Hawker

On Thu, 11 Jan 2024 at 20:40, Dave Taht <dave.taht@gmail.com> wrote:

...

On Wed, Jan 10, 2024 at 11:06 AM Tom Beecher <beecher@beecher.cc> wrote:

...

...

There's a whole bunch of software out there that makes certain assumptions about allowable ranges. That is, they've been compiled with a header that defines ..

Of course correct. It really depends on the vendor / software / versions in an environment. A lot of vendors removed that years ago, because frankly a lot of large networks have been using 240/4 as pseudo RFC1918 for years. Others have worked with smaller vendors and open source projects to do the same.

It's consistently a topic in the debates about 240/4 reclassification.

There's debates still? I gave up. After making 240/4 and 0/8 work across all of linux and BSD and all the daemons besides bird (which refused the patch , I took so much flack that I decided I would just work on other things. So much of that flack was BS - like if you kill the checks in the OS the world will end - that didn't happen. Linux has had these two address ranges just work for over 5 years now.

240/4 is intensely routable and actually used in routers along hops inside multiple networks today, but less so as a destination.

I would really like, one day, to see it move from reserved to unicast status, officially. I would have loved it if 0/8 was used by a space RIR, behind CGNAT, for starters, but with a plan towards making it routable. I am not holding my breath.

The principal accomplishment of the whole unicast extensions project was to save a nanosecond across all the servers in the world on every packet by killing the useless 0/8 check. That patch paid for itself the first weekend after that linux kernel deployed. It is the simplest, most elegant, and most controversial patch I have ever written.

https://news.ycombinator.com/item?id=20430096

...

On Wed, Jan 10, 2024 at 10:45 AM Michael Butler <imb@protected-networks.net> wrote:

...

On 1/10/24 10:12, Tom Beecher wrote:

...

Karim-

Please be cautious about this advice, and understand the full context.

240/4 is still classified as RESERVED space. While you would certainly be able to use it on internal networks if your equipment supports it, you cannot use it as publicly routable space. There have been many proposals over the years to reclassify 240/4, but that has not happened, and is unlikely to at any point in the foreseeable future.

While you may be able to get packets from point A to B in a private setting, using them might also be .. a challenge.

There's a whole bunch of software out there that makes certain assumptions about allowable ranges. That is, they've been compiled with a header that defines ..

#define IN_BADCLASS(i) (((in_addr_t)(i) & 0xf0000000) == 0xf0000000)

Michael

-- 40 years of net history, a couple songs: https://www.youtube.com/watch?v=D9RGX6QFm5E Dave Täht CSO, LibreQos

-- 40 years of net history, a couple songs: https://www.youtube.com/watch?v=D9RGX6QFm5E Dave Täht CSO, LibreQos

On Thu, Jan 11, 2024 at 9:29 AM Tom Beecher <beecher@beecher.cc> wrote:

Christopher-

Reclassifying this space, would add 10+ years onto the free pool for each

...

RIR. Looking at the APNIC free pool, I would estimate there is about 1/6th of a /8 pool available for delegation, another 1/6th reserved. Reclassification would see available pool volumes return to pre-2010 levels.

Citing Nick Hilliard from another reply, this is an incorrect statement.

on this point: prior to RIR depletion, the annual global run-rate on /8s

...

measured by IANA was ~13 per annum. So that suggests that 240/4 would provide a little more than 1Y of consumption, assuming no demand back-pressure, which seems an unlikely assumption.

Hi Tom, I think that's a bit of an unfair categorization--we can't look at pre-exhaustion demand numbers and extrapolate to post-exhaustion allocations, given the difference in allocation policies pre-exhaustion versus post-exhaustion. If we limited ISPs to a single /22 of post-exhaustion space, with a minimum 1 year waiting period to come back to request an additional /22, 240/4 would last a good long time. That aligns with ARIN's current NPRM initial allocation, post-exhaustion: 4.2.2. Initial Allocation to ISPs All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /22, subject to ARIN’s minimum allocation size. If you already *have* existing IPv4 space, I would propose you be ineligible to apply to ARIN for space from within 240/4; you already have a functioning business with some amount of IPv4 space, and can look at either trying to be more efficient with what you have (more CG-NAT, renumber off public space for internal links, etc.), or participating in the open market for IPv4 space transfers. 240/4 can be made to last a very long time, if we apply post-exhaustion rules, rather than allowing pre-exhaustion demand curves to continue forward. I share Dave's views, I would like to see 240/4 reclassified as unicast

...

space and 2 x /8s delegated to each RIR with the /8s for AFRINIC to be held until their issues have been resolved.

This has been discussed at great length at IETF. The consensus on the question has been consistent for many years now; doing work to free up 12-ish months of space doesn't make much sense when IPv6 exists, along with plenty of transition/translation mechanisms. Unless someone is able to present new arguments that change the current consensus, it's not going to happen.

The key difference is that IPv6-only doesn't (currently) work, transition/translation mechanisms require an entity to have at least *some* IPv4 addresses to anchor their transition/translation mechanisms to, and we've created a situation that presents significant barriers to entry for new applicants that existing entities don't face. At some point in the near future, I suspect governments will begin to look at the current ISP environment as anti-competitive if we don't adjust our stance to ensure a fair and level playing field for new entrants as well as existing incumbent providers. I think we're going to need to ensure that new applicants are able to get their initial allocation of space for the foreseeable future in order to fend off increasing regulatory pressure. Adding space from 240/4 to the initial-allocations-only pool would help ensure that.

On Thu, Jan 11, 2024 at 5:54 AM Christopher Hawker <chris@thesysadmin.au> wrote:

...

There really is no reason for 240/4 to remain "reserved". I share Dave's views, I would like to see 240/4 reclassified as unicast space and 2 x /8s delegated to each RIR with the /8s for AFRINIC to be held until their issues have been resolved.

Reclassifying this space, would add 10+ years onto the free pool for each RIR. Looking at the APNIC free pool, I would estimate there is about 1/6th of a /8 pool available for delegation, another 1/6th reserved. Reclassification would see available pool volumes return to pre-2010 levels.

https://www.apnic.net/manage-ip/ipv4-exhaustion/

In the IETF draft that was co-authored by Dave as part of the IPv4 Unicast Extensions Project, a very strong case was presented to convert this space.

https://www.ietf.org/archive/id/draft-schoen-intarea-unicast-240-00.html

Regards, Christopher Hawker

Thanks! Matt

Matthew Petach wrote on 11/01/2024 21:05:

I think that's a bit of an unfair categorization--we can't look at pre-exhaustion demand numbers and extrapolate to post-exhaustion allocations, given the difference in allocation policies pre-exhaustion versus post-exhaustion.

Matt, the demand for publicly-routable ipv4 addresses would be comparable to before, with the additional pressure of several years of pent-up demand. You're right to say that allocation policies could be different, but we had discussions about run-out policies in each RIR area in the late 2000s and each RIR community settled on particular sets of policies. I don't see that if an additional set of ipv4 address blocks were to fall out of the sky, that any future run-out policies would be much different to what we had before. So 240/4 might last a month, or a year, or two, or be different in each RIR service area, but it's not going to change anything fundamental here, or permanently move the dial: ipv4 will still be a scarce resource afterwards. Nick

Matthew Petach wrote on 13/01/2024 00:27:

In light of that, I strongly suspect that a second go-around at developing more beneficial post-exhaustion policies might turn out very differently than it did when many of us were naively thinking we understood how people would behave in a post-exhaustion world.

Naah, any future relitigation would end up the same if new ipv4 addresses fell out of the sky and became available. The ipv4 address market turned out exactly like most people suspected: it was a market; people bought and sold addresses; the addresses cost money; there were/are some sharks; life moved on.

If you limit each requesting organization to a /22 per year, we can keep the internet mostly functional for decades to come,

at least in the ripe ncc service region, all this proved was that if the cost of registering a company (or LIR) and applying for an allocation was lower than the market rate of ipv4 addresses, then people would do that. The root problem is unavoidable: ipv4 is a scarce resource with an inherent demand. Every policy designed to mitigate against this will create workarounds, and the more valuable the resource, the more inventive the workaround. In terms of hard landings vs soft landings, what will make ipv6 succeed is how compelling ipv6 is, rather than whether someone created a policy to make ipv4 less palatable. In particular, any effect from a hard landing compared would have been ephemeral. Nick

...

If you limit each requesting organization to a /22 per year, we can keep the internet mostly functional for decades to come,

at least in the ripe ncc service region, all this proved was that if the cost of registering a company (or LIR) and applying for an allocation was lower than the market rate of ipv4 addresses, then people would do that.

The root problem is unavoidable: ipv4 is a scarce resource with an inherent demand. Every policy designed to mitigate against this will create workarounds, and the more valuable the resource, the more inventive the workaround.

and complex policies lead to more complex workarounds which make the internet crappier

In terms of hard landings vs soft landings, what will make ipv6 succeed is how compelling ipv6 is, rather than whether someone created a policy to make ipv4 less palatable. In particular, any effect from a hard landing compared would have been ephemeral.

amen randy

Hi Tom, I'm not too sure I understand where the idea came from that 2 x /8 would only last one year. APNIC received their final allocation of the 103/8 prefix from ICANN/IANA on 03 February 2011, and commenced delegating space from the prefix on 18 April 2011. With the right policies in place, it can be well and truly extended. Looking at an APNIC Blog article authored by Guangliang Pan on 09 October 2023 (https://blog.apnic.net/2023/10/09/nearing-the-end-of-103-8/), as of the time the article was written there were 121 available /24 prefixes from the 103/8 pool still available. Not a great deal in the grand scheme of things, however, it demonstrates that policy works in preserving what finite resources we have left, and that a 2 x /8 will last a lot longer than one year. I could say the same, that 2 x /8 lasting a little more than a year is an extremely remote and highly unlikely assumption. Bear in mind that APNIC policy was changed 1/2 way through to drop 103/8 delegations from a /22 to a /23. Based on this, 65,536 x /23 delegations can be made to new members and as Peter said, if post-exhaustion policy is applied to 240/4 it'll go an extremely long way. Regards, Christopher Hawker On Fri, 12 Jan 2024 at 04:26, Tom Beecher <beecher@beecher.cc> wrote:

Christopher-

Reclassifying this space, would add 10+ years onto the free pool for each

...

RIR. Looking at the APNIC free pool, I would estimate there is about 1/6th of a /8 pool available for delegation, another 1/6th reserved. Reclassification would see available pool volumes return to pre-2010 levels.

Citing Nick Hilliard from another reply, this is an incorrect statement.

on this point: prior to RIR depletion, the annual global run-rate on /8s

...

measured by IANA was ~13 per annum. So that suggests that 240/4 would provide a little more than 1Y of consumption, assuming no demand back-pressure, which seems an unlikely assumption.

I share Dave's views, I would like to see 240/4 reclassified as unicast

...

space and 2 x /8s delegated to each RIR with the /8s for AFRINIC to be held until their issues have been resolved.

This has been discussed at great length at IETF. The consensus on the question has been consistent for many years now; doing work to free up 12-ish months of space doesn't make much sense when IPv6 exists, along with plenty of transition/translation mechanisms. Unless someone is able to present new arguments that change the current consensus, it's not going to happen.

On Thu, Jan 11, 2024 at 5:54 AM Christopher Hawker <chris@thesysadmin.au> wrote:

...

There really is no reason for 240/4 to remain "reserved". I share Dave's views, I would like to see 240/4 reclassified as unicast space and 2 x /8s delegated to each RIR with the /8s for AFRINIC to be held until their issues have been resolved.

Reclassifying this space, would add 10+ years onto the free pool for each RIR. Looking at the APNIC free pool, I would estimate there is about 1/6th of a /8 pool available for delegation, another 1/6th reserved. Reclassification would see available pool volumes return to pre-2010 levels.

https://www.apnic.net/manage-ip/ipv4-exhaustion/

In the IETF draft that was co-authored by Dave as part of the IPv4 Unicast Extensions Project, a very strong case was presented to convert this space.

https://www.ietf.org/archive/id/draft-schoen-intarea-unicast-240-00.html

Regards, Christopher Hawker

On Thu, 11 Jan 2024 at 20:40, Dave Taht <dave.taht@gmail.com> wrote:

...

...

...

There's a whole bunch of software out there that makes certain assumptions about allowable ranges. That is, they've been compiled

with

...

a header that defines ..

Of course correct. It really depends on the vendor / software / versions in an environment. A lot of vendors removed that years ago, because frankly a lot of large networks have been using 240/4 as pseudo RFC1918 for years. Others have worked with smaller vendors and open source

On Wed, Jan 10, 2024 at 11:06 AM Tom Beecher <beecher@beecher.cc> wrote: projects to do the same.

...

It's consistently a topic in the debates about 240/4 reclassification.

There's debates still? I gave up. After making 240/4 and 0/8 work across all of linux and BSD and all the daemons besides bird (which refused the patch , I took so much flack that I decided I would just work on other things. So much of that flack was BS - like if you kill the checks in the OS the world will end - that didn't happen. Linux has had these two address ranges just work for over 5 years now.

240/4 is intensely routable and actually used in routers along hops inside multiple networks today, but less so as a destination.

I would really like, one day, to see it move from reserved to unicast status, officially. I would have loved it if 0/8 was used by a space RIR, behind CGNAT, for starters, but with a plan towards making it routable. I am not holding my breath.

The principal accomplishment of the whole unicast extensions project was to save a nanosecond across all the servers in the world on every packet by killing the useless 0/8 check. That patch paid for itself the first weekend after that linux kernel deployed. It is the simplest, most elegant, and most controversial patch I have ever written.

https://news.ycombinator.com/item?id=20430096

...

On Wed, Jan 10, 2024 at 10:45 AM Michael Butler <

imb@protected-networks.net> wrote:

...

...

On 1/10/24 10:12, Tom Beecher wrote:

...

Karim-

Please be cautious about this advice, and understand the full

context.

...

...

240/4 is still classified as RESERVED space. While you would

certainly

...

be able to use it on internal networks if your equipment supports it, you cannot use it as publicly routable space. There have been many proposals over the years to reclassify 240/4, but that has not happened, and is unlikely to at any point in the foreseeable future.

While you may be able to get packets from point A to B in a private setting, using them might also be .. a challenge.

There's a whole bunch of software out there that makes certain assumptions about allowable ranges. That is, they've been compiled with a header that defines ..

#define IN_BADCLASS(i) (((in_addr_t)(i) & 0xf0000000) == 0xf0000000)

Michael

-- 40 years of net history, a couple songs: https://www.youtube.com/watch?v=D9RGX6QFm5E Dave Täht CSO, LibreQos

Hi, Owen: 1)    "... it seemed the 240/4 lasting a year was an optimistic count.   ":     EzIP proposes that 240/4 be used like 10.64/10 in CG-NAT. which is reusable for each isolated geographical area. Thus, there is no "Burn-rate" to talk about. Regards, Abe (2024-01-12 07:07) On 2024-01-11 19:10, Owen DeLong wrote:

At the time this was being considered, ARIN, APNIC, and RIPE NCC were each burning approximately 6 /8s per year. 240/4 is 16x/8, so with an RIR burn rate of 18 /8s per year (not counting LACNIC and AFRINIC which each accounted for <1 per year IIRC), it seemed the 240/4 lasting a year was an optimistic count.

Owen

...

On Jan 11, 2024, at 13:15, Christopher Hawker <chris@thesysadmin.au> wrote:

Hi Tom,

I'm not too sure I understand where the idea came from that 2 x /8 would only last one year. APNIC received their final allocation of the 103/8 prefix from ICANN/IANA on 03 February 2011, and commenced delegating space from the prefix on 18 April 2011. With the right policies in place, it can be well and truly extended.

Looking at an APNIC Blog article authored by Guangliang Pan on 09 October 2023 (https://blog.apnic.net/2023/10/09/nearing-the-end-of-103-8/), as of the time the article was written there were 121 available /24 prefixes from the 103/8 pool still available. Not a great deal in the grand scheme of things, however, it demonstrates that policy works in preserving what finite resources we have left, and that a 2 x /8 will last a lot longer than one year.

I could say the same, that 2 x /8 lasting a little more than a year is an extremely remote and highly unlikely assumption. Bear in mind that APNIC policy was changed 1/2 way through to drop 103/8 delegations from a /22 to a /23. Based on this, 65,536 x /23 delegations can be made to new members and as Peter said, if post-exhaustion policy is applied to 240/4 it'll go an extremely long way.

Regards, Christopher Hawker

On Fri, 12 Jan 2024 at 04:26, Tom Beecher <beecher@beecher.cc> wrote:

Christopher-

Reclassifying this space, would add 10+ years onto the free pool for each RIR. Looking at the APNIC free pool, I would estimate there is about 1/6th of a /8 pool available for delegation, another 1/6th reserved. Reclassification would see available pool volumes return to pre-2010 levels.

Citing Nick Hilliard from another reply, this is an incorrect statement.

on this point: prior to RIR depletion, the annual global run-rate on /8s measured by IANA was ~13 per annum. So that suggests that 240/4 would provide a little more than 1Y of consumption, assuming no demand back-pressure, which seems an unlikely assumption.

I share Dave's views, I would like to see 240/4 reclassified as unicast space and 2 x /8s delegated to each RIR with the /8s for AFRINIC to be held until their issues have been resolved.

This has been discussed at great length at IETF. The consensus on the question has been consistent for many years now; doing work to free up 12-ish months of space doesn't make much sense when IPv6 exists, along with plenty of transition/translation mechanisms. Unless someone is able to present new arguments that change the current consensus, it's not going to happen.

On Thu, Jan 11, 2024 at 5:54 AM Christopher Hawker <chris@thesysadmin.au> wrote:

There really is no reason for 240/4 to remain "reserved". I share Dave's views, I would like to see 240/4 reclassified as unicast space and 2 x /8s delegated to each RIR with the /8s for AFRINIC to be held until their issues have been resolved.

Reclassifying this space, would add 10+ years onto the free pool for each RIR. Looking at the APNIC free pool, I would estimate there is about 1/6th of a /8 pool available for delegation, another 1/6th reserved. Reclassification would see available pool volumes return to pre-2010 levels.

https://www.apnic.net/manage-ip/ipv4-exhaustion/

In the IETF draft that was co-authored by Dave as part of the IPv4 Unicast Extensions Project, a very strong case was presented to convert this space.

https://www.ietf.org/archive/id/draft-schoen-intarea-unicast-240-00.html

Regards, Christopher Hawker

On Thu, 11 Jan 2024 at 20:40, Dave Taht <dave.taht@gmail.com> wrote:

On Wed, Jan 10, 2024 at 11:06 AM Tom Beecher <beecher@beecher.cc> wrote: >> >> There's a whole bunch of software out there that makes certain >> assumptions about allowable ranges. That is, they've been compiled with >> a header that defines .. > > > Of course correct. It really depends on the vendor / software / versions in an environment. A lot of vendors removed that years ago, because frankly a lot of large networks have been using 240/4 as pseudo RFC1918 for years. Others have worked with smaller vendors and open source projects to do the same. > > It's consistently a topic in the debates about 240/4 reclassification.

There's debates still? I gave up. After making 240/4 and 0/8 work across all of linux and BSD and all the daemons besides bird (which refused the patch , I took so much flack that I decided I would just work on other things. So much of that flack was BS - like if you kill the checks in the OS the world will end - that didn't happen. Linux has had these two address ranges just work for over 5 years now.

240/4 is intensely routable and actually used in routers along hops inside multiple networks today, but less so as a destination.

I would really like, one day, to see it move from reserved to unicast status, officially. I would have loved it if 0/8 was used by a space RIR, behind CGNAT, for starters, but with a plan towards making it routable. I am not holding my breath.

The principal accomplishment of the whole unicast extensions project was to save a nanosecond across all the servers in the world on every packet by killing the useless 0/8 check. That patch paid for itself the first weekend after that linux kernel deployed. It is the simplest, most elegant, and most controversial patch I have ever written.

https://news.ycombinator.com/item?id=20430096

> > On Wed, Jan 10, 2024 at 10:45 AM Michael Butler <imb@protected-networks.net> wrote: >> >> On 1/10/24 10:12, Tom Beecher wrote: >> > Karim- >> > >> > Please be cautious about this advice, and understand the full context. >> > >> > 240/4 is still classified as RESERVED space. While you would certainly >> > be able to use it on internal networks if your equipment supports it, >> > you cannot use it as publicly routable space. There have been many >> > proposals over the years to reclassify 240/4, but that has not happened, >> > and is unlikely to at any point in the foreseeable future. >> >> While you may be able to get packets from point A to B in a private >> setting, using them might also be .. a challenge. >> >> There's a whole bunch of software out there that makes certain >> assumptions about allowable ranges. That is, they've been compiled with >> a header that defines .. >> >> #define IN_BADCLASS(i) (((in_addr_t)(i) & 0xf0000000) == 0xf0000000) >> >>         Michael >>

-- 40 years of net history, a couple songs: https://www.youtube.com/watch?v=D9RGX6QFm5E Dave Täht CSO, LibreQos

-- This email has been checked for viruses by Avast antivirus software. www.avast.com

Hi, Niels: 0)    Your sender name is in an unusual format. It becomes just the generic NANOG address as the recipient for me to MSG send to. 1)   "  You have posted this statement like five times now in the past two days.   ":     Perhaps so, I have been responding to numerous comments since my initial post in response to Karim Mekkaoui's inquiry. Since I have to address each individually, some from different angles, while some others are new discussions or debates, it is no surprise that the same expression has been used more than once to deal with them respectively. If you count this specific item on the sideline, you definitely will see the repeats. The important criterion here is whether any of them are out of the context? (To be honest with you, I myself feel that I have been playing broken records on this pretty simple and straightforward topic.) 2)   " Who is asking for this expansion of 100.64/10 (which you misspelled, by the way)?    ":     Thanks for catching the typo. My understanding is that there is a general desire (human nature) to get a larger netblock than 100.64/10 in CG-NAT. This could be used for either growing market or less dynamic reassignment. The 240/4 can provide additional benefits to CG-NAT operations such as static addressing that no one has realized possible. So, I am putting the solution on the table. This is a basic process of sharing the new discoveries. Is there anything wrong with the process? On the other hand, if RFC6598 had picked 240/4 instead of 100.64/10 as the netblock, we do not need today's discussions. Regards, Abe (2024-01-13 12:14) On 2024-01-12 07:34, Niels Bakker wrote:

* aychen@avinta.com (Abraham Y. Chen) [Fri 12 Jan 2024, 13:09 CET]:

...

    EzIP proposes that 240/4 be used like 10.64/10 in CG-NAT. which is reusable for each isolated geographical area. Thus, there is no "Burn-rate" to talk about.

You have posted this statement like five times now in the past two days.

Who is asking for this expansion of 100.64/10 (which you misspelled, by the way)? Where are the claims that the amount of private space behind a CGNAT is the limiting factor in CGNAT deployments?

[five meters of superfluous quote history snipped]

    -- Niels.

-- This email has been checked for viruses by Avast antivirus software. www.avast.com

EzIP proposes

EzIP is a concept that has zero interest in the field , aside from Mr. Chen himself. It's been discussed and analysed. Legitimate issues have been raised, and Mr. Chen simply handwaves them away. The only IETF actions on it has been Mr. Chen refreshing the draft every 6 months. There's really no point in talking about what it is , or what it wants to do, when it has the same force and effect as the legendary IPv10 draft, and April Fools RFCs. On Fri, Jan 12, 2024 at 7:08 AM Abraham Y. Chen <aychen@avinta.com> wrote:

Hi, Owen:

1) "... it seemed the 240/4 lasting a year was an optimistic count. ":

EzIP proposes that 240/4 be used like 10.64/10 in CG-NAT. which is reusable for each isolated geographical area. Thus, there is no "Burn-rate" to talk about.

Regards,

Abe (2024-01-12 07:07)

On 2024-01-11 19:10, Owen DeLong wrote:

At the time this was being considered, ARIN, APNIC, and RIPE NCC were each burning approximately 6 /8s per year. 240/4 is 16x/8, so with an RIR burn rate of 18 /8s per year (not counting LACNIC and AFRINIC which each accounted for <1 per year IIRC), it seemed the 240/4 lasting a year was an optimistic count.

Owen

On Jan 11, 2024, at 13:15, Christopher Hawker <chris@thesysadmin.au> <chris@thesysadmin.au> wrote:

Hi Tom,

I'm not too sure I understand where the idea came from that 2 x /8 would only last one year. APNIC received their final allocation of the 103/8 prefix from ICANN/IANA on 03 February 2011, and commenced delegating space from the prefix on 18 April 2011. With the right policies in place, it can be well and truly extended.

Looking at an APNIC Blog article authored by Guangliang Pan on 09 October 2023 (https://blog.apnic.net/2023/10/09/nearing-the-end-of-103-8/), as of the time the article was written there were 121 available /24 prefixes from the 103/8 pool still available. Not a great deal in the grand scheme of things, however, it demonstrates that policy works in preserving what finite resources we have left, and that a 2 x /8 will last a lot longer than one year.

I could say the same, that 2 x /8 lasting a little more than a year is an extremely remote and highly unlikely assumption. Bear in mind that APNIC policy was changed 1/2 way through to drop 103/8 delegations from a /22 to a /23. Based on this, 65,536 x /23 delegations can be made to new members and as Peter said, if post-exhaustion policy is applied to 240/4 it'll go an extremely long way.

Regards, Christopher Hawker

On Fri, 12 Jan 2024 at 04:26, Tom Beecher <beecher@beecher.cc> wrote:

...

Christopher-

Reclassifying this space, would add 10+ years onto the free pool for each

...

RIR. Looking at the APNIC free pool, I would estimate there is about 1/6th of a /8 pool available for delegation, another 1/6th reserved. Reclassification would see available pool volumes return to pre-2010 levels.

Citing Nick Hilliard from another reply, this is an incorrect statement.

on this point: prior to RIR depletion, the annual global run-rate on /8s

...

measured by IANA was ~13 per annum. So that suggests that 240/4 would provide a little more than 1Y of consumption, assuming no demand back-pressure, which seems an unlikely assumption.

I share Dave's views, I would like to see 240/4 reclassified as unicast

...

space and 2 x /8s delegated to each RIR with the /8s for AFRINIC to be held until their issues have been resolved.

This has been discussed at great length at IETF. The consensus on the question has been consistent for many years now; doing work to free up 12-ish months of space doesn't make much sense when IPv6 exists, along with plenty of transition/translation mechanisms. Unless someone is able to present new arguments that change the current consensus, it's not going to happen.

On Thu, Jan 11, 2024 at 5:54 AM Christopher Hawker <chris@thesysadmin.au> wrote:

...

There really is no reason for 240/4 to remain "reserved". I share Dave's views, I would like to see 240/4 reclassified as unicast space and 2 x /8s delegated to each RIR with the /8s for AFRINIC to be held until their issues have been resolved.

Reclassifying this space, would add 10+ years onto the free pool for each RIR. Looking at the APNIC free pool, I would estimate there is about 1/6th of a /8 pool available for delegation, another 1/6th reserved. Reclassification would see available pool volumes return to pre-2010 levels.

https://www.apnic.net/manage-ip/ipv4-exhaustion/

In the IETF draft that was co-authored by Dave as part of the IPv4 Unicast Extensions Project, a very strong case was presented to convert this space.

https://www.ietf.org/archive/id/draft-schoen-intarea-unicast-240-00.html

Regards, Christopher Hawker

On Thu, 11 Jan 2024 at 20:40, Dave Taht <dave.taht@gmail.com> wrote:

...

...

...

There's a whole bunch of software out there that makes certain assumptions about allowable ranges. That is, they've been compiled

with

...

a header that defines ..

Of course correct. It really depends on the vendor / software / versions in an environment. A lot of vendors removed that years ago, because frankly a lot of large networks have been using 240/4 as pseudo RFC1918 for years. Others have worked with smaller vendors and open source

On Wed, Jan 10, 2024 at 11:06 AM Tom Beecher <beecher@beecher.cc> wrote: projects to do the same.

...

It's consistently a topic in the debates about 240/4 reclassification.

There's debates still? I gave up. After making 240/4 and 0/8 work across all of linux and BSD and all the daemons besides bird (which refused the patch , I took so much flack that I decided I would just work on other things. So much of that flack was BS - like if you kill the checks in the OS the world will end - that didn't happen. Linux has had these two address ranges just work for over 5 years now.

240/4 is intensely routable and actually used in routers along hops inside multiple networks today, but less so as a destination.

I would really like, one day, to see it move from reserved to unicast status, officially. I would have loved it if 0/8 was used by a space RIR, behind CGNAT, for starters, but with a plan towards making it routable. I am not holding my breath.

The principal accomplishment of the whole unicast extensions project was to save a nanosecond across all the servers in the world on every packet by killing the useless 0/8 check. That patch paid for itself the first weekend after that linux kernel deployed. It is the simplest, most elegant, and most controversial patch I have ever written.

https://news.ycombinator.com/item?id=20430096

...

On Wed, Jan 10, 2024 at 10:45 AM Michael Butler <

imb@protected-networks.net> wrote:

...

...

On 1/10/24 10:12, Tom Beecher wrote: > Karim- > > Please be cautious about this advice, and understand the full

context.

...

> > 240/4 is still classified as RESERVED space. While you would certainly > be able to use it on internal networks if your equipment supports it, > you cannot use it as publicly routable space. There have been many > proposals over the years to reclassify 240/4, but that has not happened, > and is unlikely to at any point in the foreseeable future.

While you may be able to get packets from point A to B in a private setting, using them might also be .. a challenge.

There's a whole bunch of software out there that makes certain assumptions about allowable ranges. That is, they've been compiled with a header that defines ..

#define IN_BADCLASS(i) (((in_addr_t)(i) & 0xf0000000) == 0xf0000000)

Michael

-- 40 years of net history, a couple songs: https://www.youtube.com/watch?v=D9RGX6QFm5E Dave Täht CSO, LibreQos

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virus-free.www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> <#m_-2250022354537390834_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Yes, my suggestion wasn't to permit 240/4 for use in EzIP, rather it was for it to be reclassified as Unicast (instead of Reserved) space for delegations by RIRs to members. 100.64/10 will never go back into the free pool, it's too heavily integrated into CG-NATted networks. The technical involvement for global networks to renumber makes this impossible. It's akin to recalling 192.168/16 RFC1918 space. Regards, Christopher Hawker On Fri, 12 Jan 2024 at 15:40, Abraham Y. Chen <aychen@avinta.com> wrote:

Hi, Christopher:

1) " ... I would like to see 240/4 reclassified as unicast space ... ":

We are in agreement with this first part.

2) " ... 2 x /8s delegated to each RIR with the /8s for AFRINIC ... ":

This second part is not what EzIP is proposing, because it will run into the old trap of "quickly used up". Instead, 240/4 should be used to replace 100.64/10 in creating RANs (Regional Area Networks) that are the same as the existing CG-NAT clusters but 64 fold bigger. So that 240/4 is reused worldwide like the RFC6598 netblocks, plus other possible benefits such as putting 100.64/10 back into the allocatable pool (Wasn't this pulled out of ARIN for worldwide use?) doing so, we do not have 240/4 exhaustion issue to consider.

Regards,

Abe (2024-01-11 23:40)

On 2024-01-11 05:54, Christopher Hawker wrote:

There really is no reason for 240/4 to remain "reserved". I share Dave's views, I would like to see 240/4 reclassified as unicast space and 2 x /8s delegated to each RIR with the /8s for AFRINIC to be held until their issues have been resolved.

Reclassifying this space, would add 10+ years onto the free pool for each RIR. Looking at the APNIC free pool, I would estimate there is about 1/6th of a /8 pool available for delegation, another 1/6th reserved. Reclassification would see available pool volumes return to pre-2010 levels.

https://www.apnic.net/manage-ip/ipv4-exhaustion/

In the IETF draft that was co-authored by Dave as part of the IPv4 Unicast Extensions Project, a very strong case was presented to convert this space.

https://www.ietf.org/archive/id/draft-schoen-intarea-unicast-240-00.html

Regards, Christopher Hawker

On Thu, 11 Jan 2024 at 20:40, Dave Taht <dave.taht@gmail.com> wrote:

...

...

...

There's a whole bunch of software out there that makes certain assumptions about allowable ranges. That is, they've been compiled with a header that defines ..

Of course correct. It really depends on the vendor / software / versions in an environment. A lot of vendors removed that years ago, because frankly a lot of large networks have been using 240/4 as pseudo RFC1918 for years. Others have worked with smaller vendors and open source

On Wed, Jan 10, 2024 at 11:06 AM Tom Beecher <beecher@beecher.cc> wrote: projects to do the same.

...

It's consistently a topic in the debates about 240/4 reclassification.

There's debates still? I gave up. After making 240/4 and 0/8 work across all of linux and BSD and all the daemons besides bird (which refused the patch , I took so much flack that I decided I would just work on other things. So much of that flack was BS - like if you kill the checks in the OS the world will end - that didn't happen. Linux has had these two address ranges just work for over 5 years now.

240/4 is intensely routable and actually used in routers along hops inside multiple networks today, but less so as a destination.

I would really like, one day, to see it move from reserved to unicast status, officially. I would have loved it if 0/8 was used by a space RIR, behind CGNAT, for starters, but with a plan towards making it routable. I am not holding my breath.

The principal accomplishment of the whole unicast extensions project was to save a nanosecond across all the servers in the world on every packet by killing the useless 0/8 check. That patch paid for itself the first weekend after that linux kernel deployed. It is the simplest, most elegant, and most controversial patch I have ever written.

https://news.ycombinator.com/item?id=20430096

...

On Wed, Jan 10, 2024 at 10:45 AM Michael Butler <

imb@protected-networks.net> wrote:

...

...

On 1/10/24 10:12, Tom Beecher wrote:

...

Karim-

Please be cautious about this advice, and understand the full

context.

...

...

240/4 is still classified as RESERVED space. While you would

certainly

...

be able to use it on internal networks if your equipment supports it, you cannot use it as publicly routable space. There have been many proposals over the years to reclassify 240/4, but that has not happened, and is unlikely to at any point in the foreseeable future.

While you may be able to get packets from point A to B in a private setting, using them might also be .. a challenge.

There's a whole bunch of software out there that makes certain assumptions about allowable ranges. That is, they've been compiled with a header that defines ..

#define IN_BADCLASS(i) (((in_addr_t)(i) & 0xf0000000) == 0xf0000000)

Michael

-- 40 years of net history, a couple songs: https://www.youtube.com/watch?v=D9RGX6QFm5E Dave Täht CSO, LibreQos

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virus-free.www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> <#m_-4203599433410923242_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Abraham, You're arguing semantics instead of the actual point. Residential customers want Internet access, not intranet access. Again, VRFs are plentiful and so are CG-NAT firewall appliances or servers to run those VMs. Save yourself the time and effort on this and implement IPv6. Ryan ________________________________ From: NANOG <nanog-bounces+ryan=rkhtech.org@nanog.org> on behalf of Abraham Y. Chen <aychen@avinta.com> Sent: Thursday, January 11, 2024 9:24:18 AM To: Michael Butler <imb@protected-networks.net> Cc: nanog@nanog.org <nanog@nanog.org> Subject: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments. Hi, Michael: 1) " ... While you may be able to get packets from point A to B in a private setting, using them might also be .. a challenge. ... ": EzIP uses 240/4 netblock only within the RAN (Regional Area Network) as "Private" address, not "publicly" routable, according to the conventional Internet definition. This is actually the same as how 100.64/10 is used within CG-NAT. 2) However, this might be where the confusion comes from. With the geographical area coverage so much bigger, an RAN is effectively a public network. To mesh the two for consistency, we defined everything related to 240/4 as "Semi-Public" to distinguish this new layer of networking facility from the current public / private separation. That is, the CG-NAT routers will become SPRs (Semi-Public Routers) in EzIP's RAN, once the 240/4 is deployed. Hope this helps, Abe (2024-01-11 12:21) On 2024-01-10 10:45, Michael Butler via NANOG wrote: On 1/10/24 10:12, Tom Beecher wrote: Karim- Please be cautious about this advice, and understand the full context. 240/4 is still classified as RESERVED space. While you would certainly be able to use it on internal networks if your equipment supports it, you cannot use it as publicly routable space. There have been many proposals over the years to reclassify 240/4, but that has not happened, and is unlikely to at any point in the foreseeable future. While you may be able to get packets from point A to B in a private setting, using them might also be .. a challenge. There's a whole bunch of software out there that makes certain assumptions about allowable ranges. That is, they've been compiled with a header that defines .. #define IN_BADCLASS(i) (((in_addr_t)(i) & 0xf0000000) == 0xf0000000) Michael [https://s-install.avcdn.net/ipm/preview/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virus-free.www.avast.com<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>

Abraham, It has existed for many years, already supported on many devices, does not require NAT, address space is plentiful, does not require additional proposals, and it accounts for 40% of the traffic at Google. Ryan ________________________________ From: Abraham Y. Chen <aychen@avinta.com> Sent: Friday, January 12, 2024 3:45:32 AM To: Ryan Hamel <ryan@rkhtech.org> Cc: nanog@nanog.org <nanog@nanog.org>; Michael Butler <imb@protected-networks.net>; Chen, Abraham Y. <AYChen@alum.MIT.edu> Subject: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments. Hi, Ryan: 1) " ... Save yourself the time and effort on this and implement IPv6. ": What is your selling point? Regards, Abe (2024-01-12 06:44) 2024-01-11 12:39, Ryan Hamel wrote: Abraham, You're arguing semantics instead of the actual point. Residential customers want Internet access, not intranet access. Again, VRFs are plentiful and so are CG-NAT firewall appliances or servers to run those VMs. Save yourself the time and effort on this and implement IPv6. Ryan ________________________________ From: NANOG <nanog-bounces+ryan=rkhtech.org@nanog.org><mailto:nanog-bounces+ryan=rkhtech.org@nanog.org> on behalf of Abraham Y. Chen <aychen@avinta.com><mailto:aychen@avinta.com> Sent: Thursday, January 11, 2024 9:24:18 AM To: Michael Butler <imb@protected-networks.net><mailto:imb@protected-networks.net> Cc: nanog@nanog.org<mailto:nanog@nanog.org> <nanog@nanog.org><mailto:nanog@nanog.org> Subject: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments. Hi, Michael: 1) " ... While you may be able to get packets from point A to B in a private setting, using them might also be .. a challenge. ... ": EzIP uses 240/4 netblock only within the RAN (Regional Area Network) as "Private" address, not "publicly" routable, according to the conventional Internet definition. This is actually the same as how 100.64/10 is used within CG-NAT. 2) However, this might be where the confusion comes from. With the geographical area coverage so much bigger, an RAN is effectively a public network. To mesh the two for consistency, we defined everything related to 240/4 as "Semi-Public" to distinguish this new layer of networking facility from the current public / private separation. That is, the CG-NAT routers will become SPRs (Semi-Public Routers) in EzIP's RAN, once the 240/4 is deployed. Hope this helps, Abe (2024-01-11 12:21) On 2024-01-10 10:45, Michael Butler via NANOG wrote: On 1/10/24 10:12, Tom Beecher wrote: Karim- Please be cautious about this advice, and understand the full context. 240/4 is still classified as RESERVED space. While you would certainly be able to use it on internal networks if your equipment supports it, you cannot use it as publicly routable space. There have been many proposals over the years to reclassify 240/4, but that has not happened, and is unlikely to at any point in the foreseeable future. While you may be able to get packets from point A to B in a private setting, using them might also be .. a challenge. There's a whole bunch of software out there that makes certain assumptions about allowable ranges. That is, they've been compiled with a header that defines .. #define IN_BADCLASS(i) (((in_addr_t)(i) & 0xf0000000) == 0xf0000000) Michael [https://s-install.avcdn.net/ipm/preview/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virus-free.www.avast.com<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>

If 50٪ of the servers and 50% of the clients can do IPv6, the amount of IPv6 traffic will be around 25% since both ends have to do IPv6. If you're running an IPv6 enabled server you'll see 50% of your traffic as IPv6 in the above scenario. Likewise, if you are on an IPv6 connected client, then you'll also see 50٪ of your traffic as IPv6. Note that if your adoption rates are lower, say 30% and 40%, your IPv6 traffic will be lower.. around 12% in the 30/40٪ scenario. Cloudflare has an interesting analysis. https://blog.cloudflare.com/ipv6-from-dns-pov#:~:text=IPv6%20Adoption%20on%20the%20Server%20Side,-The%20following%20graph&text=IPv6%20adoption%20by%20servers%20is,what%20was%20observed%20for%20clients . On Sun, Jan 14, 2024, 8:51 PM Abraham Y. Chen <aychen@avinta.com> wrote:

Hi, Ryan:

1) " ... it accounts for 40% of the traffic at Google. ":

Perhaps you were referring to the following?

https://www.google.com/intl/en/ipv6/statistics.html

2) If so, your quotation is correct, except there are some hidden stories below the surface:

A. When you Google for it with key words "IPv6 Traffic Google", the first hit shows "IPv6 *Adoption*" that lead to the above. So, strictly speaking, it is *not traffic *data that you are looking at.

B. Above the actual graph, you will find statements, such as " ... the *availability of IPv6 connectivity* among Google users. ...." So, legally, the graph is correct on its own right, but may not be exactly what you thought. Reader be aware!

It implies that the graph the IPv6 capability (equipment readiness) of Google users, not necessarily the actual traffic they generate. The two do not equate to each other.

3) However, the above did seem to support what was generally said in the public. Until, we found an interesting ongoing (the only one of such resource that is updated about every ten minutes) statistics by AMS-IX (AMSterdam Internet eXchange) :

https://stats.ams-ix.net/sflow/ipv6.html

https://stats.ams-ix.net/sflow/ether_type.html a The second URL shows that IPv6 accounts for approximately 5.7% of the overall Internet traffic that AMS-IX sees today. If one traces back through the archived data, the earlier numbers were even much lower. In fact, those graphs looked meaningless, because there was hardly any visible trace colored for IPv6. This has been going on for at least the last one decade. So, it could not be an error.

4) We contacted AMS-IX for a possible explanation of the obvious discrepancy. They politely referred us to our own ISPs. This triggered our curiosity. We decided that we needed to find the full world-wide IPv6 traffic data.

5) There was an annual world-wide Internet traffic statistics and forecast published by Cisco that stopped after 2017 (see URL below to the last issue). We contacted Cisco in 2020 and got an eMail confirmation.

https://cloud.report/Resources/Whitepapers/eea79d9b-9fe3-4018-86c6-3d1df813d...

6) However, there has never been any equivalent publication for the IPv6 by itself that we could locate.

7) In search for a possible explanation of the discrepancy between Pts. 1) & 3), we came across the following article. In brief, it reported that the Peering agreements among Internet backbone providers were less settled for IPv6 than IPv4. Thus, higher percentage of IPv6 traffic than that of IPv4 should have been directed through the IXs (Internet eXchanges), such as AMS-IX.

https://www.theregister.com/2018/08/28/ipv6_peering_squabbles/

8) The conclusion of Pt. 7) furthered our puzzlement, because it was opposite to what we were hoping for. That is, the roughly 5.7% IPv6 traffic that AMS-IX sees implies that within the overall Internet, the IPv6 traffic should be even less than 5.7%, not as high as Google's 40+% (Adoption) rate. Since we did not have the resources to further the research on this topic, we saved the above summary to share with anyone interested in pursuing for a better understanding. It will be much appreciated, if you could share your insights of this topic.

Regards,

Abe (2024-01-14 22:49 EST)

On 2024-01-12 09:20, Ryan Hamel wrote:

Abraham,

It has existed for many years, already supported on many devices, does not require NAT, address space is plentiful, does not require additional proposals, and it accounts for 40% of the traffic at Google.

Ryan

------------------------------ *From:* Abraham Y. Chen <aychen@avinta.com> <aychen@avinta.com> *Sent:* Friday, January 12, 2024 3:45:32 AM *To:* Ryan Hamel <ryan@rkhtech.org> <ryan@rkhtech.org> *Cc:* nanog@nanog.org <nanog@nanog.org> <nanog@nanog.org>; Michael Butler <imb@protected-networks.net> <imb@protected-networks.net>; Chen, Abraham Y. <AYChen@alum.MIT.edu> <AYChen@alum.MIT.edu> *Subject:* IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments.

Hi, Ryan:

1) " ... Save yourself the time and effort on this and implement IPv6. ":

What is your selling point?

Regards,

Abe (2024-01-12 06:44)

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virus-free.www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> <#m_-185959041418492683_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

All those measurements are missing the amount of traffic in the caches located at the ISPs. For each download passing thru AMSIX, there are thousands of multiples of that download (videos, music, documents, static contents, OS updates, etc.) flowing to thousands of customers. In some cases is even hundreds of thousands, or even millions. There is not an easy way to measure IPv6 traffic, unless it is done at the ISP level, and if you as, to ISPs that have deployed IPv6, they will tell you different numbers. For example, T-Mobile already explained a few years ago in v6ops that they were having over 75% of IPv6 traffic, 24% in the NAT64 and 1% in the CLAT+NAT64. In actual customer deployments I see the same levels, even up to 85% of IPv6 traffic. It basically depends on the usage of the caches and the % of residential vs corporate customers. Regards, Jordi @jordipalet

El 15 ene 2024, a las 7:50, Saku Ytti <saku@ytti.fi> escribió:

On Mon, 15 Jan 2024 at 06:18, Forrest Christian (List Account) <lists@packetflux.com <mailto:lists@packetflux.com>> wrote:

...

If 50٪ of the servers and 50% of the clients can do IPv6, the amount of IPv6 traffic will be around 25% since both ends have to do IPv6.

This assumes cosmological principle applies to the Internet, but Internet traffic is not uniformly distributed.

It is entirely possible, and even reasonable, that AMSIX ~5% and GOOG 40% are bps shares, and both are correct. Because AMSIX sees large entropy between A-B end-points, GOOG sees very low entropy, it being always the B.

Certain tier1 transit network could see traffic being >50% IPv6 between two specific pops, so great IPv6 adoption? Except it was a single CDN sending traffic from them to them, if you'd exclude that CDN flows between the pop, the IPv6 traffic share was low single digit percentage.

I am not saying IPv6 traffic is not increasing, I am saying that we are not doing any favours to anyone, pretending we are on-track and that this will happen, and that there are organic drivers which will ensure we are going to end up with IPV6-only Internet.

-- ++ytti

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

No, I’m not saying that. I’m saying "in actual deployments", which doesn’t mean that everyone is deploying, we are missing many ISPs, we are missing many enterprises. Saludos, Jordi @jordipalet

El 15 ene 2024, a las 9:26, Saku Ytti <saku@ytti.fi> escribió:

On Mon, 15 Jan 2024 at 10:05, jordi.palet--- via NANOG <nanog@nanog.org> wrote:

...

In actual customer deployments I see the same levels, even up to 85% of IPv6 traffic. It basically depends on the usage of the caches and the % of residential vs corporate customers.

You think you are contributing to the IPv6 cause, by explaining how positive the situation is. But in reality you are damaging it greatly, because you're not communicating that we are not on a path to IPv4 free Internet. If we had been on such a path, we would have been IPv4 free for more than a decade. And unless we admit we are not on that path, we will not work to get on that path.

-- ++ytti

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