Re: 202401100645.AYC Re: IPv4 address block

[Emanuele Balla]

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...

Re: Streamline the CG-NAT Re: 202401101433.AYC Re: EzIP Re: 202401100645.AYC Re: IPv4 address block

[Forrest Christian (List Account)]

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  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  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 

Re: 202401100645.AYC Re: IPv4 address block

[Giorgio Bonfiglio via NANOG]

>> 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.

Re: 202401100645.AYC Re: IPv4 address block

[Randy Bush]

> 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

Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address block

[Ryan Hamel]

Abraham,

You may not need permission from the IETF, but you effectively need it from 
every networking vendor, hardware vendor, and OS vendor. If you do not have buy 
in from key stakeholders, it's dead-on arrival.

Ryan

From: NANOG  on behalf of Abraham Y. 
Chen 
Sent: Thursday, January 11, 2024 6:38:52 PM
To: Vasilenko Eduard 
Cc: Chen, Abraham Y. ; nanog@nanog.org 
Subject: Stealthy Overlay Network 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, Vasilenko:

1)... These “multi-national conglo” has enough influence on the IETF to not 
permit it.":

As classified by Vint Cerf, 240/4 enabled EzIP is an overlay network that 
may be deployed stealthily (just like the events reported by the RIPE-LAB). So, 
EzIP deployment does not need permission from the IETF.

Regards,


Abe (2024-01-11 21:38 EST)




On 2024-01-11 01:17, Vasilenko Eduard wrote:

> It has been known that multi-national conglomerates have been using it 
> without announcement.

This is an assurance that 240/4 would never be permitted for Public Internet. 
These “multi-national conglo” has enough influence on the IETF to not permit it.

Ed/

From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] On 
Behalf Of Abraham Y. Chen
Sent: Wednesday, January 10, 2024 3:35 PM
To: KARIM MEKKAOUI 
Cc: nanog@nanog.org; Chen, Abraham Y. 

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]

Virus-free.www.avast.com

IPv6? Re: 202401100645.AYC Re: IPv4 address block

[Abraham Y. Chen]

Hi, Saku:

1)   "  ...we need to figure out why we are in this dual-stack mess, 
which was never intended, and how to get out of it. ... ":


    After our team worked out the EzIP scheme and then classified by 
Vint Cerf as an overlay network, more than a couple of the 
considerations that you outlined could be left alone for them to run 
their own courses. This is because the EzIP approach resolved the size 
limitation of the CG-NAT which appears (from my limited knowledge) to be 
the primary current IPv4 handicap with respect to IPv6. EzIP can be 
configured in parallel to and operates in arm's length with the existing 
Internet, so that it can grow independent of the latter.


Regards,


Abe (2024-01-11 23:54)





On 2024-01-11 06:03, Saku Ytti wrote:

On Thu, 11 Jan 2024 at 12:57, Christopher Hawker  wrote:


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.

Just enough time for us to retire comfortably and let some other fool
fix the mess we built?

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.

We've created this stupid anti-competitive IPv4 market and as far as I
can foresee, we will never organically stop using IPv4. We've added
CAPEX and OPEX costs and a lot of useless work, for no other reason,
but our failure to provide a reasonable solution going from IPv4 to
IPv6.

I can't come up with a less stupid way to fix this, than major players
commonly signing a pledge to drop IPv4 in their edge at 2040-01-01, or
some such. To finally create an incentive and date when you need to
get your IPv6 affairs in order, and to fix the IPv4 antitrust issue.
Only reason people need IPv4 to offer service is because people
offering connectivity have no incentive to offer IPv6. In fact if
you've done any IPv6 at all, you're wasting money and acting against
the best interest of your shareholders, because there is no good
reason to spend time and money on IPv6, but there should be.




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

Re: Reusable 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Christopher Hawker]

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  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  wrote:
>
>> On Wed, Jan 10, 2024 at 11:06 AM Tom Beecher  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 <
>> i...@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.
>> >>
>> >> 

Reusable 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Abraham Y. Chen]

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  wrote:

On Wed, Jan 10, 2024 at 11:06 AM Tom Beecher 
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
 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) & 0xf000) ==
0xf000)
>>
>>         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.

