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

[Owen DeLong via NANOG]

Apologies, I failed to realize that we were still discussing the absurdity of 240/4 and thought we were talking IPv6. All my comments below apply to v6 progress. 240/4 remains in the who knows?/who cares? Category as far as I’m concerned. OwenOn Jan 12, 2024, at 22:51, Owen DeLong  wrote:Windows, Mac, Linux, bad are all done. Juniper, MikroTik, even Cisco are done.Most consumer routers sold in the last 2-3 years are done. Not sure what “hardware vendor” would be necessary beyond those. There are probably some little used corner cases of routers, os, etc. but for the most part, we are actually there, it’s just deployment at this point. What’s missing to some extent:Applications (some, less every day)Logging/monitoring/log parsing (some, getting better)Technical training (especially service providers)OwenOn Jan 12, 2024, at 10:02, Mike Hammett  wrote:" every networking vendor, hardware vendor, and OS vendor"How far are we from that, in reality? I don't have any intention on using the space, but I would like to put some definition to this boogey man.-Mike HammettIntelligent Computing SolutionsMidwest Internet ExchangeThe Brothers WISPFrom: "Ryan Hamel" To: "Abraham Y. Chen" , "Vasilenko Eduard" Cc: "Abraham Y. Chen" , nanog@nanog.orgSent: Thursday, January 11, 2024 11:04:31 PMSubject: Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address block




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

 

 

 







Virus-free.www.avast.com




 

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

[Owen DeLong via NANOG]

Windows, Mac, Linux, bad are all done. Juniper, MikroTik, even Cisco are done.Most consumer routers sold in the last 2-3 years are done. Not sure what “hardware vendor” would be necessary beyond those. There are probably some little used corner cases of routers, os, etc. but for the most part, we are actually there, it’s just deployment at this point. What’s missing to some extent:Applications (some, less every day)Logging/monitoring/log parsing (some, getting better)Technical training (especially service providers)OwenOn Jan 12, 2024, at 10:02, Mike Hammett  wrote:" every networking vendor, hardware vendor, and OS vendor"How far are we from that, in reality? I don't have any intention on using the space, but I would like to put some definition to this boogey man.-Mike HammettIntelligent Computing SolutionsMidwest Internet ExchangeThe Brothers WISPFrom: "Ryan Hamel" To: "Abraham Y. Chen" , "Vasilenko Eduard" Cc: "Abraham Y. Chen" , nanog@nanog.orgSent: Thursday, January 11, 2024 11:04:31 PMSubject: Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address block




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

 

 

 







Virus-free.www.avast.com




 

Re: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block

[Randy Bush]

interesting side note:

when iij was deploying the v6 backbone in '97, commercial routers did
not support dual stack.  so it was a parallel backbone built on netbsd
with the kame stack, which was developed in iij lab.

we remember itojun.

randy

Re: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block

[Christopher Hawker]

Wow... There is some serious learning about the internet to be done here!

When Randy was deploying IPv6 across the IIJ backbone, I was running around
in kindergarten. I didn't even know what the internet was back then.

Amazing what can happen in 26 years...

Regards,
Christopher Hawker

On Sat, 13 Jan 2024 at 09:35, Abraham Y. Chen  wrote:

> Hi, Randy:
>
> 1)" ... dual-stack mess ...   it was intended. it was the original
> transition plan. ":
>
> Perhaps you are too young to realize that the original IPv6 plan was
> not designed to be backward compatible to IPv4, and Dual-Stack was
> developed (through some iterations) to bridge the transition between IPv4
> and IPv6? You may want to spend a few moments to read some history on this.
>
>
> Regards,
>
>
> Abe (2024-01-12 17:34)
>
>
>
> On 2024-01-12 00:11, Randy Bush wrote:
>
> We don't need to extend IPv4, we need to figure out why we are in this
> dual-stack mess, which was never intended, and how to get out of it.
>
> it was intended.  it was the original transition plan.  like many things
> about ipv6, it could have been a bit better thought out.
>
> randy
>
>
>
>
> 
> Virus-free.www.avast.com
> 
> <#m_-2764172948748324147_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>

okta probing

[Randy Bush]

can someone explain what some child out there hopes to gain by
repeatedly failing to authenticate to okta in my accound name?
a couple of times a day, i have to take 40 seconds to unlock the
account the kiddie has triggered.  seems silly as they do not
have the 2fa.

it's -3c here, so i guess the clue level is going down as well
as the temp.

randy

Re: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block

[Randy Bush]

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

but it sure is a change to have a n00b troll.

i was really looking forward to it making me young.  sigh.

randy

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

[Tom Beecher]

Fair enough, I misunderstood your question.

I still think it's basically not knowable.

On Fri, Jan 12, 2024 at 3:16 PM Mike Hammett  wrote:

