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

[Abraham Y. Chen via NANOG]

Hi, Owen:

0)    I am glad that you do not object to the notion that two premises 
on an RAN can establish end-to-end connectivity via L2 routing.


1)    For a better visualization, the below derivation will make use of 
figures in the EzIP Draft:


https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space

    A.    As I stated, premises on RAN1 (served by SPR1 - 
69.41.190.110)and premises on RAN4 (served by SPR4 - 69.41.190.148) in 
Figure 1 can communicate with one another via L2 routing based on 240/4, 
respectively. Since the 240/4 pool is large enough to serve the entire 
population of most countries, each needs only one RAN to provide the 
basic end-to-end connectivity for daily life of all citizens. Thus, 
Intra-RAN direct connectivity is provided.


    B.    Similarly, SPR1 (69.41.190.110)and SPR4 (69.41.190.148)can 
communicate with each other by L2 routing via the Internet core routers 
(utilizing plain IPv4 headers as well).


    C.    For T1z (192.168.1.9) on Premises 1 (240.0.0.0) to 
communicate with IoT T4z (246.1.6.40), we will need to extend the plain 
IPv4 header used in Step B. above by utilizing RFC791 to carry the 240/4 
addresses as Option words. Figure 16 shows an EzIP header configured for 
such a situation. Note that Word 9 represents the port numbers of IoTs 
on RGs. Since T4z is an IoT directly connect to SPR4, only the value 
(9N) for T1z is meaningful.


    D.    An IP packet with header in the form of Figure 16 can be 
delivered, if


        a.    Routers between SPR1 and SPR4 will treat it as a plain 
IPv4 packet (i.e., ignoring the Option words), and,


        b.    SPRs recognize the Option words and make use of then to 
route the packets across the RANs.


2)    For Step 1) D. a., it is said that many network routers drop 
packets having Option word due to certain security ("IP Source Route" 
attacks?) concerns. Although, there have been reports that such packets 
did get through certain routes anyway. This scheme is similar as those 
dropping 240/4 addressed packets. So, disabling such mechanism along the 
desired path may be feasible.


3)    For Step 1) D. b., enhanced SPR programs will be needed to 
recognize the Option words for utilizing them to route when the 
inter-RAN direct connectivity mode is activated.


        So, direct world-wide end-to-end connectivity is possible based 
on the EzIP scheme.


4)    However, economics comes into play when considering to deploy Step 
1) D. at this juncture. Since the Internet has evolved into the 
predominantly CDN model whose architecture is a master-slave hierarchy, 
subscribers desiring for direct inter-RAN connectivity is likely a much 
smaller subset among those desiring for Intra-RAN connectivity. This is 
like comparing international mail versus the domestic counter part. It 
may be difficult to justify efforts for Steps 2) & 3), before the demand 
becomes universal upon the general public realizing the possible 
functions. Instead, one of the old PSTN practices may be mimicked here 
as the interim solution. That is, the telephony "Foreign Exchange" setup 
used to enable a subscriber at distance to appear on local telephone 
services. It was achieved by permanently "nailed-up" a telephone 
extension wiring (started from a pair of actual physical copper wires in 
the earlier days to a dedicated voice channel in a digital multiplex 
environment) to a business that is remote from a community it serves. I 
am sure that the equivalent capability already exists in the Internet 
and is being used somewhere. This can be utilized to set up the 
extension link between any two RANs having the need.


Regards,


Abe (2024-01-24 12:28 EST)





On 2024-01-20 13:23, Owen DeLong wrote:
No. No matter how you cobble it, IPv4 doesn’t have enough addresses to 
restore proper end to end connectivity.


Owen



On Jan 20, 2024, at 07:36, Abraham Y. Chen  wrote:


Hi, Owen:

1)    "  ...  IPv4 used to work before NAT made everything horrible.  ":

    Utilizing 240/4, RAN is a flat space which should support this 
kind of rudimentary end-to-end connectivity within each RAN. (called 
L2 routing, correct?)


Regards,


Abe (2024-01-20 10:35)


On 2024-01-19 04:02, Owen DeLong wrote:
Any host connected to a reasonably well peered ISP (e.g. NOT Cogent) 
with IPv6 should be able to communicate with any other such host so 
long as the administrative policies on both sides permit it.


I have no difficulty directly reaching a variety of IPv6 hosts from 
the /48 in my home.


However, it’s not like dial-up modem operations in the PSTN in that 
IP is an inherently connectionless packet switched service while 
modems were an inherently circuit switched connection oriented service.


However, it does work like IPv4 used to work before NAT made 
everything horrible.


Owen



On Jan 15, 2024, at 12:20, Abraham Y. Chen  wrote:

Hi, Forrest:

1) I have a question:

    If I subscribe to IPv6, can I contact another 

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

[Owen DeLong via NANOG]

No. No matter how you cobble it, IPv4 doesn’t have enough addresses to restore proper end to end connectivity. OwenOn Jan 20, 2024, at 07:36, Abraham Y. Chen  wrote:

  

  
  
Hi, Owen:

  
1)    "  ...  IPv4 used
to work before NAT made everything horrible.  ":

  
    Utilizing 240/4, RAN
is a flat space which should support this kind of rudimentary
end-to-end connectivity within each RAN. (called L2 routing,
correct?)

  
Regards,

  

  
Abe (2024-01-20 10:35)




On 2024-01-19 04:02, Owen DeLong wrote:


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

  
On Jan 15, 2024, at 12:20, Abraham Y. Chen 
  wrote:


  
   Hi, Forrest:

  