Reusable 240/4 Re: IPv4 address block

[Abraham Y. Chen]

Hi, Nick:

1)    " ... So that suggests that 240/4 would provide a little more than 
1Y of consumption, ...   ":


    EzIP proposes to use 240/4 CG-NAT's 100.64/10. So, 240/4 will be 
reusable worldwide and no need to consider consumption rate.


Regards,

Abe (2024-01-11 23:06)


On 2024-01-11 07:43, Nick Hilliard wrote:

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




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

Re: Streamline the CG-NAT Re: 202401101433.AYC Re: EzIP Re: 202401100645.AYC Re: IPv4 address block

[Christopher Hawker]

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  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  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, 

Streamline The CG-NAT Re: 202401100645.AYC Re: IPv4 address block

[Abraham Y. Chen]

Hi, Nick:

1)    Perhaps it will be easier to visualize the EzIP scheme by 
replacing the 100.64/10 netblock with 240/4, so that the CG-NAT is 
enhanced, starting from being 64 fold bigger in address capacity.


Regards,


Abe (2024-01-11 22:42)


On 2024-01-11 05:25, Nick Hilliard wrote:

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




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

Streamline the CG-NAT Re: 202401101433.AYC Re: EzIP Re: 202401100645.AYC Re: IPv4 address block

[Abraham Y. Chen]

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  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 

Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address block

[Abraham Y. Chen]

Hi, Vasilenko:

1)    ... These “multi-national conglo” has enough influence on the IETF 
to not permit it.":


    As classified by Vint Cerf, 240/4 enabled EzIP is an overlay 
network that may be deployed stealthily (just like the events reported 
by the RIPE-LAB). So, EzIP deployment does not need permission from the 
IETF.


Regards,


Abe (2024-01-11 21:38 EST)




On 2024-01-11 01:17, Vasilenko Eduard wrote:


> It has been known that multi-national conglomerates have been using 
it without announcement.


This is an assurance that 240/4 would never be permitted for Public 
Internet. These “multi-national conglo” has enough influence on the 
IETF to not permit it.


Ed/

*From:* NANOG 
[mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] *On 
Behalf Of *Abraham Y. Chen

*Sent:* Wednesday, January 10, 2024 3:35 PM
*To:* KARIM MEKKAOUI 
*Cc:* nanog@nanog.org; Chen, Abraham Y. 
*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





Virus-free.www.avast.com 






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

Re: 202401100645.AYC Re: IPv4 address block

[Owen DeLong via NANOG]

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  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  > 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 > > 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 >> > wrote:
 On Wed, Jan 10, 2024 at 11:06 AM Tom Beecher >>> > 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 

Re: 202401100645.AYC Re: IPv4 address block

[Owen DeLong via NANOG]

ARIN has been gutting IPv4 free-pool based policy left and right lately… Other 
RIRs have not been quite as aggressive, but have done some similar things. 
This, if for no other reason, makes it a bad idea to suddenly restore RIR IPv4 
free pools.

Just my $0.02.

I’ve got as little power in the IETF as it’s possible to have, but I admit I do 
share in the consensus view that the effort spent writing up a plan for 240/4 
would be better invested in deploying IPv6.

Owen


> On Jan 11, 2024, at 13:05, Matthew Petach  wrote:
> 
> 
> 
> On Thu, Jan 11, 2024 at 9:29 AM Tom Beecher  > 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 > > 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 

Re: 202401100645.AYC Re: IPv4 address block

[Christopher Hawker]

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  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 
> 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  wrote:
>>
>>> On Wed, Jan 10, 2024 at 11:06 AM Tom Beecher  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 

Re: 202401100645.AYC Re: IPv4 address block

[Matthew Petach]

On Thu, Jan 11, 2024 at 9:29 AM Tom Beecher  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 
> 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

Re: 202401100645.AYC Re: IPv4 address block

[Tom Beecher]

>
> 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.
>