> I'm not talking about global, public use, only private use.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions 
> 
> 
> 
> 
> Midwest Internet Exchange 
> 
> 
> 
> The Brothers WISP 
> 
> 
> --
> *From: *"Tom Beecher" 
> *To: *"Mike Hammett" 
> *Cc: *"Ryan Hamel" , "Abraham Y. Chen" <
> ayc...@alum.mit.edu>, nanog@nanog.org
> *Sent: *Friday, January 12, 2024 2:06:32 PM
> *Subject: *Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4
> address block
>
> You don't need everything in the world to support it, just the things
>> "you" use.
>
>
> You run an ISP, let me posit something.
>
> Stipulate your entire network infra, services, and applications support
> 240/4, and that it's approved for global , public use tomorrow. Some
> company gets a block in there, stands up some website. Here are some
> absolutely plausible scenarios that you might have to deal with.
>
> - Some of your customers are running operating systems / network gear that
> doesn't support 240/4.
> - Some of your customers may be using 3rd party DNS resolvers that don't
> support 240/4.
> - Some network in between you and the dest missed a few bogon ACLs ,
> dropping your customer's traffic.
>
> All of this becomes support issues you have to deal with.
>
> On Fri, Jan 12, 2024 at 2:21 PM Mike Hammett  wrote:
>
>> I wouldn't say it's unknowable, just that no one with a sufficient enough
>> interest in the cause has been loud enough with the research they've done,
>> assuming some research has been done..
>>
>> You don't need everything in the world to support it, just the things
>> "you" use.
>>
>>
>>
>> -
>> Mike Hammett
>> Intelligent Computing Solutions 
>> 
>> 
>> 
>> 
>> Midwest Internet Exchange 
>> 
>> 
>> 
>> The Brothers WISP 
>> 
>> 
>> --
>> *From: *"Tom Beecher" 
>> *To: *"Mike Hammett" 
>> *Cc: *"Ryan Hamel" , "Abraham Y. Chen" <
>> ayc...@alum.mit.edu>, nanog@nanog.org
>> *Sent: *Friday, January 12, 2024 1:16:53 PM
>> *Subject: *Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4
>> address block
>>
>> How far are we from that, in reality? I don't have any intention on using
>>> the space, but I would like to put some definition to this boogey man.
>>
>>
>> It's unknowable really.
>>
>> Lots of network software works just fine today with it. Some don't. To my
>> knowledge some NOS vendors have outright refused to support 240/4 unless
>> it's reclassified. Beyond network equipment, there is an unknowable number
>> of software packages , drivers, etc out in the world which 240/4 is still
>> hardcoded not to work. It's been unfortunate to see this fact handwaved
>> away in many discussions on the subject.
>>
>> The Mirai worm surfaced in 2016. The software vulnerabilities used in its
>> attack vectors are still unpatched and present in massive numbers
>> across the internet; there are countless variants that still use the same
>> methods, 8 years later. Other vulnerabilities still exist after
>> multiple decades. But we somehow think devices will be patched to support
>> 240/4 quickly?
>>
>> It's just unrealistic.
>>
>> On Fri, Jan 12, 2024 at 1:03 PM Mike Hammett  wrote:
>>
>>> " every networking vendor, hardware vendor, and OS vendor"
>>>
>>> How far are we from that, in reality? I don't have any intention on
>>> using the space, but I would like to put some definition to this boogey man.
>>>
>>>
>>>
>>> -
>>> Mike Hammett
>>> Intelligent Computing Solutions 
>>> 
>>> 
>>> 
>>> 
>>> Midwest Internet Exchange 
>>> 
>>> 

Re: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block

[Matthew Petach]

On Fri, Jan 12, 2024 at 2:47 PM Randy Bush  wrote:

> > Perhaps you are too young to realize that the original IPv6 plan was
> > not designed to be backward compatible to IPv4, and Dual-Stack was
> > developed (through some iterations) to bridge the transition between
> > IPv4 and IPv6? You may want to spend a few moments to read some
> > history on this.
>
> ROFL!!!  if there is anything you can do to make me that young, you
> could have a very lucrative career outside of the internet.
>
> hint: unfortunately i already had grey hair in the '90s and was in the
> room for all this, and spent a few decades managing to get some of the
> worst stupidities (TLA, NLA, ...) pulled out of the spec.  at iij, we
> rolled ipv6 on the backbone in 1997.
>
> randy
>

OMFG,  that just made my afternoon.  :D  :D
Someone calling Randy Bush "too young".

If Randy Bush is too young, the rest of us must still need our diapers
changed on a regular basis.  :P

Matt

Re: 202401100645.AYC Re: IPv4 address block

[Matthew Petach]

On Fri, Jan 12, 2024 at 2:43 AM Nick Hilliard  wrote:

> Matthew Petach wrote on 11/01/2024 21:05:
> > I think that's a bit of an unfair categorization--we can't look at
> > pre-exhaustion demand numbers and extrapolate to post-exhaustion
> > allocations, given the difference in allocation policies pre-exhaustion
> > versus post-exhaustion.
>
> Matt,
>
> the demand for publicly-routable ipv4 addresses would be comparable to
> before, with the additional pressure of several years of pent-up demand.
>
> You're right to say that allocation policies could be different, but we
> had discussions about run-out policies in each RIR area in the late
> 2000s and each RIR community settled on particular sets of policies. I
> don't see that if an additional set of ipv4 address blocks were to fall
> out of the sky, that any future run-out policies would be much different
> to what we had before.
>
> So 240/4 might last a month, or a year, or two, or be different in each
> RIR service area, but it's not going to change anything fundamental
> here, or permanently move the dial: ipv4 will still be a scarce resource
> afterwards.
>
> Nick
>


Hi Nick,

I participated in many of those pre-exhaustion policy discussions at ARIN
meetings;
at the time, I thought a hard landing would motivate everyone to simply
shift to IPv6.

Having lived through the free-pool exhaustion, and discovered that the hard
landing
concept didn't get people to move to IPv6, it just made the battle for IPv4
resources
more cutthroat, I've come to rethink my earlier stances on NRPM updates.  I
suspect
I'm not the only one who sees things differently now, in a post-exhaustion
world with
no signs of IPv6 adoption crossing the nebulous tipping point any time soon.

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

If we limit every registrant to only what is necessary to support the
minimum level of
NAT'd connectivity for IPv4, we can stretch 240/4 out for decades to come.
You don't
need a *lot* of IPv4 space to run 464XLAT, for example, but you *do* need
at least a
small block of public IPv4 addresses to make the whole thing work.  If you
limit each
requesting organization to a /22 per year, we can keep the internet mostly
functional
for decades to come, well past the point where L*o has retired, and Android
starts
supporting DHCPv6.  ;)

But I agree--if we looked at 2000's era policies, 240/4 wouldn't last
long.  I just think
that many of us have matured a bit since then, and would vote differently
on updates
to the NRPM.  ^_^

Thanks!

Matt

Re: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block

[Tom Beecher]

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

Fairly impressive sequence of self ownage.

On Fri, Jan 12, 2024 at 5:46 PM Randy Bush  wrote:

> > Perhaps you are too young to realize that the original IPv6 plan was
> > not designed to be backward compatible to IPv4, and Dual-Stack was
> > developed (through some iterations) to bridge the transition between
> > IPv4 and IPv6? You may want to spend a few moments to read some
> > history on this.
>
> ROFL!!!  if there is anything you can do to make me that young, you
> could have a very lucrative career outside of the internet.
>
> hint: unfortunately i already had grey hair in the '90s and was in the
> room for all this, and spent a few decades managing to get some of the
> worst stupidities (TLA, NLA, ...) pulled out of the spec.  at iij, we
> rolled ipv6 on the backbone in 1997.
>
> randy
>

Re: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block

[Eric Parsonage]

Is that a faux pas?

On 13 January 2024 9:15:11 am ACDT, Randy Bush  wrote:
>> Perhaps you are too young to realize that the original IPv6 plan was
>> not designed to be backward compatible to IPv4, and Dual-Stack was
>> developed (through some iterations) to bridge the transition between
>> IPv4 and IPv6? You may want to spend a few moments to read some
>> history on this.
>
>ROFL!!!  if there is anything you can do to make me that young, you
>could have a very lucrative career outside of the internet.
>
>hint: unfortunately i already had grey hair in the '90s and was in the
>room for all this, and spent a few decades managing to get some of the
>worst stupidities (TLA, NLA, ...) pulled out of the spec.  at iij, we
>rolled ipv6 on the backbone in 1997.
>
>randy

One Can't Have It Both Ways Re: Streamline the CG-NAT Re: EzIP Re: IPv4 address block

[Abraham Y. Chen]

Hi, Forrest:

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


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


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


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


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


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


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


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


Regards,


Abe (2024-01-12 18:42)



On 2024-01-12 01:34, Forrest Christian (List Account) wrote:
The problem isn't the quantity of "inside" CG-NAT address space.  It's 
the existence of CG-NAT at all.


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


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



On Thu, Jan 11, 2024, 7:36 PM Abraham Y. Chen  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)




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

Re: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block

[Randy Bush]

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

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

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

randy

Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block

[Abraham Y. Chen]

Hi, Randy:

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


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



Regards,


Abe (2024-01-12 17:34)




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

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

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

randy




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

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

[Mike Hammett]

I'm not talking about global, public use, only private use. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Tom Beecher"  
To: "Mike Hammett"  
Cc: "Ryan Hamel" , "Abraham Y. Chen" , 
nanog@nanog.org 
Sent: Friday, January 12, 2024 2:06:32 PM 
Subject: Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address 
block 




You don't need everything in the world to support it, just the things "you" 
use. 




You run an ISP, let me posit something. 


Stipulate your entire network infra, services, and applications support 240/4, 
and that it's approved for global , public use tomorrow. Some company gets a 
block in there, stands up some website. Here are some absolutely plausible 
scenarios that you might have to deal with. 


- Some of your customers are running operating systems / network gear that 
doesn't support 240/4. 
- Some of your customers may be using 3rd party DNS resolvers that don't 
support 240/4. 
- Some network in between you and the dest missed a few bogon ACLs , dropping 
your customer's traffic. 


All of this becomes support issues you have to deal with. 


On Fri, Jan 12, 2024 at 2:21 PM Mike Hammett < na...@ics-il.net > wrote: 





I wouldn't say it's unknowable, just that no one with a sufficient enough 
interest in the cause has been loud enough with the research they've done, 
assuming some research has been done.. 


You don't need everything in the world to support it, just the things "you" 
use. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 



From: "Tom Beecher" < beec...@beecher.cc > 
To: "Mike Hammett" < na...@ics-il.net > 
Cc: "Ryan Hamel" < r...@rkhtech.org >, "Abraham Y. Chen" < ayc...@alum.mit.edu 
>, nanog@nanog.org 
Sent: Friday, January 12, 2024 1:16:53 PM 
Subject: Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address 
block 




How far are we from that, in reality? I don't have any intention on using the 
space, but I would like to put some definition to this boogey man. 




It's unknowable really. 


Lots of network software works just fine today with it. Some don't. To my 
knowledge some NOS vendors have outright refused to support 240/4 unless it's 
reclassified. Beyond network equipment, there is an unknowable number of 
software packages , drivers, etc out in the world which 240/4 is still 
hardcoded not to work. It's been unfortunate to see this fact handwaved away in 
many discussions on the subject. 


The Mirai worm surfaced in 2016. The software vulnerabilities used in its 
attack vectors are still unpatched and present in massive numbers across the 
internet; there are countless variants that still use the same methods, 8 years 
later. Other vulnerabilities still exist after multiple decades. But we somehow 
think devices will be patched to support 240/4 quickly? 


It's just unrealistic. 


On Fri, Jan 12, 2024 at 1:03 PM Mike Hammett < na...@ics-il.net > wrote: 





" every networking vendor, hardware vendor, and OS vendor" 


How far are we from that, in reality? I don't have any intention on using the 
space, but I would like to put some definition to this boogey man. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 



From: "Ryan Hamel" < r...@rkhtech.org > 
To: "Abraham Y. Chen" < ayc...@avinta.com >, "Vasilenko Eduard" < 
vasilenko.edu...@huawei.com > 
Cc: "Abraham Y. Chen" < ayc...@alum.mit.edu >, nanog@nanog.org 
Sent: Thursday, January 11, 2024 11:04:31 PM 
Subject: Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address 
block 


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 < ayc...@avinta.com > 
Sent: Thursday, January 11, 2024 6:38:52 PM 
To: Vasilenko Eduard < vasilenko.edu...@huawei.com > 
Cc: Chen, Abraham Y. < ayc...@alum.mit.edu >; nanog@nanog.org < 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 

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

[Michael Thomas]

On 1/12/24 11:54 AM, Darrel Lewis wrote:

On Jan 12, 2024, at 11:47 AM, Seth David Schoen  wrote:

Michael Thomas writes:


I wonder if the right thing to do is to create a standards track RFC that
makes the experimental space officially an add on to rfc 1918. If it works
for you, great, if not your problem. It would at least stop all of these
recurring arguments that we could salvage it for public use when the
knowability of whether it could work is zero.

In 2008 there were two proposals

https://datatracker.ietf.org/doc/draft-fuller-240space/
https://datatracker.ietf.org/doc/draft-wilson-class-e/

where the former was agnostic about how we would eventually be able to
use 240/4, and the latter designated it as RFC 1918-style private space.
Unfortunately, neither proposal was adopted as an RFC then, so we lost a
lot of time in which more vendors and operators could have made more
significant progress on its usability.

Well, we were supposed to all be using IPv6 (only) by now, and making 240/4 
useable was just going to slow that process down.

IMHO, this is what you get when religion is mixed with engineering.


But it wouldn't be globally routable so it wouldn't change much. I'm not 
even sure it would change much on the ground for CGNAT deployment? You 
still need enough public addresses to service the load. It might make it 
easier than partitioning your internal net into multiple 10/8 but on the 
other hand you need to make certain your internal net still works with 
240/4.


I'm mostly throwing this out there as a way to shut down these kinds of 
discussions.


Mike

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

[Darrel Lewis]

> On Jan 12, 2024, at 11:47 AM, Seth David Schoen  wrote:
> 
> Michael Thomas writes:
> 
>> I wonder if the right thing to do is to create a standards track RFC that
>> makes the experimental space officially an add on to rfc 1918. If it works
>> for you, great, if not your problem. It would at least stop all of these
>> recurring arguments that we could salvage it for public use when the
>> knowability of whether it could work is zero.
> 
> In 2008 there were two proposals
> 
> https://datatracker.ietf.org/doc/draft-fuller-240space/
> https://datatracker.ietf.org/doc/draft-wilson-class-e/
> 
> where the former was agnostic about how we would eventually be able to
> use 240/4, and the latter designated it as RFC 1918-style private space.
> Unfortunately, neither proposal was adopted as an RFC then, so we lost a
> lot of time in which more vendors and operators could have made more
> significant progress on its usability.

Well, we were supposed to all be using IPv6 (only) by now, and making 240/4 
useable was just going to slow that process down.   

IMHO, this is what you get when religion is mixed with engineering.

-Darrel

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

[Tom Beecher]

>
> You don't need everything in the world to support it, just the things
> "you" use.


You run an ISP, let me posit something.

Stipulate your entire network infra, services, and applications support
240/4, and that it's approved for global , public use tomorrow. Some
company gets a block in there, stands up some website. Here are some
absolutely plausible scenarios that you might have to deal with.

- Some of your customers are running operating systems / network gear that
doesn't support 240/4.
- Some of your customers may be using 3rd party DNS resolvers that don't
support 240/4.
- Some network in between you and the dest missed a few bogon ACLs ,
dropping your customer's traffic.

All of this becomes support issues you have to deal with.

On Fri, Jan 12, 2024 at 2:21 PM Mike Hammett  wrote:

> I wouldn't say it's unknowable, just that no one with a sufficient enough
> interest in the cause has been loud enough with the research they've done,
> assuming some research has been done..
>
> You don't need everything in the world to support it, just the things
> "you" use.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions 
> 
> 
> 
> 
> Midwest Internet Exchange 
> 
> 
> 
> The Brothers WISP 
> 
> 
> --
> *From: *"Tom Beecher" 
> *To: *"Mike Hammett" 
> *Cc: *"Ryan Hamel" , "Abraham Y. Chen" <
> ayc...@alum.mit.edu>, nanog@nanog.org
> *Sent: *Friday, January 12, 2024 1:16:53 PM
> *Subject: *Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4
> address block
>
> How far are we from that, in reality? I don't have any intention on using
>> the space, but I would like to put some definition to this boogey man.
>
>
> It's unknowable really.
>
> Lots of network software works just fine today with it. Some don't. To my
> knowledge some NOS vendors have outright refused to support 240/4 unless
> it's reclassified. Beyond network equipment, there is an unknowable number
> of software packages , drivers, etc out in the world which 240/4 is still
> hardcoded not to work. It's been unfortunate to see this fact handwaved
> away in many discussions on the subject.
>
> The Mirai worm surfaced in 2016. The software vulnerabilities used in its
> attack vectors are still unpatched and present in massive numbers
> across the internet; there are countless variants that still use the same
> methods, 8 years later. Other vulnerabilities still exist after
> multiple decades. But we somehow think devices will be patched to support
> 240/4 quickly?
>
> It's just unrealistic.
>
> On Fri, Jan 12, 2024 at 1:03 PM Mike Hammett  wrote:
>
>> " every networking vendor, hardware vendor, and OS vendor"
>>
>> How far are we from that, in reality? I don't have any intention on using
>> the space, but I would like to put some definition to this boogey man.
>>
>>
>>
>> -
>> Mike Hammett
>> Intelligent Computing Solutions 
>> 
>> 
>> 
>> 
>> Midwest Internet Exchange 
>> 
>> 
>> 
>> The Brothers WISP 
>> 
>> 
>> --
>> *From: *"Ryan Hamel" 
>> *To: *"Abraham Y. Chen" , "Vasilenko Eduard" <
>> vasilenko.edu...@huawei.com>
>> *Cc: *"Abraham Y. Chen" , nanog@nanog.org
>> *Sent: *Thursday, January 11, 2024 11:04:31 PM
>> *Subject: *Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4
>> address block
>>
>> 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 <
>> 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:

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

[Mu]

Would it be possible for you to reply in-thread, rather than creating a new 
thread with a new subject line every time you reply to someone?

Trying to follow the conversation becomes very difficult for no reason.
On Friday, January 12th, 2024 at 2:55 PM, Abraham Y. Chen  
wrote:

> Hi, Tony:
>
> 0) As the saying goes, there is more than one way to skin a cat. We do not 
> need to address a request by literally following the thought trend. In 
> troubleshooting, engineers are taught to look for the Root-Cause which more 
> than often turns out to be something else originally thought. In this case, 
> the "Any idea" hints that requester is open-minded for possible alternatives 
> other than stated on the surface.
>
> 1) When reviewing a problem, we need to go one or more steps toward the 
> source or the origin to look for the solution. Since the predominant 
> operation model is CDN supported by CG-NAT, the primary reason to look for a 
> publicly routable IPv4 address is to create another CG-NAT cluster. On the 
> other hand, if there is a way to expand the capacity of the existing CG-NAT 
> cluster, the need for additional publicly routable IPv4 address is reduced.
>
> Regards,
>
> Abe (2024-01-12 14:54)
>
> On 2024-01-10 23:26, Tony Wicks wrote:
>
>> 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.
>>
>> The OP asked for “Any idea please on the best way to buy IPv4 blocs and what 
>> is the price”. I would expect they want actual public IPv4 address blocks 
>> and not internal CGNAT space. While the idea of using 240/4 instead of 
>> 100.64/10 would certainly have some merit I don’t believe its in any way 
>> related to what this OP asked for.
>>
>> regards
>
> https://www.avast.com/sig-email   
> Virus-free.[www.avast.com](https://www.avast.com/sig-email)#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2

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

[Abraham Y. Chen]

Hi, Tony:

0)    As the saying goes, there is more than one way to skin a cat. We 
do not need to address a request by literally following the thought 
trend. In troubleshooting, engineers are taught to look for the 
Root-Cause which more than often turns out to be something else 
originally thought. In this case, the "Any idea" hints that requester is 
open-minded for possible alternatives other than stated on the surface.


1)    When reviewing a problem, we need to go one or more steps toward 
the source or the origin to look for the solution. Since the predominant 
operation model is CDN supported by CG-NAT, the primary reason to look 
for a publicly routable IPv4 address is to create another CG-NAT 
cluster. On the other hand, if there is a way to expand the capacity of 
the existing CG-NAT cluster, the need for additional publicly routable 
IPv4 address is reduced.


Regards,


Abe (2024-01-12 14:54)



On 2024-01-10 23:26, Tony Wicks wrote:


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.


The OP asked for “Any idea please on the best way to buy IPv4 blocs 
and what is the price”. I would expect they want actual public IPv4 
address blocks and not internal CGNAT space. While the idea of using 
240/4 instead of 100.64/10 would certainly have some merit I don’t 
believe its in any way related to what this OP asked for.


regards




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

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

[Seth David Schoen]

Michael Thomas writes:

> I wonder if the right thing to do is to create a standards track RFC that
> makes the experimental space officially an add on to rfc 1918. If it works
> for you, great, if not your problem. It would at least stop all of these
> recurring arguments that we could salvage it for public use when the
> knowability of whether it could work is zero.

In 2008 there were two proposals

https://datatracker.ietf.org/doc/draft-fuller-240space/
https://datatracker.ietf.org/doc/draft-wilson-class-e/

where the former was agnostic about how we would eventually be able to
use 240/4, and the latter designated it as RFC 1918-style private space.
Unfortunately, neither proposal was adopted as an RFC then, so we lost a
lot of time in which more vendors and operators could have made more
significant progress on its usability.

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

[Michael Thomas]

On 1/12/24 8:45 AM, Owen DeLong via NANOG wrote:
Frankly, I care less. No matter how you use whatever IPv4 space you 
attempt to cajole into whatever new form of degraded service, the 
simple fact remains. IPv4 is a degraded technology that only continues 
to get worse over time. NAT was bad. CGNAT is even worse (and 
tragically does nothing to eliminate consumer NAT, just layers more 
disaster on top of the existing mess).


The only currently available end to end peer to peer technology, for 
better or worse, is IPv6. Despite its naysayers, it is a proven 
technology that has been shouldering a significant fraction of 
internet traffic for many years now and that fraction continues to grow.


You simply can’t make IPv4 adequate and more hackers to extend its 
life merely expands the amount of pain and suffering we must endure 
before it is finally retired.


I wonder if the right thing to do is to create a standards track RFC 
that makes the experimental space officially an add on to rfc 1918. If 
it works for you, great, if not your problem. It would at least stop all 
of these recurring arguments that we could salvage it for public use 
when the knowability of whether it could work is zero.


Mike

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

[Mike Hammett]

I wouldn't say it's unknowable, just that no one with a sufficient enough 
interest in the cause has been loud enough with the research they've done, 
assuming some research has been done.. 


You don't need everything in the world to support it, just the things "you" 
use. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Tom Beecher"  
To: "Mike Hammett"  
Cc: "Ryan Hamel" , "Abraham Y. Chen" , 
nanog@nanog.org 
Sent: Friday, January 12, 2024 1:16:53 PM 
Subject: Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address 
block 




How far are we from that, in reality? I don't have any intention on using the 
space, but I would like to put some definition to this boogey man. 




It's unknowable really. 


Lots of network software works just fine today with it. Some don't. To my 
knowledge some NOS vendors have outright refused to support 240/4 unless it's 
reclassified. Beyond network equipment, there is an unknowable number of 
software packages , drivers, etc out in the world which 240/4 is still 
hardcoded not to work. It's been unfortunate to see this fact handwaved away in 
many discussions on the subject. 


The Mirai worm surfaced in 2016. The software vulnerabilities used in its 
attack vectors are still unpatched and present in massive numbers across the 
internet; there are countless variants that still use the same methods, 8 years 
later. Other vulnerabilities still exist after multiple decades. But we somehow 
think devices will be patched to support 240/4 quickly? 


It's just unrealistic. 


On Fri, Jan 12, 2024 at 1:03 PM Mike Hammett < na...@ics-il.net > wrote: 





" every networking vendor, hardware vendor, and OS vendor" 


How far are we from that, in reality? I don't have any intention on using the 
space, but I would like to put some definition to this boogey man. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 