1)    I have
a question: 

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

   
Regards,

  

  
Abe
(2024-01-15 15:20)




  

  


om
  

  
   
  

  


  



  

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

[Abraham Y. Chen]

Hi, Owen:

1)    "  ...  IPv4 used to work before NAT made everything horrible.  ":

    Utilizing 240/4, RAN is a flat space which should support this kind 
of rudimentary end-to-end connectivity within each RAN. (called L2 
routing, correct?)


Regards,


Abe (2024-01-20 10:35)


On 2024-01-19 04:02, Owen DeLong wrote:
Any host connected to a reasonably well peered ISP (e.g. NOT Cogent) 
with IPv6 should be able to communicate with any other such host so 
long as the administrative policies on both sides permit it.


I have no difficulty directly reaching a variety of IPv6 hosts from 
the /48 in my home.


However, it’s not like dial-up modem operations in the PSTN in that IP 
is an inherently connectionless packet switched service while modems 
were an inherently circuit switched connection oriented service.


However, it does work like IPv4 used to work before NAT made 
everything horrible.


Owen



On Jan 15, 2024, at 12:20, Abraham Y. Chen  wrote:

Hi, Forrest:

1)    I have a question:

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


Regards,


Abe (2024-01-15 15:20)


	om 
 









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

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

[Owen DeLong via NANOG]

Any host connected to a reasonably well peered ISP (e.g. NOT Cogent) with IPv6 
should be able to communicate with any other such host so long as the 
administrative policies on both sides permit it.

I have no difficulty directly reaching a variety of IPv6 hosts from the /48 in 
my home.

However, it’s not like dial-up modem operations in the PSTN in that IP is an 
inherently connectionless packet switched service while modems were an 
inherently circuit switched connection oriented service.

However, it does work like IPv4 used to work before NAT made everything 
horrible.

Owen


> On Jan 15, 2024, at 12:20, Abraham Y. Chen  wrote:
> 
> Hi, Forrest:
> 
> 1)I have a question: 
> 
> If I subscribe to IPv6, can I contact another similar subscriber to 
> communicate (voice and data) directly between two homes in private like the 
> dial-up modem operations in the PSTN? If so, is it available anywhere right 
> now?
> 
> Regards,
> 
> 
> Abe (2024-01-15 15:20)
> 
> 
>> Let me start with I think we're largely on the same page here.
>> 
>> The transition I see happening next is that the consumer traffic largely 
>> moves to IPv6 with no CG-NAT.  That is, if you're at home or on your phone 
>> watching video or doing social media or using whatever app is all the rage 
>> it's going to be over IPv6. 
>> 
>> My point was largely that I believe that at some point the big consumer (not 
>> business) focused companies are going to realize they can use market forces 
>> to encourage the remaining IPv4-only eyeball networks to transition to 
>> support IPv6 connections from their customers.  I don't know if the 
>> timeframe is next year or 20 years from now,  but I do know the tech 
>> companies are very good at looking at the costs of maintaining backwards 
>> compatibility with old tech and figuring out ways to shed those costs when 
>> they no longer make sense.  If they can utilize various forms of pressure to 
>> make this happen quicker, I fully expect them to do so. 
>> 
>> Inside a business network,  or even at home,  it wouldn't surprise me if 
>> we're both long gone before IPv4 is eradicated.   I know there is going to 
>> be a lot of IPv4 in my network for years to come just because of product 
>> lifecycles.   
>> 
>> As far as "CG-NAT-like" technologies go (meaning NAT in a provider's 
>> network), they're unfortunately going to be with us for a long time since 
>> customers seem to want to be able to reach everything regardless of the IPv4 
>> or IPv6 status of the customer or endpoint.   I also expect that most 
>> service providers with business customers are going to be carrying both IPv4 
>> and IPv6 for a long time, not to mention doing a fair bit of translation in 
>> both directions.  
>> 
>> I won't go deeply into the whole IPv4 vs IPv6 discussion for a business 
>> customer's "public address" because the topic is far too nuanced for an 
>> email to cover them accurately.   Suffice it to say that I don't disagree 
>> that business today largely wants IPv4, but some seem to be becoming aware 
>> of what IPv6 can do and are looking to have both options available to them, 
>> at least outside the firewall.
>> 
>> On Sat, Jan 13, 2024, 2:04 AM Brett O'Hara > > wrote:
>>> Ok you've triggered me on your point 2.  I'll address the elephant in the 
>>> room.
>>> 
>>> IPv4 is never ever going away.
>>> 
>>> Right now consumer services are mostly (mobile, wireless, landline, wide 
>>> generalization) are IPv6 capable.  Most consumer applications are ipv6 
>>> capable, Google, Facebook, etc.There is light at the very end of the tunnel 
>>> that suggests that one day we won't have to deploy CGNAT444 for our 
>>> consumers to get to content, we may only have to do NAT64 for them to get 
>>> to the remaining Ipv4 Internet.  We're still working hard on removing our 
>>> reliance on genuine ipv4 ranges to satisfy our customer needs, It's still a 
>>> long way off, but it's coming.
>>> 
>>> Here's the current problem.  Enterprise doesn't need ipv6 or want ipv6.  
>>> You might be able to get away with giving CGNAT to your consumers, but your 
>>> enterprise customer will not accept this. How will they terminate their 
>>> remote users?  How will they do B2B with out inbound NAT?  Yes, there are 
>>> solutions, but if you don't need to, why?  They pay good money, why can't 
>>> they have real ipv4?  All their internal networks are IPv4 rfc1918.  They 
>>> are happy with NAT.  Their application service providers are ipv4 only. 
>>> Looking at the services I access for work things like SAP, SerivceNow, 
>>> Office386, Sharepoint, Okta, Dayforce, Xero, and I'm sure many more, none 
>>> can not be accessed on ipv6 alone..  Their internal network lifecycle is 
>>> 10+ years.  They have no interest in trying new things or making new 
>>> technology work without a solid financial reason and there is none for them 
>>> implementing ipv6.   And guess where all the IP addresses we're 

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