Sure, because even though direct allocations from RIRs are exhausted, there
are still TONS of non-RFC1918 IPv4 addresses out there not actually being
used at all. We all know that years ago it wasn't that difficult to get way
more than you needed, and there was never any real pressure or incentive to
give anything back. Once exhaustion got on people's radars, hoarding
begin in earnest because it wasn't difficult to predict that there would
prob be a way to monetize it later. A former employer of mine is still
sitting on around a /12 worth that we had accumulated through some
acquisitions. We never NEEDED more than a /19. I left more than a decade
ago, and he's been subsidizing the long , slow decline of the primary
business by selling off chunks of that space here and there. Certainly not
a unique circumstance. We know there are companies out there that
categorize IP addresses as an appreciable investment asset.

The fact that $/IP peaked about 3 years ago, and has steadily been in
decline since is instructive that demand for v4 space is decreasing, which
tends to toss a wrench in the story that 240/4 is *needed*.

There are rumblings far outside the realm of the ietf.
>

AFAIK, at this point IANA will only change the designation of a V4 block if
the IETF process decides they should. So I'm not sure why other rumblings
matter all that much.


> 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.
>

I know a lot of places that are not those companies that are using 240/4
internally. Some are many orders of magnitude smaller.

I would disagree with it being referred to as 'squatting'. Today, nobody's
usage of 240/4 internally impacts anyone else.




On Thu, Jan 11, 2024 at 12:37 PM Dave Taht  wrote:

> On Thu, Jan 11, 2024 at 12:26 PM Tom Beecher  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 
> 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 

[NANOG-announce] N90 Keynotes, Important Update on Hotel, Committee Nominations + More!

[Nanog News]

*NANOG 90 Keynotes *
*Rob Shakir + Mark Johnson Take the N90 Stage*

Did you know North Carolina boasts a rich computer science and
communications legacy? Or do you want a more candid look at the evolution
of the next generation of Google's management (and control) planes?

Whether you want to delve deep into the OpenConfig journey or learn the
legendary Internet history of our meeting location's state, check out our
incredible Keynote Speakers for NANOG 90 lineup!


*LEARN MORE  *
*NANOG 90 Room Block Open*
Important Update *


*NANOG 90 will occur at the Le Méridien / Sheraton Charlotte.*
*Le Méridien Room Block Dates: *10-16 February 2024 - Monday SOLD OUT
*Sheraton Room Block Dates:* 11-14 February 2024
*Room Block Dates:* Extended to 25 January 2024 (or sold out)


*BOOK NOW  *
*Nominations Are Open For Seven Different NANOG Committees!*

We are looking for volunteers to serve on the Program Committee, Audit
Committee, Diversity Equity and Inclusion Committee, Education Committee,
Elections Committee, Hackathon Committee, and Mentorship Committee.

*MORE INFO *


*Guest Blog: The Orange España Hack w/ Kentik's Doug Madory *
*Exploring the Recent Hack on Spain's Second-Biggest Mobile Operator*

This month, Spain’s second-largest mobile operator, Orange España,
experienced a national outage, spanning multiple hours.

The cause? A compromised password and an increasingly robust routing
system. The network operator’s favorite defense tool (RPKI) can be a
double-edged sword.

*READ MORE *




*N90 Peering Forum Applications Are Open!**90-Minute Session, to be Held on
12-Feb During NANOG 90 Conference*

The forum allows attendees to meet and network with others in the peering
community present at NANOG. Applications will remain open until 15
applications are received or 2-Feb-2024, whichever is first.

*MORE INFO* 


*N90 Sponsorships Are Still Available!*

Contact Shawn Winstead swinst...@nanog.org for more information.
___
NANOG-announce mailing list
NANOG-announce@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce

N90 Keynotes, Important Update on Hotel, Committee Nominations + More!

[Nanog News]

*NANOG 90 Keynotes *
*Rob Shakir + Mark Johnson Take the N90 Stage*

Did you know North Carolina boasts a rich computer science and
communications legacy? Or do you want a more candid look at the evolution
of the next generation of Google's management (and control) planes?

Whether you want to delve deep into the OpenConfig journey or learn the
legendary Internet history of our meeting location's state, check out our
incredible Keynote Speakers for NANOG 90 lineup!


*LEARN MORE  *
*NANOG 90 Room Block Open*
Important Update *