From: "Ryan Hamel" < r...@rkhtech.org > 
To: "Abraham Y. Chen" < ayc...@avinta.com >, "Vasilenko Eduard" < 
vasilenko.edu...@huawei.com > 
Cc: "Abraham Y. Chen" < ayc...@alum.mit.edu >, nanog@nanog.org 
Sent: Thursday, January 11, 2024 11:04:31 PM 
Subject: Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address 
block 


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 < ayc...@avinta.com > 
Sent: Thursday, January 11, 2024 6:38:52 PM 
To: Vasilenko Eduard < vasilenko.edu...@huawei.com > 
Cc: Chen, Abraham Y. < ayc...@alum.mit.edu >; nanog@nanog.org < 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) 

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

[Tom Beecher]

>
> How far are we from that, in reality? I don't have any intention on using
> the space, but I would like to put some definition to this boogey man.


It's unknowable really.

Lots of network software works just fine today with it. Some don't. To my
knowledge some NOS vendors have outright refused to support 240/4 unless
it's reclassified. Beyond network equipment, there is an unknowable number
of software packages , drivers, etc out in the world which 240/4 is still
hardcoded not to work. It's been unfortunate to see this fact handwaved
away in many discussions on the subject.

The Mirai worm surfaced in 2016. The software vulnerabilities used in its
attack vectors are still unpatched and present in massive numbers
across the internet; there are countless variants that still use the same
methods, 8 years later. Other vulnerabilities still exist after
multiple decades. But we somehow think devices will be patched to support
240/4 quickly?

It's just unrealistic.

On Fri, Jan 12, 2024 at 1:03 PM Mike Hammett  wrote:

> " every networking vendor, hardware vendor, and OS vendor"
>
> How far are we from that, in reality? I don't have any intention on using
> the space, but I would like to put some definition to this boogey man.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions 
> 
> 
> 
> 
> Midwest Internet Exchange 
> 
> 
> 
> The Brothers WISP 
> 
> 
> --
> *From: *"Ryan Hamel" 
> *To: *"Abraham Y. Chen" , "Vasilenko Eduard" <
> vasilenko.edu...@huawei.com>
> *Cc: *"Abraham Y. Chen" , nanog@nanog.org
> *Sent: *Thursday, January 11, 2024 11:04:31 PM
> *Subject: *Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4
> address block
>
> 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 <
> 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 

Re: Feds seek to seize funds from lv.net ISP bank accounts and allege $3+ million fraud in bitcoin

[Matt]

And for those who have had the misfortune of actually dealing with LV.Net, this doesn't come as a 
huge surprise. I once had an corporate rep from them tell me about how the owners "have a bunch of 
schemes to make money" going on.


Matt

On 12/21/23 5:28 AM, Eric Kuhnke wrote:
https://storage.courtlistener.com/recap/gov.uscourts.nysd.590823/gov.uscourts.nysd.590823.62.0.pdf 



https://www.google.com/search?q=lv.net+ISP+nevada 


It's a fairly well known regional ISP...

Weekly Global IPv4 Routing Table Report

[Routing Table Analysis Role Account]

This is an automated weekly mailing describing the state of the Global
IPv4 Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
UKNOF, TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net.

For historical data, please see https://thyme.apnic.net.

If you have any comments please contact Philip Smith .

IPv4 Routing Table Report   04:00 +10GMT Sat 13 Jan, 2024

  BGP Table (Global) as seen in Japan.

Report Website: https://thyme.apnic.net
Detailed Analysis:  https://thyme.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  938625
Prefixes after maximum aggregation (per Origin AS):  356925
Deaggregation factor:  2.63
Unique aggregates announced (without unneeded subnets):  455683
Total ASes present in the Internet Routing Table: 75263
Prefixes per ASN: 12.47
Origin-only ASes present in the Internet Routing Table:   64540
Origin ASes announcing only one prefix:   26595
Transit ASes present in the Internet Routing Table:   10723
Transit-only ASes present in the Internet Routing Table:492
Average AS path length visible in the Internet Routing Table:   4.3
Max AS path length visible:  55
Max AS path prepend of ASN (265020)  50
Prefixes from unregistered ASNs in the Routing Table:  1118
Number of instances of unregistered ASNs:  1120
Number of 32-bit ASNs allocated by the RIRs:  43370
Number of 32-bit ASNs visible in the Routing Table:   35692
Prefixes from 32-bit ASNs in the Routing Table:  180042
Number of bogon 32-bit ASNs visible in the Routing Table:17
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:495
Number of addresses announced to Internet:   3047253248
Equivalent to 181 /8s, 161 /16s and 101 /24s
Percentage of available address space announced:   82.3
Percentage of allocated address space announced:   82.3
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.6
Total number of prefixes smaller than registry allocations:  310100

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   251179
Total APNIC prefixes after maximum aggregation:   72591
APNIC Deaggregation factor:3.46
Prefixes being announced from the APNIC address blocks:  244097
Unique aggregates announced from the APNIC address blocks:99806
APNIC Region origin ASes present in the Internet Routing Table:   13911
APNIC Prefixes per ASN:   17.55
APNIC Region origin ASes announcing only one prefix:   4202
APNIC Region transit ASes present in the Internet Routing Table:   1873
Average APNIC Region AS path length visible:4.4
Max APNIC Region AS path length visible: 34
Number of APNIC region 32-bit ASNs visible in the Routing Table:   9269
Number of APNIC addresses announced to Internet:  774771584
Equivalent to 46 /8s, 46 /16s and 19 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-153913
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:273292
Total ARIN prefixes after maximum aggregation:   123615
ARIN Deaggregation factor: 2.21
Prefixes being announced from the ARIN address blocks:   278201
Unique aggregates announced from the ARIN address blocks:132052
ARIN Region origin ASes present in the Internet Routing Table:19063
ARIN Prefixes per ASN:

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

[Mike Hammett]

" every networking vendor, hardware vendor, and OS vendor" 