[Abraham Y. Chen]

Hi, Forrest:

1) "  if you have IPv6 service and I have IPv6 service, our IPv6 devices 
can talk directly to each other without needing any VPN or similar. ":


Thanks. So, is it true that the reason IPv4 could not do so is solely 
because it does not have enough static addresses for every subscriber?


2)    " ...  taking other security/safety steps.  (Like the PSTN, the 
internet can be tapped).  ":


Agreed. However, the extra steps should be for those who have some 
secret to hide. In the PSTN days, most traffic was voice and no 
encryption. For the Internet, everything is digitized. Distinguishing 
among voice and data becomes extra work. So, I see the tendency to 
encrypt everything.



Regards,


Abe (2024-01-18 23:15)


On 2024-01-16 01:38, Forrest Christian (List Account) wrote:



On Mon, Jan 15, 2024, 1:21 PM Abraham Y. Chen  wrote:

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


Yes,  if you have IPv6 service and I have IPv6 service, our IPv6 
devices can talk directly to each other without needing any VPN or 
similar.  And yes, this is available today.


Note that just like the PSTN you might not want to do this without 
encryption and taking other security/safety steps.   (Like the PSTN, 
the internet can be tapped).





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

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

[Forrest Christian (List Account)]

On Mon, Jan 15, 2024, 3:08 PM Abraham Y. Chen  wrote:

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

I started to type a big long reply, but I realized that I'm not really sure
how to convince you any further.

Let me try this statement:  Networks made of relatively modern equipment
are likely able to just have IPv6 turned on.   Your solution requires
software engineering and then a whole bunch of software deployed.   And
only then have the 240/4 turned on.

Whether the middle of the network is IPv4 or IPv6 (the portion that 240/4
would replace) is largely irrelevant to the public IPv4 network and to IPv4
devices in residential settings.   With the right configuration, a
residential user can have IPv4 devices talking across a 100% IPv6 network
to the rest of the IPv4 internet.  This software exists and works today.
 And, as a big advantage, once this is done, IPv6-enabled devices can talk
native IPv6 to the IPv6 internet, bypassing all of the CG-NAT mess.

As has been pointed out, IPv6 is not without its challenges.  But so would
be trying to deploy 240/4.

In addition, to support the 'overlay' portion of your solution a lot of
additional work will need to be done.   Explain how I, as a residential
user on RAN #1, can know about and connect to a service on RAN #2.   None
of that work has been done, and in order for your solution to be useful,
you need to do that work.   By contrast, all of that work is already done
with IPv6, and is working today.

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

[Forrest Christian (List Account)]

On Mon, Jan 15, 2024, 1:21 PM Abraham Y. Chen  wrote:

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

Yes,  if you have IPv6 service and I have IPv6 service, our IPv6 devices
can talk directly to each other without needing any VPN or similar.  And
yes, this is available today.

Note that just like the PSTN you might not want to do this without
encryption and taking other security/safety steps.   (Like the PSTN, the
internet can be tapped).

>

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

[Christopher Hawker]

It was always about using 240/4 as shared service provider space, just a
roundabout way of doing it.

You can call a horse a horse, or you can call it "an animal that pulls a
wagon which carries people and items from A to B". At the end of the day,
it's still a horse.

Regards,
Christopher Hawker

On Tue, 16 Jan 2024 at 14:00, Brandon Jackson  wrote:

> If I remember correctly, quite a few years ago, "EzIP" was something else
> entirely.
>
> I vaguely remember them talking about having some kind of extended IPv4
> address or to use an extension header or something like that. It was
> something that would essentially require the entire Internet to be reworked
> in order to work. Kind of like this, but even more so because these
> modified bastardized packets would be sent across the DFZ.
>
> And it seems now it's morphed into simply opening up and reusing 240/4
>
>
> Brandon Jackson
> bjack...@napshome.net
>
>
> On Mon, Jan 15, 2024, 19:47 Christopher Hawker 
> wrote:
>
>> From what I gather, "EzIP" is just a fancy name for repurposing the 240/4
>> address space as RFC6598 shared address space for service providers and
>> adding another gateway into a network to make it look like a new
>> technology, nothing more. It does absolutely nothing more than what is
>> already available and in use today. It's a solid NO from me, in case it's
>> not already clear.
>>
>> Regards,
>> Christopher Hawker
>>
>> On Tue, 16 Jan 2024 at 11:16,  wrote:
>>
>>> The reality is your whole concept for EzIP is so impractical and so
>>> unlikely to be implemented by any service provider with half a clue, that
>>> I’m not sure why I would even try to explain to you why a Radio Access
>>> Network is relevant to the Internet.  You obviously have decided you are
>>> smarter than everyone else on NANOG.
>>>
>>> Shane
>>>
>>> On Jan 15, 2024, at 6:46 PM, Abraham Y. Chen  wrote:
>>>
>>> 
>>> Hi, Sronan:
>>>
>>> 1) “Radio Access Network”:
>>>
>>> Thanks for bringing this up. Being an RF engineer by training, I am
>>> aware of this terminology. However, how specific is its claimed applicable
>>> domain?
>>>
>>> 2)I went to search on an acronym site and found a long list of
>>> expressions that abbreviate to RAN. It starts with Royal Australian Navy
>>> and Rainforest Action Network as the third. Then, Return Authorization
>>> Number is the fourth:
>>>
>>> https://www.acronymfinder.com/RAN.html
>>>
>>> 3)In fact, "Regional Area Network" is about twentieth on it! So,
>>> unless there is some kind of Registered Trademark conflict, this probably
>>> is on my low priority to-do list for the time being.
>>> 4) Of course, if you have any alternative to suggest, my ears are
>>> all yours.
>>>
>>> Regards,
>>>
>>> Abe (2024-01-15 18:48)
>>>
>>>
>>>
>>>
>>>
>>> On 2024-01-15 17:14, sro...@ronan-online.com wrote:
>>>
>>> Please don’t use the term RAN, this acronym already has a very specific
>>> definition in the telecom/network space as “Radio Access Network.”
>>>
>>> Shane
>>>
>>> On Jan 15, 2024, at 5:12 PM, Abraham Y. Chen 
>>>  wrote:
>>>
>>> 
>>> Hi, Forrest:
>>>
>>> 1)Re: Ur. Pt. 1):The initial deployment of EzIP overlay is only
>>> applying 240/4 to existing (IPv4 based) CG-NAT facility to become the
>>> overlaying RAN, plus upgrading RG-NATs (Routing / Residential NATs) to
>>> OpenWrt. So that none of the on-premises IoTs will sense any changes. I
>>> don't see how an upgrade of such equipment to IPv6 could be simpler and
>>> less work. Please elaborate.
>>>
>>> 2)Re: Ur. Pt. 2): Since the RAN still appear to be the original
>>> CG-NAT to the Internet through the same IPv4 link to the Internet core,
>>> services from Google, YouTube, etc. will not know something has changed
>>> either.
>>>
>>> 3)" ... someone with enough market power is going to basically say
>>> "enough is enough"  ...  ":
>>>
>>> We need to look at this transition with a "Divide and Conquer"
>>> perspective. That is, the CG-NAT and consequently the RAN are part of IAP
>>> (Internet Access Provider) facility. While Google, YouTube, etc. are ICPs
>>> (Internet Content Providers). Relatively speaking, the IAP is like the
>>> hardware part of a system, while ICP is the software. They are two separate
>>> parts when combined will provide the service that customers want. Normally,
>>> these two parts are separate businesses, although some may be under the
>>> same owner in some situations. The scenario that you are proposing is like
>>> back to the old Bell System days when AT decided everything. I am sure
>>> that Internet players will try very hard to avoid being labelled as such.
>>>
>>> Regards,
>>>
>>>
>>> Abe (2024-01-15 00:02)
>>>
>>>
>>> On 2024-01-13 03:30, Forrest Christian (List Account) wrote:
>>>
>>> A couple of points:
>>>
>>> 1) There is less work needed to support IPv6 than your proposed
>>> solution.  I'm not taking about 230/4.  I'm talking about your EzIP
>>> overlay.
>>>
>>> 2) Assume that Google decided that 

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

[Brandon Jackson]

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

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

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


Brandon Jackson
bjack...@napshome.net


On Mon, Jan 15, 2024, 19:47 Christopher Hawker  wrote:

> From what I gather, "EzIP" is just a fancy name for repurposing the 240/4
> address space as RFC6598 shared address space for service providers and
> adding another gateway into a network to make it look like a new
> technology, nothing more. It does absolutely nothing more than what is
> already available and in use today. It's a solid NO from me, in case it's
> not already clear.
>
> Regards,
> Christopher Hawker
>
> On Tue, 16 Jan 2024 at 11:16,  wrote:
>
>> The reality is your whole concept for EzIP is so impractical and so
>> unlikely to be implemented by any service provider with half a clue, that
>> I’m not sure why I would even try to explain to you why a Radio Access
>> Network is relevant to the Internet.  You obviously have decided you are
>> smarter than everyone else on NANOG.
>>
>> Shane
>>
>> On Jan 15, 2024, at 6:46 PM, Abraham Y. Chen  wrote:
>>
>> 
>> Hi, Sronan:
>>
>> 1) “Radio Access Network”:
>>
>> Thanks for bringing this up. Being an RF engineer by training, I am
>> aware of this terminology. However, how specific is its claimed applicable
>> domain?
>>
>> 2)I went to search on an acronym site and found a long list of
>> expressions that abbreviate to RAN. It starts with Royal Australian Navy
>> and Rainforest Action Network as the third. Then, Return Authorization
>> Number is the fourth:
>>
>> https://www.acronymfinder.com/RAN.html
>>
>> 3)In fact, "Regional Area Network" is about twentieth on it! So,
>> unless there is some kind of Registered Trademark conflict, this probably
>> is on my low priority to-do list for the time being.
>> 4) Of course, if you have any alternative to suggest, my ears are all
>> yours.
>>
>> Regards,
>>
>> Abe (2024-01-15 18:48)
>>
>>
>>
>>
>>
>> On 2024-01-15 17:14, sro...@ronan-online.com wrote:
>>
>> Please don’t use the term RAN, this acronym already has a very specific
>> definition in the telecom/network space as “Radio Access Network.”
>>
>> Shane
>>
>> On Jan 15, 2024, at 5:12 PM, Abraham Y. Chen 
>>  wrote:
>>
>> 
>> Hi, Forrest:
>>
>> 1)Re: Ur. Pt. 1):The initial deployment of EzIP overlay is only
>> applying 240/4 to existing (IPv4 based) CG-NAT facility to become the
>> overlaying RAN, plus upgrading RG-NATs (Routing / Residential NATs) to
>> OpenWrt. So that none of the on-premises IoTs will sense any changes. I
>> don't see how an upgrade of such equipment to IPv6 could be simpler and
>> less work. Please elaborate.
>>
>> 2)Re: Ur. Pt. 2): Since the RAN still appear to be the original
>> CG-NAT to the Internet through the same IPv4 link to the Internet core,
>> services from Google, YouTube, etc. will not know something has changed
>> either.
>>
>> 3)" ... someone with enough market power is going to basically say
>> "enough is enough"  ...  ":
>>
>> We need to look at this transition with a "Divide and Conquer"
>> perspective. That is, the CG-NAT and consequently the RAN are part of IAP
>> (Internet Access Provider) facility. While Google, YouTube, etc. are ICPs
>> (Internet Content Providers). Relatively speaking, the IAP is like the
>> hardware part of a system, while ICP is the software. They are two separate
>> parts when combined will provide the service that customers want. Normally,
>> these two parts are separate businesses, although some may be under the
>> same owner in some situations. The scenario that you are proposing is like
>> back to the old Bell System days when AT decided everything. I am sure
>> that Internet players will try very hard to avoid being labelled as such.
>>
>> Regards,
>>
>>
>> Abe (2024-01-15 00:02)
>>
>>
>> On 2024-01-13 03:30, Forrest Christian (List Account) wrote:
>>
>> A couple of points:
>>
>> 1) There is less work needed to support IPv6 than your proposed
>> solution.  I'm not taking about 230/4.  I'm talking about your EzIP
>> overlay.
>>
>> 2) Assume that Google decided that they would no longer support IPv4 for
>> any of their services at a specific date a couple of years in the future.
>> That is,  you either needed an IPv6 address or you couldn't reach Google,
>> youtube, Gmail and the rest of the public services.  I bet that in this
>> scenario every eyeball provider in the country all of a sudden would be
>> extremely motivated to deploy IPv6, even if the IPv4 providers end up
>> natting their IPv4 customers to IPv6.  I really expect something like 

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

[Christopher Hawker]

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

Regards,
Christopher Hawker

On Tue, 16 Jan 2024 at 11:16,  wrote:

> The reality is your whole concept for EzIP is so impractical and so
> unlikely to be implemented by any service provider with half a clue, that
> I’m not sure why I would even try to explain to you why a Radio Access
> Network is relevant to the Internet.  You obviously have decided you are
> smarter than everyone else on NANOG.
>
> Shane
>
> On Jan 15, 2024, at 6:46 PM, Abraham Y. Chen  wrote:
>
> 
> Hi, Sronan:
>
> 1) “Radio Access Network”:
>
> Thanks for bringing this up. Being an RF engineer by training, I am
> aware of this terminology. However, how specific is its claimed applicable
> domain?
>
> 2)I went to search on an acronym site and found a long list of
> expressions that abbreviate to RAN. It starts with Royal Australian Navy
> and Rainforest Action Network as the third. Then, Return Authorization
> Number is the fourth:
>
> https://www.acronymfinder.com/RAN.html
>
> 3)In fact, "Regional Area Network" is about twentieth on it! So,
> unless there is some kind of Registered Trademark conflict, this probably
> is on my low priority to-do list for the time being.
> 4) Of course, if you have any alternative to suggest, my ears are all
> yours.
>
> Regards,
>
> Abe (2024-01-15 18:48)
>
>
>
>
>
> On 2024-01-15 17:14, sro...@ronan-online.com wrote:
>
> Please don’t use the term RAN, this acronym already has a very specific
> definition in the telecom/network space as “Radio Access Network.”
>
> Shane
>
> On Jan 15, 2024, at 5:12 PM, Abraham Y. Chen 
>  wrote:
>
> 
> Hi, Forrest:
>
> 1)Re: Ur. Pt. 1):The initial deployment of EzIP overlay is only
> applying 240/4 to existing (IPv4 based) CG-NAT facility to become the
> overlaying RAN, plus upgrading RG-NATs (Routing / Residential NATs) to
> OpenWrt. So that none of the on-premises IoTs will sense any changes. I
> don't see how an upgrade of such equipment to IPv6 could be simpler and
> less work. Please elaborate.
>
> 2)Re: Ur. Pt. 2): Since the RAN still appear to be the original
> CG-NAT to the Internet through the same IPv4 link to the Internet core,
> services from Google, YouTube, etc. will not know something has changed
> either.
>
> 3)" ... someone with enough market power is going to basically say
> "enough is enough"  ...  ":
>
> We need to look at this transition with a "Divide and Conquer"
> perspective. That is, the CG-NAT and consequently the RAN are part of IAP
> (Internet Access Provider) facility. While Google, YouTube, etc. are ICPs
> (Internet Content Providers). Relatively speaking, the IAP is like the
> hardware part of a system, while ICP is the software. They are two separate
> parts when combined will provide the service that customers want. Normally,
> these two parts are separate businesses, although some may be under the
> same owner in some situations. The scenario that you are proposing is like
> back to the old Bell System days when AT decided everything. I am sure
> that Internet players will try very hard to avoid being labelled as such.
>
> Regards,
>
>
> Abe (2024-01-15 00:02)
>
>
> On 2024-01-13 03:30, Forrest Christian (List Account) wrote:
>
> A couple of points:
>
> 1) There is less work needed to support IPv6 than your proposed solution.
> I'm not taking about 230/4.  I'm talking about your EzIP overlay.
>
> 2) Assume that Google decided that they would no longer support IPv4 for
> any of their services at a specific date a couple of years in the future.
> That is,  you either needed an IPv6 address or you couldn't reach Google,
> youtube, Gmail and the rest of the public services.  I bet that in this
> scenario every eyeball provider in the country all of a sudden would be
> extremely motivated to deploy IPv6, even if the IPv4 providers end up
> natting their IPv4 customers to IPv6.  I really expect something like this
> to be the next part of the end game for IPv4.
>
> Or stated differently: at some point someone with enough market power is
> going to basically say "enough is enough" and make the decision for the
> rest of us that IPv4 is effectively done on the public internet.   The
> large tech companies all have a history of sunsetting things when it
> becomes a bigger problem to support than it's worth.  Try getting a modern
> browser that works on 32 bit windows.   Same with encryption protocols,
> Java in the browser,  Shockwave and flash, and on and on.
>
> I see no reason why IPv4 should be any different.
>
> On Fri, Jan 12, 2024, 3:42 PM Abraham Y. Chen  wrote:
>
>> Hi, Forrest:
>>
>> 0)You put out more than 

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