*NANOG 90 will occur at the Le Méridien / Sheraton Charlotte.*
*Le Méridien Room Block Dates: *10-16 February 2024 - Monday SOLD OUT
*Sheraton Room Block Dates:* 11-14 February 2024
*Room Block Dates:* Extended to 25 January 2024 (or sold out)


*BOOK NOW  *
*Nominations Are Open For Seven Different NANOG Committees!*

We are looking for volunteers to serve on the Program Committee, Audit
Committee, Diversity Equity and Inclusion Committee, Education Committee,
Elections Committee, Hackathon Committee, and Mentorship Committee.

*MORE INFO *


*Guest Blog: The Orange España Hack w/ Kentik's Doug Madory *
*Exploring the Recent Hack on Spain's Second-Biggest Mobile Operator*

This month, Spain’s second-largest mobile operator, Orange España,
experienced a national outage, spanning multiple hours.

The cause? A compromised password and an increasingly robust routing
system. The network operator’s favorite defense tool (RPKI) can be a
double-edged sword.

*READ MORE *




*N90 Peering Forum Applications Are Open!**90-Minute Session, to be Held on
12-Feb During NANOG 90 Conference*

The forum allows attendees to meet and network with others in the peering
community present at NANOG. Applications will remain open until 15
applications are received or 2-Feb-2024, whichever is first.

*MORE INFO* 


*N90 Sponsorships Are Still Available!*

Contact Shawn Winstead swinst...@nanog.org for more information.

Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Ryan Hamel]

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  on behalf of Abraham Y. 
Chen 
Sent: Thursday, January 11, 2024 9:24:18 AM
To: Michael Butler 
Cc: 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) & 0xf000) == 0xf000)

Michael



[https://s-install.avcdn.net/ipm/preview/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]
  
Virus-free.www.avast.com

Re: 202401100645.AYC Re: IPv4 address block

[Dave Taht]

On Thu, Jan 11, 2024 at 12:26 PM Tom Beecher  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  
> 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  wrote:
>>>
>>> On Wed, Jan 10, 2024 at 11:06 AM Tom Beecher  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, 

Re: 202401100645.AYC Re: IPv4 address block

[Tom Beecher]

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 
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  wrote:
>
>> On Wed, Jan 10, 2024 at 11:06 AM Tom Beecher  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 <
>> i...@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 

Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Abraham Y. Chen]

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) & 0xf000) == 0xf000)

Michael




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

Re: 202401102221.AYC Re: Streamline The CG-NAT Re: 202401100645.AYC Re: IPv4 address block

[Tom Beecher]

>
> 1)Your caution advice to Karim is professional. With a lot of
> convoluted topics behind it, however, the net result is basically
> discouraging the listener from investigating the possibilities.


No, it is not.

The original question from Karim was about acquiring some IPv4 space. We
can absolutely infer he wanted that space to be publically routable *today*.

The facts are that *today* :

1. 240/4 is not space that will provide expected internet connectivity
2. There are no plans or timelines in place that would change #1.

You stated to Karim that there was a way he could get IPs for free , and
implied if he reached out to you off list , you could help him make it
work. That was intentionally misleading, and frankly doesn't reflect very
well on you at all.


On Wed, Jan 10, 2024 at 11:09 PM Abraham Y. Chen  wrote:

> Hi, Tom:
>
> 1)Your caution advice to Karim is professional. With a lot of
> convoluted topics behind it, however, the net result is basically
> discouraging the listener from investigating the possibilities. Since this
> is rather philosophical, it can distract us from the essence unless we
> carry on a lengthy debate. Instead, I would like to address below only one
> aspect that you brought up.
>
> 2)"... an operator clearly looking to acquire *publicly routable*
> space without being clear that this suggestion wouldn't meet their needs.
> ":
>
> Since 240/4 has 256M addresses while 100.64/10 has only 4M, a current
> CG-NAT cluster can be expanded 64 fold once the 240/4 is used. Looking from
> another angle, an IAP will then be able to expand the subscriber set 64
> fold with still the original one publicly routable IPv4 address.
>
> 3)This 64 fold scaling factor is critical because it allows one CG-NAT
> cluster to serve a geographical area that becomes sufficient to cover a
> significant political territory. For example, if we assign two 240/4
> addresses to each subscriber, one for stationary applications, one for
> mobile devices. And, each 240/4 address can be expanded by RFC1918
> netblocks (total about 17.6M each). Each CG-NAT can now serve a country
> with population up to 128M. It turns out that population of over 90+ % of
> countries are fewer than this. So, each of them needs only one publicly
> routable IPv4 address. Then, the demand for IPv4 address is drastically
> reduced.
>
> 4)In brief, the 240/4 is to substitute that of 100.64/10. So that the
> need for the publicly routable IPv4 addresses is significantly reduced.
>
> Regards,
>
>
> Abe (2024-01-10 23:08 EST)
>
>
> On 2024-01-10 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.
>
> Mr. Chen-
>
> I understand your perspective surrounding 240/4, and respect your
> position, even though I disagree. That being said, it's pretty dirty pool
> to toss this idea to an operator clearly looking to acquire *publicaly
> routable* space without being clear that this suggestion wouldn't meet
> their needs.
>
> ( Unless people are transferring RFC1918 space these days, in which case
> who wants to make me an offer for 10/8? )
>
> On Wed, Jan 10, 2024 at 9:48 AM KARIM MEKKAOUI 
> wrote:
>
>> Interesting and thank you for sharing.
>>
>>
>>
>> KARIM
>>
>>
>>
>> *From:* Abraham Y. Chen 
>> *Sent:* January 10, 2024 7:35 AM
>> *To:* KARIM MEKKAOUI 
>> *Cc:* nanog@nanog.org; Chen, Abraham Y. 
>> *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 

Re: 202401100645.AYC Re: IPv4 address block

[Gaurav Kansal via NANOG]

+1 to the Christopher comment

> On 11-Jan-2024, at 16:24, ch...@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  > wrote:
>> On Wed, Jan 10, 2024 at 11:06 AM Tom Beecher > > 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 
>> > mailto:i...@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) & 0xf000) == 0xf000)
>> >>
>> >> Michael
>> >>
>> 
>> 
>> -- 
>> 40 years of net history, a couple songs:
>> https://www.youtube.com/watch?v=D9RGX6QFm5E
>> Dave Täht CSO, LibreQos

Re: IPv4 address block

[Nick Hilliard]

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

Re: 202401100645.AYC Re: IPv4 address block

[Benny Lyne Amorsen]

Saku Ytti  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.

Re: 202401100645.AYC Re: IPv4 address block

[Saku Ytti]

On Thu, 11 Jan 2024 at 12:57, Christopher Hawker  wrote:

> 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.

Just enough time for us to retire comfortably and let some other fool
fix the mess we built?

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.

We've created this stupid anti-competitive IPv4 market and as far as I
can foresee, we will never organically stop using IPv4. We've added
CAPEX and OPEX costs and a lot of useless work, for no other reason,
but our failure to provide a reasonable solution going from IPv4 to
IPv6.

I can't come up with a less stupid way to fix this, than major players
commonly signing a pledge to drop IPv4 in their edge at 2040-01-01, or
some such. To finally create an incentive and date when you need to
get your IPv6 affairs in order, and to fix the IPv4 antitrust issue.
Only reason people need IPv4 to offer service is because people
offering connectivity have no incentive to offer IPv6. In fact if
you've done any IPv6 at all, you're wasting money and acting against
the best interest of your shareholders, because there is no good
reason to spend time and money on IPv6, but there should be.

-- 
  ++ytti

Re: 202401100645.AYC Re: IPv4 address block

[Christopher Hawker]

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  wrote:

> On Wed, Jan 10, 2024 at 11:06 AM Tom Beecher  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 <
> i...@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) & 0xf000) == 0xf000)
> >>
> >> Michael
> >>
>
>
> --
> 40 years of net history, a couple songs:
> https://www.youtube.com/watch?v=D9RGX6QFm5E
> Dave Täht CSO, LibreQos
>

Re: 202401100645.AYC Re: IPv4 address block

[Nick Hilliard]

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

Re: 202401100645.AYC Re: IPv4 address block

[Dave Taht]

On Wed, Jan 10, 2024 at 11:06 AM Tom Beecher  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  
> 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) & 0xf000) == 0xf000)
>>
>> Michael
>>


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