How far are we from that, in reality? I don't have any intention on using the 
space, but I would like to put some definition to this boogey man. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Ryan Hamel"  
To: "Abraham Y. Chen" , "Vasilenko Eduard" 
 
Cc: "Abraham Y. Chen" , nanog@nanog.org 
Sent: Thursday, January 11, 2024 11:04:31 PM 
Subject: Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address 
block 


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 








Virus-free. www.avast.com 

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

[borg]

I could NOT agree more. Even tho, I am IPv6 phobic, let IPv4 go away.
At least, make it go away from mainstream commercial Internet.
90% users do NOT care about it. They want to browse web, watch movies
or play games. They can do it using IPv6.
I cant wait :) more IPv4 address space for people like me and our projects.


-- Original message --

From: Owen DeLong via NANOG 
To: Abraham Y. Chen 
Cc: "Chen, Abraham Y." , nanog@nanog.org
Subject: Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address
block
Date: Fri, 12 Jan 2024 08:45:22 -0800

Frankly, I care less. No matter how you use whatever IPv4 space you
attempt to cajole into whatever new form of degraded service, the simple
fact remains. IPv4 is a degraded technology that only continues to get
worse over time. NAT was bad. CGNAT is even worse (and tragically does
nothing to eliminate consumer NAT, just layers more disaster on top of
the existing mess). 

The only currently available end to end peer to peer technology, for
better or worse, is IPv6. Despite its naysayers, it is a proven
technology that has been shouldering a significant fraction of internet
traffic for many years now and that fraction continues to grow.

You simply can˙˙t make IPv4 adequate and more hackers to extend its life
merely expands the amount of pain and suffering we must endure before it
is finally retired. 

Owen


  On Jan 12, 2024, at 03:46, Abraham Y. Chen
   wrote:

  ˙˙ Hi, Ryan:

1)   " ...  Save yourself the time and effort on this and implement
IPv6.":

What is your selling point?


Regards,


Abe (2024-01-12 06:44)




2024-01-11 12:39, Ryan Hamel wrote:
  Abraham,

You're arguing semantics instead of the actual
point. Residential customers want Internet access, not
intranet access. Again, VRFs are plentiful and so are CG-NAT
firewall appliances or servers to run those VMs.

Save yourself the time and effort on this and implement IPv6.

Ryan


From: NANOG  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



[icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]
Virus-free.www.avast.com

Re: 202401100645.AYC Re: IPv4 address block

[Brandon Butterworth]

On 11/01/2024, 21:05:22, "Matthew Petach"  wrote:

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.

And ensure there are no routes for people to take them all for profit
(as happened at RIPE resulting in run out in about year), which would
probably require they cost more than the open market is charging.

brandon

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

[Owen DeLong via NANOG]

Frankly, I care less. No matter how you use whatever IPv4 space you attempt to cajole into whatever new form of degraded service, the simple fact remains. IPv4 is a degraded technology that only continues to get worse over time. NAT was bad. CGNAT is even worse (and tragically does nothing to eliminate consumer NAT, just layers more disaster on top of the existing mess). The only currently available end to end peer to peer technology, for better or worse, is IPv6. Despite its naysayers, it is a proven technology that has been shouldering a significant fraction of internet traffic for many years now and that fraction continues to grow.You simply can’t make IPv4 adequate and more hackers to extend its life merely expands the amount of pain and suffering we must endure before it is finally retired. OwenOn Jan 12, 2024, at 03:46, Abraham Y. Chen  wrote:

  

  
  
Hi, Ryan:

   
1)   " ...  Save
yourself the time and effort on this and implement IPv6.    ":

   
    What is your selling
point?

  

  
Regards,

  

  
Abe (2024-01-12 06:44)









2024-01-11 12:39, Ryan Hamel wrote:


  
  Abraham,
  
  
  You're arguing semantics instead of the actual
point. Residential
  customers want Internet access, not intranet access.
Again, VRFs are plentiful and so are CG-NAT firewall appliances
or servers to run those VMs. 
  
  
  Save yourself the time and effort on this and
implement IPv6.
  


Ryan
  
  

From:
  NANOG 
  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 

  
  
  
 

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

[Ryan Hamel]

Abraham,

It has existed for many years, already supported on many devices, does not 
require NAT, address space is plentiful, does not require additional proposals, 
and it accounts for 40% of the traffic at Google.

Ryan


From: Abraham Y. Chen 
Sent: Friday, January 12, 2024 3:45:32 AM
To: Ryan Hamel 
Cc: nanog@nanog.org ; Michael Butler 
; Chen, Abraham Y. 
Subject: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address 
block

Caution: This is an external email and may be malicious. Please take care when 
clicking links or opening attachments.

Hi, Ryan:

1)   " ...  Save yourself the time and effort on this and implement IPv6.":

What is your selling point?


Regards,


Abe (2024-01-12 06:44)




2024-01-11 12:39, Ryan Hamel wrote:
Abraham,

You're arguing semantics instead of the actual point. Residential customers 
want Internet access, not intranet access. Again, VRFs are plentiful and so are 
CG-NAT firewall appliances or servers to run those VMs.

Save yourself the time and effort on this and implement IPv6.

Ryan


From: NANOG 

 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: Burn Rate? Re: 202401100645.AYC Re: IPv4 address block

[Tom Beecher]

>
> EzIP proposes


EzIP is a concept that has zero interest in the field , aside from Mr. Chen
himself. It's been discussed and analysed. Legitimate issues have been
raised, and Mr. Chen simply handwaves them away.

The only IETF actions on it has been Mr. Chen refreshing the draft every 6
months.

There's really no point in talking about what it is , or what it wants to
do, when it has the same force and effect as the legendary IPv10 draft, and
April Fools RFCs.

On Fri, Jan 12, 2024 at 7:08 AM Abraham Y. Chen  wrote:

> Hi, Owen:
>
> 1)"... it seemed the 240/4 lasting a year was an optimistic count.   ":
>
> EzIP proposes that 240/4 be used like 10.64/10 in CG-NAT. which is
> reusable for each isolated geographical area. Thus, there is no "Burn-rate"
> to talk about.
>
> Regards,
>
>
> Abe (2024-01-12 07:07)
>
>
> On 2024-01-11 19:10, Owen DeLong wrote:
>
> At the time this was being considered, ARIN, APNIC, and RIPE NCC were each
> burning approximately 6 /8s per year. 240/4 is 16x/8, so with an RIR burn
> rate of 18 /8s per year (not counting LACNIC and AFRINIC which each
> accounted for <1 per year IIRC), it seemed the 240/4 lasting a year was an
> optimistic count.
>
> Owen
>
>
> On Jan 11, 2024, at 13:15, Christopher Hawker 
>  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:
 >>
 >> 

Re: Burn Rate? Re: 202401100645.AYC Re: IPv4 address block

[Niels Bakker]

* ayc...@avinta.com (Abraham Y. Chen) [Fri 12 Jan 2024, 13:09 CET]:
    EzIP proposes that 240/4 be used like 10.64/10 in CG-NAT. which is 
reusable for each isolated geographical area. Thus, there is no 
"Burn-rate" to talk about.


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

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


[five meters of superfluous quote history snipped]


-- Niels.

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

[Christopher Hawker]

"Source NAT changes the source address in IP header of a packet. It may
also change the source port in the TCP/UDP headers. The typical usage is to
change the a private (rfc1918) address/port into a public address/port for
packets leaving your network."

"Destination NAT changes the destination address in IP header of a packet.
It may also change the destination port in the TCP/UDP headers.The typical
usage of this is to redirect incoming packets with a destination of a
public address/port to a private IP address/port inside your network."

Source:
https://serverfault.com/questions/119365/what-is-the-difference-between-a-source-nat-destination-nat-and-masquerading

Regards,
Christopher Hawker

On Fri, 12 Jan 2024 at 23:17, Abraham Y. Chen  wrote:

> Hi, Christopher:
>
> 1)   "  destination/source NAT  ":
>
> I am not sure about this terminology. Could you please elaborate? If
> you are referring EzIP being a bigger CG-NAT, it is exactly correct. That
> is, the first step of EzIP implementation is just to give CG-NAT a larger
> netblock to work with, so that the chore of dynamic address assignment to
> the client may be avoided.
>
> Regards,
>
> Abe (2024-01-12 07:16)
>
>
>
> On 2024-01-11 22:46, Christopher Hawker wrote:
>
> Not going to lie, EzIP just seems to be some version of destination/source
> NAT on steroids.
>
> Regards,
> Christopher Hawker
>
> On Fri, 12 Jan 2024 at 14:36, Abraham Y. Chen  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.
>>
>>
>>
>>
>>
>>>
>>> 
>>> Virus-free.www.avast.com
>>> 
>>> <#m_7003280393758044796_m_-3759812132042785637_m_-2040759016673337921_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>>
>>
>>
>

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

[Abraham Y. Chen]

Hi, Christopher:

1) "  destination/source NAT  ":

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


Regards,

Abe (2024-01-12 07:16)



On 2024-01-11 22:46, Christopher Hawker wrote:
Not going to lie, EzIP just seems to be some version of 
destination/source NAT on steroids.


Regards,
Christopher Hawker

On Fri, 12 Jan 2024 at 14:36, Abraham Y. Chen  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.







Virus-free.www.avast.com





<#m_-3759812132042785637_m_-2040759016673337921_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>






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

Burn Rate? Re: 202401100645.AYC Re: IPv4 address block

[Abraham Y. Chen]

Hi, Owen:

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

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


Regards,


Abe (2024-01-12 07:07)


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


Owen


On Jan 11, 2024, at 13:15, Christopher Hawker  
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

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

[Abraham Y. Chen]

Hi, Ryan:

1)   " ...  Save yourself the time and effort on this and implement 
IPv6.    ":


    What is your selling point?


Regards,


Abe (2024-01-12 06:44)




2024-01-11 12:39, Ryan Hamel wrote:

Abraham,

You're arguing semantics instead of the actual point. Residential 
customers want Internet access, not intranet access. Again, VRFs are 
plentiful and so are CG-NAT firewall appliances or servers to run 
those VMs.


Save yourself the time and effort on this and implement IPv6.

Ryan


*From:* NANOG  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




 
	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

[Nick Hilliard]

Matthew Petach wrote on 11/01/2024 21:05:
I think that's a bit of an unfair categorization--we can't look at 
pre-exhaustion demand numbers and extrapolate to post-exhaustion 
allocations, given the difference in allocation policies pre-exhaustion 
versus post-exhaustion.


Matt,

the demand for publicly-routable ipv4 addresses would be comparable to 
before, with the additional pressure of several years of pent-up demand.


You're right to say that allocation policies could be different, but we 
had discussions about run-out policies in each RIR area in the late 
2000s and each RIR community settled on particular sets of policies. I 
don't see that if an additional set of ipv4 address blocks were to fall 
out of the sky, that any future run-out policies would be much different 
to what we had before.


So 240/4 might last a month, or a year, or two, or be different in each 
RIR service area, but it's not going to change anything fundamental 
here, or permanently move the dial: ipv4 will still be a scarce resource 
afterwards.


Nick

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

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

[Vasilenko Eduard via NANOG]

Public side of the NAT would need a huge IPv4 Public pool.
Replacing Private pool to something bigger is a very corner case.
Mobile Carriers identify subscribers not by the IP, they could easy tolerate 
many overlapping 10/8 even on one Mobile Core.
Huge private pool 240/4 is needed only for Cloud providers that have many 
micro-services.
Nothing to dispute here. The people that need it already well aware about it.
Eduard
From: Abraham Y. Chen [mailto:ayc...@avinta.com]
Sent: Friday, January 12, 2024 5:39 AM
To: Vasilenko Eduard 
Cc: nanog@nanog.org; KARIM MEKKAOUI ; Chen, Abraham Y. 

Subject: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address block
Importance: High

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