[sronan]

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

  

  
  
Hi, Sronan:

  
1) “Radio Access
Network”:

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

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

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


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

  

   

   

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


  
  Please don’t use the term RAN, this acronym already
has a very specific definition in the telecom/network space as
“Radio Access Network.”
  
  
  Shane
  
On Jan 15, 2024, at 5:12 PM, Abraham Y.
  Chen 
  wrote:
  

  
  

  
  Hi, Forrest:
  

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

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

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

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

  Regards,
  

  

  Abe (2024-01-15
  00:02)
  

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


  A couple of points: 
  
  
  1) There is less work needed to support
IPv6 than your proposed solution.  I'm not taking about
230/4.  I'm talking about your EzIP overlay. 
  
  
  2) Assume that Google decided that they
would no longer support IPv4 for any of their services
at a specific date a couple of years in the future. 
That is,  you either needed an IPv6 address or you
couldn't reach Google, youtube, Gmail and the rest of
the public services.  I bet that in this scenario every
eyeball provider in the country all of a sudden would be
extremely motivated to deploy IPv6, even if the IPv4
  

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

[Abraham Y. Chen]

Hi, Sronan:

1) “Radio Access Network”:

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


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


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

3)    In fact, "Regional Area Network" is about twentieth on it! So, 
unless there is some kind of Registered Trademark conflict, this 
probably is on my low priority to-do list for the time being.


4)     Of course, if you have any alternative to suggest, my ears are 
all yours.


Regards,

Abe (2024-01-15 18:48)





On 2024-01-15 17:14, sro...@ronan-online.com wrote:
Please don’t use the term RAN, this acronym already has a very 
specific definition in the telecom/network space as “Radio Access 
Network.”


Shane


On Jan 15, 2024, at 5:12 PM, Abraham Y. Chen  wrote:


Hi, Forrest:

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


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


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


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


Regards,


Abe (2024-01-15 00:02)


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

A couple of points:

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


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


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


I see no reason why IPv4 should be any different.

On Fri, Jan 12, 2024, 3:42 PM Abraham Y. Chen  wrote:

Hi, Forrest:

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

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

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

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

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

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

[Christopher Hawker]

You most certainly can, it's called a VPN. One side initiates a connection
to the other.

;)

Regards,
Christopher Hawker

On Tue, 16 Jan 2024 at 07:21, Abraham Y. Chen  wrote:

> Hi, Forrest:
>
> 1)I have a question:
>
> If I subscribe to IPv6, can I contact another similar subscriber to
> communicate (voice and data) directly between two homes in private like the
> dial-up modem operations in the PSTN? If so, is it available anywhere right
> now?
>
> Regards,
>
>
> Abe (2024-01-15 15:20)
>
>
> Let me start with I think we're largely on the same page here.
>
> The transition I see happening next is that the consumer traffic largely
> moves to IPv6 with no CG-NAT.  That is, if you're at home or on your phone
> watching video or doing social media or using whatever app is all the rage
> it's going to be over IPv6.
>
> My point was largely that I believe that at some point the big consumer
> (not business) focused companies are going to realize they can use market
> forces to encourage the remaining IPv4-only eyeball networks to transition
> to support IPv6 connections from their customers.  I don't know if the
> timeframe is next year or 20 years from now,  but I do know the tech
> companies are very good at looking at the costs of maintaining backwards
> compatibility with old tech and figuring out ways to shed those costs when
> they no longer make sense.  If they can utilize various forms of pressure
> to make this happen quicker, I fully expect them to do so.
>
> Inside a business network,  or even at home,  it wouldn't surprise me if
> we're both long gone before IPv4 is eradicated.   I know there is going to
> be a lot of IPv4 in my network for years to come just because of product
> lifecycles.
>
> As far as "CG-NAT-like" technologies go (meaning NAT in a provider's
> network), they're unfortunately going to be with us for a long time since
> customers seem to want to be able to reach everything regardless of the
> IPv4 or IPv6 status of the customer or endpoint.   I also expect that most
> service providers with business customers are going to be carrying both
> IPv4 and IPv6 for a long time, not to mention doing a fair bit of
> translation in both directions.
>
> I won't go deeply into the whole IPv4 vs IPv6 discussion for a business
> customer's "public address" because the topic is far too nuanced for an
> email to cover them accurately.   Suffice it to say that I don't disagree
> that business today largely wants IPv4, but some seem to be becoming aware
> of what IPv6 can do and are looking to have both options available to them,
> at least outside the firewall.
>
> On Sat, Jan 13, 2024, 2:04 AM Brett O'Hara  wrote:
>
>> Ok you've triggered me on your point 2.  I'll address the elephant in the
>> room.
>>
>> IPv4 is never ever going away.
>>
>> Right now consumer services are mostly (mobile, wireless, landline, wide
>> generalization) are IPv6 capable.  Most consumer applications are ipv6
>> capable, Google, Facebook, etc.There is light at the very end of the tunnel
>> that suggests that one day we won't have to deploy CGNAT444 for our
>> consumers to get to content, we may only have to do NAT64 for them to get
>> to the remaining Ipv4 Internet.  We're still working hard on removing our
>> reliance on genuine ipv4 ranges to satisfy our customer needs, It's still a
>> long way off, but it's coming.
>>
>> Here's the current problem.  Enterprise doesn't need ipv6 or want ipv6.
>> You might be able to get away with giving CGNAT to your consumers, but your
>> enterprise customer will not accept this. How will they terminate their
>> remote users?  How will they do B2B with out inbound NAT?  Yes, there are
>> solutions, but if you don't need to, why?  They pay good money, why can't
>> they have real ipv4?  All their internal networks are IPv4 rfc1918.  They
>> are happy with NAT.  Their application service providers are ipv4
>> only. Looking at the services I access for work things like SAP,
>> SerivceNow, Office386, Sharepoint, Okta, Dayforce, Xero, and I'm sure many
>> more, none can not be accessed on ipv6 alone..  Their internal network
>> lifecycle is 10+ years.  They have no interest in trying new things or
>> making new technology work without a solid financial reason and there is
>> none for them implementing ipv6.   And guess where all the IP addresses
>> we're getting back from our consumers are going?  Straight to our good
>> margin enterprise customers and their application service providers.
>> Consumer CGNAT isn't solving problems, it's creating more.
>>
>> The end of IPv4 isn't nigh, it's just privileged only.
>>
>> PS When you solve that problem in 50 years time, I'll be one of those old
>> fogey's keeping an IPv4 service alive as an example of "the old Internet"
>> for those young whippersnappers to be amazed by.
>>
>> Regards,
>>Brett
>>
>>
>
> 
> Virus-free.www.avast.com

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

[sronan]

Please don’t use the term RAN, this acronym already has a very specific definition in the telecom/network space as “Radio Access Network.”ShaneOn Jan 15, 2024, at 5:12 PM, Abraham Y. Chen  wrote:

  

  
  
Hi, Forrest:

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

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

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

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

  
Regards,

  

  
Abe (2024-01-15 00:02)

  


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


  
  
A couple of points: 


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


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


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


I see no reason why IPv4 should be any
  different.  

  
On Fri, Jan 12, 2024, 3:42
  PM Abraham Y. Chen 
  wrote:


  
Hi, Forrest:
0)    You put out more than one topic,
all at one time. Allow me to address each briefly.
1)   "  The existence of that CG-NAT
box is a thorn in every provider's side and every
provider that has one wants to make it go away as
quickly as possible.   ":
    The feeling and desire are
undeniable facts. However, the existing
configuration was evolved from various
considerations through a long time. There is a
tremendous inertia accumulated on it. There is no
magic bullet to get rid of it quickly. We must study carefully to evolve it
further incrementally. Otherwise, an even bigger
headache or disaster will happen.
  
2)    "  The
quickest and most straightforward way to eliminate
the need for any CG-NAT is to move to a bigger
address 

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

[Abraham Y. Chen]

Hi, Forrest:

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


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


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


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


Regards,


Abe (2024-01-15 00:02)


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

A couple of points:

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


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


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


I see no reason why IPv4 should be any different.

On Fri, Jan 12, 2024, 3:42 PM Abraham Y. Chen  wrote:

Hi, Forrest:

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

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

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

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

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

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

    This strategy is easily said than done. It reminds me of my
system planning work for the old AT 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.

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

[Abraham Y. Chen]

Hi, Forrest:

1)    I have a question:

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


Regards,


Abe (2024-01-15 15:20)



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

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


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


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


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


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


On Sat, Jan 13, 2024, 2:04 AM Brett O'Hara  wrote:

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

IPv4 is never ever going away.

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

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

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

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

Regards,
   Brett



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

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

[Brian Knight via NANOG]

On 2024-01-13 04:03, Brett O'Hara wrote:

They have no interest in trying new things or making new technology 
work without a solid financial reason and there is none for them 
implementing ipv6.


When I left $DAYJOB-1 almost 2 years ago, they had just finished 
increasing fees on IPv4 blocks (larger than /29) that had already been 
assigned to customers.


This wasn't on new assignments only. It was applied to all Internet 
customers with /28 and larger assignments that were already assigned and 
working at the time of the increase.


I know $DAYJOB-1 weren't alone in the NSP industry.

Also, one very large cloud provider I use for personal projects is 
charging additional fees for IPv4 starting this year. My cost for (3) 
IPv4 addresses went from zero to $10.80/mo/ip, jacking up my bill about 
20%. These were IPs assigned to my services 6-7 years ago.


There is a financial reason looming. I grant you that, at the moment, it 
may still be low enough to be considered "cost of doing business" for 
nearly all enterprises. But it's exerting force like a glacier does; 
slowly, irregularly, yet inexorably; so it can be difficult to see.


