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:

    I

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 
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 









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

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 > <mailto:br...@fj.com.au>> wrote:
>>> Ok you've triggered me on your point 2.  I'll address the elephant in the 
>>> room.
>>> 
>>> IPv4 is never ever going away.
>>> 
>>> Right now consumer services are mostly (mobile, wireless, landline, wide 
>>> generalization) are IPv6 capable.  Most consumer applications are ipv6 
>>> capable, Google, Facebook, etc.There is light at the very end of the tunnel 
>>> that suggests that one day we won't have to deploy CGNAT444 for our 
>>> consumers to get to content, we may only have to do NAT64 for them to get 
>>> to the remaining Ipv4 Internet.  We're still working hard on removing our 
>>> reliance on genuine ipv4 ranges to satisfy our customer needs, It's still a 
>>> long way off, but it's coming.
>>> 
>>> Here's the current problem.  Enterprise doesn't need ipv6 or want ipv6.  
>>> You might be able to get away with giving CGNAT to your consumers, but your 
>>> enterprise customer will not accept this. How will they terminate their 
>>> remote users?  How will they do B2B with out inbound NAT?  Yes, there are 
>>> solutions, but if you don't need to, why?  They pay good money, why can't 
>>> they h

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 Conten

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&T decided everything. I am sure
>> that Internet players will try very hard to avoid being labelled as such.
>>
>> Regards,
>>
>>
>> Abe (2024-01-15 00:02)
>>
>>
>> On 2024-01-13 03:30, Forrest Christian (List Account) wrote:
>>
>> A couple of points:
>>
>> 1) There is les

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&T decided everything. I am sure
> that Internet players will try very hard to avoid being labelled as such.
>
> Regards,
>
>
> Abe (2024-01-15 00:02)
>
>
> On 2024-01-13 03:30, Forrest Christian (List Account) wrote:
>
> A couple of points:
>
> 1) There is less work needed to support IPv6 than your proposed solution.
> I'm not taking about 230/4.  I'm talking about your EzIP overlay.
>
> 2) Assume that Google decided that they would no longer support IPv4 for
> any of their services at a specific date a couple of years in the future.
> That is,  you either needed an IPv6 address or you couldn't reach Google,
> youtube, Gmail and the rest of the public services.  I bet that in this
> scenario every eyeball provider in the country all of a sudden would be
> extremely motivated to deploy IPv6, even if the IPv4 providers end up
> natting their IPv4 customers to IPv6.  I really expect something like this
> to be the next part of the end game for IPv4.
>
> Or stated differently: at some point someone with enough market power is
> going to basically say "enough is enough" and make the decision for the
> rest of us that IPv4 is effectively done on the public internet.   The
> large tech companies all have a

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&T decided everything. I am sure that Internet
  players will try very hard to avoid being labelled as
  such.
  

  Regards,
  

  

  Abe (2024-01-15
  00:02)
  

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


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

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&T decided everything. I am sure that 
Internet players will try very hard to avoid being labelled as such.


Regards,


Abe (2024-01-15 00:02)


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

A couple of points:

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


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


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


I see no reason why IPv4 should be any different.

On Fri, Jan 12, 2024, 3:42 PM Abraham Y. Chen  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

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

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&T decided
everything. I am sure that Internet players will try very hard
to avoid being labelled as such.

  
Regards,

  

  
Abe (2024-01-15 00:02)

  


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


  
  
A couple of points: 


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


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


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


I see no reason why IPv4 should be any
  different.  

  
On Fri, Jan 12, 2024, 3:42
  PM Abraham Y. Chen <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 stra

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&T decided 
everything. I am sure that Internet players will try very hard to avoid 
being labelled as such.


Regards,


Abe (2024-01-15 00:02)


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

A couple of points:

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


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


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


I see no reason why IPv4 should be any different.

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

Hi, Forrest:

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

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

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

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

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

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

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

    Fast forward by half a century, the Internet promotes
distributed approaches. Few things can be controlled by limited
couple part

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 develop

Re: How threading works (was Re: Root Cause Re: 202401102221.AYC Re: Streamline The CG-NAT Re: 202401100645.AYC Re: IPv4 address block)

[Jay R. Ashworth]

- Original Message -
> From: "William Herrin" 

> Respectfully, your MUA is not the only MUA. Others work differently.
> 
> GMail, for example, follows the message IDs as you say but assumes
> that if you change the subject line in your reply (more than adding
> "Re:") then you intend to start a new thread from that point in the
> discussion. It groups messages accordingly.
> 
> This is not an unreasonable expectation: if you merely want to
> continue the current conversation without going off on a new tangent
> then there's no need for a different subject line.

Maybe it's not.

Looking at threads in NANOGs piper, though, it's easy to see threads where
the Subject line evolves to follow the conversation, without dropping people
who still want to participate in it.

The fact that the "(was: old subject)" convention continues in good service
to this day, *even though no mailer does that for you* (so far as I'm aware)
suggests that people will put in the effort, to me at least.

The number of times when I've consciously wanted to break a reply chain -- and
usually was not provided with the facility by my mailer -- is much smaller than
the number when I wanted it to continue.  The only mailer I remember being able
to do it in, really, is mutt, where you could get all the headers into vi, and
delete In-Reply-To:.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re: How threading works (was Re: Root Cause Re: 202401102221.AYC Re: Streamline The CG-NAT Re: 202401100645.AYC Re: IPv4 address block)

[Jay R. Ashworth]

- Original Message -
> From: "Abraham Y. Chen" 

> Hi, Bryan:

[ ... ]

> 2)    From the Wikipedia explanation of RFC5822, I as a ThunderBird
> user, really have nothing to do with the Message-ID that it puts on my
> MSGs nor how does it make use of such to display the threads. And, my
> Subject line style can't affect it either. So, why some colleagues are
> having difficulties with just my eMails, but seemly not from others?
> Could this be caused by the large number of MSGs within a short period
> of time that amplified this issue? From another feedback, I realized
> that some colleagues may be using plain text text editors or alike for
> eMail, because they could not see color nor italic emphasizing of my
> text. Could such be related to this issue?

Well, when Bryan says:
>> Threading has nothing to do with subject lines.  RFC822 (now 5822)
>> specifies how this works based on message ID.  This thread displays
>> fine in threaded mode in my MUA and in the archives.

he's not wrong... but he fails to take into account that there are still
email clients which don't thread based on *that*, as they should; they
make up cock-a-mamie rules about the contents of the Subject line, and 
use those to thread with, and those clients *will* come apart if you make
'gratuitous' edits to it.

Well, at least, this *has been* a running problem for 20 or 30 years; I don't
have my fingers on a list of which clients get it right and which wrong, and
which might have gotten religion over the years on the topic.  5322 isn't my
primary RFC.  :-)

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re: How threading works (was Re: Root Cause Re: 202401102221.AYC Re: Streamline The CG-NAT Re: 202401100645.AYC Re: IPv4 address block)

[Christopher Hawker]

Bryan:

> Gmail is therefore in violation of the RFC5822.  It's quite clear how it
should work per the RFC appendix.

Actually, no it's not. RFC5322 reads: "This specification is not intended
to dictate ... any of the characteristics of user interface programs that
create or read messages".

5822 has not been issued, see https://www.rfc-editor.org/info/rfc5822.

Abraham:

> For more than one year, I have been accused of breaking the eMail
etiquette established by a standard, yet identified.

If multiple people have been asking you for over a year to not change
subject headings on emails, does this not indicate a bigger issue regarding
your mailing list etiquette? The fact that it continues indicates a
complete disregard. I cannot think of one technical reason to include a
manual timestamp in a subject line (such as your 202401102221.AYC).

> If we have trouble to keep our communication tool's framework solid, we
will be spending needless extra resources on technical discussions. This is
not productive.

One person changing the subject line of a mailing list thread every few
emails for their own benefit, and no one else, is not productive. There is
nothing wrong with MUAs currently in use. A user adapts to the MUA, not the
other way around.

> Obviously, I am just barely able to read the exchanges on this thread due
to so many terminologies that I have never heard of.

If a number of people on a mailing list were using terminologies that I
didn't understand, I would:
1. Listen to and understand what they are saying.
2. Contact them off-list and ask for clarification.
3. Heed their advice.

Regards,
Christopher Hawker

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

> Hi, Bryan:
>
> 1)"  ...  Gmail is therefore in violation of the RFC5822. ...  I
> think it's quite unreasonable to expect others to compensate for an MUA which
> doesn't implement 25+ year old standards properly. ...  ":
>
> I am so glad that you decided to come out to be a well-informed
> referee. For more than one year, I have been accused of breaking the eMail
> etiquette established by a standard, yet never identified. It seriously
> distracted our attention from the topic of essence. You now have
> demonstrated that the reverse appears to be the case. What a big surprise!
>
> 2)If we have trouble to keep our communication tool's framework solid,
> we will be spending needless extra resources on technical discussions. This
> is not productive.
>
> 3)Obviously, I am just barely able to read the exchanges on this
> thread due to so many terminologies that I have never heard of. I shall
> remain silent on this thread from now on, awaiting for you to lead us out
> of this puzzlement.
>
> Sincerely and Best Regards,
>
>
> Abe (2024-01-14 08:11 EST)
>
>
>
> On 2024-01-14 03:53, Bryan Fields wrote:
>
> On 1/14/24 1:01 AM, William Herrin wrote:
>
> Respectfully, your MUA is not the only MUA. Others work differently.
>
> Bill, I use multiple MUA's, among them Thunderbird, mutt, kmail and even the
> zimbra web interface.  All follow and implement RFC5822 as it pertains to
> threading.
>
> Note, threading works fine in the list archives too, but only displays two
> levels deep.
>
>
> GMail, for example, follows the message IDs as you say but assumes
> that if you change the subject line in your reply (more than adding
> "Re:") then you intend to start a new thread from that point in the
> discussion. It groups messages accordingly.
>
> Gmail is therefore in violation of the RFC5822.  It's quite clear how it
> should work per the RFC appendix.
>
>
> This is not an unreasonable expectation: if you merely want to
> continue the current conversation without going off on a new tangent
> then there's no need for a different subject line.
>
> I think it's quite unreasonable to expect others to compensate for an MUA
> which doesn't implement 25+ year old standards properly.
>
>
>
>
> 
> Virus-free.www.avast.com
> 
> <#m_4325909844379148972_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>

Re: How threading works (was Re: Root Cause Re: 202401102221.AYC Re: Streamline The CG-NAT Re: 202401100645.AYC Re: IPv4 address block)

[Tom Beecher]

>
> Gmail is therefore in violation of the RFC5822.  It's quite clear how it
> should work per the RFC appendix.
>

Well, no. Asterisks added for emphasis.

 This specification is intended as a definition of what message
>content format is to be passed between systems.  Though some message
>systems locally store messages in this format (which eliminates the
>need for translation between formats) and others use formats that
>differ from the one specified in this specification, local storage is
>outside of the scope of this specification.
>
>   Note: This specification is not intended to dictate the internal
>   formats used by sites, the specific message system features that
>   they are expected to support, *** or any of the characteristics of
>   user interface programs that create or read messages. ***  In
>   addition, this document does not specify an encoding of the
>   characters for either transport or storage; that is, it does not
>   specify the number of bits used or how those bits are specifically
>   transferred over the wire or stored on disk.
>
> 5822 defines the structure and syntax of the data. Not how mail agents
should work with it.



On Sun, Jan 14, 2024 at 3:55 AM Bryan Fields  wrote:

> On 1/14/24 1:01 AM, William Herrin wrote:
> > Respectfully, your MUA is not the only MUA. Others work differently.
>
> Bill, I use multiple MUA's, among them Thunderbird, mutt, kmail and even
> the
> zimbra web interface.  All follow and implement RFC5822 as it pertains to
> threading.
>
> Note, threading works fine in the list archives too, but only displays two
> levels deep.
>
> > GMail, for example, follows the message IDs as you say but assumes
> > that if you change the subject line in your reply (more than adding
> > "Re:") then you intend to start a new thread from that point in the
> > discussion. It groups messages accordingly.
>
> Gmail is therefore in violation of the RFC5822.  It's quite clear how it
> should work per the RFC appendix.
>
> > This is not an unreasonable expectation: if you merely want to
> > continue the current conversation without going off on a new tangent
> > then there's no need for a different subject line.
>
> I think it's quite unreasonable to expect others to compensate for an MUA
> which doesn't implement 25+ year old standards properly.
> --
> Bryan Fields
>
> 727-409-1194 - Voice
> http://bryanfields.net
>

Re: How threading works (was Re: Root Cause Re: 202401102221.AYC Re: Streamline The CG-NAT Re: 202401100645.AYC Re: IPv4 address block)

[James R Cutler]

On Sat, Jan 13, 2024 at 12:58 PM Bryan Fields mailto:br...@bryanfields.net>> wrote:
> On 1/12/24 3:04 PM, Mu wrote:
>> 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.
> 
> Threading has nothing to do with subject lines.  RFC822 (now 5822) specifies
> how this works based on message ID.  This thread displays fine in threaded
> mode in my MUA and in the archives.

Bryan,

My personal use of email agents involves ordering incoming messages by date 
sent. Many others order their inbox by date received. I don't use MUA ordering 
by thread or conversation because I must use MUAs on many diverse systems. So 
for many decades, I have continued to use my own mental programming to sort and 
group messages by subject. This, by the way, is akin to aural conversations 
between persons where announcing a change of subject is expected to be followed 
by a new topic.

For those of us on OCD, ADD, or Autism spectrums, multiple subjects lines cause 
cognitive dissonance - sometimes damaging comprehension of the continuing 
thread (conversation). I don't claim it violates the ADA, but it should 
especially when willfully continued after requests for amended behavior. 
Lazarus Long would probably express this more cogently.

In the interest of polite conversation,
-
James R. Cutler
james.cut...@consultant.com

Re: How threading works (was Re: Root Cause Re: 202401102221.AYC Re: Streamline The CG-NAT Re: 202401100645.AYC Re: IPv4 address block)

[Giorgio Bonfiglio via NANOG]

> I am so glad that you decided to come out to be a well-informed referee. 
> For more than one year, I have been accused of breaking the eMail etiquette 
> established by a standard, yet never identified. It seriously distracted our 
> attention from the topic of essence. You now have demonstrated that the 
> reverse appears to be the case. What a big surprise! 

Even if it doesn’t break the threading RFCs, I am at a loss looking for a 
reason why the subject line of a thread should be a/ arbitrarily changed 
without a correlated change in subject, b/ extended to a point where it takes 
1/3rd of the screen of my iPhone and doesn’t fit in the table view in my 
Thunderbird and c/ in a list with thousands of individuals be changed to 
include some sort of timestamp specific to one of them (202401102221.AYC).

Please, think at scale. If every single one of us had to randomly change 
subject at every response or add their own timestamp (why even?) 
202401151356.BG this would quickly get out of hand.

I don’t think we need to be in specific breach of an RFC to ask an individual 
which is clearly acting off the standard ML practice to please stop, no?

Re: How threading works (was Re: Root Cause Re: 202401102221.AYC Re: Streamline The CG-NAT Re: 202401100645.AYC Re: IPv4 address block)

[Abraham Y. Chen]

Hi, Bryan:

1)    "  ...  Gmail is therefore in violation of the RFC5822. ... I 
think it's quite unreasonable to expect others to compensate for an MUA 
which doesn't implement 25+ year old standards properly. ...  ":


    I am so glad that you decided to come out to be a well-informed 
referee. For more than one year, I have been accused of breaking the 
eMail etiquette established by a standard, yet never identified. It 
seriously distracted our attention from the topic of essence. You now 
have demonstrated that the reverse appears to be the case. What a big 
surprise!


2)    If we have trouble to keep our communication tool's framework 
solid, we will be spending needless extra resources on technical 
discussions. This is not productive.


3)    Obviously, I am just barely able to read the exchanges on this 
thread due to so many terminologies that I have never heard of. I shall 
remain silent on this thread from now on, awaiting for you to lead us 
out of this puzzlement.


Sincerely and Best Regards,


Abe (2024-01-14 08:11 EST)



On 2024-01-14 03:53, Bryan Fields wrote:

On 1/14/24 1:01 AM, William Herrin wrote:

Respectfully, your MUA is not the only MUA. Others work differently.

Bill, I use multiple MUA's, among them Thunderbird, mutt, kmail and even the
zimbra web interface.  All follow and implement RFC5822 as it pertains to
threading.

Note, threading works fine in the list archives too, but only displays two
levels deep.


GMail, for example, follows the message IDs as you say but assumes
that if you change the subject line in your reply (more than adding
"Re:") then you intend to start a new thread from that point in the
discussion. It groups messages accordingly.

Gmail is therefore in violation of the RFC5822.  It's quite clear how it
should work per the RFC appendix.


This is not an unreasonable expectation: if you merely want to
continue the current conversation without going off on a new tangent
then there's no need for a different subject line.

I think it's quite unreasonable to expect others to compensate for an MUA
which doesn't implement 25+ year old standards properly.




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

Re: How threading works (was Re: Root Cause Re: 202401102221.AYC Re: Streamline The CG-NAT Re: 202401100645.AYC Re: IPv4 address block)

[Bryan Fields]

On 1/14/24 1:01 AM, William Herrin wrote:
> Respectfully, your MUA is not the only MUA. Others work differently.

Bill, I use multiple MUA's, among them Thunderbird, mutt, kmail and even the
zimbra web interface.  All follow and implement RFC5822 as it pertains to
threading.

Note, threading works fine in the list archives too, but only displays two
levels deep.

> GMail, for example, follows the message IDs as you say but assumes
> that if you change the subject line in your reply (more than adding
> "Re:") then you intend to start a new thread from that point in the
> discussion. It groups messages accordingly.

Gmail is therefore in violation of the RFC5822.  It's quite clear how it
should work per the RFC appendix.

> This is not an unreasonable expectation: if you merely want to
> continue the current conversation without going off on a new tangent
> then there's no need for a different subject line.

I think it's quite unreasonable to expect others to compensate for an MUA
which doesn't implement 25+ year old standards properly.
-- 
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net

Re: How threading works (was Re: Root Cause Re: 202401102221.AYC Re: Streamline The CG-NAT Re: 202401100645.AYC Re: IPv4 address block)

[William Herrin]

On Sat, Jan 13, 2024 at 12:58 PM Bryan Fields  wrote:
> On 1/12/24 3:04 PM, Mu wrote:
> > 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.
>
> Threading has nothing to do with subject lines.  RFC822 (now 5822) specifies
> how this works based on message ID.  This thread displays fine in threaded
> mode in my MUA and in the archives.

Hi Bryan,

Respectfully, your MUA is not the only MUA. Others work differently.

GMail, for example, follows the message IDs as you say but assumes
that if you change the subject line in your reply (more than adding
"Re:") then you intend to start a new thread from that point in the
discussion. It groups messages accordingly.

This is not an unreasonable expectation: if you merely want to
continue the current conversation without going off on a new tangent
then there's no need for a different subject line.

Regards,
Bill Herrin



-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: How threading works (was Re: Root Cause Re: 202401102221.AYC Re: Streamline The CG-NAT Re: 202401100645.AYC Re: IPv4 address block)

[Joel Esler]

Things you have to remember.  Not everyone uses thunderbird.  Not every mail client threads like thunderbird.  — Sent from my iPhoneOn Jan 13, 2024, at 17:39, Abraham Y. Chen  wrote:

  

  
  
Hi, Bryan:

  
0)    Thank you so much
for coming to the rescue!!! 
  

  
1)    Basically trained
as a radio frequency hardware engineer, I am only capable of
using software as tools necessary for my work. For eMail, I have
been using ThunderBird ever since its beginning. With my own
time-stamping Subject line discipline, I never needed its
threading function. When I received complaints last year, I
experimented threading on it and found that it was doing just
fine. Whether I prefixed or suffixed the timestamps to the
Subject line could not break it. I requested counter examples
from those who were having difficulties with my MSGs, but
received none. Frustrated but not able to do anything, I went
back to continue my EzIP work, leaving this subject in the back
burner of my mind. This time around, the problem popped up again
in the midst of large number of MSG exchanges. I am so relieved
that you presented the threading on the NANOG eMail server that
mirrors what I saw on my own PC. So, we now have a common
reference for everyone to look at this phenomenon. (Why no one else knew about this facility?) 
  

  
2)    From the Wikipedia
explanation of RFC5822, I as a ThunderBird user, really have
nothing to do with the Message-ID that it puts on my MSGs nor
how does it make use of such to display the threads. And, my
Subject line style can't affect it either. So, why some
colleagues are having difficulties with just my eMails, but
seemly not from others? Could this be caused by the large number
of MSGs within a short period of time that amplified this issue?
From another feedback, I realized that some colleagues may be
using plain text text editors or alike for eMail, because they
could not see color nor italic emphasizing of my text. Could
such be related to this issue?
  

  
I would appreciate very
much if you could advance my education with some explanations
after perhaps discussions with those offended by my MSGs. 
  


Regards,

  

  
Abe (2024-01-13 17:37)



 







On
  1/12/24 3:04 PM, Mu wrote: 
  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. 
  
  
  Threading has nothing to do with subject lines.  RFC822 (now 5822)
  specifies how this works based on message ID.  This thread
  displays fine in threaded mode in my MUA and in the archives. 
  
  https://en.wikipedia.org/wiki/Conversation_threading
  
  https://mailman.nanog.org/pipermail/nanog/2024-January/thread.html
  
  
  If people could please reply to threads properly, inline and
  trimming non relevant text, it would make following discussion
  much easier. 
  



  Virus-free.www.avast.com 

Re: How threading works (was Re: Root Cause Re: 202401102221.AYC Re: Streamline The CG-NAT Re: 202401100645.AYC Re: IPv4 address block)

[Abraham Y. Chen]

Hi, Bryan:

0)    Thank you so much for coming to the rescue!!!

1)    Basically trained as a radio frequency hardware engineer, I am 
only capable of using software as tools necessary for my work. For 
eMail, I have been using ThunderBird ever since its beginning. With my 
own time-stamping Subject line discipline, I never needed its threading 
function. When I received complaints last year, I experimented threading 
on it and found that it was doing just fine. Whether I prefixed or 
suffixed the timestamps to the Subject line could not break it. I 
requested counter examples from those who were having difficulties with 
my MSGs, but received none. Frustrated but not able to do anything, I 
went back to continue my EzIP work, leaving this subject in the back 
burner of my mind. This time around, the problem popped up again in the 
midst of large number of MSG exchanges. I am so relieved that you 
presented the threading on the NANOG eMail server that mirrors what I 
saw on my own PC. So, we now have a common reference for everyone to 
look at this phenomenon. (Why no one else knew about this facility?)


2)    From the Wikipedia explanation of RFC5822, I as a ThunderBird 
user, really have nothing to do with the Message-ID that it puts on my 
MSGs nor how does it make use of such to display the threads. And, my 
Subject line style can't affect it either. So, why some colleagues are 
having difficulties with just my eMails, but seemly not from others? 
Could this be caused by the large number of MSGs within a short period 
of time that amplified this issue? From another feedback, I realized 
that some colleagues may be using plain text text editors or alike for 
eMail, because they could not see color nor italic emphasizing of my 
text. Could such be related to this issue?


I would appreciate very much if you could advance my education with some 
explanations after perhaps discussions with those offended by my MSGs.



Regards,


Abe (2024-01-13 17:37)






On 1/12/24 3:04 PM, Mu wrote:
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.


Threading has nothing to do with subject lines.  RFC822 (now 5822) 
specifies how this works based on message ID.  This thread displays 
fine in threaded mode in my MUA and in the archives.


https://en.wikipedia.org/wiki/Conversation_threading
https://mailman.nanog.org/pipermail/nanog/2024-January/thread.html

If people could please reply to threads properly, inline and trimming 
non relevant text, it would make following discussion much easier.





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

How threading works (was Re: Root Cause Re: 202401102221.AYC Re: Streamline The CG-NAT Re: 202401100645.AYC Re: IPv4 address block)

[Bryan Fields]

On 1/12/24 3:04 PM, Mu wrote:

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.


Threading has nothing to do with subject lines.  RFC822 (now 5822) specifies 
how this works based on message ID.  This thread displays fine in threaded 
mode in my MUA and in the archives.


https://en.wikipedia.org/wiki/Conversation_threading
https://mailman.nanog.org/pipermail/nanog/2024-January/thread.html

If people could please reply to threads properly, inline and trimming non 
relevant text, it would make following discussion much easier.


--
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net

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 

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

[Abraham Y. Chen]

Hi, Christopher:

Thanks for the confirmation.

Regards,


Abe (2024-01-13 11:42)


On 2024-01-12 07:30, Christopher Hawker wrote:
"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.






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

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



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








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

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

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&T. At that time, Bell Operating Companies
> (BOCs) could be coerced to upgrade their facility by just gradually raising
> the cost of owning the old equipment by assuming fewer would be be used,
> while the newer version would cost less because growing number of
> deployments. Looking at resultant financial forecast, the BOC decisions
> were easy. Originally trained as a hardware radio engineer, I was totally
> stunned. But, it worked well under the regulated monopoly environment.
>
> Fast forward by half a century, the Internet promotes distributed
> approaches. Few things can be controlled by limited couple parties. The
> decision of go or no-go is made by parties in the field who have their own
> respective considerations. Accumulated, they set the direction of the
> Internet. In this case, IPv6 has had the opportunity of over four decades
> of planning and nearly two decades of deployment. Its future growth rate is
> set by its own performance merits. No one can force its rate by persuasion
> tactic of any kind. Hoping so is wishful thinking which contributes to
> wasteful activities. So, we need realistic planning.
> Regards,
>
>
> Abe (2024-01-12 18:42)
>
>
>
> On 2024-01-12 01:34, Forrest Christian (List Account) wrote:
>
> The problem isn't the quantity of "inside" CG-NAT address space.  It's the
> existence of CG-NAT at all.
>
> It doesn't matter if the available space is a /12 or a /4, you still need
> something to translate it to the public internet.   The existence of that
> CG-NAT box is a thorn in every provider's side and every provider that has
> one wants to make it go away as quickly as possible.
>
> The quickest and most straightforward way to eliminate the need for any
> CG-NAT is to move to a bigger address space.  As I pointed out, IPv6 is
> already ready and proven to work so moving to IPv6 is a straightforward
> process technically.  What isn't straightforward is convincing IPv4 users
> to move.  Until the cost (or pain) to stay on IPv4 is greater than the cost
> to move,  we're going to see continued resistance to doing so.
>
>

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&T. At that time, Bell Operating 
Companies(BOCs) could be coerced to upgrade their facility by just 
gradually raising the cost of owning the old equipment by assuming fewer 
would be be used, while the newer version would cost less because 
growing number of deployments. Looking at resultant financial forecast, 
the BOC decisions were easy. Originally trained as a hardware radio 
engineer, I was totally stunned. But, it worked well under the regulated 
monopoly environment.


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


Regards,


Abe (2024-01-12 18:42)



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


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


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



On Thu, Jan 11, 2024, 7:36 PM Abraham Y. Chen  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: 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: 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.
>>
>>
>>
>>
>>
>>>
>>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>>> Virus-free.www.avast.com
>>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>>> <#m_7003280393758044796_m_-3759812132042785637_m_-2040759016673337921_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>>
>>
>>
>

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.






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

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



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






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

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

[Forrest Christian (List Account)]

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

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

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


On Thu, Jan 11, 2024, 7:36 PM Abraham Y. Chen  wrote:

> Hi, Forrest:
>
> 0)Thanks for your in-depth analysis.
>
> 1) However, my apologies for not presenting the EzIP concept clearer.
> That is, one way to look at the EzIP scheme is to substitute the current
> 100.64/10  netblock in the CG-NAT with 240/4. Everything else in the
> current CG-NAT setup stays unchanged. This makes each CG-NAT cluster 64
> fold bigger. And, various capabilities become available.
>
> Regards,
>
> Abe (2024-01-11 22:35)
>
>
>
> On 2024-01-11 02:02, Forrest Christian (List Account) wrote:
>
> I shouldn't probably go down this path... as I know this has been
> discussed but I'm hoping that this might make a difference.
>
> Abraham,
>
> Even if 240/4 is "fixed", your EzIP scheme will require some sort of NAT
> box between the 240/4 addressed devices and the non-EzIP internet.  That
> NAT box will have to remain in place until such time as every single
> publically addressed device on the public internet has been updated to
> support EzIP.  In addition, protocols such as DNS, SIP, and others which
> pass around addresses will need to be updated to be able to pass the full
> EzIP addressing around so endpoints can properly insert the EzIP header,
> and so on.
>
> The point I'm trying to make is that, at this point, deploying EzIP as an
> end to end address exhaustion solution has MORE challenges that simply
> deploying IPv6 would.  This is because, just like EzIP, deploying IPv6
> requires a NAT box of some sort to be put in place until the last IPv4
> device is turned off.   But unlike EzIP, almost every new device coming out
> supports IPv6 out of the box.   All of the technical standards work has
> already been done.   Thus, the only meaningful barrier to IPv6 at this
> point is convincing people to use it, not convincing people to use it PLUS
> convincing the tech companies to support it,  and doing protocol changes
> like you would with EzIP.
>
> I applaud your attempt at a unique solution but I really feel that ship
> has sailed, at least for an EzIP type of solution. Maybe something like
> this would have better received years ago, but at this point IPv6 is a much
> more logical path forward.
>
> I do wonder,  however,  if some of your concepts might be able to be
> applied to the IPv6 transition.  I have some ideas here,  but most, if not
> all, of them are only partially cooked but some have similar approaches as
> EzIP but with an actual IPv6 packet inside.
>
>
>
> On Wed, Jan 10, 2024, 7:11 PM Abraham Y. Chen  wrote:
>
>> Hi, Enno:
>>
>> 0)Thanks for your comments referring to historical efforts.
>>
>> 1)However, the "IPv4 Unicast Extension Project" that your paper cited
>> does not make any specific recommendation about how to utilize the 240/4
>> netblock uniformly across the entire Internet. Our proposal, EzIP outlines
>> a scheme that makes a clear use of the 240/4 by the general public,
>> basically discouraging disparate private usages. We were very much lost
>> with what has been going on with the 240/4 netblock, because there was no
>> information about who were using it for what. The RIPE-Lab report clarified
>> the fact that it has been fragmented due to unannounced activities by
>> multi-national conglomerates and likely nerds, while under the cover of
>> "Reserved for Future Use".
>>
>> 2)" As you state yourself this could be considered "unorthodox, if
>> not controversial". ... usually means 'breaks something' ":
>>
>> I am afraid that  you read into my diplomatic expression too far.
>>
>> A.The first step of the EzIP proposal is to enhance the CG-NAT by
>> providing it with a much larger netblock, as I presume that Karim is
>> looking for. Such process (disabli

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

[Christopher Hawker]

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

Regards,
Christopher Hawker

On Fri, 12 Jan 2024 at 14:36, Abraham Y. Chen  wrote:

> Hi, Forrest:
>
> 0)Thanks for your in-depth analysis.
>
> 1) However, my apologies for not presenting the EzIP concept clearer.
> That is, one way to look at the EzIP scheme is to substitute the current
> 100.64/10  netblock in the CG-NAT with 240/4. Everything else in the
> current CG-NAT setup stays unchanged. This makes each CG-NAT cluster 64
> fold bigger. And, various capabilities become available.
>
> Regards,
>
> Abe (2024-01-11 22:35)
>
>
>
> On 2024-01-11 02:02, Forrest Christian (List Account) wrote:
>
> I shouldn't probably go down this path... as I know this has been
> discussed but I'm hoping that this might make a difference.
>
> Abraham,
>
> Even if 240/4 is "fixed", your EzIP scheme will require some sort of NAT
> box between the 240/4 addressed devices and the non-EzIP internet.  That
> NAT box will have to remain in place until such time as every single
> publically addressed device on the public internet has been updated to
> support EzIP.  In addition, protocols such as DNS, SIP, and others which
> pass around addresses will need to be updated to be able to pass the full
> EzIP addressing around so endpoints can properly insert the EzIP header,
> and so on.
>
> The point I'm trying to make is that, at this point, deploying EzIP as an
> end to end address exhaustion solution has MORE challenges that simply
> deploying IPv6 would.  This is because, just like EzIP, deploying IPv6
> requires a NAT box of some sort to be put in place until the last IPv4
> device is turned off.   But unlike EzIP, almost every new device coming out
> supports IPv6 out of the box.   All of the technical standards work has
> already been done.   Thus, the only meaningful barrier to IPv6 at this
> point is convincing people to use it, not convincing people to use it PLUS
> convincing the tech companies to support it,  and doing protocol changes
> like you would with EzIP.
>
> I applaud your attempt at a unique solution but I really feel that ship
> has sailed, at least for an EzIP type of solution. Maybe something like
> this would have better received years ago, but at this point IPv6 is a much
> more logical path forward.
>
> I do wonder,  however,  if some of your concepts might be able to be
> applied to the IPv6 transition.  I have some ideas here,  but most, if not
> all, of them are only partially cooked but some have similar approaches as
> EzIP but with an actual IPv6 packet inside.
>
>
>
> On Wed, Jan 10, 2024, 7:11 PM Abraham Y. Chen  wrote:
>
>> Hi, Enno:
>>
>> 0)Thanks for your comments referring to historical efforts.
>>
>> 1)However, the "IPv4 Unicast Extension Project" that your paper cited
>> does not make any specific recommendation about how to utilize the 240/4
>> netblock uniformly across the entire Internet. Our proposal, EzIP outlines
>> a scheme that makes a clear use of the 240/4 by the general public,
>> basically discouraging disparate private usages. We were very much lost
>> with what has been going on with the 240/4 netblock, because there was no
>> information about who were using it for what. The RIPE-Lab report clarified
>> the fact that it has been fragmented due to unannounced activities by
>> multi-national conglomerates and likely nerds, while under the cover of
>> "Reserved for Future Use".
>>
>> 2)" As you state yourself this could be considered "unorthodox, if
>> not controversial". ... usually means 'breaks something' ":
>>
>> I am afraid that  you read into my diplomatic expression too far.
>>
>> A.The first step of the EzIP proposal is to enhance the CG-NAT by
>> providing it with a much larger netblock, as I presume that Karim is
>> looking for. Such process (disabling the program code that has been
>> disabling the use of 240/4) does not need any running code to prove it. To
>> be blunt, anyone who claims that this will be a real task only shows that
>> he does not know his own code.
>>
>> B.The second EzIP step is to utilize RFC791 for setting up
>> end-to-end links which the Internet has not been able to deliver. This is
>> because the current predominant CG-NAT based CDN business is a master-slave
>> model which does not support it. However, this capability is like
>> international postal or telephony services that are not daily needs for
>> everyone. So, it should be treated as a premium service that can be
>

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

[Abraham Y. Chen]

Hi, Nick:

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


Regards,


Abe (2024-01-11 22:42)


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

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

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


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


Nick




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

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

[Abraham Y. Chen]

Hi, Forrest:

0)    Thanks for your in-depth analysis.

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


Regards,

Abe (2024-01-11 22:35)



On 2024-01-11 02:02, Forrest Christian (List Account) wrote:
I shouldn't probably go down this path... as I know this has been 
discussed but I'm hoping that this might make a difference.


Abraham,

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


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


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


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




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

Hi, Enno:

0)    Thanks for your comments referring to historical efforts.

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

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

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

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

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

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

Regards,


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





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

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

Hi, Karim:

1)?? If you have control of your own equipment (I presume that your
business includes IAP - Internet Access Provider, since you are asking
to buy IPv4 blocks.), you can get a large block of reserved IPv4 address
_/*for free*/_ by _/*disabling*/_ the program c

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

[Tom Beecher]

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


No, it is not.

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

The facts are that *today* :

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

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


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

> Hi, Tom:
>
> 1)Your caution advice to Karim is professional. With a lot of
> convoluted topics behind it, however, the net result is basically
> discouraging the listener from investigating the possibilities. Since this
> is rather philosophical, it can distract us from the essence unless we
> carry on a lengthy debate. Instead, I would like to address below only one
> aspect that you brought up.
>
> 2)"... an operator clearly looking to acquire *publicly routable*
> space without being clear that this suggestion wouldn't meet their needs.
> ":
>
> Since 240/4 has 256M addresses while 100.64/10 has only 4M, a current
> CG-NAT cluster can be expanded 64 fold once the 240/4 is used. Looking from
> another angle, an IAP will then be able to expand the subscriber set 64
> fold with still the original one publicly routable IPv4 address.
>
> 3)This 64 fold scaling factor is critical because it allows one CG-NAT
> cluster to serve a geographical area that becomes sufficient to cover a
> significant political territory. For example, if we assign two 240/4
> addresses to each subscriber, one for stationary applications, one for
> mobile devices. And, each 240/4 address can be expanded by RFC1918
> netblocks (total about 17.6M each). Each CG-NAT can now serve a country
> with population up to 128M. It turns out that population of over 90+ % of
> countries are fewer than this. So, each of them needs only one publicly
> routable IPv4 address. Then, the demand for IPv4 address is drastically
> reduced.
>
> 4)In brief, the 240/4 is to substitute that of 100.64/10. So that the
> need for the publicly routable IPv4 addresses is significantly reduced.
>
> Regards,
>
>
> Abe (2024-01-10 23:08 EST)
>
>
> On 2024-01-10 10:12, Tom Beecher wrote:
>
> Karim-
>
> Please be cautious about this advice, and understand the full context.
>
> 240/4 is still classified as RESERVED space. While you would certainly be
> able to use it on internal networks if your equipment supports it, you
> cannot use it as publicly routable space. There have been many proposals
> over the years to reclassify 240/4, but that has not happened, and is
> unlikely to at any point in the foreseeable future.
>
> Mr. Chen-
>
> I understand your perspective surrounding 240/4, and respect your
> position, even though I disagree. That being said, it's pretty dirty pool
> to toss this idea to an operator clearly looking to acquire *publicaly
> routable* space without being clear that this suggestion wouldn't meet
> their needs.
>
> ( Unless people are transferring RFC1918 space these days, in which case
> who wants to make me an offer for 10/8? )
>
> On Wed, Jan 10, 2024 at 9:48 AM KARIM MEKKAOUI 
> wrote:
>
>> Interesting and thank you for sharing.
>>
>>
>>
>> KARIM
>>
>>
>>
>> *From:* Abraham Y. Chen 
>> *Sent:* January 10, 2024 7:35 AM
>> *To:* KARIM MEKKAOUI 
>> *Cc:* nanog@nanog.org; Chen, Abraham Y. 
>> *Subject:* 202401100645.AYC Re: IPv4 address block
>> *Importance:* High
>>
>>
>>
>> Hi, Karim:
>>
>>
>>
>> 1)If you have control of your own equipment (I presume that your
>> business includes IAP - Internet Access Provider, since you are asking to
>> buy IPv4 blocks.), you can get a large block of reserved IPv4 address *for
>> free* by *disabling* the program codes in your current facility that has
>> been *disabling* the use of 240/4 netblock. Please have a look at the
>> below whitepaper. Utilized according to the outlined disciplines, this is a
>> practically unlimited resources. It has been known that multi-national
>> conglomerates have been using it without announcement. So, you can do so
>> stealthily according to the proposed mechanism which establishes uniform
>> practices, just as w

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

[Ryan Hamel]

Abraham,

There is no need to run one giant cluster. Many small clusters with VRFs and 
CG-NAT devices to bridge the gap from the VRF to the Internet and keep the 
blast radius small, are enough. A CG-NAT ISP should not need to work so hard to 
provide a unique enough CG-NAT IP address, as long as they can match a MAC 
address of the customer router + MAC address of the carrier equipment, to the 
DHCP and flow logs.

As along as the carrier implements IPv6, it will cut down on the active NAT 
sessions and port forwards the equipment needs to process.

Ryan Hamel


From: NANOG  on behalf of Abraham Y. 
Chen 
Sent: Wednesday, January 10, 2024 8:09 PM
To: Tom Beecher 
Cc: Chen, Abraham Y. ; nanog@nanog.org 
Subject: 202401102221.AYC Re: Streamline The CG-NAT 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, Tom:

1)Your caution advice to Karim is professional. With a lot of convoluted 
topics behind it, however, the net result is basically discouraging the 
listener from investigating the possibilities. Since this is rather 
philosophical, it can distract us from the essence unless we carry on a lengthy 
debate. Instead, I would like to address below only one aspect that you brought 
up.

2)"... an operator clearly looking to acquire *publicly routable* space 
without being clear that this suggestion wouldn't meet their needs.  ":

Since 240/4 has 256M addresses while 100.64/10 has only 4M, a current 
CG-NAT cluster can be expanded 64 fold once the 240/4 is used. Looking from 
another angle, an IAP will then be able to expand the subscriber set 64 fold 
with still the original one publicly routable IPv4 address.

3)This 64 fold scaling factor is critical because it allows one CG-NAT 
cluster to serve a geographical area that becomes sufficient to cover a 
significant political territory. For example, if we assign two 240/4 addresses 
to each subscriber, one for stationary applications, one for mobile devices. 
And, each 240/4 address can be expanded by RFC1918 netblocks (total about 17.6M 
each). Each CG-NAT can now serve a country with population up to 128M. It turns 
out that population of over 90+ % of countries are fewer than this. So, each of 
them needs only one publicly routable IPv4 address. Then, the demand for IPv4 
address is drastically reduced.

4)In brief, the 240/4 is to substitute that of 100.64/10. So that the need 
for the publicly routable IPv4 addresses is significantly reduced.

Regards,


Abe (2024-01-10 23:08 EST)


On 2024-01-10 10:12, Tom Beecher wrote:
Karim-

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

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

Mr. Chen-

I understand your perspective surrounding 240/4, and respect your position, 
even though I disagree. That being said, it's pretty dirty pool to toss this 
idea to an operator clearly looking to acquire *publicaly routable* space 
without being clear that this suggestion wouldn't meet their needs.

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

On Wed, Jan 10, 2024 at 9:48 AM KARIM MEKKAOUI 
mailto:amekka...@mektel.ca>> wrote:

Interesting and thank you for sharing.



KARIM



From: Abraham Y. Chen mailto:ayc...@avinta.com>>
Sent: January 10, 2024 7:35 AM
To: KARIM MEKKAOUI mailto:amekka...@mektel.ca>>
Cc: nanog@nanog.org<mailto:nanog@nanog.org>; Chen, Abraham Y. 
mailto:ayc...@alum.mit.edu>>
Subject: 202401100645.AYC Re: IPv4 address block
Importance: High



Hi, Karim:



1)If you have control of your own equipment (I presume that your business 
includes IAP - Internet Access Provider, since you are asking to buy IPv4 
blocks.), you can get a large block of reserved IPv4 address for free by 
disabling the program codes in your current facility that has been disabling 
the use of 240/4 netblock. Please have a look at the below whitepaper. Utilized 
according to the outlined disciplines, this is a practically unlimited 
resources. It has been known that multi-national conglomerates have been using 
it without announcement. So, you can do so stealthily according to the proposed 
mechanism which establishes uniform practices, just as well.



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



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





Regards,





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







On 2024-01-07 

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

[Tony Wicks]

 

 

 

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

 

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

[Abraham Y. Chen]

Hi, Tom:

1)    Your caution advice to Karim is professional. With a lot of 
convoluted topics behind it, however, the net result is basically 
discouraging the listener from investigating the possibilities. Since 
this is rather philosophical, it can distract us from the essence unless 
we carry on a lengthy debate. Instead, I would like to address below 
only one aspect that you brought up.


2)    "... an operator clearly looking to acquire *publicly routable* 
space without being clear that this suggestion wouldn't meet their 
needs.  ":


    Since 240/4 has 256M addresses while 100.64/10 has only 4M, a 
current CG-NAT cluster can be expanded 64 fold once the 240/4 is used. 
Looking from another angle, an IAP will then be able to expand the 
subscriber set 64 fold with still the original one publicly routable 
IPv4 address.


3)    This 64 fold scaling factor is critical because it allows one 
CG-NAT cluster to serve a geographical area that becomes sufficient to 
cover a significant political territory. For example, if we assign two 
240/4 addresses to each subscriber, one for stationary applications, one 
for mobile devices. And, each 240/4 address can be expanded by RFC1918 
netblocks (total about 17.6M each). Each CG-NAT can now serve a country 
with population up to 128M. It turns out that population of over 90+ % 
of countries are fewer than this. So, each of them needs only one 
publicly routable IPv4 address. Then, the demand for IPv4 address is 
drastically reduced.


4)    In brief, the 240/4 is to substitute that of 100.64/10. So that 
the need for the publicly routable IPv4 addresses is significantly reduced.


Regards,


Abe (2024-01-10 23:08 EST)


On 2024-01-10 10:12, Tom Beecher wrote:

Karim-

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

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


Mr. Chen-

I understand your perspective surrounding 240/4, and respect your 
position, even though I disagree. That being said, it's pretty dirty 
pool to toss this idea to an operator clearly looking to acquire 
*publicaly routable* space without being clear that this suggestion 
wouldn't meet their needs.


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


On Wed, Jan 10, 2024 at 9:48 AM KARIM MEKKAOUI  
wrote:


Interesting and thank you for sharing.

KARIM

*From:*Abraham Y. Chen 
*Sent:* January 10, 2024 7:35 AM
*To:* KARIM MEKKAOUI 
*Cc:* nanog@nanog.org; Chen, Abraham Y. 
*Subject:* 202401100645.AYC Re: IPv4 address block
*Importance:* High

Hi, Karim:

1) If you have control of your own equipment (I presume that your
business includes IAP - Internet Access Provider, since you are
asking to buy IPv4 blocks.), you can get a large block of reserved
IPv4 address */_for free_/* by */_disabling_/* the program codes
in your current facility that has been */_disabling_/* the use of
240/4 netblock. Please have a look at the below whitepaper.
Utilized according to the outlined disciplines, this is a
practically unlimited resources. It has been known that
multi-national conglomerates have been using it without
announcement. So, you can do so stealthily according to the
proposed mechanism which establishes uniform practices, just as well.

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

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

Regards,

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

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

Hi Nanog Community

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

Thank you

KARIM


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



Virus-free.www.avast.com

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




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

Re: Enhance CG-NAT Re: V6 still not supported

[Abraham Y. Chen]

Hi, Bill:

0)    Thanks for bringing up the NANOG posting guideline. We now have 
something tangible to discuss.


1)    Section 6. looks most relevant. So, I copy and paste it below for 
our discussion:


    A.    6.1.1. "... > relevant excerpt 1   response to excerpt 1 ... 
   ":    This seems to be what I have been doing, except maybe how to 
interpret the keyword "excerpt". Perhaps you are expecting me to cite 
more text from the message that I am responding to, such as a complete 
paragraph, instead of only a short phrase or two? If so, I certainly 
will be glad to do so.


    B.    On the other hand, the leading sentence "When posting to the 
NANOG list please avoid: Top-posting, i.e., putting your reply right on 
top of the message you're responding to,  ...   " seems to discourage 
threading the messages (keeping a long tail of the earlier texts)?


    Perhaps there is some kind of optimal trade-off between how much 
each of these two should be included in a message?


2)    The two URLs are kind of odd:

    A.    The first URL led me to a blank webpage.

    B.    The second URL led me to a list of Q&A's that seem to be more 
humorous than instructive.


***
*6. Posting Conventions*

1. *Format*
   When posting to the NANOG list please avoid:
1. Top-posting, i.e., putting your reply right on top of the
   message you're responding to, rather than quoting and responding
   as follows: > relevant excerpt 1
   response to excerpt
> relevant excerpt 2
   response to excerpt
> relevant excerpt 3
   response to excerpt
2. Using non-standard methods of quoting prior text;
3. Failing to quote, or to snip, as appropriate;
4. Sending in HTML or other non-standard attachment formats;
5. Starting or participating in flame wars.
   The linux-kernel mailing list FAQ provides detailed instructions
   for* quoting prior text*:

   http://www.tux.org/lkml/#s3-9


   "Dear Emily Postnews" at
   http://www.templetons.com/brad/emily.html makes lots of good
   suggestions about *signatures* and other items of interest.

***

Please review and advise.

Regards,


Abe (2022-04-06 17:31)




On 2022-04-06 11:33, William Nelson wrote:



I am still learning the proper eMail etiquette on NANOG. Could you please echo 
back some of my writings as you received? So that I can see what they got 
transformed to.



There is no transforming of your formatting after you send it.  It's 
frustrating in the format you typed it in.

https://archive.nanog.org/list/faq#posting

-bn.



Confidentiality Notice:

This email message, any attachment, and the information therein is 
confidential, intended only for the named recipient(s), and may contain 
material that is proprietary, privileged, or otherwise private under applicable 
law. If you have received this message in error, or are not a named recipient:
  
(1) You are advised that any disclosure, copying, distribution or use of this email, or the information in its content, is strictly prohibited;


(2) We ask you immediately to notify the sender by return email or contact 
Third Federal at 1-800-THIRD-FED (1-800-844-7333);

(3) We instruct you to delete this email message and any attachment from your 
computer.

Thank you.





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

Re: Enhance CG-NAT Re: V6 still not supported

[Abraham Y. Chen]

Hi, Ant:

1)    As I Cc:'ed you, I attempted to contact the author of the IPv4+ 
draft a few days ago to offer my reading of his work. I have not heard 
any response. In short, I believe that IPv4+ is paraphrasing the scheme 
of the unsuccessful RFC1385 that EzIP Draft cited as Informative 
Reference [12]. -- meaning that EzIP has avoided the trap of such approach.


2)    I went back to earlier versions of the IPv4+ drafts and discovered 
a surprising trend. That is, through all eight revisions, there has been 
hardly any actual write-up text changes! It appears that the author is 
just keeping the six-months-timer ticking.


3)    Since you indicated that IPv4+ was reported to NANOG, maybe you 
could retrieve that thread and check with the author about what is the 
status?


4)    "Have you approached any vendors about the feasibility of IP 
Options being used for switching at line rate in silicon?    ":    No. 
For the first phase of implementing EzIP, the configuration is called 
RAN (Regional Area Network). It is essentially a numbering plan 
enhancement to CG-NAT. There is no change to the basic IPv4 Header. The 
only engineering effort is "disabling the program code that has been 
disabling the use of the 240/4 netblock", followed by retiring the NAT 
function. So that CG-NAT can operate as simple routers, by having the 
look-up state-tables capability as backup.


5)    In the long run, yes, processing of the Option Word needs be 
considered and ideally be implemented in silicon to achieve the line 
rate switching. Many claim, however, such end-to-end connectivity is not 
needed according to the current trend, which is primarily Server / 
Client model by CDN business. So, EzIP is actually a forward looking two 
stage scheme. We can focus on the first phase for now to relieve the 
underlying issues. There will be plenty of lead time to upgrade the 
silicon when the demand for end-to-end connectivity begins to build up.


6)    " ...   but your replies are practically illegible because of 
formatting.   ... ":    I am still learning the proper eMail etiquette 
on NANOG. Could you please echo back some of my writings as you 
received? So that I can see what they got transformed to.


Thanks,


Abe (2022-04-06 11:25)


On 2022-04-03 16:14, Anthony Newman wrote:

You should check 
outhttps://datatracker.ietf.org/doc/html/draft-tang-ipv4plus-08  which is still 
dragging on
after receiving similar treatment here to EzIP (although less patented by its 
author) and equally unlikely
to be possible to implement in the real world in a timely fashion.

Have you approached any vendors about the feasibility of IP Options being used 
for switching at line rate in silicon?
Software IP stacks are the absolute least of your problem when proposing 
alterations to routing behaviour based on
packet contents. Apologies if this has been covered, but your replies are 
practically illegible because of formatting.





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

Re: Enhance CG-NAT Re: V6 still not supported

[Abraham Y. Chen]

Hi, Eduard:

0)    Appreciate very much for you spending the time to read all 55 
pages of our draft and then offering your extensive thoughts.


1)    "Your first pages are oriented for low-level engineers (“for 
dummies”).  ...  ": Thanks. I believe that the Abstract, Introduction, 
etc. at the beginning of a document are intended for "dummies" and those 
busy high level executives to get a quick overview. Unless, the 
descriptions are sugar coated to mislead the reader. In general, 
however, I do admit that we have not done a good job of describing the 
EzIP solution from the perspectives of colleagues who are used to the 
current "Internet way". This is because we approached the topic from an 
outsider's viewpoint, and there are more than a few parameters behind 
the EzIP scheme that do not follow the current approaches, but the 
alternatives which could be regarded as opposing techniques. We will 
need to highlight these to alert the readers of the distinction. If you 
could treat the EzIP scheme as unorthodox, but patiently review it with 
a pair of  critical eyes, I believe that you will see that the below 
explanations are realistic.


2)    " ... To give the chance for the merge that may be needed for a 
business. Minimize probability for address duplication inside 240/4 
block (that everybody would use). ...how to coordinate one 240/4 
distribution between all subscribers. Because address space between 
Carrier and Subscriber are Private too.  ":    The implied EzIP address 
management is by one administrative body per 240/4 netblock with 
considerations such as static, geolocation and hierarchical. Thus, there 
will not be issues when businesses merge. This implies that the 240/4 
should be respected as "*/natural resources/*", instead of the current 
treatment of being "*/personal properties/*", actually "*/business 
property/*".  --- This is analogous to how PSTN numbers were handled in 
the old days.


3)    "... You have not discussed in the document CGNAT case that is 
typically called NAT444 (double NAT translation). ... ":    If I 
understand NAT444 properly, it is a network architecture going from 
RG-NAT (Residential / Routing Gateway NAT) at one  end of a link through 
CG-NAT (Carrier Grade NAT) in the middle before reaching the public 
Internet network. What EzIP proposes to do is to replace the CG-NAT with 
a basic router. This can be achieved by simply assigning a 240/4 address 
permanently to each subscriber premises that currently makes use of a 
dynamic port number, without affecting the hardware equipment nor the 
networking architecture. For software implementation, enabling the use 
of 240/4 netblock is all what is needed. At least, we have identified a 
simple case for the inspiration. And, the "IPv4 Unicast Extension" 
project has found numerous equipment already supporting 240/4.


4)    " ... I do not see a big difference between EzIP and NAPT that we 
have right now.   ...   ":    Precisely! Please see Pt. 3) above. Simply 
put, EzIP is a numbering plan upgrade for CG-NAT.


5)    " ... Initially, the majority of servers on the internet would not 
be capable to read Ez options (private 240/4 address extension). ...  
":    Correct. But, this is only needed when we extend EzIP service to 
include the true end-to-end connectivity between any two premises around 
the world like the IDDD (International Direct Distance Dialing) of the 
PSTN. The initial EzIP deployment is only RAN that upgrades the CG-NAT 
modules in a coordinated process (see Pt. 2) above). Even so, it can be 
done progressively by individual routers within a CG-NAT operation. That 
is, enable the root level routers to be able to handle 240/4 addressed 
packets for simple routing. Then, enable the next level routers to do 
the same. These are just standby capabilities until each of the lowest 
level (the subscriber premises) routers (the RGs) is assigned with a 
static 240/4 address. At that point, the NAT functions in the CG-NAT 
routers can be retired to standby status. This RAN architecture will 
last a pretty long time because the Internet is currently predominantly 
operated in Master/Slave mode by CDNs that are doing well with their 
Sever/Client model. By the time the end-to-end connectivity between 
different RANs is needed, either the RANs can designate some of their 
own routers (the SPRs) for such interconnect function, or certain 
existing Internet routers have been enabled to handle the Option Words.


6    " The gateway (that would be exposing 240/4 options) would need 
additionally to translate UDP ports to avoid a collision (as usual for 
NAPT). The gateway could not stop NAPT till the last server on the 
internet would be capable to read address extension (240/4) in options  
   ":    The gateway of a RAN cluster (we call it a Sub-Internet) or 
a CDN mo

RE: Enhance CG-NAT Re: V6 still not supported

[Vasilenko Eduard via NANOG]

Hi Abraham,
I propose you improve EzIP by the advice in the draft on the way how to 
randomize small sites choice inside 240/4 (like in ULA?).
To give the chance for the merge that may be needed for a business. Minimize 
probability for address duplication inside 240/4 block (that everybody would 
use).

You have not discussed in the document CGNAT case that is typically called 
NAT444 (double NAT translation).
I assume it is possible, but would be a big question how to coordinate one 
240/4 distribution between all subscribers. Because address space between 
Carrier and Subscriber are Private too.

I do not see a big difference between EzIP and NAPT that we have right now. 
Explanation:
Initially, the majority of servers on the internet would not be capable to read 
Ez options (private 240/4 address extension).
Hence, the Web server would see just UDP:Public_IP.
The gateway (that would be exposing 240/4 options) would need additionally to 
translate UDP ports to avoid a collision (as usual for NAPT).
The gateway could not stop NAPT till the last server on the internet would be 
capable to read address extension (240/4) in options, because the gateway would 
not know what server is capable to parse EzIP options.
It means NEVER, at least not in this century. Hence, the additional value from 
EzIP is small, because the primary job would be still done by NAPT.
You could try to patch this problem. If the new server would signal to the 
gateway that it is capable to understand EzIP options then overlapping UDP 
ports from the same Public IP address would be not a problem, because the 
server may additionally use private address space for traffic multiplexing.
IMHI: it would be a very dirty work-around if servers would need to teach their 
capabilities to every NAPT device.

Sorry, I have not read all 55 pages, but the principal architecture questions 
are not possible to understand from the first 9 pages.
Your first pages are oriented for low-level engineers (“for dummies”).

Eduard
From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] On 
Behalf Of Abraham Y. Chen
Sent: Sunday, April 3, 2022 6:14 AM
To: Matthew Petach ; Masataka Ohta 

Cc: nanog@nanog.org
Subject: Enhance CG-NAT Re: V6 still not supported

Hi, Matt:

1)The challenge that you described can be resolved as one part of the 
benefits from the EzIP proposal that I introduced to this mailing list about 
one month ago. That discussion has gyrated into this thread more concerned 
about IPv6 related topics, instead. If you missed that introduction, please 
have a look at the following IETF draft to get a feel of what could be done:


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

2)   With respect to the specific case you brought up, consider the EzIP 
address pool (240/4 netblock with about 256M addresses) as the replacement to 
that of CG-NAT (100.64/10 netblock with about 4M addresses). This much bigger 
(2^6 times) pool enables every customer premises to get a static IP address 
from the 240/4 pool to operate in simple router mode, instead of requesting for 
a static port number and still operates in NAT mode. Within each customer 
premises, the conventional three private netblocks may be used to handle the 
hosts (IoTs).

3)There is a whitepaper that presents an overview of other possibilities 
based on EzIP approach:

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

Hope the above makes sense to you.

Regards,


Abe (2022-04-02 23:10)






On 2022-04-02 16:25, Matthew Petach wrote:


On Fri, Apr 1, 2022 at 6:37 AM Masataka Ohta 
mailto:mo...@necom830.hpcl.titech.ac.jp>> 
wrote:

If you make the stateful NATs static, that is, each
private address has a statically configured range of
public port numbers, it is extremely easy because no
logging is necessary for police grade audit trail
opacity.
Masataka Ohta

Hi Masataka,
One quick question.  If every host is granted a range of public port
numbers on the static stateful NAT device, what happens when
two customers need access to the same port number?

Because there's no way in a DNS NS entry to specify a
port number, if I need to run a DNS server behind this
static NAT, I *have* to be given port 53 in my range;
there's no other way to make DNS work.  This means
that if I have two customers that each need to run a
DNS server, I have to put them on separate static
NAT boxes--because they can't both get access to
port 53.

This limits the effectiveness of a stateful static NAT
box to the number of customers that need hard-wired
port numbers to be mapped through; which, depending
on your customer base, could end up being all of them,
at which point you're back to square one, with every
customer needing at least 1 IPv4 address dedicated
to them on the NAT device.

Either that, or you simply tell your customers "so sorry
you didn't get on the Int

Enhance CG-NAT Re: V6 still not supported

[Abraham Y. Chen]

Hi, Matt:

1)    The challenge that you described can be resolved as one part of 
the benefits from the EzIP proposal that I introduced to this mailing 
list about one month ago. That discussion has gyrated into this thread 
more concerned about IPv6 related topics, instead. If you missed that 
introduction, please have a look at the following IETF draft to get a 
feel of what could be done:


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



2)   With respect to the specific case you brought up, consider the EzIP 
address pool (240/4 netblock with about 256M addresses) as the 
replacement to that of CG-NAT (100.64/10 netblock with about 4M 
addresses). This much bigger (2^6 times) pool enables every customer 
premises to get a static IP address from the 240/4 pool to operate in 
simple router mode, instead of requesting for a static port number and 
still operates in NAT mode. Within each customer premises, the 
conventional three private netblocks may be used to handle the hosts (IoTs).


3)    There is a whitepaper that presents an overview of other 
possibilities based on EzIP approach:


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

Hope the above makes sense to you.

Regards,


Abe (2022-04-02 23:10)






On 2022-04-02 16:25, Matthew Petach wrote:



On Fri, Apr 1, 2022 at 6:37 AM Masataka Ohta 
 wrote:



If you make the stateful NATs static, that is, each
private address has a statically configured range of
public port numbers, it is extremely easy because no
logging is necessary for police grade audit trail
opacity. 


                Masataka Ohta


Hi Masataka,
One quick question.  If every host is granted a range of public port
numbers on the static stateful NAT device, what happens when
two customers need access to the same port number?

Because there's no way in a DNS NS entry to specify a
port number, if I need to run a DNS server behind this
static NAT, I *have* to be given port 53 in my range;
there's no other way to make DNS work.  This means
that if I have two customers that each need to run a
DNS server, I have to put them on separate static
NAT boxes--because they can't both get access to
port 53.

This limits the effectiveness of a stateful static NAT
box to the number of customers that need hard-wired
port numbers to be mapped through; which, depending
on your customer base, could end up being all of them,
at which point you're back to square one, with every
customer needing at least 1 IPv4 address dedicated
to them on the NAT device.

Either that, or you simply tell your customers "so sorry
you didn't get on the Internet soon enough; you're all
second class citizens that can't run your own servers;
if you need to do that, you can go pay Amazon to host
your server needs."

And perhaps that's not as unreasonable as it first sounds;
we may all start running IPv4-IPv6 application gateways
on Amazon, so that IPv6-only networks can still interact
with the IPv4-only internet, and Amazon will be the great
glue that holds it all together.

tl;dr -- "if only we'd thought of putting a port number field
in the NS records in DNS back in 1983..."

Matt




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

Re: NAT devices not translating privileged ports

[Fernando Gont via NANOG]

Hi, Jean,

On Thu, 2021-06-10 at 08:23 -0400, Jean St-Laurent wrote:
> Let's start with this example. When I click sync my clock in windows,
> this happened. 
> 
> On the inside or Private side
> 08:15:07.434344 IP 192.168.254.205.123 > 13.86.101.172.123: NTPv3,
> Client, length 48
> 08:15:07.473681 IP 13.86.101.172.123 > 192.168.254.205.123: NTPv3,
> Server, length 48
> 
> You are indeed right that the client must use UDP port 123. Is the
> RFC saying must or should on the client SRC port? I'm not sure.

Section 9.1 ("Peer Process Variables") of [RFC5905] SAYS:

  dstport: UDP port number of the client, ordinarily the NTP port
  number PORT (123) assigned by the IANA.  This becomes the source
  port number in packets sent from this association.


That said, as noted in 
https://datatracker.ietf.org/doc/html/draft-ietf-ntp-port-randomization-06#section-5
 , other client implementations don't bind the local port to 123, and
hence assign an ephemeral port.



> But, on the Public, this happened.
> 08:15:07.434381 IP 192.2XX.XXX.58291 > 13.86.101.172.123: NTPv3,
> Client, length 48
> 08:15:07.473656 IP 13.86.101.172.123 > 192.2XX.XXX.58291: NTPv3,
> Server, length 48
> 
> // Public ip obfuscated. I know, it indeed starts with 192.2. It's
> EBOX in Canada.
> 
> What we see on the public side, is that a network device did a NAT
> translation of the SRC UDP port to 58921. My clock synced perfectly.
> 
> So your goal is to find the devices that don't follow this behaviour,
> right?

> No. The goal of our I-D is that NTP clients randomize their source
> port -- there's no need for clients to use port 123, and using that
> port on the client side has negative security implications.

Thanks,
-- 
Fernando Gont
Director of Information Security
EdgeUno, Inc.
PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531

Re: NAT devices not translating privileged ports

[Blake Hudson]

On 6/10/2021 4:04 AM, Fernando Gont wrote:

Hi, Blake,

Thanks a lot for your comments! In-line


On Fri, 2021-06-04 at 11:13 -0500, Blake Hudson wrote:

Current gen Cisco ASA firewalls have logic so that if the connection
from a private host originated from a privileged source port, the
NAT
translation to public IP also uses an unprivileged source port (not
necessarily the same source port though).

Did you actaully mean "...also uses a *privileged port*"?


Yes I did. Thanks.


I found out that this behavior can cause issues when you have devices
on
your network that implement older DNS libraries or configs using UDP
53
as a source and destination port for their DNS lookups. Occasionally
the
source port gets translated to one that ISC BIND servers have in a
blocklist (chargen, echo, time, and a few others) and the query is
ignored. As I recall, this behavior is hard coded so patching and
recompiling BIND is required to work around it.

I forget what the older ASA behavior was. It may have been to leave
the
source port unchanged through the NAT process (I think this is what
you
mean by "not translated"). In that case the client doesn't implement
source port randomization and the NAT doesn't "upgrade" the
connection
to a random source port so I don't really see it as an issue.

The issue would be that if the port is not translated, and multiple
systems in the internal real of the NAT try to use the same privileged
port (say, 123) simultaneously, things wouldn't work.




Not quite. If multiple devices behind a NAT use SRC=123 & DST = 123 for 
connections, their connections will still work most of the time. First, 
if the connections are to different destinations there would be no NAT 
conflict. Second, if the connections occur at different times, there 
would be no NAT conflict. Third, if there was a NAT conflict (meaning 
connections using the same SRC port, DST port, and DST host at the same 
time) the NAT device would see this and would either adjust the 
translation to use a different SRC port (in which case the connection 
succeeds) or may drop/reject the connection (in which case the client 
would eventually retry).


So saying "things wouldn't work" or "you won't be able to have multiple 
NTP clients behind the same firewall" is not true. Saying that "the 
number of simultaneous connections is limited" when behind a NAT would 
be more accurate. _But this statement is true of any one-to-many NAT_. 
Most NTP clients utilize multiple NTP servers, often from a pool of 
available servers, and initiate connections rather infrequently so I do 
not expect this to be a problem in practice unless there are thousands 
of NTP clients behind a single NAT accessing a common NTP server (and 
that NAT does not do a good job of dealing with collisions).


I do, however, agree that clients should probably use ephemeral ports 
when making any outbound connections as this provides more entropy for 
NAT as well as for connection security. This extends to NTP.

RE: NAT devices not translating privileged ports

[Jean St-Laurent via NANOG]

Let's start with this example. When I click sync my clock in windows, this 
happened. 

On the inside or Private side
08:15:07.434344 IP 192.168.254.205.123 > 13.86.101.172.123: NTPv3, Client, 
length 48
08:15:07.473681 IP 13.86.101.172.123 > 192.168.254.205.123: NTPv3, Server, 
length 48

You are indeed right that the client must use UDP port 123. Is the RFC saying 
must or should on the client SRC port? I'm not sure.

But, on the Public, this happened.
08:15:07.434381 IP 192.2XX.XXX.58291 > 13.86.101.172.123: NTPv3, Client, length 
48
08:15:07.473656 IP 13.86.101.172.123 > 192.2XX.XXX.58291: NTPv3, Server, length 
48

// Public ip obfuscated. I know, it indeed starts with 192.2. It's EBOX in 
Canada.

What we see on the public side, is that a network device did a NAT translation 
of the SRC UDP port to 58921. My clock synced perfectly.

So your goal is to find the devices that don't follow this behaviour, right?

Jean


-Original Message-
From: Fernando Gont  
Sent: June 10, 2021 7:09 AM
To: j...@ddostest.me; nanog@nanog.org
Subject: Re: NAT devices not translating privileged ports

Hi, Jean,

On Thu, 2021-06-10 at 06:54 -0400, Jean St-Laurent via NANOG wrote:
> Hi Fernando,
> 
> NTP sounds simple but it could be very complex when you dig deep down 
> and/or get lost in details.
> Here are 2 things to consider:
> 
> 1. NTP clients can query NTP servers by using SRC UDP ports > 1024. 

This is indeed the case we're addressing. The NTP spec mandates srt port=123, 
even for client-to-server cases.

Re: NAT devices not translating privileged ports

[Fernando Gont via NANOG]

Hi, Jean,

On Thu, 2021-06-10 at 06:54 -0400, Jean St-Laurent via NANOG wrote:
> Hi Fernando,
> 
> NTP sounds simple but it could be very complex when you dig deep down
> and/or get lost in details. 
> Here are 2 things to consider:
> 
> 1. NTP clients can query NTP servers by using SRC UDP ports > 1024. 

This is indeed the case we're addressing. The NTP spec mandates srt
port=123, even for client-to-server cases.



> In your case, it sounds like you want to achieve NTP server to NTP
> server, but you mention NTP clients behind NAT devices. 

Nope. We simply recommend to randomize the source port for client-to-
server cases.

So in the quoted section we make the case that requiring src port=123
clients doesnt really make sense:
1) if the NAT translates the port, the server won-t see src 123 anyway
2) if the NAT doesn't translate the port, you won't be able to ahve
multiple NTP clients behind the same firewall.



> Can you give us more details on what kind of communication you need
> here? From what I understand client to server should work just fine
> with any NAT devices. 
> 
> Maybe you meant multiple NTP servers behind the same NAT to external
> NTP servers

Please let me know if what I wrote above clarifies our intent.

Thanks!

Regards,
-- 
Fernando Gont
Director of Information Security
EdgeUno, Inc.
PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531

RE: NAT devices not translating privileged ports

[Jean St-Laurent via NANOG]

Hi Fernando,

NTP sounds simple but it could be very complex when you dig deep down and/or 
get lost in details. 
Here are 2 things to consider:

1. NTP clients can query NTP servers by using SRC UDP ports > 1024. 
2. NTP servers cannot query/sync/communicate to  another NTP server when using 
SRC UDP port > 1024.

In short, server to server wants SRC and DST UDP 123.  The query and the 
response will be fully 123 when server to server.

In your case, it sounds like you want to achieve NTP server to NTP server, but 
you mention NTP clients behind NAT devices. 

Because multiple clients behind the same NAT devices should work. Multiple NTP 
servers behind the same NAT and wanting to use other NTP server *should* not 
work.

Can you give us more details on what kind of communication you need here? From 
what I understand client to server should work just fine with any NAT devices. 

Maybe you meant multiple NTP servers behind the same NAT to external NTP server?

Thanks
Jean

Re: NAT devices not translating privileged ports

[Fernando Gont via NANOG]

Hi, Bjørn,

On Thu, 2021-06-10 at 12:10 +0200, Bjørn Mork wrote:
> Fernando Gont via NANOG  writes:
> 
> > What has been reported to us is that some boxes do not translate
> > the
> > src port if it's a privileged port.
> > 
> > IN such scenarios, NTP implementations that always use src
> > port=123,
> > dst port=123 might be in trouble if there are multiple NTP clients
> > behind the same NAT device
> 
> This problem used to be very common for 500/udp.  Ref
> https://datatracker.ietf.org/doc/html/rfc3715#section-2.3

THanks a lot for the link! -- this is indeed a good read.  I'm curious
if there exists something similar for UDP/123?


FWIW, we have this IETF I-D on NTP port randomization: 
https://datatracker.ietf.org/doc/html/draft-ietf-ntp-port-randomization-06
 , which has this section on the same kind of behavior, but for the NTP
port:

 cut here 
3.4.  Effect on NAT devices

  Some NAT devices will not translate the source port of a packet when
  a privileged port number is employed.  In networks where such NAT
  devices are employed, use of the NTP well-known port for the client
  port will essentially limit the number of hosts that may successfully
  employ NTP client implementations.

  In the case of NAT devices that will translate the source port even
  when a privileged port is employed, packets reaching the external
  realm of the NAT will not employ the NTP well-known port as the local
  port, since the local port will normally be translated by the NAT
  device possibly, but not necessarily, with a random port.
 cut here 

So I'm trying to find some reference that documents such behavior for
the NTP case

Thanks!

Regards,
-- 
Fernando Gont
Director of Information Security
EdgeUno, Inc.
PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531

Re: NAT devices not translating privileged ports

[Bjørn Mork]

Fernando Gont via NANOG  writes:

> What has been reported to us is that some boxes do not translate the
> src port if it's a privileged port.
>
> IN such scenarios, NTP implementations that always use src port=123,
> dst port=123 might be in trouble if there are multiple NTP clients
> behind the same NAT device

This problem used to be very common for 500/udp.  Ref
https://datatracker.ietf.org/doc/html/rfc3715#section-2.3


Bjørn

Re: NAT devices not translating privileged ports

[Fernando Gont via NANOG]

Hi, Jean,

On Fri, 2021-06-04 at 08:36 -0400, Jean St-Laurent wrote:
> I believe all devices will translate a privileged ports, but it won't
> translate to the same number on the other side. It will translate to
> an unprivileged port. Is it what you meant or really there are some
> devices that will not translate at all a privileged port?

What has been reported to us is that some boxes do not translate the
src port if it's a privileged port.

IN such scenarios, NTP implementations that always use src port=123,
dst port=123 might be in trouble if there are multiple NTP clients
behind the same NAT device

Thanks!

Regards,
--
Fernando Gont
Director of Information Security
EdgeUno, Inc.
PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531

Re: NAT devices not translating privileged ports

[Fernando Gont via NANOG]

Hi, Blake,

Thanks a lot for your comments! In-line


On Fri, 2021-06-04 at 11:13 -0500, Blake Hudson wrote:
> Current gen Cisco ASA firewalls have logic so that if the connection 
> from a private host originated from a privileged source port, the
> NAT 
> translation to public IP also uses an unprivileged source port (not 
> necessarily the same source port though).

Did you actaully mean "...also uses a *privileged port*"?



> 
> I found out that this behavior can cause issues when you have devices
> on 
> your network that implement older DNS libraries or configs using UDP
> 53 
> as a source and destination port for their DNS lookups. Occasionally
> the 
> source port gets translated to one that ISC BIND servers have in a 
> blocklist (chargen, echo, time, and a few others) and the query is 
> ignored. As I recall, this behavior is hard coded so patching and 
> recompiling BIND is required to work around it.
> 
> I forget what the older ASA behavior was. It may have been to leave
> the 
> source port unchanged through the NAT process (I think this is what
> you 
> mean by "not translated"). In that case the client doesn't implement 
> source port randomization and the NAT doesn't "upgrade" the
> connection 
> to a random source port so I don't really see it as an issue. 

The issue would be that if the port is not translated, and multiple
systems in the internal real of the NAT try to use the same privileged
port (say, 123) simultaneously, things wouldn't work.



Thanks,
-- 
Fernando Gont
Director of Information Security
EdgeUno, Inc.
PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531

Re: NAT devices not translating privileged ports

[Alvaro Pereira]

For Linux iptables SNAT (used with --to-source), the default is to change
the packet as little as possible.

https://linux.die.net/man/8/iptables
"If no port range is specified, then source ports below 512 will be mapped
to other ports below 512: those between 512 and 1023 inclusive will be
mapped to ports below 1024, and other ports will be mapped to 1024 or
above.
Where possible, no port alteration will occur."

So, if there are no "collisions", the same src port will be used. If there
are "collisions" (multiple flows with the same src port and dst IP/port),
then another src port within its "range" will be used.

But it can be configured, for example, to use ports 1024-65535, in which
case flows with src port < 1024 will endup using ports > 1024 after they
are NATed.

https://datatracker.ietf.org/doc/html/rfc6335#section-6 is also a good
reference.

Alvaro

On Fri, Jun 4, 2021 at 10:14 AM Blake Hudson  wrote:

> Current gen Cisco ASA firewalls have logic so that if the connection
> from a private host originated from a privileged source port, the NAT
> translation to public IP also uses an unprivileged source port (not
> necessarily the same source port though).
>
> I found out that this behavior can cause issues when you have devices on
> your network that implement older DNS libraries or configs using UDP 53
> as a source and destination port for their DNS lookups. Occasionally the
> source port gets translated to one that ISC BIND servers have in a
> blocklist (chargen, echo, time, and a few others) and the query is
> ignored. As I recall, this behavior is hard coded so patching and
> recompiling BIND is required to work around it.
>
> I forget what the older ASA behavior was. It may have been to leave the
> source port unchanged through the NAT process (I think this is what you
> mean by "not translated"). In that case the client doesn't implement
> source port randomization and the NAT doesn't "upgrade" the connection
> to a random source port so I don't really see it as an issue. Ideally
> the client would implement source port randomization itself so it would
> be using source ports within its ephemeral port range for outgoing
> connections.
>
> --Blake
>
>
> On 6/4/2021 7:36 AM, Jean St-Laurent via NANOG wrote:
> > I believe all devices will translate a privileged ports, but it won't
> translate to the same number on the other side. It will translate to an
> unprivileged port. Is it what you meant or really there are some devices
> that will not translate at all a privileged port?
> >
> > What are you trying to achieve?
> >
> > Jean
> >
> > -Original Message-
> > From: NANOG  On Behalf Of
> Fernando Gont
> > Sent: June 4, 2021 3:00 AM
> > To: nanog@nanog.org
> > Subject: NAT devices not translating privileged ports
> >
> > Folks,
> >
> > While discussing port randomization (in the context of
> https://www.ietf.org/archive/id/draft-ietf-ntp-port-randomization-06.txt
> > ), it has been raised to us that some NAT devices do not translate the
> source port if the source port is a privileged port (<1024).
> >
> > Any clues/examples of this type of NATs?
> >
> > Thanks!
> >
> > Regards,
> > --
> > Fernando Gont
> > Director of Information Security
> > EdgeUno, Inc.
> > PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531
> >
> >
> >
> >
> >
>
>

Re: NAT devices not translating privileged ports

[Blake Hudson]

Current gen Cisco ASA firewalls have logic so that if the connection 
from a private host originated from a privileged source port, the NAT 
translation to public IP also uses an unprivileged source port (not 
necessarily the same source port though).


I found out that this behavior can cause issues when you have devices on 
your network that implement older DNS libraries or configs using UDP 53 
as a source and destination port for their DNS lookups. Occasionally the 
source port gets translated to one that ISC BIND servers have in a 
blocklist (chargen, echo, time, and a few others) and the query is 
ignored. As I recall, this behavior is hard coded so patching and 
recompiling BIND is required to work around it.


I forget what the older ASA behavior was. It may have been to leave the 
source port unchanged through the NAT process (I think this is what you 
mean by "not translated"). In that case the client doesn't implement 
source port randomization and the NAT doesn't "upgrade" the connection 
to a random source port so I don't really see it as an issue. Ideally 
the client would implement source port randomization itself so it would 
be using source ports within its ephemeral port range for outgoing 
connections.


--Blake


On 6/4/2021 7:36 AM, Jean St-Laurent via NANOG wrote:

I believe all devices will translate a privileged ports, but it won't translate 
to the same number on the other side. It will translate to an unprivileged 
port. Is it what you meant or really there are some devices that will not 
translate at all a privileged port?

What are you trying to achieve?

Jean

-Original Message-
From: NANOG  On Behalf Of Fernando 
Gont
Sent: June 4, 2021 3:00 AM
To: nanog@nanog.org
Subject: NAT devices not translating privileged ports

Folks,

While discussing port randomization (in the context of 
https://www.ietf.org/archive/id/draft-ietf-ntp-port-randomization-06.txt
), it has been raised to us that some NAT devices do not translate the source port 
if the source port is a privileged port (<1024).

Any clues/examples of this type of NATs?

Thanks!

Regards,
--
Fernando Gont
Director of Information Security
EdgeUno, Inc.
PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531

RE: NAT devices not translating privileged ports

[Jean St-Laurent via NANOG]

I believe all devices will translate a privileged ports, but it won't translate 
to the same number on the other side. It will translate to an unprivileged 
port. Is it what you meant or really there are some devices that will not 
translate at all a privileged port?

What are you trying to achieve?

Jean

-Original Message-
From: NANOG  On Behalf Of Fernando 
Gont
Sent: June 4, 2021 3:00 AM
To: nanog@nanog.org
Subject: NAT devices not translating privileged ports

Folks,

While discussing port randomization (in the context of 
https://www.ietf.org/archive/id/draft-ietf-ntp-port-randomization-06.txt
), it has been raised to us that some NAT devices do not translate the source 
port if the source port is a privileged port (<1024).

Any clues/examples of this type of NATs?

Thanks!

Regards,
--
Fernando Gont
Director of Information Security
EdgeUno, Inc.
PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531

NAT devices not translating privileged ports

[Fernando Gont]

Folks,

While discussing port randomization (in the context of 
https://www.ietf.org/archive/id/draft-ietf-ntp-port-randomization-06.txt
), it has been raised to us that some NAT devices do not translate the
source port if the source port is a privileged port (<1024).

Any clues/examples of this type of NATs?

Thanks!

Regards,
-- 
Fernando Gont
Director of Information Security
EdgeUno, Inc.
PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531

RE: QUIC, Connection IDs and NAT

[Jean St-Laurent via NANOG]

Hey Rob, quick question for you. 

Are you able to see the connection ID when you are forwarding the frames and
doing NAT? 

I thought this is encrypted. Can you confirm?

Thanks
Jean

-Original Message-
From: NANOG  On Behalf Of Jean
St-Laurent via NANOG
Sent: June 1, 2021 6:51 AM
To: 'The source of all things networking' 
Subject: RE: QUIC, Connection IDs and NAT

The first thing that comes to mind is to check the NAT timers.

By default, TCP is 86400 seconds or 24h.
Udp is usually shorter at around 300 seconds or 5 minutes.

This is not a standard, but it seems to be broadly accepted in the industry.

I am not sure, if UDP/443 should be left at 300 or increase a bit.

Anyone?
Jean

P.S.: I'm not a fan of Quic. It's opening the gates to massive DDoS for
Akamai and all the others CDN. Good luck

-Original Message-
From: NANOG  On Behalf Of Robert
Brockway
Sent: May 31, 2021 11:15 PM
To: The source of all things networking 
Subject: QUIC, Connection IDs and NAT

QUIC has Connection IDs independent from IP.  This was done to make it
easier to move from one IP network to another while keeping connections
active, as most here will know.

Does the existence of Connection IDs separate from IP mean that the host/IP
contention ratio in CGNAT can be higher?  IE, can a single CGNAT device
provide Internet access for a greater number of end-users?

And if so, does this reduce demand on IPv4 resources?

It's ok, I'm wearing a fire-resistant suit with self-contained breathing
apparatus as I type this.

Rob

RE: QUIC, Connection IDs and NAT

[Jean St-Laurent via NANOG]

The first thing that comes to mind is to check the NAT timers.

By default, TCP is 86400 seconds or 24h.
Udp is usually shorter at around 300 seconds or 5 minutes.

This is not a standard, but it seems to be broadly accepted in the industry.

I am not sure, if UDP/443 should be left at 300 or increase a bit.

Anyone?
Jean

P.S.: I'm not a fan of Quic. It's opening the gates to massive DDoS for
Akamai and all the others CDN. Good luck

-Original Message-
From: NANOG  On Behalf Of Robert
Brockway
Sent: May 31, 2021 11:15 PM
To: The source of all things networking 
Subject: QUIC, Connection IDs and NAT

QUIC has Connection IDs independent from IP.  This was done to make it
easier to move from one IP network to another while keeping connections
active, as most here will know.

Does the existence of Connection IDs separate from IP mean that the host/IP
contention ratio in CGNAT can be higher?  IE, can a single CGNAT device
provide Internet access for a greater number of end-users?

And if so, does this reduce demand on IPv4 resources?

It's ok, I'm wearing a fire-resistant suit with self-contained breathing
apparatus as I type this.

Rob

Re: QUIC, Connection IDs and NAT

[George Michaelson]

the 5tuple includes protocol so increased adoption of QUIC alongside
TCP bound services effectively does increase the potential size of the
NAT binding table but if we're really a single-browser model and all
going to QUIC enabled webs, the effective outcome is to burn the port
space in UDP, not in TCP. its same-same if everyone jumps ship.

On the plus side, QUIC is a session: it multiplexes. So for a given
endpoint, there might only be one long-held QUIC binding. Sure, TCP
HTTPS in principle did this, but most of the code appeared to open
multiple simultaneous TCP connections. I am less sure this is
happening with the QUIC stack as presented. Maybe somebody smarter can
say.

the real problem is not the port count, its the amount of buffer space
the tiny chip has set aside, to hold "open" bindings in. We're
revisiting 1980s kernels and the TCB and ways to flush it, at this
point. By now, manufacturers should be making home routers out of
devices which have more memory purely for connection holding, than
prior devices had overall to boot a kernel in. But, consumers hold on
to WRT54G forever.

(I'm old. this may be a bad take on history, and current technology)

On Tue, Jun 1, 2021 at 1:52 PM John Levine  wrote:
>
> It appears that Robert Brockway  said:
> >Does the existence of Connection IDs separate from IP mean that
> >the host/IP contention ratio in CGNAT can be higher?  IE, can a single
> >CGNAT device provide Internet access for a greater number of end-users?
>
> No, QUIC runs over UDP which runs over IP.  QUIC replaces the TCP sessions 
> that a web
> browser uses but the device is still doing all of the other IP stuff that it 
> does.
>
> I could imagine that the connection ID might slightly increase the load on a 
> NAT since a device
> might be hopping back and forth between networks, e.g. mobile and wifi, and 
> be considered a new NAT
> client each time it does.
>

Re: QUIC, Connection IDs and NAT

[John Levine]

It appears that Robert Brockway  said:
>Does the existence of Connection IDs separate from IP mean that 
>the host/IP contention ratio in CGNAT can be higher?  IE, can a single 
>CGNAT device provide Internet access for a greater number of end-users?

No, QUIC runs over UDP which runs over IP.  QUIC replaces the TCP sessions that 
a web
browser uses but the device is still doing all of the other IP stuff that it 
does.

I could imagine that the connection ID might slightly increase the load on a 
NAT since a device
might be hopping back and forth between networks, e.g. mobile and wifi, and be 
considered a new NAT
client each time it does.

QUIC, Connection IDs and NAT

[Robert Brockway]

QUIC has Connection IDs independent from IP.  This was done to 
make it easier to move from one IP network to another while keeping 
connections active, as most here will know.


Does the existence of Connection IDs separate from IP mean that 
the host/IP contention ratio in CGNAT can be higher?  IE, can a single 
CGNAT device provide Internet access for a greater number of end-users?


And if so, does this reduce demand on IPv4 resources?

It's ok, I'm wearing a fire-resistant suit with self-contained breathing 
apparatus as I type this.


Rob

RE: NAT/CGNAT IP address/users ratios

[aaron1]

I currently have about ~2750 public IP's (11 /24's) for ~53,000 broadband
customers.  (ftth, cable modem and dsl)

 

I cap them at 3,000 ports using PBA, port block allocation.. Blocks of 100
at a time, and 30 blocks per subscriber.  (100*30=3000)

 

I usually see, when a private internal IP is using up the full 3,000 ports,
when we look closer at the sessions, they usually look suspect, as if the
end host is infected or has malware causing lots of connections

 

I run all this though, (6) MX960's with (1) MS-MPC-128G in each chassis, and
(2) MX104's with (1) MS-MIC-16G per 104.  The utilization as far as I've
seen, regarding memory and load on the service modules seems fine at the
levels we are at.

 

Hope that helps.

 

-Aaron

NAT/CGNAT IP address/users ratios

[Scott, Thomas]

Hello NANOG (and friends),

Asking if anyone would care to share their CGNAT and NAT ratios. We're looking 
at some best practices and I wanted to see what the community at large has seen 
working, and not working.

I am by no means a NAT expert, and usually I see the other end where it's 
clearly *not* working.

Does anyone have estimating formulas for devices/users to internal blocks to 
public IPs?

Regards,
[cid:image001.png@01D74BF4.DDAC29B0]<https://www.intelsat.com/>
Thomas Scott
Engineer, Network Operations

2875 Fork Creek Church Road, Ellenwood, GA 30294
+1 404-381-2446 | M +1 480-241-7422
www.intelsat.com<http://www.intelsat.com/>



[https://www.intelsat.com/wp-content/uploads/2020/12/INTELSAT-Logo-Horiz_4C_200-002.jpg]

As the foundational architects of satellite technology, Intelsat operates the 
largest, most advanced satellite fleet and connectivity infrastructure in the 
world. We apply our unparalleled expertise and global scale to reliably and 
seamlessly connect people, devices and networks in even the most challenging 
and remote locations. Transformation happens when businesses, governments and 
communities build a ubiquitous connected future through Intelsat's 
next-generation global network and simplified managed services. At Intelsat, we 
turn possibilities into reality. Imagine Here, with us, at Intelsat.com.

For more information, visit www.intelsat.com<http://www.intelsat.com> and 
follow us on 
Facebook<https://www.facebook.com/#%21/pages/Intelsat/106822915740>, 
Twitter<https://twitter.com/INTELSAT> and 
LinkedIn<http://www.linkedin.com/company/5071?trk=vsrp_companies_res_name&trkInfo=VSRPsearchId%3A858898061376423570001%2CVSRPtargetId%3A5071%2CVSRPcmpt%3Aprimary>

This email message is for the sole use of the intended recipients and may 
contain confidential and privileged information. Any unauthorized review, use, 
disclosure or distribution is prohibited. If you are not the intended 
recipient, please contact the sender by reply email and destroy all copies of 
the original message. Any views expressed in this message are those of the 
individual sender, except where the sender specifically states them to be the 
views of Intelsat S.A. and its subsidiaries.

Re: Issue with point to point VPNs behind NAT and asymmetric traffic

[Anurag Bhatia]

The issue is resolved by tweaking the route validation.

Added following my ansible playbook for both ends:

  - name: Enable Controls source route verification
sysctl:
  name: net.ipv4.conf.default.rp_filter
  value: '0'
  sysctl_set: yes

  - name: Do not accept source routing
sysctl:
  name: net.ipv4.conf.default.accept_source_route
  value: '1'
  sysctl_set: yes


and it works fien now.

Thanks, everyone for the inputs.

On Thu, Jun 13, 2019 at 3:55 AM Jerry Cloe  wrote:

> Linux by default (regardless of firewall rules) will not accept a packet
> on an interface when the source of that packet "should" be on another
> interface according to the current route table (in other words, you're
> doing asymetric routing).
>
>
>
> Easy fix:
>
>
> # Controls source route verification
> net.ipv4.conf.default.rp_filter = 0
> # Do not accept source routing
> net.ipv4.conf.default.accept_source_route = 1
>
>
>
> -Original message-
> *From:* Anurag Bhatia 
> *Sent:* Wed 06-12-2019 04:45 pm
> *Subject:* Issue with point to point VPNs behind NAT and asymmetric
> traffic
> *To:* NANOG Mailing List ;
> Hello everyone,
>
> Trying to get my head around a certain unexpected behaviour.
>
>
> I am running two site to site VPNs (wireguard now, OpenVPN earlier)
> between my home and a remote server over two different WAN links. Both WAN
> links are just consumer connections - one with public IP and one with
> CGNATed IP.
> The redundancy here is taken care of by the OSPF running via FRR on both
> ends.
>
>
> The unexpected behaviour I get is that if I set OSPF cost to prefer say
> link1 between home -> server and prefer link 2 between server -> home then
> connectivity completely breaks between the routed pools. The point to point
> IPs stay reachable (which is over expected links i.e symmetric via both
> ends). As long as both ends prefer link1 or link2, it works fine. At first,
> I thought it had to do something with NAT but still can't understand how.
> Since VPN tunnels have a keep-alive timer (for 10 seconds), the tunnel is
> always up. Any idea why asymmetric packets are being dropped here?
> This exact behaviour was in case of earlier OpenVPN + bird + iBGP and is
> still the same when I moved everything to Wireguard for VPN + FRR for
> routing + OSPF.
>
>
>
>
> Thanks.
>
>
> --
>
>
> Anurag Bhatia
>
> anuragbhatia.com
>
>

-- 


Anurag Bhatia
anuragbhatia.com

Re: Issue with point to point VPNs behind NAT and asymmetric traffic

[Grant Taylor via NANOG]

On 6/15/19 2:06 PM, William Herrin wrote:

This is probably enabled on one or both ends:

http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.kernel.rpf.html


Do some distros enable this now?

I thought it was disabled by default.


Disable it.


Or make sure it's using loose (2) filtering.

rp_filter - INTEGER
0 - No source validation.
1 - Strict mode as defined in RFC3704 Strict Reverse Path Each incoming 
packet is tested against the FIB and if the interface is not the best 
reverse path the packet check will fail. By default failed packets are 
discarded.
2 - Loose mode as defined in RFC3704 Loose Reverse Path Each incoming 
packet's source address is also tested against the FIB and if the source 
address is not reachable via any interface the packet check will fail.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Issue with point to point VPNs behind NAT and asymmetric traffic

[William Herrin]

On Wed, Jun 12, 2019 at 2:45 PM Anurag Bhatia  wrote:
>
>
> I am running two site to site VPNs (wireguard now, OpenVPN earlier)
between my home and a remote server over two different WAN links. Both WAN
links are just consumer connections - one with public IP and one with
CGNATed IP.
> The redundancy here is taken care of by the OSPF running via FRR on both
ends.
>
>
> The unexpected behaviour I get is that if I set OSPF cost to prefer say
link1 between home -> server and prefer link 2 between server -> home then
connectivity completely breaks between the routed pools. The point to point
IPs stay reachable (which is over expected links i.e symmetric via both
ends). As long as both ends prefer link1 or link2, it works fine. At first,
I thought it had to do something with NAT but still can't understand how.
Since VPN tunnels have a keep-alive timer (for 10 seconds), the tunnel is
always up. Any idea why asymmetric packets are being dropped here?

This is probably enabled on one or both ends:

http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.kernel.rpf.html

Disable it.



-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: Issue with point to point VPNs behind NAT and asymmetric traffic

[Anurag Bhatia]

Hi


I did disable firewall at both ends to test and the result was similar.
Please note firewall rules do allow the UDP ports to establish the VPN link
and inside the link, there aren't any firewall restrictions.
However, as I said I wonder if or if not the CGNAT device of my link 2 will
allow the inbound traffic on the established link.

On Thu, Jun 13, 2019 at 3:35 AM Ross Tajvar  wrote:

> My guess is something is doing stateful filtering. If you send a SYN down
> one link and the SYN-ACK comes back a different link, the receiving
> firewall will discard it as bogus. You should be able to test this by doing
> pcaps to confirm the traffic is arriving (though I'm not familiar with
> WireGuard so maybe not), and you should be able to disable this by setting
> a rule or unchecking a box in your firewall.
>
> On Wed, Jun 12, 2019, 5:47 PM Anurag Bhatia  wrote:
>
>> Hello everyone,
>>
>> Trying to get my head around a certain unexpected behaviour.
>>
>>
>> I am running two site to site VPNs (wireguard now, OpenVPN earlier)
>> between my home and a remote server over two different WAN links. Both WAN
>> links are just consumer connections - one with public IP and one with
>> CGNATed IP.
>> The redundancy here is taken care of by the OSPF running via FRR on both
>> ends.
>>
>>
>> The unexpected behaviour I get is that if I set OSPF cost to prefer say
>> link1 between home -> server and prefer link 2 between server -> home then
>> connectivity completely breaks between the routed pools. The point to point
>> IPs stay reachable (which is over expected links i.e symmetric via both
>> ends). As long as both ends prefer link1 or link2, it works fine. At first,
>> I thought it had to do something with NAT but still can't understand how.
>> Since VPN tunnels have a keep-alive timer (for 10 seconds), the tunnel is
>> always up. Any idea why asymmetric packets are being dropped here?
>> This exact behaviour was in case of earlier OpenVPN + bird + iBGP and is
>> still the same when I moved everything to Wireguard for VPN + FRR for
>> routing + OSPF.
>>
>>
>>
>>
>> Thanks.
>>
>>
>> --
>>
>>
>> Anurag Bhatia
>> anuragbhatia.com
>>
>

-- 


Anurag Bhatia
anuragbhatia.com

Re: Issue with point to point VPNs behind NAT and asymmetric traffic

[Grant Taylor via NANOG]

On 6/12/19 3:44 PM, Anurag Bhatia wrote:

Hello everyone,


Hi,

I am running two site to site VPNs (wireguard now, OpenVPN earlier) 
between my home and a remote server over two different WAN links. Both 
WAN links are just consumer connections - one with public IP and one 
with CGNATed IP.


Okay.

Is there any filtering of the traffic that flows through the VPNs?  Or 
do things have full connectivity through them?


What OS is on each of the VPN endpoints?

The redundancy here is taken care of by the OSPF running via FRR on both 
ends.


Okay.

The unexpected behaviour I get is that if I set OSPF cost to prefer say 
link1 between home -> server and prefer link 2 between server -> home 
then connectivity completely breaks between the routed pools.


O.o

The point to point IPs stay reachable (which is over expected links i.e 
symmetric via both ends).


Please clarify if those IPs are inside the VPN or outside the VPN?


As long as both ends prefer link1 or link2, it works fine.


Okay.

At first, I thought it had to do something with NAT but still can't 
understand how. Since VPN tunnels have a keep-alive timer (for 10 
seconds), the tunnel is always up.


Is NAT or SPI being applied to the traffic flowing through the VPN?


Any idea why asymmetric packets are being dropped here?


Not enough data to speculate yet.

This exact behaviour was in case of earlier OpenVPN + bird + iBGP and is 
still the same when I moved everything to Wireguard for VPN + FRR for 
routing + OSPF.


Can I ask why the change of the VPN technology, routing daemon, and 
protocol all at the same time?  Or was that a diagnostic step?




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

RE: Issue with point to point VPNs behind NAT and asymmetric traffic

[Jerry Cloe]

Linux by default (regardless of firewall rules) will not accept a packet on an 
interface when the source of that packet "should" be on another interface 
according to the current route table (in other words, you're doing asymetric 
routing).

 
Easy fix:

 
# Controls source route verification
net.ipv4.conf.default.rp_filter = 0
# Do not accept source routing
net.ipv4.conf.default.accept_source_route = 1

 
-Original message-
From:Anurag Bhatia 
Sent:Wed 06-12-2019 04:45 pm
Subject:Issue with point to point VPNs behind NAT and asymmetric traffic
To:NANOG Mailing List ; 
 
Hello everyone, 
 Trying to get my head around a certain unexpected behaviour. 
  I am running two site to site VPNs (wireguard now, OpenVPN earlier) between 
my home and a remote server over two different WAN links. Both WAN links are 
just consumer connections - one with public IP and one with CGNATed IP. 
The redundancy here is taken care of by the OSPF running via FRR on both ends. 
  The unexpected behaviour I get is that if I set OSPF cost to prefer say link1 
between home -> server and prefer link 2 between server -> home then 
connectivity completely breaks between the routed pools. The point to point IPs 
stay reachable (which is over expected links i.e symmetric via both ends). As 
long as both ends prefer link1 or link2, it works fine. At first, I thought it 
had to do something with NAT but still can't understand how. Since VPN tunnels 
have a keep-alive timer (for 10 seconds), the tunnel is always up. Any idea why 
asymmetric packets are being dropped here? 
This exact behaviour was in case of earlier OpenVPN + bird + iBGP and is still 
the same when I moved everything to Wireguard for VPN + FRR for routing + OSPF. 
Thanks. 

 -- 

 Anurag Bhatia
 anuragbhatia.com <http://anuragbhatia.com> 
 

Re: Issue with point to point VPNs behind NAT and asymmetric traffic

[Ross Tajvar]

My guess is something is doing stateful filtering. If you send a SYN down
one link and the SYN-ACK comes back a different link, the receiving
firewall will discard it as bogus. You should be able to test this by doing
pcaps to confirm the traffic is arriving (though I'm not familiar with
WireGuard so maybe not), and you should be able to disable this by setting
a rule or unchecking a box in your firewall.

On Wed, Jun 12, 2019, 5:47 PM Anurag Bhatia  wrote:

> Hello everyone,
>
> Trying to get my head around a certain unexpected behaviour.
>
>
> I am running two site to site VPNs (wireguard now, OpenVPN earlier)
> between my home and a remote server over two different WAN links. Both WAN
> links are just consumer connections - one with public IP and one with
> CGNATed IP.
> The redundancy here is taken care of by the OSPF running via FRR on both
> ends.
>
>
> The unexpected behaviour I get is that if I set OSPF cost to prefer say
> link1 between home -> server and prefer link 2 between server -> home then
> connectivity completely breaks between the routed pools. The point to point
> IPs stay reachable (which is over expected links i.e symmetric via both
> ends). As long as both ends prefer link1 or link2, it works fine. At first,
> I thought it had to do something with NAT but still can't understand how.
> Since VPN tunnels have a keep-alive timer (for 10 seconds), the tunnel is
> always up. Any idea why asymmetric packets are being dropped here?
> This exact behaviour was in case of earlier OpenVPN + bird + iBGP and is
> still the same when I moved everything to Wireguard for VPN + FRR for
> routing + OSPF.
>
>
>
>
> Thanks.
>
>
> --
>
>
> Anurag Bhatia
> anuragbhatia.com
>

Re: Issue with point to point VPNs behind NAT and asymmetric traffic

[blakangel]

Could it be as simple as a stateful firewall?

Anurag Bhatia wrote on 6/12/2019 14:44:


Hello everyone,

Trying to get my head around a certain unexpected behaviour.


I am running two site to site VPNs (wireguard now, OpenVPN earlier) 
between my home and a remote server over two different WAN links. Both 
WAN links are just consumer connections - one with public IP and one 
with CGNATed IP.
The redundancy here is taken care of by the OSPF running via FRR on 
both ends.



The unexpected behaviour I get is that if I set OSPF cost to prefer 
say link1 between home -> server and prefer link 2 between server -> 
home then connectivity completely breaks between the routed pools. The 
point to point IPs stay reachable (which is over expected links i.e 
symmetric via both ends). As long as both ends prefer link1 or link2, 
it works fine. At first, I thought it had to do something with NAT but 
still can't understand how. Since VPN tunnels have a keep-alive timer 
(for 10 seconds), the tunnel is always up. Any idea why asymmetric 
packets are being dropped here?
This exact behaviour was in case of earlier OpenVPN + bird + iBGP and 
is still the same when I moved everything to Wireguard for VPN + FRR 
for routing + OSPF.





Thanks.


--


Anurag Bhatia
anuragbhatia.com <http://anuragbhatia.com>

Issue with point to point VPNs behind NAT and asymmetric traffic

[Anurag Bhatia]

Hello everyone,

Trying to get my head around a certain unexpected behaviour.


I am running two site to site VPNs (wireguard now, OpenVPN earlier) between
my home and a remote server over two different WAN links. Both WAN links
are just consumer connections - one with public IP and one with CGNATed IP.
The redundancy here is taken care of by the OSPF running via FRR on both
ends.


The unexpected behaviour I get is that if I set OSPF cost to prefer say
link1 between home -> server and prefer link 2 between server -> home then
connectivity completely breaks between the routed pools. The point to point
IPs stay reachable (which is over expected links i.e symmetric via both
ends). As long as both ends prefer link1 or link2, it works fine. At first,
I thought it had to do something with NAT but still can't understand how.
Since VPN tunnels have a keep-alive timer (for 10 seconds), the tunnel is
always up. Any idea why asymmetric packets are being dropped here?
This exact behaviour was in case of earlier OpenVPN + bird + iBGP and is
still the same when I moved everything to Wireguard for VPN + FRR for
routing + OSPF.




Thanks.


-- 


Anurag Bhatia
anuragbhatia.com

Re: netflix OCA in a CG-NAT world

[Mark Tinka]

So comparing the ARP and ND tables on my Mikrotik home router, I see
that my Apple TV, indeed, does have an IPv6 address assigned to it
(SLAAC), even though the device, itself, does not display any IPv6
information in its network settings.

Then again, Apple never did think an "HDD is Active" blinker on their
laptops was ever necessary :-).

Mark.

On 28/Nov/18 22:10, Mark Tinka wrote:
>
> On 28/Nov/18 17:23, Nikolay Shopik wrote:
>
>> tvOS will only show IPv6 dns servers in their "Network Settings" tab.
>> They just forgot to update interface for some reason, like they did in
>> back ios10 iirc to show all network configuration including IPv6.
> I'm running tvOS 12.1 (16J602), and there is no display of anything IPv6
> anywhere on the system.
>
> Mark.

Re: netflix OCA in a CG-NAT world

[Mark Tinka]

On 28/Nov/18 17:23, Nikolay Shopik wrote:

> tvOS will only show IPv6 dns servers in their "Network Settings" tab.
> They just forgot to update interface for some reason, like they did in
> back ios10 iirc to show all network configuration including IPv6.

I'm running tvOS 12.1 (16J602), and there is no display of anything IPv6
anywhere on the system.

Mark.

Re: netflix OCA in a CG-NAT world

[Nikolay Shopik]

On 28/11/18 5:25 pm, Mark Tinka wrote:
> Well, my Apple TV interface only has IPv4 bits to show.
> 
> Are you saying IPv6 is hidden from the "Network Settings" tab? I haven't
> done an actual wire tap.

tvOS doesn't expose IPv6 addresses but it fully supported just like all
ios based systems since all apps now required to work in IPv6-only
network, otherwise they won't able push update into app store.

tvOS will only show IPv6 dns servers in their "Network Settings" tab.
They just forgot to update interface for some reason, like they did in
back ios10 iirc to show all network configuration including IPv6.

Re: netflix OCA in a CG-NAT world

[Bryan Holloway]

On 11/28/18 8:25 AM, Mark Tinka wrote:



On 28/Nov/18 13:37, Nikolay Shopik wrote:


Sony Entertainment is know to be slowpoke in this area. PS4
firmware/kernel is SLAC enabled IPv6 but its not exposed to devs and
thus apps doesn't use it at all.


Which is what really surprised me with this 2014 TV I have, considering
it stopped getting updates about 2 or so years ago.


Are you sure about ATV4 netflix app? Support is there and I've seen
traffic from it when recently did tcpdump from ATV4.


Well, my Apple TV interface only has IPv4 bits to show.

Are you saying IPv6 is hidden from the "Network Settings" tab? I haven't
done an actual wire tap.

Mark.




Vizio also no joy with IPv6.

Sigh.

Re: netflix OCA in a CG-NAT world

[Mark Tinka]

On 28/Nov/18 16:15, Radu-Adrian Feurdean wrote:

> Or there is some braindead wifi in-between that does not allow IPv6 to 
> function (or makes it unreliable). Already seens a number of such devices 
> from different vendors.

I have mine hooked into Cat-6 to my home switch (which has switching
IPv6 traffic for all devices that support it).

I have IPv6 working over wi-fi for all devices that support it,
including iPhones and such.

But like I said before, I've seen every device supporting IPv6 to have
IPv6 setting bits. Apple TV 4 - my one anyway - does not have this. Only
IPv4.

Mark.

Re: netflix OCA in a CG-NAT world

[Mark Tinka]

On 28/Nov/18 15:41, valdis.kletni...@vt.edu wrote:

> Odd.  Mine does DHCPv6. It might do SLAC as well, my OpenWRT wouldn't
> notice an unused SLAC address..

On what Sony device? I know they have different OS's for different TV
models, which could have an impact on this...

Mark.



signature.asc
Description: OpenPGP digital signature

Re: netflix OCA in a CG-NAT world

[Mark Tinka]

On 28/Nov/18 13:37, Nikolay Shopik wrote:

> Sony Entertainment is know to be slowpoke in this area. PS4
> firmware/kernel is SLAC enabled IPv6 but its not exposed to devs and
> thus apps doesn't use it at all.

Which is what really surprised me with this 2014 TV I have, considering
it stopped getting updates about 2 or so years ago.
>
> Are you sure about ATV4 netflix app? Support is there and I've seen
> traffic from it when recently did tcpdump from ATV4.

Well, my Apple TV interface only has IPv4 bits to show.

Are you saying IPv6 is hidden from the "Network Settings" tab? I haven't
done an actual wire tap.

Mark.

Re: netflix OCA in a CG-NAT world

[Radu-Adrian Feurdean]

On Wed, Nov 28, 2018, at 12:37, Nikolay Shopik wrote:

> Are you sure about ATV4 netflix app? Support is there and I've seen
> traffic from it when recently did tcpdump from ATV4.

Or there is some braindead wifi in-between that does not allow IPv6 to function 
(or makes it unreliable). Already seens a number of such devices from different 
vendors.

Re: netflix OCA in a CG-NAT world

[valdis . kletnieks]

On Wed, 28 Nov 2018 14:37:06 +0300, Nikolay Shopik said:
> Sony Entertainment is know to be slowpoke in this area. PS4
> firmware/kernel is SLAC enabled IPv6 but its not exposed to devs and
> thus apps doesn't use it at all.

Odd.  Mine does DHCPv6. It might do SLAC as well, my OpenWRT wouldn't
notice an unused SLAC address..


pgpLIxoRc8bvb.pgp
Description: PGP signature

Re: netflix OCA in a CG-NAT world

[Nikolay Shopik]

Sony Entertainment is know to be slowpoke in this area. PS4
firmware/kernel is SLAC enabled IPv6 but its not exposed to devs and
thus apps doesn't use it at all.

Are you sure about ATV4 netflix app? Support is there and I've seen
traffic from it when recently did tcpdump from ATV4.

On 28/11/18 9:27 am, Mark Tinka wrote:
> But I watch my Netflix on my Apple TV 4, PS4 and PS3, all of which don't
> currently support IPv6 in 2018 :-(...

Re: netflix OCA in a CG-NAT world

[Mark Tinka]

On 26/Nov/18 06:47, Dave Temkin wrote:

>
> And yes, IPv6 is fully supported by every piece of our infrastructure;
> the issue is TVs and STBs that do not support v6 - but we have finally
> seen the largest device manufacturers commit to supporting it (if they
> don't already on their late model sets) so that should change year
> over year.

Funny you should mention this... my Sony TV from 2014 has IPv6 support:

    https://www.youtube.com/watch?v=la9G3bF6rYU   

But I watch my Netflix on my Apple TV 4, PS4 and PS3, all of which don't
currently support IPv6 in 2018 :-(...

Mark.

Re: netflix OCA in a CG-NAT world

[Dave Temkin]

On Tue, Nov 27, 2018 at 3:48 AM Grant Taylor via NANOG 
wrote:

> On 11/25/2018 09:47 PM, Dave Temkin wrote:
> > Putting an OCA with bypass through the CGN with RFC1918 space will
> > actually work just fine. We (Netflix) don't formally support it because
> > of the vast number of non-standard CGN implementations out there, but if
> > your clients are in RFC1918 space and the next hop router from the OCA
> > knows how to reach them, it will just work.
>
> Does this include RFC 6598 Shared Address Space, 100.64.0.0/10?  Or is
> it limited to RFC 1918 Address Space?
>
> Does it really matter what the private IPs are?  (I've seen people
> re-use publicly allocated but not publicly used IP address space.)  Or
> does it "just work" as long as the OCA's first hop knows how to reach
> the private IPs?
>
>
>
The latter.

-Dave

Re: netflix OCA in a CG-NAT world

[Grant Taylor via NANOG]

On 11/25/2018 09:47 PM, Dave Temkin wrote:
Putting an OCA with bypass through the CGN with RFC1918 space will 
actually work just fine. We (Netflix) don't formally support it because 
of the vast number of non-standard CGN implementations out there, but if 
your clients are in RFC1918 space and the next hop router from the OCA 
knows how to reach them, it will just work.


Does this include RFC 6598 Shared Address Space, 100.64.0.0/10?  Or is 
it limited to RFC 1918 Address Space?


Does it really matter what the private IPs are?  (I've seen people 
re-use publicly allocated but not publicly used IP address space.)  Or 
does it "just work" as long as the OCA's first hop knows how to reach 
the private IPs?




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: netflix OCA in a CG-NAT world

[Dave Temkin]

Not exactly. You don't need to advertise the RFC1918 to the OCA - just make
sure you advertise the CGN prefix to it, and make sure that the OCA's
default gateway knows how to reach the RFC1918 clients. So long as the
"outside" IP of your CGN is advertised to the OCA (the IP that clients who
would be using the OCA would appear to the internet as) it should work.

Regards,
-Dave

On Mon, Nov 26, 2018 at 1:04 PM Aaron1  wrote:

> Thanks Dave, so my local OCA will listen to my BGP advertisements for
> RFC1918 prefixes if I decided to advertise them?
>
> Aaron
>
> On Nov 25, 2018, at 10:47 PM, Dave Temkin  wrote:
>
> FWIW (reviving an old thread)-
>
> Putting an OCA with bypass through the CGN with RFC1918 space will
> actually work just fine. We (Netflix) don't formally support it because of
> the vast number of non-standard CGN implementations out there, but if your
> clients are in RFC1918 space and the next hop router from the OCA knows how
> to reach them, it will just work. We only use BGP to inform our control
> plane, not for local routing. Any traffic not served via the OCA will go
> through CGN as usual and out peering/transit. Note that it does complicate
> troubleshooting for both sides.
>
> And yes, IPv6 is fully supported by every piece of our infrastructure; the
> issue is TVs and STBs that do not support v6 - but we have finally seen the
> largest device manufacturers commit to supporting it (if they don't already
> on their late model sets) so that should change year over year.
>
> -Dave
>
> On Mon, Sep 17, 2018 at 11:52 PM Jared Mauch 
> wrote:
>
>>
>>
>> > On Sep 17, 2018, at 6:54 AM, Tom Ammon  wrote:
>> >
>> > I'm looking to understand the impact of CG-NAT on a set of netflix
>> OCAs, in an ISP environment. I see in Netflix's FAQ on the subject that
>> traffic sourced from RFC 1918/6598 endpoints can't be delivered to the OCA.
>> Is this simply a matter of deploying the OCA on the outside of the CGN
>> layer? What are the other consequences of CGN upon the OCA?
>> >
>>
>> Yes, you want to deploy it outside your CG-NAT.
>>
>> I also strongly suggest you look at how to get native IPv6 from your
>> clients behind the CG-NAT rolled out.  I know many folks have had issues
>> with various CDNs and the number of devices that reach out.  This is why
>> folks get the Google captcha, etc.
>>
>> Giving those end-users an alternate way out will help.  I understand this
>> may take effort and is harder for folks using UBNT & Tik gear in a smaller
>> environment, but there is value for your end-users.
>>
>> - Jared
>>
>>

Re: netflix OCA in a CG-NAT world

[Aaron1]

Thanks Dave, so my local OCA will listen to my BGP advertisements for RFC1918 
prefixes if I decided to advertise them?

Aaron

> On Nov 25, 2018, at 10:47 PM, Dave Temkin  wrote:
> 
> FWIW (reviving an old thread)-
> 
> Putting an OCA with bypass through the CGN with RFC1918 space will actually 
> work just fine. We (Netflix) don't formally support it because of the vast 
> number of non-standard CGN implementations out there, but if your clients are 
> in RFC1918 space and the next hop router from the OCA knows how to reach 
> them, it will just work. We only use BGP to inform our control plane, not for 
> local routing. Any traffic not served via the OCA will go through CGN as 
> usual and out peering/transit. Note that it does complicate troubleshooting 
> for both sides.
> 
> And yes, IPv6 is fully supported by every piece of our infrastructure; the 
> issue is TVs and STBs that do not support v6 - but we have finally seen the 
> largest device manufacturers commit to supporting it (if they don't already 
> on their late model sets) so that should change year over year.
> 
> -Dave
> 
>> On Mon, Sep 17, 2018 at 11:52 PM Jared Mauch  wrote:
>> 
>> 
>> > On Sep 17, 2018, at 6:54 AM, Tom Ammon  wrote:
>> > 
>> > I'm looking to understand the impact of CG-NAT on a set of netflix OCAs, 
>> > in an ISP environment. I see in Netflix's FAQ on the subject that traffic 
>> > sourced from RFC 1918/6598 endpoints can't be delivered to the OCA. Is 
>> > this simply a matter of deploying the OCA on the outside of the CGN layer? 
>> > What are the other consequences of CGN upon the OCA?
>> > 
>> 
>> Yes, you want to deploy it outside your CG-NAT.  
>> 
>> I also strongly suggest you look at how to get native IPv6 from your clients 
>> behind the CG-NAT rolled out.  I know many folks have had issues with 
>> various CDNs and the number of devices that reach out.  This is why folks 
>> get the Google captcha, etc.
>> 
>> Giving those end-users an alternate way out will help.  I understand this 
>> may take effort and is harder for folks using UBNT & Tik gear in a smaller 
>> environment, but there is value for your end-users.
>> 
>> - Jared
>> 

Re: netflix OCA in a CG-NAT world

[Dave Temkin]

FWIW (reviving an old thread)-

Putting an OCA with bypass through the CGN with RFC1918 space will actually
work just fine. We (Netflix) don't formally support it because of the vast
number of non-standard CGN implementations out there, but if your clients
are in RFC1918 space and the next hop router from the OCA knows how to
reach them, it will just work. We only use BGP to inform our control plane,
not for local routing. Any traffic not served via the OCA will go through
CGN as usual and out peering/transit. Note that it does complicate
troubleshooting for both sides.

And yes, IPv6 is fully supported by every piece of our infrastructure; the
issue is TVs and STBs that do not support v6 - but we have finally seen the
largest device manufacturers commit to supporting it (if they don't already
on their late model sets) so that should change year over year.

-Dave

On Mon, Sep 17, 2018 at 11:52 PM Jared Mauch  wrote:

>
>
> > On Sep 17, 2018, at 6:54 AM, Tom Ammon  wrote:
> >
> > I'm looking to understand the impact of CG-NAT on a set of netflix OCAs,
> in an ISP environment. I see in Netflix's FAQ on the subject that traffic
> sourced from RFC 1918/6598 endpoints can't be delivered to the OCA. Is this
> simply a matter of deploying the OCA on the outside of the CGN layer? What
> are the other consequences of CGN upon the OCA?
> >
>
> Yes, you want to deploy it outside your CG-NAT.
>
> I also strongly suggest you look at how to get native IPv6 from your
> clients behind the CG-NAT rolled out.  I know many folks have had issues
> with various CDNs and the number of devices that reach out.  This is why
> folks get the Google captcha, etc.
>
> Giving those end-users an alternate way out will help.  I understand this
> may take effort and is harder for folks using UBNT & Tik gear in a smaller
> environment, but there is value for your end-users.
>
> - Jared
>
>

Re: NAT on a Trident/Qumran(/or other?) equipped whitebox?

[Paul Zugnoni]

The problem asking whether this can be done "at line rate" in a specific
switch platform ignores these critical measurements:
- what's the packet rate expected for the nat flows?
- will the control plane add a forwarding plane rule for every new session?
if so, how quickly can that rule be pushed to the ASIC? how many per second
can be done? I think you'll quickly find that new session rate will be a
more limiting factor to the thruput than the bandwidth of the involved
ports. An architecture to support that would be far more expensive. Maybe
this was the case on the platforms Joel noted, and I believe modern
"hardware based" firewall like higher end SRX and some Fortinet.
- If not with the architecture above, then every packet needs to be punted
to the CPU. What's the bw between ASIC and CPU? Consider the CPU is doing
the decision making based on flows; the control plane usually has only 1G
to the ASIC, sometimes and probably increasingly common is 10G.

For these reasons I doubt the 7150s in the original email can dynamically
NAT at line rate

PZ

On Tue, Oct 16, 2018 at 9:25 AM joel jaeggli  wrote:

> On 10/16/18 08:55, Brandon Martin wrote:
> > On 10/16/18 10:05 AM, James Bensley wrote:
> >> NAT/PAT is an N:1 swapping (map) though so a state/translation table
> >> is required to correctly "swap" back the return traffic. MPLS for
> >> example is 1:1 mapping/action. NAT/PAT state tables tend to fill
> >> quickly so to aid with this we also have timers to time out the
> >> translations and free up space in the translation table, and also
> >> track e.g. TCP RST or TCP FIN to remove entries from the table, so
> >> it's not "just swapping".
> >
> > I do wonder, though, if these popular switching ASICs are flexible
> > enough in terms of their header matching and manipulation capabilities
> > to handle packet mangling and forwarding in hardware for a given NAT
> > state entry while punting anything that requires a state change to a CPU
> > for inspection and state update.
> >
> > You'd need a somewhat more powerful CPU than your typical L3 switch
> > might have, but it seems like you'd still be able to offload the vast
> > majority of the actual packet processing to hardware.
>
> This is a flow cached router fundamentally. They exist. In that design
> you burn your fib on flow entries rather than on nexthop routes. They
> tend to explode at forwarding rates far lower than a typical ethernet
> switch when their ability to accumulate new state is exercised.
> riverstone RS circa 1999-2004 and various cisco products (sup 1a cat6k?)
> did follow that model.
>
> > State table size (on a typical "switching" ASIC) might be an issue
> > before you could actually fill up a 10Gbps+ link with typical SP
> > multi-user traffic flows, I guess, and given that a moderate-spec PC can
> > keep up with 10Gbps without much issue these days, maybe it's a
> > non-starter.
>
>
>