-Brian

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

[Vasilenko Eduard via NANOG]

+1

From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] On 
Behalf Of Brett O'Hara
Sent: Saturday, January 13, 2024 1:04 PM
To: Forrest Christian (List Account) 
Cc: Chen, Abraham Y. ; NANOG 
Subject: Re: One Can't Have It Both Ways Re: Streamline the CG-NAT Re: EzIP Re: 
IPv4 address block

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

IPv4 is never ever going away.

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

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

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

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

Regards,
   Brett



On Sat, Jan 13, 2024 at 7:31 PM Forrest Christian (List Account) 
mailto:li...@packetflux.com>> wrote:
A couple of points:

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

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

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

I see no reason why IPv4 should be any different.

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

Hi, Forrest:

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

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

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

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

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

3)   "  Until the cost (or pain) to stay on IPv4 is greater than the cost to 
m

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

[Brett O'Hara]

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

IPv4 is never ever going away.

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

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

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

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

Regards,
   Brett



On Sat, Jan 13, 2024 at 7:31 PM Forrest Christian (List Account) <
li...@packetflux.com> wrote:

> A couple of points:
>
> 1) There is less work needed to support IPv6 than your proposed solution.
> I'm not taking about 230/4.  I'm talking about your EzIP overlay.
>
> 2) Assume that Google decided that they would no longer support IPv4 for
> any of their services at a specific date a couple of years in the future.
> That is,  you either needed an IPv6 address or you couldn't reach Google,
> youtube, Gmail and the rest of the public services.  I bet that in this
> scenario every eyeball provider in the country all of a sudden would be
> extremely motivated to deploy IPv6, even if the IPv4 providers end up
> natting their IPv4 customers to IPv6.  I really expect something like this
> to be the next part of the end game for IPv4.
>
> Or stated differently: at some point someone with enough market power is
> going to basically say "enough is enough" and make the decision for the
> rest of us that IPv4 is effectively done on the public internet.   The
> large tech companies all have a history of sunsetting things when it
> becomes a bigger problem to support than it's worth.  Try getting a modern
> browser that works on 32 bit windows.   Same with encryption protocols,
> Java in the browser,  Shockwave and flash, and on and on.
>
> I see no reason why IPv4 should be any different.
>
> On Fri, Jan 12, 2024, 3:42 PM Abraham Y. Chen  wrote:
>
>> Hi, Forrest:
>>
>> 0)You put out more than one topic, all at one time. Allow me to
>> address each briefly.
>>
>> 1)   "  The existence of that CG-NAT box is a thorn in every provider's
>> side and every provider that has one wants to make it go away as quickly as
>> possible.   ":
>>
>> The feeling and desire are undeniable facts. However, the existing
>> configuration was evolved from various considerations through a long time.
>> There is a tremendous inertia accumulated on it. There is no magic bullet
>> to get rid of it quickly. We must study carefully to evolve it further
>> incrementally. Otherwise, an even bigger headache or disaster will happen.
>>
>> 2)"  The quickest and most straightforward way to eliminate the need
>> for any CG-NAT is to move to a bigger address space.  ":
>>
>> The obvious answer was IPv6. However, its performance after near two
>> decades of deployment has not been convincing. EzIP is an alternative,
>> requiring hardly any development, to address this need immediately.
>>
>> 3)   "  Until the cost (or pain) to stay on IPv4 is greater than the
>> cost to move,  we're going to see continued resistance to doing so.   ":
>>
>> This strategy is easily said than done. It reminds me of my system
>> planning work for the old AT 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 

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

[Brandon Butterworth]

On 13/01/2024, 08:40:11, "Giorgio Bonfiglio via NANOG"  
wrote:

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


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


A step before that might not cost anything: add IPv6 search ranking 
boost

and see how fast the SEO hawkers push all content to v6, then it's just
down to those with cgnat realising they can save money by moving to IPv6 
too.


brandon

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

[Forrest Christian (List Account)]

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

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

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

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

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

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

On Sat, Jan 13, 2024, 2:04 AM Brett O'Hara  wrote:

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

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

[Giorgio Bonfiglio via NANOG]

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

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

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

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

[Forrest Christian (List Account)]

A couple of points:

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

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

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

I see no reason why IPv4 should be any different.

On Fri, Jan 12, 2024, 3:42 PM Abraham Y. Chen  wrote:

> Hi, Forrest:
>
> 0)You put out more than one topic, all at one time. Allow me to
> address each briefly.
>
> 1)   "  The existence of that CG-NAT box is a thorn in every provider's
> side and every provider that has one wants to make it go away as quickly as
> possible.   ":
>
> The feeling and desire are undeniable facts. However, the existing
> configuration was evolved from various considerations through a long time.
> There is a tremendous inertia accumulated on it. There is no magic bullet
> to get rid of it quickly. We must study carefully to evolve it further
> incrementally. Otherwise, an even bigger headache or disaster will happen.
>
> 2)"  The quickest and most straightforward way to eliminate the need
> for any CG-NAT is to move to a bigger address space.  ":
>
> The obvious answer was IPv6. However, its performance after near two
> decades of deployment has not been convincing. EzIP is an alternative,
> requiring hardly any development, to address this need immediately.
>
> 3)   "  Until the cost (or pain) to stay on IPv4 is greater than the cost
> to move,  we're going to see continued resistance to doing so.   ":
>
> This strategy is easily said than done. It reminds me of my system
> planning work for the old AT 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 

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