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: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address block

[Abraham Y. Chen via NANOG]

Hi, Chris:

0)    Thanks for your observation.

1)    Although I specifically requested Karim to go offline on our idea 
to his inquiry, lots of comments appeared on NANOG publicly. To be 
polite, I tried to respond by clarifying and describing each. 
Unfortunately, many comments are actually persistent IPv6 promotions, 
even my attempt of bringing up the community consensus of "Dual-Stack 
has distinguished IPv6 and IPv4 into separate tracks" was in vain.


2)    Philosophically, IPv6 and IPv4 are kind of like two religions, 
each with its own believers. As long as the devotees of each focus on 
their respective passion, the world will be peaceful. As soon as one 
camp imposes its preference onto the other, friction starts. Unchecked, 
it can go even worse. ... But, I digressed.


Regards,


Abe (2024-01-21 12:06)


On 2024-01-20 12:50, Chris Adams wrote:

Once upon a time,sro...@ronan-online.comsaid:

I am curious if anyone has ever given you positive feedback on this idea? So far
all I’ve seen is the entire community thinking it’s a bad idea. Why do you
insist this is a good solution?

Because people keep responding.




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

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

[Abraham Y. Chen]

Hi, Christopher:

1)     "    ... It would simply increase the workload of their support 
and provisioning teams. Right now, in cases where ISPs use DHCP, they 
can simply ship a router to an end-user, the user plugs it in, turns it 
on, and away they go. ":


    I do understand the current practice that you are describing. 
However, there is nothing wrong by instructing a subscriber to attempt 
accessing the ISP's sign-up website with his browser when first turning 
on the router, so that a process of checking the credentials of the 
subscriber can go through, then a static WAN (240/4) address is assigned 
to the router. From there on, everything should operate normally  as far 
as the subscriber is concrned. This process is not special. For example, 
when a traveler checks into a hotel these days, he would go through 
pretty much the same steps with minimal identification (Certain hotel 
network even knew which room I was in by popping my name on the screen, 
perhaps because the WiFi access point was fed by wired Ethernet! Only 
password provided by the front desk was needed.) Then, everything works 
just like at home.


2)    "   ...  If an end-user has a router that does not support 
OpenWrt, it will require the end-user to replace their router with one 
that does in order to connect to an EzIP-enabled network. ":


    Correct. But, RAN is an overlay network that provides a parallel 
route to the same services as the current CG-NAT. So, an end-user has 
the option to use it. Nothing hurts, if he decides to ignore the RAN.


3)    "  A carrier would not have a need for more than ~4.1m devices on 
a single regional access network ...   ":


    This is a system level planning consideration. That is, even if 
some carriers do not need EzIP, it does not mean that the capability 
should not be presented to the general audience. Let's hold this off for 
the moment.


Regards,


Abe (2024-01-20 11:55)




On 2024-01-18 23:19, Christopher Hawker wrote:
According to the diagram on page 8 of the presentation on your website 
at https://www.avinta.com/phoenix-1/home/EzIPenhancedInternet.pdf, it 
simply identifies 240/4 as CGNAT space. Routing between regional 
access networks typically doesn't take place when using such space on 
an ISP network, and most ISPs (that I know of) will offer public 
addressing when it is required. Further, if you think the need for 
DHCP will be eliminated through the use of your solution, I hate to 
say it, but ISPs will not statically configure WAN addressing on CPE 
for residential services. It would simply increase the workload of 
their support and provisioning teams. Right now, in cases where ISPs 
use DHCP, they can simply ship a router to an end-user, the user plugs 
it in, turns it on, and away they go. Connectivity to the internet.


If an end-user has a router that does not support OpenWRT, it will 
require the end-user to replace their router with one that does in 
order to connect to an EzIP-enabled network. This is not reasonably 
practical. This would also require router vendors to support 
connectivity to a proprietary "semi-public router".


Again, for the sake of completeness, this solution is a waste of time 
and resources. A carrier would not have a need for more than ~4.1m 
devices on a single regional access network and some may run more than 
one in a single region, so as not to put all of their proverbial eggs 
into the same basket.


Regards,
Christopher Hawker

On Fri, 19 Jan 2024 at 14:49, Abraham Y. Chen  wrote:

Hi, Christopher:

1)    " If "EzIP" is about using 240/4 as CGNAT space, ...   ":

    This correlation is just the starting point for EzIP
deployment, so that it would not be regarded as a base-less crazy
dream. Once a 240/4 enabled RAN is established as a new network
overlaying on the CG-NAT infrastructure, the benefits of making
use of the 240/4 resources can begin to be considered. For
example, with sufficient addresses, static address administration
can be practiced within a RAN which will remove the need for DHCP
service. From this, related consequences may be discussed.


2)    " I don't think you quite grasp the concept that OpenWRT is
not compatible with devices that do not support it.  it would
not be appropriate to expect every device vendor to support it. 
...   ":

    Perhaps we have some offset about the terminology of "who
supports whom?" My understanding of the OpenWrt project is that it
is an open-source program code that supports a long list (but not
all) of primarily commercial RGs (Residential/Routing Gateways)
and WiFi routers that serve / support CPE devices (on-premises
IoTs). Its basic purpose is to let private network owners to
replace the firmware code in the RGs with the OpenWrt equivalent
so that they will have full control of their RGs a

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_source=link_campaign=sig-email_content=emailclient> 









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

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

[Abraham Y. Chen]

Hi, Owen:

0)   Thanks for sorting out my vague memory, citing some consumer 
electronics evolution history and an excellent overview of the current 
IPv4/IPv6 landscape.


1)    I believe that consumer electronics including PC related products 
and services are in a separate category from the IPv4 to IPv6 transition 
considerations. The latter is part of global communications systems that 
backward compatibility should be regarded a given requirement. The 
former normally plays out by free market force such as consumer 
preference which are highly influenced by marketing banners and changes 
with time. (For example, the vacuum tube stereo amplifiers and vinyl 
records recently came back in force, after so many years of obsolescent. 
However, going either direction was not a concern of most, except a few 
audio enthusiasts.)  Maintaining smooth daily operation of the latter 
while going through the evolution is very important for everyone. Short 
of such, the process will be frustratingly hard to predict.


2)   "   In the case of the DTMF transition, ...  AT could simply 
have shipped replacement phones with instructions for returning the 
older phone and done a retrofit operation if they really wanted to drive 
the transition.":


    Correct, because back then, the station instruments were on long 
term lease from Bell Operating Companies. Even so, CO equipment 
readiness and the economics (Although DTMF shortened each subscriber 
dialing session almost by ~90% which was a big operation saving for the 
COs, subscriber could not sense, therefore did not care for the upgrade 
from DD.)  of such a big replacement process had to be carefully 
considered. With the break-up of the Bell System and the consequent 
abundance of CPE products on the market, the window of opportunity went 
by before anyone realized.


3)    The diversity of the Internet constituencies as you outlined make 
the transition from IPv4 to IPv6 an even more challenging event. I 
believe that the current general consensus of coexistence with 
Dual-Stack bridging the two should have settled the debates.  From now 
on, everyone should focus on his own passion. The continued efforts of 
persuading others to move one way or the other are counter-productive 
from an overall perspective.


Regards,


Abe (2024-01-19 12:20)



On 2024-01-19 05:26, Owen DeLong wrote:




On Jan 15, 2024, at 09:37, Abraham Y. Chen  wrote:

Hi, Christopher"

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

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




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


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


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


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


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


2)    Allow me to share with you an almost parallel event in the 
PSTN, to illustrate how tough is to achieve the replacement of a 
wo

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: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address block

[Abraham Y. Chen]

ng ideas and suggestions and working towards 
proper IPv6 deployment. It certainly appears to be the case that the 
community does not support your proposed "EzIP" solution. If you are 
recommending that 240/4 space be used for CGNAT space under RFC6598, 
then call it as it is instead of inventing new terminology.


Regards,
Christopher Hawker

On Tue, 16 Jan 2024 at 03:27, Abraham Y. Chen  wrote:

Hi, Christopher:

1)    " Hang on... So EzIP is now about using 240/4 as CGNAT
space? Wait, I'm lost...   ":

    Correct. This is one way to visualize the EzIP deployment.
This configuration is so far the most concise manner to describe
the the EzIP building block, RAN (Regional Area Network). The nice
thing about this approach is that everything exists and is already
working daily in each CG-NAT cluster. All needed to expand its
capability is a larger netblock. Since 240/4 is fundamentally not
an outlier in the overall IPv4 address pool, except being
classified as "Reserved" for a long time, enabling it to work in a
CG-NAT should not be any big challenge.

2)    "   ... There is no such thing as "semi-private" space in
the world of CGNAT, ... ":

    Correct. However, not distinguishing 100.64/10 netblock from
the common public and private parts of the IPv4 space made it
vague as which function does it provide. That is, in terms of
re-usability for each isolated geographical area, it is like
another RFC1918 private netblock. On the other hand, CG-NAT is
clearly used in geographically public areas. So, 100.64/10 should
be classified as "public". In addition, 100.64/10 is listed
according to "IANA IPv4 Address Space Registry" as part of the
100/8 netblock under ARIN, but now used by everyone worldwide. To
avoid similar ambiguity that leads to confusions, we decided to
call 240/4 as "semi-public" to more explicitly convey the concept.
(Actually, we initially called 240/4 "semi-private" thinking that
it could be the fourth RFC1918 netblock, until we realized that
the RFC6589 environment was a much better fit.)

3)    " Your "solution" to residential gateways not supporting the
use of 240/4 space being upgraded to OpenWrt won't work, because
not all CPE supports OpenWrt.   ":

    OpenWrt is just an open source RG code that can replace that
in commercial RGs that have been supporting CPEs. Like the EzIP
concept, the OpenWrt upgrade of RG-NAT is an enhancement to the
existing RG functionality. Thus, OpenWrt enabled RGs can operate
with the combination of public (including RFC6589) with 240/4
netblocks on the upstream (WAN) side, and private (RFC1918) with
240/4 netblocks on the downstream (LAN) side. So, there is no
compatibility change that a CPE (on-premises IoT) can sense. This
critical characteristics was the result of an OpenWrt core code
upgrade in 2019 contributed by Dave Taht of "IPv4 Unicast
Extensions Project". Before that, EzIP was just a theoretically
feasible scheme.

4)    In addition,  OpenWrt at least works with one network router
by D-Link (see URL below). This means that, with both WAN and LAN
sides of a router supporting 240/4, a beginner's reference RAN can
be built and experimented with it:


https://us.dlink.com/en/products/dgs-1210-28-28-port-gigabit-smart-managed-switch

5)    " Instead of attempting to use a larger prefix for CGNAT,
IPv6 is definitely the easier solution to implement as the vast
majority of vendors already support v6. ":

    Since the general consensus is that for moving ahead, we will
rely on Dual-Stack to bridge IPv6 and IPv4 worlds enabling them to
coexist for the foreseeable future, it would more expedient for
the community as a whole, if we could focus on technical
discussions for each camp respectively, while minimizing
invitation messages from the other side. I hope you do agree.

Regards,


Abe (2024-01-15 11:27)




<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
Virus-free.www.avast.com

<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>


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

[Abraham Y. Chen]

Hi, Sronan:

1) “Radio Access Network”:

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


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


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

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


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


Regards,

Abe (2024-01-15 18:48)





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


Shane


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


Hi, Forrest:

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


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


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


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


Regards,


Abe (2024-01-15 00:02)


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

A couple of points:

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


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


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


I see no reason why IPv4 should be any different.

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

Hi, Forrest:

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

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

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

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

    The obvious answer was IPv6. However, its performance after
near two decades of deployment has not been convincing. Ez

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

[Abraham Y. Chen]

Hi, Forrest:

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


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


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


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


Regards,


Abe (2024-01-15 00:02)


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

A couple of points:

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


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


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


I see no reason why IPv4 should be any different.

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

Hi, Forrest:

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

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

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

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

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

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

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

    Fast forward by half a century, the Internet promotes
distributed approaches. Few things can be controlled by limited
couple parties. The decision of go or no-go is made by

Re: Vint Cerf Re: Backward Compatibility Re: IPv4 address block

[Abraham Y. Chen]

, and RFC 793 / 9293 (
TCP, original and updated ).



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


Hi, Tom:

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

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

***


internetpol...@elist.isoc.org
<mailto:internetpol...@elist.isoc.org>eMail thread


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


Dear Vint:


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

Thanks,

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


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


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


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


        /*v*/


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


Hi, Scott:


 0)    Thanks for your research.


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


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



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

Hope the above clears the air.


Regards,


Abe (2024-01-13 07:34)


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



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

Fairly impressive sequence of self ownage.

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





<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
Virus-free.www.avast.com

<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_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

[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: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block

[Abraham Y. Chen]

Hi, Christopher"

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

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


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


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


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


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


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


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


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


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


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


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


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


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



Regards,


Abe (2024-01-15 12:37)




On 2024-01-15 00:15, Christopher Hawker wrote:
To my knowledge IPv6 is designed to replace IPv4. Anyone, feel free to 
correct me if I'm wrong. There are just short of 4.3 billion IPv4 
addresses, where the number of IPv6 addresses is 39 digits long.


Regards,
Christopher Hawker

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

Hi, Randy:

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

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

Regards,


Abe (2024-01-14 23:17)


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

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

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

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

randy





<https://www.avast.com/sig-e

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

[Abraham Y. Chen]

Hi, Christopher:

1)    " Hang on... So EzIP is now about using 240/4 as CGNAT space? 
Wait, I'm lost...   ":


    Correct. This is one way to visualize the EzIP deployment. This 
configuration is so far the most concise manner to describe the the EzIP 
building block, RAN (Regional Area Network). The nice thing about this 
approach is that everything exists and is already working daily in each 
CG-NAT cluster. All needed to expand its capability is a larger 
netblock. Since 240/4 is fundamentally not an outlier in the overall 
IPv4 address pool, except being classified as "Reserved" for a long 
time, enabling it to work in a CG-NAT should not be any big challenge.


2)    "   ... There is no such thing as "semi-private" space in the 
world of CGNAT, ... ":


    Correct. However, not distinguishing 100.64/10 netblock from the 
common public and private parts of the IPv4 space made it vague as which 
function does it provide. That is, in terms of re-usability for each 
isolated geographical area, it is like another RFC1918 private netblock. 
On the other hand, CG-NAT is clearly used in geographically public 
areas. So, 100.64/10 should be classified as "public". In addition, 
100.64/10 is listed according to "IANA IPv4 Address Space Registry" as 
part of the 100/8 netblock under ARIN, but now used by everyone 
worldwide. To avoid similar ambiguity that leads to confusions, we 
decided to call 240/4 as "semi-public" to more explicitly convey the 
concept. (Actually, we initially called 240/4 "semi-private" thinking 
that it could be the fourth RFC1918 netblock, until we realized that the 
RFC6589 environment was a much better fit.)


3)    " Your "solution" to residential gateways not supporting the use 
of 240/4 space being upgraded to OpenWrt won't work, because not all CPE 
supports OpenWrt.   ":


    OpenWrt is just an open source RG code that can replace that in 
commercial RGs that have been supporting CPEs. Like the EzIP concept, 
the OpenWrt upgrade of RG-NAT is an enhancement to the existing RG 
functionality. Thus, OpenWrt enabled RGs can operate with the 
combination of public (including RFC6589) with 240/4 netblocks on the 
upstream (WAN) side, and private (RFC1918) with 240/4 netblocks on the 
downstream (LAN) side. So, there is no compatibility change that a CPE 
(on-premises IoT) can sense. This critical characteristics was the 
result of an OpenWrt core code upgrade in 2019 contributed by Dave Taht 
of "IPv4 Unicast Extensions Project". Before that, EzIP was just a 
theoretically feasible scheme.


4)    In addition, OpenWrt at least works with one network router by 
D-Link (see URL below). This means that, with both WAN and LAN sides of 
a router supporting 240/4, a beginner's reference RAN can be built and 
experimented with it:


https://us.dlink.com/en/products/dgs-1210-28-28-port-gigabit-smart-managed-switch

5)    " Instead of attempting to use a larger prefix for CGNAT, IPv6 is 
definitely the easier solution to implement as the vast majority of 
vendors already support v6. ":


    Since the general consensus is that for moving ahead, we will rely 
on Dual-Stack to bridge IPv6 and IPv4 worlds enabling them to coexist 
for the foreseeable future, it would more expedient for the community as 
a whole, if we could focus on technical discussions for each camp 
respectively, while minimizing invitation messages from the other side. 
I hope you do agree.


Regards,


Abe (2024-01-15 11:27)



On 2024-01-15 00:09, Christopher Hawker wrote:
Hang on... So EzIP is now about using 240/4 as CGNAT space? Wait, I'm 
lost...


With CGNAT, there is either public IP space in front of the gateway, 
or private space behind it. There is no such thing as "semi-private" 
space in the world of CGNAT, as devices with public IPs can't directly 
access devices behind a CGNAT gateway with a 100.64/10 address. It's 
either a public address, or a private address (not to be confused with 
an RFC1918 private address).


Let's talk hypothetically for a minute and assume that 240/4 is used 
as CGNAT space. Your "solution" to residential gateways not supporting 
the use of 240/4 space being upgraded to OpenWRT won't work, because 
not all CPE supports OpenWRT.


Instead of attempting to use a larger prefix for CGNAT, IPv6 is 
definitely the easier solution to implement as the vast majority of 
vendors already support v6.


Regards,
Christopher Hawker

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

Hi, Mike:

1)   "... only private use. ...":

    The EzIP deployment plan is to use 240/4 netblock as
"Semi-Public" addresses for the existing CG-NAT facility. With
many RG-NATs (Routing / Residential Gateway -NATs) already capable
of being 240/4 clients thru the upgrade to OpenWrt, no IoT on any
private premises will sense a

Re: Vint Cerf Re: Backward Compatibility Re: IPv4 address block

[Abraham Y. Chen]

rs **are not the same thing**.


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


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

Hi, Tom:

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

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

***

internetpol...@elist.isoc.orgeMail thread

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

Dear Vint:

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

Thanks,

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

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

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

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

/*v*/

    On Mon, Oct 18, 2021 at 8:33 AM Abraham Y. Chen via InternetPolicy
 wrote:

Hi, Scott:

 0)    Thanks for your research.

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

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



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

Hope the above clears the air.


Regards,


Abe (2024-01-13 07:34)


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


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

Fairly impressive sequence of self ownage.

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





<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
Virus-free.www.avast.com

<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>



<#m_9068981657915465318_m_898116838406432442_m_-7063806684299367540_m_-462970855676450446_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>




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

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

[Abraham Y. Chen]

Hi, Randy:

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


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


Regards,


Abe (2024-01-14 23:17)


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

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

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

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

randy




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

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

[Abraham Y. Chen]

Hi, Mike:

1)   "... only private use. ...":

    The EzIP deployment plan is to use 240/4 netblock as "Semi-Public" 
addresses for the existing CG-NAT facility. With many RG-NATs (Routing / 
Residential Gateway -NATs) already capable of being 240/4 clients thru 
the upgrade to OpenWrt, no IoT on any private premises will sense any 
change.


Regards,


Abe (2024-01-14 23:04)


On 2024-01-12 15:16, Mike Hammett wrote:

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



-
Mike Hammett
Intelligent Computing Solutions <http://www.ics-il.com/>
<https://www.facebook.com/ICSIL><https://plus.google.com/+IntelligentComputingSolutionsDeKalb><https://www.linkedin.com/company/intelligent-computing-solutions><https://twitter.com/ICSIL>
Midwest Internet Exchange <http://www.midwest-ix.com/>
<https://www.facebook.com/mdwestix><https://www.linkedin.com/company/midwest-internet-exchange><https://twitter.com/mdwestix>
The Brothers WISP <http://www.thebrotherswisp.com/>
<https://www.facebook.com/thebrotherswisp><https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg>
--------
*From: *"Tom Beecher" 
*To: *"Mike Hammett" 
*Cc: *"Ryan Hamel" , "Abraham Y. Chen" 
, nanog@nanog.org

*Sent: *Friday, January 12, 2024 2:06:32 PM
*Subject: *Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 
address block


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


You run an ISP, let me posit something.

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


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


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

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

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

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



-
Mike Hammett
Intelligent Computing Solutions <http://www.ics-il.com/>

<https://www.facebook.com/ICSIL><https://plus.google.com/+IntelligentComputingSolutionsDeKalb><https://www.linkedin.com/company/intelligent-computing-solutions><https://twitter.com/ICSIL>
Midwest Internet Exchange <http://www.midwest-ix.com/>

<https://www.facebook.com/mdwestix><https://www.linkedin.com/company/midwest-internet-exchange><https://twitter.com/mdwestix>
The Brothers WISP <http://www.thebrotherswisp.com/>

<https://www.facebook.com/thebrotherswisp><https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg>

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

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


It's unknowable really.

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

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

It's just unrealistic.

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

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

How far are we from that, in reality? I don't have any

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

[Abraham Y. Chen]

Hi, Ryan:

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

    Perhaps you were referring to the following?

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

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


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


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


    It implies that the graph the IPv6 capability (equipment readiness) 
of Google users, not necessarily the actual traffic they generate. The 
two do not equate to each other.
3)    However, the above did seem to support what was generally said in 
the public. Until, we found an interesting ongoing (the only one of such 
resource that is updated about every ten minutes) statistics by AMS-IX 
(AMSterdam Internet eXchange) :


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

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


4)    We contacted AMS-IX for a possible explanation of the obvious 
discrepancy. They politely referred us to our own ISPs. This triggered 
our curiosity. We decided that we needed to find the full world-wide 
IPv6 traffic data.


5)    There was an annual world-wide Internet traffic statistics and 
forecast published by Cisco that stopped after 2017 (see URL below to 
the last issue). We contacted Cisco in 2020 and got an eMail confirmation.


https://cloud.report/Resources/Whitepapers/eea79d9b-9fe3-4018-86c6-3d1df813d3b8_white-paper-c11-741490.pdf

6)    However, there has never been any equivalent publication for the 
IPv6 by itself that we could locate.


7)    In search for a possible explanation of the discrepancy between 
Pts. 1) & 3), we came across the following article. In brief, it 
reported that the Peering agreements among Internet backbone providers 
were less settled for IPv6 than IPv4. Thus, higher percentage of IPv6 
traffic than that of IPv4 should have been directed through the IXs 
(Internet eXchanges), such as AMS-IX.


https://www.theregister.com/2018/08/28/ipv6_peering_squabbles/

8)    The conclusion of Pt. 7) furthered our puzzlement, because it was 
opposite to what we were hoping for. That is, the roughly 5.7% IPv6 
traffic that AMS-IX sees implies that within the overall Internet, the 
IPv6 traffic should be even less than 5.7%, not as high as Google's 40+% 
(Adoption) rate. Since we did not have the resources to further the 
research on this topic, we saved the above summary to share with anyone 
interested in pursuing for a better understanding. It will be much 
appreciated, if you could share your insights of this topic.


Regards,


Abe (2024-01-14 22:49 EST)




On 2024-01-12 09:20, Ryan Hamel wrote:

Abraham,

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


Ryan

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



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



Hi, Ryan:

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


    What is your selling point?


Regards,


Abe (2024-01-12 06:44)





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

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

[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

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

[Abraham Y. Chen]

Hi, Seth:

0)    Thanks for bringing up this pair of Drafts.

1)    While I believe your "IPv4 Unicast Extension" team carried on with 
the first, Avinta got accidentally exposed to the second. After analyzed 
the hurdle it faced in adding on to RFC1918, the EzIP Project is now 
focusing on enhancing CG-NAT by expanding  RFC6598.


Regards,


Abe (2024-01-13 16:08)

On 2024-01-12 14:45, Seth David Schoen wrote:

Michael Thomas writes:


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

In 2008 there were two proposals

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

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




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

Re: Vint Cerf Re: Backward Compatibility Re: IPv4 address block

[Abraham Y. Chen]

Hi, Gary:

0)    My apologies!

1)    I thought that I am one of only a few who insist on using the most 
basic tools that get the job done, such preferring hand tools than power 
tools if possible. I believed that the ThunderBird eMail client software 
was pretty basic. Your message just reminds me that there are colleagues 
here probably still using plain text editors for eMail?


I shall keep this in mind for my future eMails.

Regards,


Abe (2024-01-13 15:54)




On 2024-01-13 14:45, Gary E. Miller wrote:

Yo Abraham!

On Sat, 13 Jan 2024 07:35:09 -0500
"Abraham Y. Chen"  wrote:


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

Uh, you realize many of us never see your red or italics?

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com   Tel:+1  541 382 8588

Veritas liberabit vos. -- Quid est veritas?
 "If you can't measure it, you can't improve it." - Lord Kelvin




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

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

[Abraham Y. Chen]

Hi, Niels:

0)    Your sender name is in an unusual format. It becomes just the 
generic NANOG address as the recipient for me to MSG send to.


1)   "  You have posted this statement like five times now in the past 
two days.   ":


    Perhaps so, I have been responding to numerous comments since my 
initial post in response to Karim Mekkaoui's inquiry. Since I have to 
address each individually, some from different angles, while some others 
are new discussions or debates, it is no surprise that the same 
expression has been used more than once to deal with them respectively. 
If you count this specific item on the sideline, you definitely will see 
the repeats. The important criterion here is whether any of them are out 
of the context? (To be honest with you, I myself feel that I have been 
playing broken records on this pretty simple and straightforward topic.)


2)   " Who is asking for this expansion of 100.64/10 (which you 
misspelled, by the way)?    ":


    Thanks for catching the typo. My understanding is that there is a 
general desire (human nature) to get a larger netblock than 100.64/10 in 
CG-NAT. This could be used for either growing market or less dynamic 
reassignment. The 240/4 can provide additional benefits to CG-NAT 
operations such as static addressing that no one has realized possible. 
So, I am putting the solution on the table. This is a basic process of 
sharing the new discoveries. Is there anything wrong with the process? 
On the other hand, if RFC6598 had picked 240/4 instead of 100.64/10 as 
the netblock, we do not need today's discussions.


Regards,

Abe (2024-01-13 12:14)


On 2024-01-12 07:34, Niels Bakker wrote:

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


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

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


[five meters of superfluous quote history snipped]


-- Niels.




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

[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_source=link_campaign=sig-email_content=emailclient>
Virus-free.www.avast.com

<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_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

Vint Cerf Re: Backward Compatibility Re: IPv4 address block

[Abraham Y. Chen]

Hi, Tom:

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


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


***

internetpol...@elist.isoc.orgeMail thread

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

Dear Vint:

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

Thanks,

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

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

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

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

/*v*/

On Mon, Oct 18, 2021 at 8:33 AM Abraham Y. Chen via InternetPolicy 
 wrote:


Hi, Scott:

 0)    Thanks for your research.

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


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




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


Hope the above clears the air.


Regards,


Abe (2024-01-13 07:34)


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

I go into my cave to finish the todo list for the week, and I come out 
to see Mr. Chen :

- Telling Randy Bush he should "read some history" on IPv6
- Implying that Vint Cerf ever said anything about EzIP

Fairly impressive sequence of self ownage.

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




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

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

[Abraham Y. Chen]

Hi, Forrest:

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


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


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


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


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


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


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


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


Regards,


Abe (2024-01-12 18:42)



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


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


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



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

Hi, Forrest:

0)    Thanks for your in-depth analysis.

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

Regards,

Abe (2024-01-11 22:35)




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

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

[Abraham Y. Chen]

Hi, Randy:

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


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



Regards,


Abe (2024-01-12 17:34)




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

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

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

randy




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

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

[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_source=link_campaign=sig-email_content=emailclient>
Virus-free.www.avast.com

<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_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

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

[Abraham Y. Chen]

Hi, Owen:

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

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


Regards,


Abe (2024-01-12 07:07)


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


Owen


On Jan 11, 2024, at 13:15, Christopher Hawker  
wrote:


Hi Tom,

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


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


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


Regards,
Christopher Hawker



On Fri, 12 Jan 2024 at 04:26, Tom Beecher  wrote:

Christopher-

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


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

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


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


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

On Thu, Jan 11, 2024 at 5:54 AM Christopher Hawker
 wrote:

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

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

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

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

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

Regards,
Christopher Hawker

On Thu, 11 Jan 2024 at 20:40, Dave Taht 
wrote:

On Wed, Jan 10, 2024 at 11:06 AM Tom Beecher
 wrote:
>>
>> There's a whole bunch of software out there that makes
certain
>> assumptions about allowable ranges. That is, they've
been compiled with
>> a header that defines ..
>
>
> Of course correct. It really depends on the vendor /
software / versions in an environment. A lot of vendors
removed that years ago, because frankly a lot of large

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

[Abraham Y. Chen]

Hi, Ryan:

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


    What is your selling point?


Regards,


Abe (2024-01-12 06:44)




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

Abraham,

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


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

Ryan


*From:* NANOG  on behalf of 
Abraham Y. Chen 

*Sent:* Thursday, January 11, 2024 9:24:18 AM
*To:* Michael Butler 
*Cc:* nanog@nanog.org 
*Subject:* Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block



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



Hi, Michael:

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


    EzIP uses 240/4 netblock only within the RAN (Regional Area 
Network) as "Private" address, not "publicly" routable, according to 
the conventional Internet definition. This is actually the same as how 
100.64/10 is used within CG-NAT.


2)    However, this might be where the confusion comes from. With the 
geographical area coverage so much bigger, an RAN is effectively a 
public network. To mesh the two for consistency, we defined everything 
related to 240/4 as "Semi-Public" to distinguish this new layer of 
networking facility from the current public / private separation. That 
is, the CG-NAT routers will become SPRs (Semi-Public Routers) in 
EzIP's RAN, once the 240/4 is deployed.


Hope this helps,


Abe (2024-01-11 12:21)



On 2024-01-10 10:45, Michael Butler via NANOG wrote:

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

Karim-

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

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


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


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


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

Michael




<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient> 
	Virus-free.www.avast.com 
<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient> 







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

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

[Abraham Y. Chen]

Hi, Saku:

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


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


Regards,


Abe (2024-01-11 23:54)





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

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


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

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

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

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

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




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

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

[Abraham Y. Chen]

Hi, Christopher:

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


    We are in agreement with this first part.

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

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


Regards,

Abe (2024-01-11 23:40)



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


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


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

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


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

Regards,
Christopher Hawker

On Thu, 11 Jan 2024 at 20:40, Dave Taht  wrote:

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

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

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

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

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

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


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


-- 
40 years of net history, a couple songs:

https://www.youtube.com/watch?v=D9RGX6QFm5E
Dave Täht CSO, LibreQos




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

Reusable 240/4 Re: IPv4 address block

[Abraham Y. Chen]

Hi, Nick:

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


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


Regards,

Abe (2024-01-11 23:06)


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

Christopher Hawker wrote on 11/01/2024 10:54:
Reclassifying this space, would add 10+ years onto the free pool for 
each RIR


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


Nick




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

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

[Abraham Y. Chen]

Hi, Nick:

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


Regards,


Abe (2024-01-11 22:42)


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

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

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


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


Nick




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

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

[Abraham Y. Chen]

Hi, Forrest:

0)    Thanks for your in-depth analysis.

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


Regards,

Abe (2024-01-11 22:35)



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


Abraham,

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


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


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


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




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

Hi, Enno:

0)    Thanks for your comments referring to historical efforts.

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

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

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

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

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

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

Regards,


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





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

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

Hi, Karim:

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

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

[Abraham Y. Chen]

Hi, Vasilenko:

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


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


Regards,


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




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


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


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


Ed/

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

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

Hi, Karim:

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


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

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


Regards,

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

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

Hi Nanog Community

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

Thank you

KARIM

<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>



Virus-free.www.avast.com 
<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>





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

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

[Abraham Y. Chen]

Hi, Michael:

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


    EzIP uses 240/4 netblock only within the RAN (Regional Area 
Network) as "Private" address, not "publicly" routable, according to the 
conventional Internet definition. This is actually the same as how 
100.64/10 is used within CG-NAT.


2)    However, this might be where the confusion comes from. With the 
geographical area coverage so much bigger, an RAN is effectively a 
public network. To mesh the two for consistency, we defined everything 
related to 240/4 as "Semi-Public" to distinguish this new layer of 
networking facility from the current public / private separation. That 
is, the CG-NAT routers will become SPRs (Semi-Public Routers) in EzIP's 
RAN, once the 240/4 is deployed.


Hope this helps,


Abe (2024-01-11 12:21)



On 2024-01-10 10:45, Michael Butler via NANOG wrote:

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

Karim-

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

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


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


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


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

Michael




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

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_source=link_campaign=sig-email_content=emailclient>



Virus-free.www.avast.com

<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>




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

202401101433.AYC Re: EzIP Re: 202401100645.AYC Re: IPv4 address block

[Abraham Y. Chen]

Hi, Enno:

0)    Thanks for your comments referring to historical efforts.

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


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


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

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


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


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

Regards,


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





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

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

Hi, Karim:

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

As you state yourself this could be considered "unorthodox, if not 
controversial".
Alas in network operations 'unorthodox' usually means 'breaks something'. Which 
is exactly why you may avoid this, see also:

https://theinternetprotocolblog.wordpress.com/2019/10/06/some-notes-on-ipv4-address-space/

cheers

Enno





  Please

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

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

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


Regards,


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



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

Hi Nanog Community

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

Thank you

KARIM


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

202401100645.AYC Re: IPv4 address block

[Abraham Y. Chen]

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




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

Re: A straightforward transition plan (was: Re: V6 still not supported)

[Abraham Y. Chen]

Dear BZS:

1)   " ... it was more likely due to the success of CGNAT.":   Looking 
forward from this milestone marker, what would you envision as the 
possible additions to CG-NAT's characteristics and capabilities for the 
potential expansion of its services and enhancement to its performances?


Thanks,


Abe (2023-01-16 10:22)


On 2023-01-11 19:33, b...@theworld.com wrote:

On January 12, 2023 at 02:11n...@neo.co.tz  (Noah) wrote:
  > Hi John,
  >
  > So, It was assumed that IPv4 depletion would effectively lead to the 
adoption
  > of IPv6. This has not been the case in the last decade save for a very few
  > countries in the world.
  >
  > It was also assumed that IPv6 only networks would crop all over the place 
as a
  > result, providing the same interconnectivity benefits enjoyed by the IPv4
  > internet.
  >
  > Out of curiosity,did the emergency of transfer markets slow IPNG adoption 
while
  > creating prolonged dependence on IPv4?

Probably ten people have said this already but it was more likely due
to the success of CGNAT.




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

202212160543.AYC Re: eMail Conventions

[Abraham Y. Chen]

Dear Bill, Et al.:

0)  Ever since I signed up to the NANOG List, I have been getting 
complaints about my eMail style, format, etc. Since I could not find any 
document that clearly stated the guidelines and no one cared about 
providing an explicit lead, it has been a very frustrating experience. 
As I explained previously, my best understanding of an eMail is that it 
is an electronic equivalent of the traditional postal letter. We should 
start from following the old business correspondence protocol and then 
enhance it by taking advantage of the available electronic facility. 
Beyond that, an eMail is a literary work from an individual writer's own 
"creativity". A receiver can do anything possible about handling an 
eMail, but should refrain from imposing "rules" to the writer, unless 
there is a mutual consent. From time to time in the past, I did get 
questions from various contacts about what was I doing. Upon describing 
my rationales, most accepted them. Some even started to mimic my 
approaches. However, feedback on this List was exceptionally strong, it 
was quite distracting. Thus, I tried my best to minimize the rough 
spots, so that we could carry on the technical discussions.


1)  "On 2022-12-01 23:54, nanog wrote: ...  1) Your emails do not 
conform to the list standards (changing subject lines with every reply 
making it impossible to digest or follow.) ...   ":


  The above from you was the most recent feedback that I got. It 
stirred up my curiosity on this topic again. Since I had some slack time 
during the past few days, I decided to look into the "threading". I have 
been using ThunderBird eMail client software ever since its 
introduction, but never bothered about using its Message Threads 
facility because my own subject line tagging technique seemed to be 
sufficient. After a bit of fiddling, I was able to get ThunderBird to 
display messages organized in threads. Below is one such example. As you 
can see, my practice of continuously prefixing timestamps to the 
"Subject" line of messages in a thread seems to conform to ThunderBird's 
mechanism! Now, I would appreciate very much to see an example of how 
your eMail system handles the message threads. So that we can compare 
notes. Thanks,



Q. E. D.

Happy Holidays!

Abe (2022-12-16 10:04 EST)

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

Re: Alternative Re: ipv4/25s and above Re: 202211232221.AYC

[Abraham Y. Chen]

Dear Mark:

1) "... Google's data also shows businesses making at about 4% if you 
look at the weekly trends that show IPv6 usage spiking on the weekend as 
business users traffic drops off. ...": Perhaps the better 
interpretation of this fluctuation is because the residential use (more 
IPv6) of the Internet peaks up during the weekend, and holidays. In 
fact, work from home during COVID-19 had a notable effect to this graph. 
Along this line, you may enjoy reviewing the following article and 
discussions:


https://circleid.com/posts/20190529_digging_into_ipv6_traffic_to_google_is_28_percent_deployment_limit/ 



Regards,


Abe (2022-12-03 18:40 EST)



On 2022-11-27 21:31, Mark Andrews wrote:

On 24 Nov 2022, at 19:53, Abraham Y. Chen  wrote:

Dear Joe:

0) Allow me to share my understanding of the two topics that you brought up.

1) "...https://www.google.com/intl/en/ipv6/statistics.html, it looks like we’ve gone 
from ~0% to ~40% in 12 years ":  Your numbers may be deceiving.

   A. The IPv6 was introduced in 1995-12, launched on 2012-06-06 and ratified 
on 2017-07-14. So, the IPv6 efforts have been quite a few years more than your 
impression. That is, the IPv6 has been around over quarter of a century.

Which doesn’t change that fact that the traffic to Google has gone from ~0% to 
40% in 12 years.  No one claimed that Google has been measuring IPv6 traffic 
since the very beginning nor does it really matter how long it has been since 
IPv6 was defined.  What we are seeing is strong continuing growth in IPv6 usage 
where the S curve is a long way from flattening off.
   

   B. If you read closely, the statement  "The graph shows the percentage of users that access 
Google over IPv6." above the graph actually means "equipment readiness". That is, 
how many Google users have IPv6 capable devices. This is similar as the APNIC statistics whose 
title makes this clearer. However, having the capability does not mean the owners are actually 
using it. Also, this is not general data, but within the Google environment. Since Google is one of 
the stronger promoters of the IPv6, this graph would be at best the cap of such data.

If you read it correctly Google is measuring actual traffic.  Thats actual data 
flowing to and from Google's servers be it Gmail, YouTube, search traffic or 
anything else.  It does mean that the owners of the devices are using IPv6.


   C. The more meaningful data would be the global IPv6 traffic statistics. 
Interestingly, they do not exist upon our extensive search. (If you know of 
any, I would appreciate to receive a lead to such.) The closest that we could 
find is % of IPv6 in AMS-IX traffic statistics (see URL below). It is currently 
at about 5-6% and has been tapering off to a growth of less than 0.1% per month 
recently, after a ramp-up period in the past. (Similar saturation behavior can 
also be found in the above Google graph.)

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

What makes that “more meaningful” data.  I just see different populations of 
users being measured.  Google's data also shows businesses making at about 4% 
if you look at the weekly trends that show IPv6 usage spiking on the weekend as 
business users traffic drops off.


   D.  One interesting parameter behind the last one is that as an 
Inter-eXchange operator, AMS-IX should see very similar percentage traffic mix 
between IPv6 and IPv4. The low numbers from AMS-IX does not support this 
viewpoint for matching with your observation. In addition, traffic through IX 
is the overflow among backbone routers. A couple years ago, there was a report 
that peering arrangements among backbone routers for IPv6 were much less 
matured then IPv4, which meant that AMS-IX should be getting more IPv6 traffic 
than the mix in the Internet core. Interpreted in reverse, % of IPv6 in overall 
Internet traffic should be less than what AMS-IX handles.

   E. This is a quite convoluted topic that we only scratched the surface. They 
should not occupy the attention of colleagues on this list. However, I am 
willing to provide more information to you off-line, if you care for further 
discussion.

2)  "...https://lore.kernel.org/lkml/20080108011057.ga21...@cisco.com/  ...":  
My basic training was in communication equipment hardware design. I knew little about 
software beyond what I needed for my primary assignment. Your example, however, reminds 
me of a programing course that I took utilizing APL (A Programming Language) for circuit 
analysis, optimization and synthesis. It was such a cryptic symbolic language that 
classmates (mostly majored in EE hardware) were murmuring to express their displeasure. 
One day we got a homework assignment to do something relatively simple. Everyone 
struggled to write the code to do the job. Although most of us did get working codes, 
they were pages long. The shortest one was one full page. Upon reviewed all homewor

Re: Fwd: Alternative Re: ipv4/25s and above Re: 202212010732.AYC Re: 202211220729.AYC

[Abraham Y. Chen]

Dear Mr. Beecher:

0) Thanks for your reply to close the loop.

1)    " I don't have any interest in continuing this discussion on this 
topic.":    I am quite surprised by your nearly 180 degree turn of your 
position from your last MSG. The only thing that I could think of is 
that my last MSG provided the missing information that made the 
difference. I would appreciate very much if you could confirm.


Regards,


Abe (2022-12-02 22:35 EST)



On 2022-12-01 16:34, Tom Beecher wrote:

Mr. Chen-

I don't have any interest in continuing this discussion on this topic. 
Best of luck to you.


On Thu, Dec 1, 2022 at 7:44 AM Abraham Y. Chen  wrote:

Dear Tom:

Have not heard from you since the below MSG. Could you please let me
know if you have seen it, so that we can carry on by avoiding the
repeated open-loop situation with this thread?

Regards,


Abe (2022-12-01 07:44 EST)


On 2022-11-22 23:23, Abraham Y. Chen wrote:
> Dear Tom:  Please disregard an earlier partial transmission of
> this MSG, caused by operator error. ***
>
> 1) One look at the NANOG archive that you retrieved tells me
that we
> are the victims of the idiosyncrasies of the eMail system. Unlike
> snail mails that are slow but reliable (There was a story that USPS
> found a forty years old letter stuck in one of the mail collection
> boxes on Boston sidewalk and then delivered it.), eMails are fast
> (Once my eMail monitoring account started to receive a long message
> that I was sending out, even before it was fully sent.) but
> unpredictable from time to time. Unfortunately, most of us are
> conditioned with its daily behavior and do not suspect the
electronic
> system hiccups (As Andrew Grove once said, "It is the software, not
> the hardware."). To deal with this kind of issues in none-real-time
> communications, I practice a discipline, started from VM and
FAX, that
> I will do my best to respond within 24 hours. I encourage my
> colleagues to start reminding me (either repeat the MSG or using
> alternative channels, such as SkyPe - My handle is
"Abraham.Y.Chen"),
> if they do not hear from me after 48 hours on topics that they
expect
> my response. This convention prevented much of the disruptions.
> Looking at your comments, I definitely would have responded back
then
> if I saw them. One possibility is that I was in the midst of being
> overwhelmed by NANOG posting protocols, such as the digest mode,
> uni-code, personal writing styles, etc. and miseed your MSG.
Anyway,
> allow me to try carrying on.
>
> 2)   "...Your proposal appears to rely on a specific value in
the IP
> option header to create your overlay": Not really, as soon
as the
> 100.64/10 netblock is replaced by the 240/4, each CG-NAT module can
> serve a very large area (such as Tokyo Metro and such) that becomes
> the RAN in EzIP terminology. Since each RAN is tethered from the
> existing Internet core by an umbilical cord operating on one IPv4
> public address, this is like a kite floating in the sky which is
the
> basic building block for the overlaying EzIP Sub-Internet when they
> expand wide enough to begin covering significant areas of the
world.
> Note that throughout this entire process, the Option Word
mechanism in
> the IP header does not need be used at all. (It turns out that
> utilizing the CG-NAT configuration as the EzIP deployment
vehicle, the
> only time that the Option Word may be used is when subscribers
in two
> separate RANs wishing to have end-to-end communication, such as
direct
> private eMail exchanges.)
>
> 3) " ... to drop any packet with an IP option set that you don't
> explicitly want because a significant number of routers kick every
> packet with options to CPU, ... ": Yes, this was what we were
reminded
> of when we started our study. However, this appears to be another
> Internet myth. Dr. Chimiak of the EnIP project (see EzIP Draft's
> Refernce 13) told me that his team had successfully sent packets
with
> Option Words. Again, even if the existing routers do knock out
packs
> with Option words, the overlay architecture of the RANs allows the
> search for those do allow this operation. Since the use of the
Option
> Word turns out to be an option to superceed IPv4's capabilities, we
> should treat it as a consideration for future premium services.
>
> 4) " ...Any device that still treated 240/4 differently would
need to
> be updated to treat it like anything else. .. ": Yes, th

Re: Fwd: Alternative Re: ipv4/25s and above Re: 202212010732.AYC Re: 202211220729.AYC

[Abraham Y. Chen]

Dear Tom:

Have not heard from you since the below MSG. Could you please let me 
know if you have seen it, so that we can carry on by avoiding the 
repeated open-loop situation with this thread?


Regards,


Abe (2022-12-01 07:44 EST)


On 2022-11-22 23:23, Abraham Y. Chen wrote:
Dear Tom:  Please disregard an earlier partial transmission of 
this MSG, caused by operator error. ***


1) One look at the NANOG archive that you retrieved tells me that we 
are the victims of the idiosyncrasies of the eMail system. Unlike 
snail mails that are slow but reliable (There was a story that USPS 
found a forty years old letter stuck in one of the mail collection 
boxes on Boston sidewalk and then delivered it.), eMails are fast 
(Once my eMail monitoring account started to receive a long message 
that I was sending out, even before it was fully sent.) but 
unpredictable from time to time. Unfortunately, most of us are 
conditioned with its daily behavior and do not suspect the electronic 
system hiccups (As Andrew Grove once said, "It is the software, not 
the hardware."). To deal with this kind of issues in none-real-time 
communications, I practice a discipline, started from VM and FAX, that 
I will do my best to respond within 24 hours. I encourage my 
colleagues to start reminding me (either repeat the MSG or using 
alternative channels, such as SkyPe - My handle is "Abraham.Y.Chen"), 
if they do not hear from me after 48 hours on topics that they expect 
my response. This convention prevented much of the disruptions. 
Looking at your comments, I definitely would have responded back then 
if I saw them. One possibility is that I was in the midst of being 
overwhelmed by NANOG posting protocols, such as the digest mode, 
uni-code, personal writing styles, etc. and miseed your MSG. Anyway, 
allow me to try carrying on.


2)   "...Your proposal appears to rely on a specific value in the IP 
option header to create your overlay": Not really, as soon as the 
100.64/10 netblock is replaced by the 240/4, each CG-NAT module can 
serve a very large area (such as Tokyo Metro and such) that becomes 
the RAN in EzIP terminology. Since each RAN is tethered from the 
existing Internet core by an umbilical cord operating on one IPv4 
public address, this is like a kite floating in the sky which is the 
basic building block for the overlaying EzIP Sub-Internet when they 
expand wide enough to begin covering significant areas of the world. 
Note that throughout this entire process, the Option Word mechanism in 
the IP header does not need be used at all. (It turns out that 
utilizing the CG-NAT configuration as the EzIP deployment vehicle, the 
only time that the Option Word may be used is when subscribers in two 
separate RANs wishing to have end-to-end communication, such as direct 
private eMail exchanges.)


3) " ... to drop any packet with an IP option set that you don't 
explicitly want because a significant number of routers kick every 
packet with options to CPU, ... ": Yes, this was what we were reminded 
of when we started our study. However, this appears to be another 
Internet myth. Dr. Chimiak of the EnIP project (see EzIP Draft's 
Refernce 13) told me that his team had successfully sent packets with 
Option Words. Again, even if the existing routers do knock out packs 
with Option words, the overlay architecture of the RANs allows the 
search for those do allow this operation. Since the use of the Option 
Word turns out to be an option to superceed IPv4's capabilities, we 
should treat it as a consideration for future premium services.


4) " ...Any device that still treated 240/4 differently would need to 
be updated to treat it like anything else. .. ": Yes, this applies to 
regions that desire to enjoy the EzIP characteristics. Since the root 
of each RAN (or sub-RAN) still appears to be one of the current CG-NAT 
modules, there is no change can be detected by other CG-NAT modules. 
This avoids interoperability issues during the incremental deployment.


5) "  ...Any existing filters that dropped packets with *any* IP 
option set would have to be modified to permit the ones you define for 
EzIP":  Since EzIP is not going to activate Option Words initially 
for enhancing the CG-NAT, this should not be a concern. In the future, 
inter-RAN communication by subscribers would use Option words. But, by 
that time, finite number of backbone / gateway routers among RANs 
capable of preserving Option Words would have been identified. This 
approach takes advantage of the hierarchical network configuration 
that CG-NAT has already been practicing implicitly.


6) "... ( At one point in the past, one big router vendor only allowed 
you to configure an ip-options filter based on the IANA defined 
values, not others. ) ...": Well, you are talking about the overly 
intertwined relationship between one big roouter vendor and the IANA 
which is

Re: Alternative Re: ipv4/25s and above Re: 202211232221.AYC

[Abraham Y. Chen]

Hi, Chris:

1) "... public fabric ... private dedicated circuits ... heavily biased 
...":   You brought up an aspect that I have no knowledge about. 
However, you did not clarify how IPv6 and IPv4 are treated differently 
by these considerations which was the key parameter that we are trying 
to sort out. Thanks.


Regards,

Abe (2022-11-24 15:40)


On 2022-11-24 12:23, Chris Welti wrote:

Hi Abe,

the problem is that the AMS-IX data only covers the public fabric, but 
the peering connections between the big CDNs/clouds and the large ISPs 
all happen on private dedicated circuits as it is so much traffic that 
it does not make sense to run it over a public IX fabric (in addition 
to local caches which dillute the stats even more). Thus that data you 
are referring to is heavily biased and should not be used for this 
generalized purpose.


Regards,
Chris

On 24.11.22 18:01, Abraham Y. Chen wrote:

Hi, Eduard:

0) Thanks for sharing your research efforts.

1) Similar as your own experience, we also recognized the granularity 
issue of the data in this particular type of statistics. Any data 
that is based on a limited number of countries, regions, businesses, 
industry segments, etc. will always be rebutted with a counter 
example of some sort. So, we put more trust into those general 
service cases with continuous reports for consistency, such as 
AMS-IX. If you know any better sources, I would like to look into them.


Regards,


Abe (2022-11-24 11:59 EST)


On 2022-11-24 04:43, Vasilenko Eduard wrote:

Hi Abraham,
Let me clarify a little bit on statistics - I did an investigation 
last year.


Google and APNIC report very similar numbers. APNIC permits drilling 
down deep details. Then it is possible to understand that they see 
only 100M Chinese. China itself reports 0.5B IPv6 users. APNIC gives 
Internet population by country - it permits to construct proportion.
Hence, it is possible to conclude that we need to add 8% to Google 
(or APNIC) to get 48% of IPv6 preferred users worldwide. We would 
likely cross 50% this year.


I spent a decent time finding traffic statics. I have found one DPI 
vendor who has it. Unfortunately, they sell it for money.
ARCEP has got it for France and published it in their "Barometer". 
Almost 70% of application requests are possible to serve from IPv6.
Hence, 70%*48%=33.6%. We could claim that 1/3 of the traffic is IPv6 
worldwide because France is typical.
My boss told me "No-No" for this logic. His example is China where 
we had reliable data for only 20% of application requests served on 
IPv6 (China has a very low IPv6 adoption by OTTs).
My response was: But India has a much better IPv6 adoption on the 
web server side. China and a few other countries are not 
representative. The majority are like France.
Unfortunately, we do not have per-country IPv6 adoption on the web 
server side.
OK. We could estimate 60% of the application readiness as a minimum. 
Then 60%*48%=28.8%.
Hence, we could claim that at least 1/4 of the worldwide traffic is 
IPv6.


IX data shows much low IPv6 adoption because the biggest OTTs have 
many caches installed directly on Carriers' sites.


Sorry for not the exact science. But it is all that I have. It is 
better than nothing.


PS: 60% of requests served by web servers does not mean "60% of 
servers". For servers themselves we have statistics - it is just 
20%+. But it is for the biggest web resources.


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

Sent: Thursday, November 24, 2022 11:53 AM
To: Joe Maimon
Cc: NANOG;b...@theworld.com
Subject: Re: Alternative Re: ipv4/25s and above Re: 202211232221.AYC

Dear Joe:

0) Allow me to share my understanding of the two topics that you 
brought up.


1) "...https://www.google.com/intl/en/ipv6/statistics.html, it looks 
like we’ve gone from ~0% to ~40% in 12 years ": Your numbers may 
be deceiving.


    A. The IPv6 was introduced in 1995-12, launched on 2012-06-06 
and ratified on 2017-07-14. So, the IPv6 efforts have been quite a 
few years more than your impression. That is, the IPv6 has been 
around over quarter of a century.


    B. If you read closely, the statement  "The graph shows the 
percentage of users that access Google over IPv6." above the graph 
actually means "equipment readiness". That is, how many Google users 
have IPv6 capable devices. This is similar as the APNIC statistics 
whose title makes this clearer. However, having the capability does 
not mean the owners are actually using it. Also, this is not general 
data, but within the Google environment. Since Google is one of the 
stronger promoters of the IPv6, this graph would be at best the cap 
of such data.


    C. The more meaningful data would be the global IPv6 traffic 
statistics. Interestingly, they do not exist upon our extensive search.
(If you kn

Re: Alternative Re: ipv4/25s and above Re: 202211232221.AYC

[Abraham Y. Chen]

Hi, Douglas:

0) Thanks for the feedback.

1)  I do not sort eMail with any tools. Other than important ones that 
do I save a copy off the system as a document for long term reference, I 
only flag those of substance for the keeps and allow the rest to 
"expire" (I do house cleaning every three months or so.). Consequently, 
I have no idea about the terminologies that you mentioned.


2)  My basic understanding is, an eMail in its entirety is the original 
work of its composer / writer / sender. As such, a receiver is free to 
do anything with it, but not to impose certain "rules" back onto the 
writing. Through the years, eMail writing styles have diversified from 
the business letter protocols that I knew so much that I had to develop 
my own conventions of writing that enabled me to organize my eMails for 
retrieval. They seem to be tolerated by most parties that communicated 
with except NANOG. If you have certain clear rules that can pass my 
"logistics" considerations, I will definitely learn and follow.


Regards,


Abe (2022-11-24 16:00 EST)



On 2022-11-24 06:51, Douglas Fischer wrote:

Hello Abraham!

I believe your e-mail client (MUA) is splitting every message on a new 
thread.
I'm not sure if it is happening with everyone, but using Gmail as MUA, 
it isn't aggregating the mails on the same thread.


Cloud you please check the confs of your tool to avoid it?

Thanks in advance.

Em qui., 24 de nov. de 2022 às 05:56, Abraham Y. Chen 
 escreveu:


Dear Joe:

0) Allow me to share my understanding of the two topics that you
brought up.

1) "... https://www.google.com/intl/en/ipv6/statistics.html, it looks
like we’ve gone from ~0% to ~40% in 12 years ":  Your numbers
may be
deceiving.

   A. The IPv6 was introduced in 1995-12, launched on 2012-06-06 and
ratified on 2017-07-14. So, the IPv6 efforts have been quite a few
years
more than your impression. That is, the IPv6 has been around over
quarter of a century.

   B. If you read closely, the statement  "The graph shows the
percentage of users that access Google over IPv6." above the graph
actually means "equipment readiness". That is, how many Google users
have IPv6 capable devices. This is similar as the APNIC statistics
whose
title makes this clearer. However, having the capability does not
mean
the owners are actually using it. Also, this is not general data, but
within the Google environment. Since Google is one of the stronger
promoters of the IPv6, this graph would be at best the cap of such
data.

   C. The more meaningful data would be the global IPv6 traffic
statistics. Interestingly, they do not exist upon our extensive
search.
(If you know of any, I would appreciate to receive a lead to
such.) The
closest that we could find is % of IPv6 in AMS-IX traffic statistics
(see URL below). It is currently at about 5-6% and has been
tapering off
to a growth of less than 0.1% per month recently, after a ramp-up
period
in the past. (Similar saturation behavior can also be found in the
above
Google graph.)

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

   D.  One interesting parameter behind the last one is that as an
Inter-eXchange operator, AMS-IX should see very similar percentage
traffic mix between IPv6 and IPv4. The low numbers from AMS-IX
does not
support this viewpoint for matching with your observation. In
addition,
traffic through IX is the overflow among backbone routers. A couple
years ago, there was a report that peering arrangements among
backbone
routers for IPv6 were much less matured then IPv4, which meant that
AMS-IX should be getting more IPv6 traffic than the mix in the
Internet
core. Interpreted in reverse, % of IPv6 in overall Internet traffic
should be less than what AMS-IX handles.

   E. This is a quite convoluted topic that we only scratched the
surface. They should not occupy the attention of colleagues on this
list. However, I am willing to provide more information to you
off-line,
if you care for further discussion.

2)  "...
https://lore.kernel.org/lkml/20080108011057.ga21...@cisco.com/
...":  My basic training was in communication equipment hardware
design.
I knew little about software beyond what I needed for my primary
assignment. Your example, however, reminds me of a programing course
that I took utilizing APL (A Programming Language) for circuit
analysis,
optimization and synthesis. It was such a cryptic symbolic
language that
classmates (mostly majored in EE hardware) were murmuring to express
their displeasure. One day we got a homework assignment to do
something
relatively simple. Everyone struggled to write the code to do the
job.
Although most o

Re: Alternative Re: ipv4/25s and above Re: 202211232221.AYC

[Abraham Y. Chen]

Hi, Eduard:

0) Thanks for sharing your research efforts.

1) Similar as your own experience, we also recognized the granularity 
issue of the data in this particular type of statistics. Any data that 
is based on a limited number of countries, regions, businesses, industry 
segments, etc. will always be rebutted with a counter example of some 
sort. So, we put more trust into those general service cases with 
continuous reports for consistency, such as AMS-IX. If you know any 
better sources, I would like to look into them.


Regards,


Abe (2022-11-24 11:59 EST)


On 2022-11-24 04:43, Vasilenko Eduard wrote:

Hi Abraham,
Let me clarify a little bit on statistics - I did an investigation last year.

Google and APNIC report very similar numbers. APNIC permits drilling down deep 
details. Then it is possible to understand that they see only 100M Chinese. 
China itself reports 0.5B IPv6 users. APNIC gives Internet population by 
country - it permits to construct proportion.
Hence, it is possible to conclude that we need to add 8% to Google (or APNIC) 
to get 48% of IPv6 preferred users worldwide. We would likely cross 50% this 
year.

I spent a decent time finding traffic statics. I have found one DPI vendor who 
has it. Unfortunately, they sell it for money.
ARCEP has got it for France and published it in their "Barometer". Almost 70% 
of application requests are possible to serve from IPv6.
Hence, 70%*48%=33.6%. We could claim that 1/3 of the traffic is IPv6 worldwide 
because France is typical.
My boss told me "No-No" for this logic. His example is China where we had 
reliable data for only 20% of application requests served on IPv6 (China has a very low 
IPv6 adoption by OTTs).
My response was: But India has a much better IPv6 adoption on the web server 
side. China and a few other countries are not representative. The majority are 
like France.
Unfortunately, we do not have per-country IPv6 adoption on the web server side.
OK. We could estimate 60% of the application readiness as a minimum. Then 
60%*48%=28.8%.
Hence, we could claim that at least 1/4 of the worldwide traffic is IPv6.

IX data shows much low IPv6 adoption because the biggest OTTs have many caches 
installed directly on Carriers' sites.

Sorry for not the exact science. But it is all that I have. It is better than 
nothing.

PS: 60% of requests served by web servers does not mean "60% of servers". For 
servers themselves we have statistics - it is just 20%+. But it is for the biggest web 
resources.

Eduard
-Original Message-
From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] On 
Behalf Of Abraham Y. Chen
Sent: Thursday, November 24, 2022 11:53 AM
To: Joe Maimon
Cc: NANOG;b...@theworld.com
Subject: Re: Alternative Re: ipv4/25s and above Re: 202211232221.AYC

Dear Joe:

0) Allow me to share my understanding of the two topics that you brought up.

1) "...https://www.google.com/intl/en/ipv6/statistics.html, it looks like we’ve gone 
from ~0% to ~40% in 12 years ":  Your numbers may be deceiving.

    A. The IPv6 was introduced in 1995-12, launched on 2012-06-06 and ratified 
on 2017-07-14. So, the IPv6 efforts have been quite a few years more than your 
impression. That is, the IPv6 has been around over quarter of a century.

    B. If you read closely, the statement  "The graph shows the percentage of users that 
access Google over IPv6." above the graph actually means "equipment readiness". That 
is, how many Google users have IPv6 capable devices. This is similar as the APNIC statistics whose 
title makes this clearer. However, having the capability does not mean the owners are actually 
using it. Also, this is not general data, but within the Google environment. Since Google is one of 
the stronger promoters of the IPv6, this graph would be at best the cap of such data.

    C. The more meaningful data would be the global IPv6 traffic statistics. 
Interestingly, they do not exist upon our extensive search.
(If you know of any, I would appreciate to receive a lead to such.) The closest 
that we could find is % of IPv6 in AMS-IX traffic statistics (see URL below). 
It is currently at about 5-6% and has been tapering off to a growth of less 
than 0.1% per month recently, after a ramp-up period in the past. (Similar 
saturation behavior can also be found in the above Google graph.)

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

    D.  One interesting parameter behind the last one is that as an 
Inter-eXchange operator, AMS-IX should see very similar percentage traffic mix 
between IPv6 and IPv4. The low numbers from AMS-IX does not support this 
viewpoint for matching with your observation. In addition, traffic through IX 
is the overflow among backbone routers. A couple years ago, there was a report 
that peering arrangements among backbone routers for IPv6 were much less 
matured then IPv4, which meant that AMS-IX should be getting more 

Re: Alternative Re: ipv4/25s and above Re: 202211240353.AYC

[Abraham Y. Chen]

Dear Mathew:

0) Appreciate very much for your professionalism. Technical discussions 
over cyberspace like this are very challenging because the lack of 
instant feedback. One person could write a long essay without knowing 
that it is already off the track. Compounded with not knowing the other 
person's background, knowledge, current situation, etc., it takes some 
effort to zero into the essence for synchronizing the two parties. I am 
glad for your patience and persistence in drilling into the topic of 
your concern and pressing me for the answer. This is the only way to 
move forward.


1) From what you detailed, I believe that I now know the gap between us. 
What I have been describing is EzIP's proposal of enhancing CG-NAT, not 
deploying a brand new network. It is implicit that everything else in 
the current CG-NAT shall not be touched. That is, simply replacing 
100.64/10 netblock with 240/4 netblock will complete the first and key 
step of the EzIP deployment. All of the existing CG-NAT configurations 
and operations that you referred to are not to be disturbed.


2)  As to the "umbilical cord" versus "single point of failure", 
"multi-homing" concerns, I was talking about EzIP from network 
architectural point of view, which needs only one physical channel. This 
does not prevent additional facilities for operational considerations 
such as traffic volume, load balancing, reliability, redundancy, etc. 
That is, it is implicit from the way that Pt. 1) is presented these are 
not to be removed.


Hope this quick brief response brings us back on track. Let me know if 
the above makes sense. Then, I will work on other topics.


Regards,


Abe (2022-11-24 04:41 EST)


On 2022-11-23 22:36, Matthew Petach wrote:



On Tue, Nov 22, 2022 at 8:26 PM Abraham Y. Chen  wrote:

Dear Tom: *

[...]


2)   "...Your proposal appears to rely on a specific value in the IP
option header to create your overlay": Not really, as soon as the
100.64/10 netblock is replaced by the 240/4, each CG-NAT module can
serve a very large area (such as Tokyo Metro and such) that
becomes the
RAN in EzIP terminology. Since each RAN is tethered from the existing
Internet core by an umbilical cord operating on one IPv4 public
address,
this is like a kite floating in the sky which is the basic building
block for the overlaying EzIP Sub-Internet when they expand wide
enough
to begin covering significant areas of the world. Note that
throughout
this entire process, the Option Word mechanism in the IP header
does not
need be used at all. (It turns out that utilizing the CG-NAT
configuration as the EzIP deployment vehicle, the only time that the
Option Word may be used is when subscribers in two separate RANs
wishing
to have end-to-end communication, such as direct private eMail
exchanges.)



Hi Abraham,

I notice you never replied to my earlier questions about EzIP deployment.
I'll assume for the moment that means my concerns were without merit, and
will leave them aside.

But in reading this new message, I find myself again rather confused.

You stated:
"Since each RAN is tethered from the existing Internet core by an 
umbilical cord operating on one IPv4 public address,"


I find myself staring at that statement, and puzzling over and over again
at how multi-homing would work in the EzIP world.

Would a given ISP anycast their single global public IPv4 address
to all their upstream providers from all of their edge routers,
and simply trust stable routing in the DFZ to ensure packets arrived
at the correct ingress location to be mapped from the public internet
into the RAN?

Or do you really mean that every RAN will have one giant single point
of failure, a single uplink through which all traffic must pass in 
order to

reach the DFZ public internet?

If your regional network is a housing subdivision, I can understand the
model of a single uplink connection for it; but for anything much larger,
a single uplink seems like an unsustainable model.  You mention Tokyo 
Metro
in your message as an example.  What size single uplink do. you think 
would
be sufficient to support all the users in the Tokyo Metro region?  And 
how
unhappy would they be if the single router their 1 public IP address 
lived

on happened to have a hardware failure?

Wouldn't it be better if the proposed model built in support for
multihoming from day one, to provide a similar level of redundancy
to what is currently available on the Internet today?

Or is EzIP designed solely for small, singled-homed residential
customers, and is not intended at all for enterprise customers
who desire a more resilient level of connectivity?

As I noted in my previous message, this seems like an awful lot of
work to go through for relatively little benefit--but this may simply be
due to a lack of essential clue on my part.  I would v

Re: Alternative Re: ipv4/25s and above Re: 202211232221.AYC

[Abraham Y. Chen]

Dear Joe:

0) Allow me to share my understanding of the two topics that you brought up.

1) "... https://www.google.com/intl/en/ipv6/statistics.html, it looks 
like we’ve gone from ~0% to ~40% in 12 years ":  Your numbers may be 
deceiving.


  A. The IPv6 was introduced in 1995-12, launched on 2012-06-06 and 
ratified on 2017-07-14. So, the IPv6 efforts have been quite a few years 
more than your impression. That is, the IPv6 has been around over 
quarter of a century.


  B. If you read closely, the statement  "The graph shows the 
percentage of users that access Google over IPv6." above the graph 
actually means "equipment readiness". That is, how many Google users 
have IPv6 capable devices. This is similar as the APNIC statistics whose 
title makes this clearer. However, having the capability does not mean 
the owners are actually using it. Also, this is not general data, but 
within the Google environment. Since Google is one of the stronger 
promoters of the IPv6, this graph would be at best the cap of such data.


  C. The more meaningful data would be the global IPv6 traffic 
statistics. Interestingly, they do not exist upon our extensive search. 
(If you know of any, I would appreciate to receive a lead to such.) The 
closest that we could find is % of IPv6 in AMS-IX traffic statistics 
(see URL below). It is currently at about 5-6% and has been tapering off 
to a growth of less than 0.1% per month recently, after a ramp-up period 
in the past. (Similar saturation behavior can also be found in the above 
Google graph.)


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

  D.  One interesting parameter behind the last one is that as an 
Inter-eXchange operator, AMS-IX should see very similar percentage 
traffic mix between IPv6 and IPv4. The low numbers from AMS-IX does not 
support this viewpoint for matching with your observation. In addition, 
traffic through IX is the overflow among backbone routers. A couple 
years ago, there was a report that peering arrangements among backbone 
routers for IPv6 were much less matured then IPv4, which meant that 
AMS-IX should be getting more IPv6 traffic than the mix in the Internet 
core. Interpreted in reverse, % of IPv6 in overall Internet traffic 
should be less than what AMS-IX handles.


  E. This is a quite convoluted topic that we only scratched the 
surface. They should not occupy the attention of colleagues on this 
list. However, I am willing to provide more information to you off-line, 
if you care for further discussion.


2)  "... https://lore.kernel.org/lkml/20080108011057.ga21...@cisco.com/ 
...":  My basic training was in communication equipment hardware design. 
I knew little about software beyond what I needed for my primary 
assignment. Your example, however, reminds me of a programing course 
that I took utilizing APL (A Programming Language) for circuit analysis, 
optimization and synthesis. It was such a cryptic symbolic language that 
classmates (mostly majored in EE hardware) were murmuring to express 
their displeasure. One day we got a homework assignment to do something 
relatively simple. Everyone struggled to write the code to do the job. 
Although most of us did get working codes, they were pages long. The 
shortest one was one full page. Upon reviewed all homework, the 
professor smiled at us and told us to look for the solution section at 
the end of the text book. It turned out to be the answer for a problem 
in the next chapter to be covered. The code was only three lines long! 
Although it did not have the codes for debugging purposes, it covered 
all error messages expected. It was such a shocker that everyone quieted 
down to focus on the subject for the rest of the semester. During my 
first employment, we had the need to optimize circuit designs. Since I 
was the only staff who knew about it, I ended up being the coordinator 
between several hardware designers and the supporting programmer. From 
that teaching, I am always looking for the most concise solution to an 
issue, not being distracted or discouraged by the manifestation on the 
surface.


https://en.wikipedia.org/wiki/APL_(programming_language)

3) Fast forward half a century, I am hoping that my "one-line code" 
serves the purpose of "there exists" an example in proofing a 
mathematical theorem for  inspiring software colleagues to review the 
network codes in front of them for improvement, instead of presenting 
such as a valid hurdle to progress.



Regards,


Abe (2022-11-24 03:53 EST)





On 2022-11-21 19:30, Joe Maimon wrote:



David Conrad wrote:

Barry,

On Nov 21, 2022, at 3:01 PM, b...@theworld.com wrote:
We've been trying to get people to adopt IPv6 widely for 30 years 
with very limited success


According to https://www.google.com/intl/en/ipv6/statistics.html, it 
looks like we’ve gone from ~0% to ~40% in 12 years. 
https://stats.labs.apnic.net/ipv6 has it around 30%. Given an 
Internet population of about 5B, this can (simplistically and 

Re: Alternative Re: ipv4/25s and above Re: 202211231506.AYC

[Abraham Y. Chen]

Dear Eric:

0) Your analysis may have started from an assumption that is different 
from that of the EzIP. That is,


1)  The EzIP proposes to use the 240/4 as a replacement of the 100.64/10 
of RFC6598 for enhancing the CG-NAT. Thus, 240/4 will be used as 
reusable netblocks like those in RFC1918. There will be nothing for 
corporate to grab.


2)  In addition, it is implicitly stated that the addresses in 240/4 
will be assigned within a geographical Region, much like telephone 
numbers that are administrated by governments of respective 
jurisdictions as natural resources, not by global businesses as private 
properties.


3)  This may sound like against the "Internet way", but likely can 
eliminate the negative consequences of the current IP address allocation 
/ assignment practices.


Regards,


Abe (2022-11-23 15:25 EST)



On 2022-11-21 19:43, Eric Kuhnke wrote:

Assume the following theoretical scenario:

You have a large number of existing RIPE, ARIN, APNIC ASes which will 
take any ipv4 resources they can get. They're all on waiting lists or 
have been informed no new blocks will be forthcoming.


240/4 is something like 256 million IPs.

Let's say that the global benevolent ipv4 dictator decides that each 
ISP, MNO or other waiting list entity gets a single /16, one time only.


That's 64,000 IPs per corporate entity. Not actually very large at all 
on the scale of regional mid sized operators with 300,000 last mile 
broadband subscribers, or mobile network operators, nevermind 
top-10-size DOCSIS3/GPON/DSL last mile operators that have many dozens 
of millions of customers. One /16 is a tiny drop in the bucket 
compared to the demand for IP space for indivudual-customer DHCP pool 
usage by an ISP the size of Astound or a South Korean GPON operator or 
similar.


That's 4000 entities which each get their one time /16 and then 240/4 
is entirely exhausted.


Unrealistic?  Halve it so that each network operator waiting for IP 
space reources gets one/ 17, one time only, I would still bet good 
money that there's 8000 ASes out there that right now would happily 
take their "free "single /17 , and you'd still have immediate complete 
exhaustion of 240/8.








On Mon, 21 Nov 2022 at 16:33, Joe Maimon  wrote:



Eric Kuhnke wrote:
> In a theoretical scenario where somebody was global benevolent
> dictator of ipv4 space, even applying a policy which limited block
> size to a few /14 per ISP, it would be possible to exhaust 240/4/in
> one week/ if they handed out /14 sized pieces to every existing
last
> mile LTE network operator with 5+ million customers globally. It is
> not a long term solution or even a good medium term solution.
>
To to the LM LTE Operator with 5+ mill. customer globally, it is not.
Agreed. Also, I think they have already sorted themselves out
sufficiently in a variety of ways. I am not concerned with them,
at all.

Which is why I did not offer that as an example of useful constraint.
Re-run your projections with what I actually discussed, I think
you will
have a different conclusion.

Joe




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

Fwd: Alternative Re: ipv4/25s and above Re: 202211220729.AYC

[Abraham Y. Chen]

time for an overlay. ...":  You are 
probably visualizing a complete overlay network right from the 
beginning. The EzIP approach is gradual and incremental as outlined in 
the above descriptions. An EzIP deployment can be as small as a 
residential network because it was how we initially figured out this 
solution. It is based on parties who desire to participate, case by 
case. Those who don't, do not need to do anything, nor could notice any 
difference. All of these turn out to be the result of the fundametal 
Internet characteristics that can transmit every bit of compatible 
signals. Then, a sub-group of routers can link up with compatible nodes 
to form a new network on their own, which can coexist with, yet 
independent of the others (such as IPv4, IPv6, ARP, other as reported by 
AMS-IX).


I look forward to your thoughts,

Regards,


Abe (2022-11-22 23:22 EST)





On 2022-11-21 18:46, Tom Beecher wrote:


1) As requested, please be specific and speak only for yourself. So
that we can carry on a professional dialog meaningfully.


I will start by citing one of my own responses to you :

https://mailman.nanog.org/pipermail/nanog/2022-March/218291.html

I do not leave a loose end to any  technical
discussion with substance.


With the utmost amount of respect, you do.

Many people on this list have provided specific , technical issues 
with your proposal. Others have commented on non-technical, but 
practical considerations. In all cases, you have simply handwaved them 
away or not commented on them further.




On Mon, Nov 21, 2022 at 5:16 PM Abraham Y. Chen  wrote:

Dear Tom:

1)  As requested, please be specific and speak only for yourself. So
that we can carry on a professional dialog meaningfully.

2) Hint: I signed up to NANOG.org only early this year. So,
whatever you
have in mind might be from somewhere else. In addition, even
though I do
not have good memory, I do not leave a loose end to any technical
discussion with substance. The revisions of the EzIP documentation
have
always been improving the presentation style for easing the reader's
efforts, not about modifying our basic scheme. So, you need to be
clear
about the topics that you are referring to. Thanks.

Regards,


Abe (2022-11-21 17:16 EST)



On 2022-11-21 13:23, Tom Beecher wrote:
>
>     1) "... for various technical reasons , ...":  Please give a
couple
>     examples, and be specific preferably using expressions that
colleagues
>     on this forum can understand.
>
>
> Myself and multiple others provided specific technical rebuttals to
> the proposal in the past on this list.
>
>
>
> On Mon, Nov 21, 2022 at 12:29 PM Abraham Y. Chen

> wrote:
>
>     Dear Tom:
>
>     1) "... for various technical reasons , ...":  Please give a
couple
>     examples, and be specific preferably using expressions that
>     colleagues
>     on this forum can understand.
>
>     Thanks,
>
>
>     Abe (2022-11-21 12:29 EST)
>
>
>
>
>     On 2022-11-21 10:44, Tom Beecher wrote:
>     >
>     >     1) "... Africa ... They don’t really have a lot of
>     alternatives. ...":
>     >     Actually, there is, simple and in plain sight. Please
have a
>     look
>     >     at the
>     >     below IETF Draft:
>     >
>     >
>
https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space
>     >
>     >
>     > For the benefit of anyone who may not understand, this is
not an
>     > 'alternative'. This is an idea that was initially proposed
by the
>     > authors almost exactly 6 years ago. It's received almost no
>     interest
>     > from anyone involved in internet standards, and for
>     various technical
>     > reasons , likely never will.
>     >



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

Re: Alternative Re: ipv4/25s and above Re: 202211220729.AYC

[Abraham Y. Chen]

Dear Tom:

1)  One look at the NANOG archive that you retrieved tells me that we 
are the victims of the idiosyncrasies of the eMail system. Unlike the 
snail mails are slow but reliable (There was a story that USPS found a 
forty years old letter stuck in one of the mail collection boxes on 
Boston sidewalk and then delivered it.), eMails are fast (Once my eMail 
monitoring account started to receive a long message that I was sending 
out, even before it was fully sent.) but unpredictable from time to 
time. Unfortunately, most of us are conditioned with the normal speed 
and do not suspect the electronic system hiccups (As Andrew Grove once 
said, "It is the software, not the hardware.). To deal with this kind of 
issues in none-real time communication, I practice a discipline started 
from VM and FAX that I will respond within 24 hours. I encourage 
colleagues to start reminding me (either repeat the MSG or using 
alternative channels, such as SkyPe - My handle is A"Abraham.Y.Chen"), 
if they do not hear from me on topics expecting responses after 48 
hours. This convention prevented much of the disruptions. Looking at 
your comments, I definitely would have responded back then if I saw it. 
One possibility is that I was in the middle of trying to get used to 
NANOG posting protocols. I was probably overwhelmed by the digest mode, 
uni-code,etc. issues. Anyway, allow me to try carry on.


2) "...Your proposal appears to rely on a specific value in the IP 
option header to create your overlay": Not really, as soon as the 
100.64/10 netblock is replaced by the 240/4, each CG-NAT module can 
serve a very large area (such as Tokyo Metro and such) that becomes the 
RAN in EzIP terminology. Each RAN is tethered from the existing Internet 
core by an umbilical core based on one IPv4 public address. This is like 
a kite floating in the sky which is basic building block of the 
overlaying Sub-Internet when they expand to cover the entire world. 
Throughout this entire process, the Option Word mechanism in the IP head 
doe not need be used at all. (It turns out that utilizing the CG-NAT 
configuration as the starting point, the only time that the Option Word 
may be used is when subscribers in two separate RANs wishing to have 
end-to-end communication, such as direct private eMail exchanges.





On 2022-11-21 18:46, Tom Beecher wrote:


1) As requested, please be specific and speak only for yourself. So
that we can carry on a professional dialog meaningfully.


I will start by citing one of my own responses to you :

https://mailman.nanog.org/pipermail/nanog/2022-March/218291.html

I do not leave a loose end to any  technical
discussion with substance.


With the utmost amount of respect, you do.

Many people on this list have provided specific , technical issues 
with your proposal. Others have commented on non-technical, but 
practical considerations. In all cases, you have simply handwaved them 
away or not commented on them further.




On Mon, Nov 21, 2022 at 5:16 PM Abraham Y. Chen  wrote:

Dear Tom:

1)  As requested, please be specific and speak only for yourself. So
that we can carry on a professional dialog meaningfully.

2) Hint: I signed up to NANOG.org only early this year. So,
whatever you
have in mind might be from somewhere else. In addition, even
though I do
not have good memory, I do not leave a loose end to any technical
discussion with substance. The revisions of the EzIP documentation
have
always been improving the presentation style for easing the reader's
efforts, not about modifying our basic scheme. So, you need to be
clear
about the topics that you are referring to. Thanks.

Regards,


Abe (2022-11-21 17:16 EST)



On 2022-11-21 13:23, Tom Beecher wrote:
>
>     1) "... for various technical reasons , ...":  Please give a
couple
>     examples, and be specific preferably using expressions that
colleagues
>     on this forum can understand.
>
>
> Myself and multiple others provided specific technical rebuttals to
> the proposal in the past on this list.
>
>
>
> On Mon, Nov 21, 2022 at 12:29 PM Abraham Y. Chen

> wrote:
>
>     Dear Tom:
>
>     1) "... for various technical reasons , ...":  Please give a
couple
>     examples, and be specific preferably using expressions that
>     colleagues
>     on this forum can understand.
>
>     Thanks,
>
>
>     Abe (2022-11-21 12:29 EST)
>
>
>
>
>     On 2022-11-21 10:44, Tom Beecher wrote:
>     >
>     >     1) "... Africa ... They don’t really have a lot of
>     alternatives. ...":
>     >     Actually, there is, simple and in plain sig

Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC

[Abraham Y. Chen]

Dear Eric:

1)  " ... expecting the vast amount of legacy ipv4-only equipment out 
there in the world that is 10, 15, 20 years old to magically become 
compatible with the use of 240/4 in the global routing table ... ":    
It is apparent that you do not recognize a few unorthodox EzIP 
characteristics. For example:


   A. The activation of 240/4 netblocks is very scalable. It can be as 
small as starting from a residential home as evidenced by our initial 
realization of this technique via expanding the address pool by 256 
folds utilizing 192.168.K/24, or as big as or even multiple of 100.64/4 
netblocks that have been deployed all over the places for CG-NAT.


  B. Since the enhancement to use 240/4 is from the last-mile equipment 
and up, equipment capable of the program change can be enhanced without 
coordinating with any router nearby. In fact, they can continue to 
communicate through the originally established setup. This is a 
selective incremental process. There is no requirement to upgrade them 
all at the same time, such as what happened to IPv6. (I hope that you 
would not tell me that the routers whose programs were modified to 
handle the 100.64/4 netblocks for CG-NAT operation only about one decade 
ago are now too old to accept 240/4.)


  C. Once a router is enhanced to use 240/4, its original capability 
set continues with the addition of end-to-end connectivity within an 
area served by that router. No other routers would know about this change.


  D. This gives incentives to other regions to upgrade at their own 
paces, respectively. Note that we are talking about a generic program 
enhancement which can be downloaded to routers of the same model series 
through maintenance update cycles. So, we should not be discouraged by 
counting how many total routers are out there.


  E. Since the first phase of the EzIP deployment is to enhance CG-NAT, 
there is no expansion of global routing table.


2) "... directly analogous to building sand castles on the beach when 
the tide is obviously coming in. ":  This is the same as "the train has 
left the station" metaphor that we were told when we first started to 
look into this issue. So, we decided that our work was just for academic 
fun. As time went on, however, we learned that the Dual-Stack 
configuration was not just necessary but also going to last for a long 
time. Recently, we even heard (see the APNIC blog below as an example) 
that the IPv4 to IP6 transition may never end. So, I believe that it 
would be prudent for everyone to focus on improving his/her preferred 
version. There is no more reason to waste energy in discrediting the 
other camp's efforts.


The transition to IPv6: Are we there yet?

https://blog.apnic.net/2022/05/04/the-transition-to-ipv6-are-we-there-yet/

3)  " ... Trying to extend the use of ipv4 space resources for a few 
more years ...  ":  Unlike other proposals that we are aware of, EzIP is 
an enhancement to RF6598 which applies to CG-NAT that is a hierarchical 
network. Following such a configuration, the manageable public IPv4 pool 
is extended to roughly 983MB addresses (see the last paragraph of 
Sub-Section 2.1 in the EzIP Draft). Administrated in the traditional 
communication system identification discipline and supplemented by 
RFC1918 netblocks, this resources can last for a really long time.



Regards,


Abe (2022-11-21 22:59 EST)



On 2022-11-21 17:04, Eric Kuhnke wrote:
Quite simply, expecting the vast amount of legacy ipv4-only equipment 
out there in the world that is 10, 15, 20 years old to magically 
become compatible with the use of 240/4 in the global routing table is 
a non viable solution. It is not a financial reality for many small to 
medium sized ISPs in lower income countries.


The amount of time and effort that would be required to implement your 
proposal is much better spent on ipv6 implementation and various forms 
of improved cgnat.


Trying to extend the use of ipv4 space resources for a few more years 
is directly analogous to building sand castles on the beach when the 
tide is obviously coming in.





On Mon, 21 Nov 2022 at 07:29, Abraham Y. Chen  wrote:

Dear Eric:

0) Your opinion by itself is very valid and much appreciate.
However, it
is from a very remotely related perspective. That is, you are
looking at
the financial disadvantage of the less developed regions. What I am
talking about is the generic issue of communication system address
management that applies across the board. This subject is normally
designed by system planners. The result is given to the product
development engineers who usually do not have enough knowledge to
question it.

1)  The IPv4 address pool depletion issue was caused by the poor
"resources management" concepts. In this case, the insistence on the
Internet addressing should be flat (instead of hierarchical) led
to the
 

Re: Alternative Re: ipv4/25s and above Re: 202211211223.AYC

[Abraham Y. Chen]

Dear Tom:

1)  As requested, please be specific and speak only for yourself. So 
that we can carry on a professional dialog meaningfully.


2) Hint: I signed up to NANOG.org only early this year. So, whatever you 
have in mind might be from somewhere else. In addition, even though I do 
not have good memory, I do not leave a loose end to any  technical 
discussion with substance. The revisions of the EzIP documentation have 
always been improving the presentation style for easing the reader's 
efforts, not about modifying our basic scheme. So, you need to be clear 
about the topics that you are referring to. Thanks.


Regards,


Abe (2022-11-21 17:16 EST)



On 2022-11-21 13:23, Tom Beecher wrote:


1) "... for various technical reasons , ...":  Please give a couple
examples, and be specific preferably using expressions that colleagues
on this forum can understand.


Myself and multiple others provided specific technical rebuttals to 
the proposal in the past on this list.




On Mon, Nov 21, 2022 at 12:29 PM Abraham Y. Chen  
wrote:


Dear Tom:

1) "... for various technical reasons , ...":  Please give a couple
examples, and be specific preferably using expressions that
colleagues
on this forum can understand.

Thanks,


Abe (2022-11-21 12:29 EST)




On 2022-11-21 10:44, Tom Beecher wrote:
>
>     1) "... Africa ... They don’t really have a lot of
alternatives. ...":
>     Actually, there is, simple and in plain sight. Please have a
look
>     at the
>     below IETF Draft:
>
>

https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space
>
>
> For the benefit of anyone who may not understand, this is not an
> 'alternative'. This is an idea that was initially proposed by the
> authors almost exactly 6 years ago. It's received almost no
interest
> from anyone involved in internet standards, and for
various technical
> reasons , likely never will.
>
> On Fri, Nov 18, 2022 at 10:52 PM Abraham Y. Chen

> wrote:
>
>     Dear Owen:
>
>     1) "... Africa ... They don’t really have a lot of alternatives.
>     ...":
>     Actually, there is, simple and in plain sight. Please have a
look
>     at the
>     below IETF Draft:
>
>

https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space
>
>     2)  If this looks a bit too technical due to the nature of
such a
>     document, there is a distilled version that provides a
bird-eye's
>     view
>     of the solution:
>
> https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf
>
>     3)  All of the above can start from making use of the 240/4
>     netblock as
>     a reusable (by region / country) unicast IP address
resources that
>     could
>     be accomplished by as simple as commenting out one line of the
>     existing
>     network router program code. I will be glad to go into the
>     specifics if
>     you can bring their attention to this almost mystic topic.
>
>     Regards,
>
>
>     Abe (2022-11-19 22:50 EST)
>
>
>     On 2022-11-18 18:20, Owen DeLong via NANOG wrote:
>     >
>     >> On Nov 18, 2022, at 03:44, Joe Maimon
 wrote:
>     >>
>     >>
>     >>
>     >> Mark Tinka wrote:
>     >>>
>     >>> On 11/17/22 19:55, Joe Maimon wrote:
>     >>>
>     >>>> You could instead use a /31.
>     >>> We could, but many of our DIA customers have all manner of
>     CPE's that may or may not support this. Having unique
designs per
>     customer does not scale well.
>     >> its almost 2023. /31 support is easily mandatory. You should
>     make it mandatory.
>     > Much of Africa in 2023 runs on what the US put into the resale
>     market in the late 1990s, tragically.
>     >
>     >> Its 2023, your folk should be able to handle addressing more
>     advanced than from the 90s. And your betting the future on IPv6?
>     > They don’t really have a lot of alternatives.
>     >
>     >>> To be honest, we'll keep using IPv4 for as long as we
have it,
>     and for as long as we can get it from AFRINIC. But it's not
where
>     we are betting the farm - that is for IPv6.
>     > And yet you wonder why I consider AFRINIC’s artificial
extension
>     of the free pool through draconian austerity mea

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[Abraham Y. Chen]

Dear Tom:

0) Thanks for your advice.

1) What I wrote was just informal online chatting. I was not attempting 
to make a water-tight legal statement. The fact is, we have identified 
at least one concise case of how this task could be done easily, as 
reported in Appendix D of the EzIP IETF Draft. Although no references 
have been published, I believe that colleagues on the IPv4 Unicast 
Extensions Project have seen similar situations.  Even without the 
latter, a "there exists one reference" should be sufficient to encourage 
other software engineers to review their own work. They should question 
the quality of their own programs if they are more complex, instead of 
ridiculing the concise example on the table.


Regards,


Abe (2022-11-21 12:54 EST)


On 2022-11-21 12:00, Tom Beecher wrote:


As stated in Subsection 4.A. of the "Revamp The
Internet" whitepaper, all need be done is "Simply disable the existing
software codes that have been disabling the use of the 240/4
netblock."


Some friendly feedback. The phrase "all that needs to be done" , is 
exceptionally reductive, and in the case of internet standards, also 
always going to end up being wrong.


On Mon, Nov 21, 2022 at 11:19 AM Abraham Y. Chen  
wrote:


Dear Mark:

0) Thanks for the clarification. I understand. A short message
through
the cyberspace, especially between parties who have never met can be
easily skewed. I am glad that I asked you, instead of taking it
negatively without raising my hand.

1) "...I'd, rather, expend those resources on IPv6, 464XLAT,
e.t.c. ...
": Since EzIP is still being further refined, it may not be clear
in our
documentation about how much work is required to get the IPv4 out
of the
current depletion mode. As stated in Subsection 4.A. of the
"Revamp The
Internet" whitepaper, all need be done is "Simply disable the
existing
software codes that have been disabling the use of the 240/4
netblock."
In fact, we have found examples that this means commenting out one
line
code that searches for then discards packets with 240/4
addressing. It
seems to me that there is no easier task than this.

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

Regards,

Abe (2022-11-21 11:18 EST)



On 2022-11-20 23:56, Mark Tinka wrote:
>
>
> On 11/20/22 19:02, Abraham Y. Chen wrote:
>
>> Dear Mark:
>>
>> 0)  I am surprised at your apparently sarcastic opinion.
>>
>> 1)  The EzIP proposal as referenced by my last MSG is the
result of
>> an in-depth system engineering effort. Since the resultant
schemes do
>> not rely on any protocol development, IETF does not need be
involved.
>> Especially, its first step of disabling one line of existing
>> networking program code empowers any party to begin deploying EzIP
>> stealthily for mitigating the IPv4 address pool depletion issues.
>> Note that EzIP is a generic solution applicable to everyone, not
>> limited to Africa.
>>
>> 2)  Of course, constructive criticism is always appreciated.
However,
>> unspecific comments that confuse and distract the readers only
>> provide dis-service to those disadvantaged population who are
>> enduring the handicaps of being the late-comers to the Internet.
>
> My comment was not directed at you. Sorry.
>
> I have nothing against the EzIP proposal. It just does not add any
> real value in solving the IPv4 depletion problem for the amount of
> effort required to implement it, in my view. I'd, rather, expend
those
> resources on IPv6, 464XLAT, e.t.c.
>
> Mark.
>


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

www.avast.com <http://www.avast.com>

Re: Alternative Re: ipv4/25s and above Re: 202211211223.AYC

[Abraham Y. Chen]

Dear Tom:

1) "... for various technical reasons , ...":  Please give a couple 
examples, and be specific preferably using expressions that colleagues 
on this forum can understand.


Thanks,


Abe (2022-11-21 12:29 EST)




On 2022-11-21 10:44, Tom Beecher wrote:


1) "... Africa ... They don’t really have a lot of alternatives. ...":
Actually, there is, simple and in plain sight. Please have a look
at the
below IETF Draft:


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


For the benefit of anyone who may not understand, this is not an 
'alternative'. This is an idea that was initially proposed by the 
authors almost exactly 6 years ago. It's received almost no interest 
from anyone involved in internet standards, and for various technical 
reasons , likely never will.


On Fri, Nov 18, 2022 at 10:52 PM Abraham Y. Chen  
wrote:


Dear Owen:

1) "... Africa ... They don’t really have a lot of alternatives.
...":
Actually, there is, simple and in plain sight. Please have a look
at the
below IETF Draft:


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

2)  If this looks a bit too technical due to the nature of such a
document, there is a distilled version that provides a bird-eye's
view
of the solution:

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

3)  All of the above can start from making use of the 240/4
netblock as
a reusable (by region / country) unicast IP address resources that
could
be accomplished by as simple as commenting out one line of the
existing
network router program code. I will be glad to go into the
specifics if
you can bring their attention to this almost mystic topic.

Regards,


Abe (2022-11-19 22:50 EST)


On 2022-11-18 18:20, Owen DeLong via NANOG wrote:
>
>> On Nov 18, 2022, at 03:44, Joe Maimon  wrote:
>>
>>
>>
>> Mark Tinka wrote:
>>>
>>> On 11/17/22 19:55, Joe Maimon wrote:
>>>
>>>> You could instead use a /31.
>>> We could, but many of our DIA customers have all manner of
CPE's that may or may not support this. Having unique designs per
customer does not scale well.
>> its almost 2023. /31 support is easily mandatory. You should
make it mandatory.
> Much of Africa in 2023 runs on what the US put into the resale
market in the late 1990s, tragically.
>
>> Its 2023, your folk should be able to handle addressing more
advanced than from the 90s. And your betting the future on IPv6?
> They don’t really have a lot of alternatives.
>
>>> To be honest, we'll keep using IPv4 for as long as we have it,
and for as long as we can get it from AFRINIC. But it's not where
we are betting the farm - that is for IPv6.
> And yet you wonder why I consider AFRINIC’s artificial extension
of the free pool through draconian austerity measures to be a
global problem?
>
>> Its on Afrinic to try and preserve their pool if they wish to
by doing things such as getting it across that progress in
addressing efficiency is an important consideration in fulfilling
requests for additional resources.
> Instead of this, they’re mostly ignoring policy, implementing
draconian restrictions on people getting space from the free pool,
and buying into various forms of reality avoidance.
>
>> But see the crux above. If your RiR isnt frowning on such
behavior then its poor strategy to implement it.
> So far, AFRINIC has given a complete pass to Tinka’s
organization and their documented excessive unused address space
despite policy that prohibits them from doing so. However, AFRINIC
management and board seem to have extreme difficulty with reading
their governing documents in anything resembling a logical
interpretation.
>
> Owen
>


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

www.avast.com <http://www.avast.com>

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[Abraham Y. Chen]

Dear Mark:

0) Thanks for the clarification. I understand. A short message through 
the cyberspace, especially between parties who have never met can be 
easily skewed. I am glad that I asked you, instead of taking it 
negatively without raising my hand.


1) "...I'd, rather, expend those resources on IPv6, 464XLAT, e.t.c. ... 
": Since EzIP is still being further refined, it may not be clear in our 
documentation about how much work is required to get the IPv4 out of the 
current depletion mode. As stated in Subsection 4.A. of the "Revamp The 
Internet" whitepaper, all need be done is "Simply disable the existing 
software codes that have been disabling the use of the 240/4 netblock." 
In fact, we have found examples that this means commenting out one line 
code that searches for then discards packets with 240/4 addressing. It 
seems to me that there is no easier task than this.


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

Regards,

Abe (2022-11-21 11:18 EST)



On 2022-11-20 23:56, Mark Tinka wrote:



On 11/20/22 19:02, Abraham Y. Chen wrote:


Dear Mark:

0)  I am surprised at your apparently sarcastic opinion.

1)  The EzIP proposal as referenced by my last MSG is the result of 
an in-depth system engineering effort. Since the resultant schemes do 
not rely on any protocol development, IETF does not need be involved. 
Especially, its first step of disabling one line of existing 
networking program code empowers any party to begin deploying EzIP 
stealthily for mitigating the IPv4 address pool depletion issues. 
Note that EzIP is a generic solution applicable to everyone, not 
limited to Africa.


2)  Of course, constructive criticism is always appreciated. However, 
unspecific comments that confuse and distract the readers only 
provide dis-service to those disadvantaged population who are 
enduring the handicaps of being the late-comers to the Internet.


My comment was not directed at you. Sorry.

I have nothing against the EzIP proposal. It just does not add any 
real value in solving the IPv4 depletion problem for the amount of 
effort required to implement it, in my view. I'd, rather, expend those 
resources on IPv6, 464XLAT, e.t.c.


Mark.




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

Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC

[Abraham Y. Chen]

Dear Eric:

0) Your opinion by itself is very valid and much appreciate. However, it 
is from a very remotely related perspective. That is, you are looking at 
the financial disadvantage of the less developed regions. What I am 
talking about is the generic issue of communication system address 
management that applies across the board. This subject is normally 
designed by system planners. The result is given to the product 
development engineers who usually do not have enough knowledge to 
question it.


1)  The IPv4 address pool depletion issue was caused by the poor 
"resources management" concepts. In this case, the insistence on the 
Internet addressing should be flat (instead of hierarchical) led to the 
quick depletion of the finite sized 32-bit pool. The fact is that the 
current prevalent CDN (Content Delivery Network) business model based on 
CG-NAT configuration is a clear hierarchical network, anyway. All what 
EzIP proposes is to make it explicit and universal for improving the 
performance.


2)  To create a viable hierarchical network with depleted address pool 
like IPv4 was practically an impossible task. Fortunately, the 240/4 
netblock is available because it was "reserved for future use" ever 
since 1981-09, yet no clear application cases could be found. So, this 
is a natural resources that will benefit everyone without reference to 
financial status, although the developing regions can benefit more by 
utilizing it to leap frog out of the current disadvantaged situations.


Hope this explanation makes sense to you.


Regards,


Abe (2022-11-21 10:29 EST)




On 2022-11-20 17:56, Eric Kuhnke wrote:
If I had a dollar for every person who has lived their entire life in 
a high-income western country (US, Canada, western Europe, etc) and 
has zero personal experience in developing-nation telecom/ISP 
operations and their unique operational requirements, yet thinks 
they've qualified to offer an opinion on it...


People should go look at some of the WISPs in the Philippines for an 
example of ISPs building last and middle mile infrastructure on 
extremely limited budgets. Or really just about anywhere else where 
the residential broadband market has households where the entire 
household monthly income is the equivalent of $500 USD.




On Sat, 19 Nov 2022 at 04:59, Mark Tinka  wrote:



    On 11/19/22 05:50, Abraham Y. Chen wrote:

> Dear Owen:
>
> 1) "... Africa ... They don’t really have a lot of alternatives.
...":
> Actually, there is, simple and in plain sight. Please have a
look at
> the below IETF Draft:

It's most amusing, to me, how Africa needs to be told how to be...

Some folk just can't help themselves.

Mark.




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

Re: Alternative Re: ipv4/25s and above Re: 202211201702.AYC

[Abraham Y. Chen]

nected to the Internet core via a 
public IPv4 address channel, the former can be regarded as a private 
network. This does not preclude RANs from establishing direct links (via 
240/4 or spare public IPv4 address) among one another. With such, an 
overlay network covering the entire globe can be formed with its own 
"top websites" that will function as a cyberspace that is parallel to, 
but practically independent of, the existing Internet.
7)  In summary, the EzIP deployment is consciously planned to be 
incremental while avoiding disturbing the existing Internet 
configurations and practices.


8) Since we are still refining the EzIP scheme, the above outline may 
not be fully self-consistent. Please let me know any parts that are not 
clear. I will try to improve them.

Regards,


Abe (2022-11-21 09:49 EST)


On 2022-11-20 16:15, Matthew Petach wrote:


On Fri, Nov 18, 2022 at 7:53 PM Abraham Y. Chen  wrote:

Dear Owen:

1) "... Africa ... They don’t really have a lot of alternatives.
...":
Actually, there is, simple and in plain sight. Please have a look
at the
below IETF Draft:


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


Hi Abraham,

I know I'm not the sharpest tool in the shed, but I'm having some
trouble understanding the deployment model for EzIP. Perhaps you
could help clear it up for me?

A non-EzIP web server is only going to see the global destination
IP address and TCP port number as the unique session identifiers
for communication, so the vast amount of additional IP space you
postulate existing behind the SPR functionally collapses down into
the 64K TCP port range available today in traditional port-based NAT
setups.  As long as the top 50 websites aren't EzIP-aware, there appears
to be no benefit for an ISP to deploy EzIP, because it doesn't actually
gain them anything beyond what existing CG-NAT devices already provide
as far as their web-browsing customer base is concerned. Most of their
communication will still be port-based-NAT, with all the headaches and
restrictions inherent in that.

And for the top 50 websites, there's a lot of expense and absolutely 
no upside
involved in deploying EzIP.  They don't care about how much IP space 
you have
behind your NAT device, and whether it's uniquely identifiable within 
your local
realm; it's not information they can access for tracking users, as 
they don't know
what your internal mapping is, so they'll continue to rely on browser 
cookies and
the like for tracking actual user sessions, regardless of the IP 
addressing format

being used.

So, you've got a model where there's functionally almost no benefit to 
the end user
until the major websites start deploying EzIP-aware infrastructure, 
and there's
pretty much no incentive for major websites to spend money upgrading 
their
infrastructure to support EzIP, because it provides no additional 
benefit for them.


This is pretty much exactly the same conundrum that IPv6 faced (and 
still faces
today).  I don't see why EzIP is any better than IPv6 or CG-NAT in 
terms of solving
the IPv4 address shortage problem, and it seems to involve more 
expense for web
providers, because it requires them to deploy additional SPR mapping 
routers into
their infrastructure in order to use it, with essentially no 
additional benefit.


Is there a piece to the picture I'm not understanding correctly?

Thanks!

Matt





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

Re: Alternative Re: ipv4/25s and above Re: 202211201503.AYC

[Abraham Y. Chen]

Dear Rubens:

0) Very good question. It is right to the point!

1) Initially, we thought that we were doing conventional protocol 
development engineering that was triggered by our curiosity about why 
IPv4 address pool was depleted. So, IETF Draft was the natural place to 
report what we were doing.


2)  As time went on, it became evident that our scheme was rather 
unorthodox. That is, it was surprisingly simpler than any other known 
techniques. As well, the benefits were more and better than we could 
have dreamed for. At the same time, developed countries such as US where 
I was in, were not in any material need for IPv4 addresses, yet 
promoting IPv6. Not being able to sort out this contradiction, it was 
necessary to keep a continuous public record as IETF Draft revisions of 
EzIP evolution as we continued to refine our scheme which had turned 
into a concise system engineering solution, or almost appeared to be a 
marketing trick.


3)  In a sense, we have been purposely publishing our work on the web 
(beyond IETF Draft) to invite critiques. So far, we have not received 
any explicit feedback pointing to its flaws, while there have been more 
than a couple subtle confirmations from rather senior Internet experts. 
I am sure that you would understand that we can not disclose the latter 
on our own. Nevertheless, they do enforce our confidence in the EzIP plan.


4)  In anticipation of your next question, I would like to add the 
following. To be sure that our discovery is protected from being claimed 
by others and then its fair use discouraged, the essence of the EzIP 
concept was submitted to US Patent Office and has been granted with US 
Pat. No. 11,159,425. This assures that EzIP may be openly discussed to 
reach as much general public as possible.


Hope the above background recap is sufficient to clear your concerns. I 
look forward to our additional exchanges.



Regards,


Abe (2022-11-20 17:00 EST)




On 2022-11-20 13:41, Rubens Kuhl wrote:

On Sun, Nov 20, 2022 at 2:03 PM Abraham Y. Chen  wrote:

Dear Mark:

0)  I am surprised at your apparently sarcastic opinion.

1)  The EzIP proposal as referenced by my last MSG is the result of an
in-depth system engineering effort. Since the resultant schemes do not
rely on any protocol development, IETF does not need be involved.

If IETF does not need to be involved, why have you submitted 12
versions of your Internet draft to IETF ?
https://datatracker.ietf.org/doc/draft-chen-ati-adaptive-ipv4-address-space/

Rubens




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

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[Abraham Y. Chen]

Dear Mark:

0)  I am surprised at your apparently sarcastic opinion.

1)  The EzIP proposal as referenced by my last MSG is the result of an 
in-depth system engineering effort. Since the resultant schemes do not 
rely on any protocol development, IETF does not need be involved. 
Especially, its first step of disabling one line of existing networking 
program code empowers any party to begin deploying EzIP stealthily for 
mitigating the IPv4 address pool depletion issues. Note that EzIP is a 
generic solution applicable to everyone, not limited to Africa.


2)  Of course, constructive criticism is always appreciated. However, 
unspecific comments that confuse and distract the readers only provide 
dis-service to those disadvantaged population who are enduring the 
handicaps of being the late-comers to the Internet.


Regards,


Abe (2022-11-20 12:02 EST)


On 2022-11-19 07:58, Mark Tinka wrote:



On 11/19/22 05:50, Abraham Y. Chen wrote:


Dear Owen:

1) "... Africa ... They don’t really have a lot of alternatives. 
...": Actually, there is, simple and in plain sight. Please have a 
look at the below IETF Draft:


It's most amusing, to me, how Africa needs to be told how to be...

Some folk just can't help themselves.

Mark.




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

Alternative Re: ipv4/25s and above

[Abraham Y. Chen]

Dear Owen:

1) "... Africa ... They don’t really have a lot of alternatives. ...": 
Actually, there is, simple and in plain sight. Please have a look at the 
below IETF Draft:


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

2)  If this looks a bit too technical due to the nature of such a 
document, there is a distilled version that provides a bird-eye's view 
of the solution:


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

3)  All of the above can start from making use of the 240/4 netblock as 
a reusable (by region / country) unicast IP address resources that could 
be accomplished by as simple as commenting out one line of the existing 
network router program code. I will be glad to go into the specifics if 
you can bring their attention to this almost mystic topic.


Regards,


Abe (2022-11-19 22:50 EST)


On 2022-11-18 18:20, Owen DeLong via NANOG wrote:



On Nov 18, 2022, at 03:44, Joe Maimon  wrote:



Mark Tinka wrote:


On 11/17/22 19:55, Joe Maimon wrote:


You could instead use a /31.

We could, but many of our DIA customers have all manner of CPE's that may or 
may not support this. Having unique designs per customer does not scale well.

its almost 2023. /31 support is easily mandatory. You should make it mandatory.

Much of Africa in 2023 runs on what the US put into the resale market in the 
late 1990s, tragically.


Its 2023, your folk should be able to handle addressing more advanced than from 
the 90s. And your betting the future on IPv6?

They don’t really have a lot of alternatives.


To be honest, we'll keep using IPv4 for as long as we have it, and for as long 
as we can get it from AFRINIC. But it's not where we are betting the farm - 
that is for IPv6.

And yet you wonder why I consider AFRINIC’s artificial extension of the free 
pool through draconian austerity measures to be a global problem?


Its on Afrinic to try and preserve their pool if they wish to by doing things 
such as getting it across that progress in addressing efficiency is an 
important consideration in fulfilling requests for additional resources.

Instead of this, they’re mostly ignoring policy, implementing draconian 
restrictions on people getting space from the free pool, and buying into 
various forms of reality avoidance.


But see the crux above. If your RiR isnt frowning on such behavior then its 
poor strategy to implement it.

So far, AFRINIC has given a complete pass to Tinka’s organization and their 
documented excessive unused address space despite policy that prohibits them 
from doing so. However, AFRINIC management and board seem to have extreme 
difficulty with reading their governing documents in anything resembling a 
logical interpretation.

Owen




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

Re: Jon Postel Re: 202210301538.AYC

[Abraham Y. Chen]

Dear William:

0) "Internet Vendor Task Force indeed.":  Thank you so much in 
distilling this thread one more step for getting even closer to its essence.


1)  The ITU charter is explicit in that governments are the parties who 
sponsor the Recommendations, then implement them as desired, 
respectively as well as dealing with the outcome, no matter it is good 
or bad, since there is no scapegoat.


2)  The IETF is implicitly sponsored by businesses to create RFCs then 
impose them on (although may be called voluntarily adopted by) players 
internationally, without claiming much responsibility for its effects to 
the society. That is, the wealth of the citizens is extracted by the 
businesses through RFCs starting from treating IP addresses as private 
properties, while the governments bear the burden of dealing with the 
negative effects such as cybersecurity vulnerabilities.


3)  It appears to me that by mentally branding ITU type of UN 
organizations "evil", the delicate balance between Cause & Consequence 
has been broken in the Internet era, with the businesses taking 
advantage of the first "C" for the benefit of their "shareholders" 
(creating billionaire CEOs, COOs, CFOs, etc.) while leaving the second 
"C" for the governments and the poor peasants to endure. I am not sure 
whether this is an improved operation model.


4)  No wonder that there was an APNIC Labs Policy notes about "The 
Internet's Gilded Age" sometime ago. We need to recognize this root 
cause and begin to take corrective actions for navigating out of it.


https://labs.apnic.net/?p=973

Regards,


Abe (2022-11-02 08:32 EDT)



On 2022-11-01 01:31, William Allen Simpson wrote:

On 10/31/22 9:27 AM, Donald Eastlake wrote:

On Mon, Oct 31, 2022 at 2:37 AM Vasilenko Eduard via NANOG
 wrote:


1.   What is going on on the Internet is not democracy even 
formally, because there is no formal voting.
3GPP, ETSI, 802.11 have voting. IETF decisions are made by bosses 
who did manage to gain power (primarily by establishing a proper 
network of relationships).
It could be even called “totalitarian” because IETF bosses could 
stay in one position for decades.


I do not see how it can be called totalitarian given the IETF Nomcom
appointment and recall mechanisms. Admittedly it is not full on
Sortition (https://en.wikipedia.org/wiki/Sortition) but it is just one
level of indirection from Sortition. (See
https://www.forbes.com/sites/forbestechcouncil/2020/08/20/indirection-the-unsung-hero-of-software-engineering/?sh=2cc673587f47) 





Donald helped setup this Nomcom system, based upon his experience in the
F community WorldCon.  Credit where credit is due, and our thanks!

Randy Bush has also had some cogent thoughts over the years.

Once upon a time, I'd proposed that we have some minimum eligibility
requirements, such as contributing at least 10,000 lines of code, and/or
*operational* experience.  Certain IESG members objected (who stuck
around for many years).

Once upon a time, IETF did have formal hums.  That went by the wayside
with IPSec.  Photuris won the hum (overwhelmingly).  We had multiple
interoperable international independent implementations.

Then Cisco issued a press release that they were supporting the US NSA
proposal.  (Money is thought to have changed hands.)  The IESG followed.

Something similar happened with IPv6.  Cisco favored a design where only
they had the hardware mechanism for high speed forwarding.  So we're
stuck with 128-bit addresses and separate ASNs.

Again with high speed fiber (Sonet/SDH).  The IESG overrode the existing
RFC with multiple independent implementations in favor of an unneeded
extra convolution that only those few companies with their own fabs could
produce.  So that ATT/Lucent could sell lower speed tier fractional 
links.


Smaller innovative companies went out of business.

Of course, many of the behemoths that used the standards process to
suppress competitors via regulatory arbitrage eventually went out of
business too.

Internet Vendor Task Force indeed.




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

Re: Jon Postel Re: 202210301538.AYC

[Abraham Y. Chen]

Dear Noah:

0)  "Iterations often times leads back to the beginning.": Thanks for 
distilling this thread to a concise principle. Perhaps your name was 
given with the foresight of this discussion? 


1)  As a newcomer to the arena, I have always been perplexed by the 
apparent collective NIH (Not Invented Here) syndrome of the Internet 
community. While promoting openness, everything seems to go with "my way 
or noway". Of course, each Internet practice or convention was 
determined by some sort of consensus by majority opinion. However, once 
it gets going, it appears to be cast in concrete. There is a huge 
inertia against considering alternatives or improvements. Some of them 
even appear to be volunteered "policing" without full understanding of 
the background. Just like how practically all democratic governments are 
facing these days, a well-intended crowd can be led by an influencer to 
derail a social normality. It does not seem to me that strictly adhering 
to "one person one vote" rule can guide us toward a productive future.


2)  To follow what you are saying, I wonder how could we think "out of 
the box" or go "back to the future", before it is too late for our world 
wide communications infrastructure to serve as a reliable daily tool 
without being a distraction constantly? That is, four decades should be 
long enough for our Internet experiments to be reviewed, so that we can 
try navigating out of the current chaos, or start with an alternative.


Regards,


Abe (2022-10-30 18:41 EDT)




On 2022-10-30 12:47, Noah wrote:



On Mon, 17 Oct 2022, 00:18 Randy Bush,  wrote:

my favorite is

It's perfectly appropriate to be upset. 



Ack

I thought of it in a slightly
different way--like a space that we were exploring and, in the
early days,
we figured out this consistent path through the space: IP, TCP,
and so on.


the impact of IP, TCP in improving human life across the globe in the 
last decades can not be overstated.


Human enginuity through names like Google have enabled the age of 
information and access to information through addresses and digital 
trade routes have continued to ensure peace for humanity on the 
positive side of the communications spectrum.


What's been happening over the last few years is that the IETF is
filling
the rest of the space with every alternative approach, not
necessarily any
better.  Every possible alternative is now being written down. 
And it's not
useful.  -- Jon Postel


I suppose original human ideas and thoughts tends to stand the taste 
of time.


Iterations often times leads back to the beginning.

Noah




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

Source Vs. Manifestations Re: 202210071016.AYC Re: FCC chairwoman: Fines alone aren't enough (Robocalls)

[Abraham Y. Chen]

Dear Brian, et al.:

0)   Thanks for sharing the Robocall situation in Italy. This confirms 
that the RoboCall phenomenon is now universal, not just in US. Although, 
from my experience, I am not surprised at all.


1)   Based on my best understanding, I believe that the entire issue has 
been handled backwards, upside down or outside in. I have been waiting 
for what FCC's latest STIR/SHAKEN directive might be able to do. Its 
technicality sounded very impressive. It did seem to have some effect on 
Robocalls. As a consumer, however, this current approach has defeated 
the basic purpose of the original Caller-ID service. Apparently, true 
telephony (common) carriers have begun to ask to be compensated for 
accessing their subscriber database in the process of validating a 
caller by other (such as VoIP) operators. (In the old days of monopoly, 
this was not an issue because it would be reciprocal within the same 
carrier, or among a limited few similar ones.) As a consequence, 
Caller-ID displays of most incoming telephone calls nowadays often lack 
the caller names which was the key ingredient of the feature. They are 
replaced by a duplicated "caller number", or at best prefixed such with 
a "[V]" symbol which took me awhile to realize what it meant. This is 
very annoying since most people can't correlate such to more than a 
couple phone numbers of close relatives or associates, on the fly. 
However, this resultant system behavior serves RoboCallers' purpose just 
fine, because the repeated and persisted ringing sound from unknown 
callers disturb the called party sufficiently to the point of answering, 
once again.


2)  The whole subject can be looked at from a very simple perspective 
such as a daily routine of accessing a premises for delivering 
something. We all know that the location of a property is publicly known 
by its street address. Any and every one can get to it. To control the 
access, a key to the lock on the door has to be given to only a welcomed 
few. For an establishment, a receptionist or a security guard serves the 
same purpose during business hours.


3)  For postal services, a mail box at the entrance to a property or a 
mail room at an establshiment has been used for the above "buffering" 
purpose to deal with the junk mail. So far, these traditional setups 
have worked reasonably well for centuries.


4)  When telephony was initially introduced, it was regarded as a 
novelty. Getting a call was a big event. No one had the notion about 
blocking any calls. Later on, the "caller pays only if a call is 
answered" convention led to the alerting device (the ringer) purposely 
made loud enough to be sure that the called party would be pressured to 
answer the call. During the manual switchboard days, operators screened 
the callers very effectively, because practically every caller was known 
to the operator.


5)  To avoid disturbing workers by random calls, a receptionist / 
telephone operator was tasked with this "buffering" duty at any sizable 
establishment. As telephone switching equipment got mechanized, the 
combined DID (Direct Inward Dialing), VM (Voice Mail) and AA 
(Auto-Attendant) technologies took over this function. So, majority 
workers at institutions and businesses (except those served by CENTREX - 
CENTRal EXchange, because each is on a direct public phone number) have 
hardly ever been bothered by unwanted calls, even to the modern days.


6)  As per-call charge dropped significantly, largely encouraged by bulk 
rates, then furthered by VoIP technology, the unwanted calls ranging 
from harassment, telemarketing to scam, etc. skyrocketed. Not knowing 
the extension numbers behind PABX (Private Automatic Branch eXchange) 
machines, Robocalls target private residences most of the time.


7)  By miniaturizing DID, VM and AA subsystems, even residential single 
line telephone service could be shielded from RoboCalls just as well, as 
disclosed by US Pat. No.5,596,631.  It was commercialized as a product 
called TriVOX VN100 (See URL below) that enabled a home owner to set a 
changeable combination lock at his telephone demarcation point for 
blocking all calls, except those welcomed callers who have been given 
the code (extension number). This effectively blocked all unwanted calls 
regardless the type, even though some might be legally exempted, such as 
political, religious or charitable, etc. However, FTC and FCC decided to 
take other routes.


https://www.avinta.com/products-1/uwc/home/uwchme.htm

8)  The Internet SPAM eMail issue can be parsed down to very similar 
components. In the earlier days, digital communication was established 
end-to-end directly via dial-up modems. Following the PSTN protocol and 
log-in procedure, the involved steps discouraged most of the abuse. Once 
the electronic messaging traffic got consolidated to limited few 
providers with store-and-forward facility, the screening function became 
part of their services. Behind the 

Test Bed for New Protocol Re: Proposals at ITU-T for Internet Evolution Raise Serious Concerns; According to ISOC Re: 202208121501.AYC

[Abraham Y. Chen]

Dear bzs et el.:

1) I was made aware of the referenced "New IP" efforts about two years 
ago. After watching the below online discussion video recording, in 
particular, Andrew Sullivan's comments near the end (starting at time 
marker 00:53:42) that reminded us about thefull architecture versus 
building block approaches, the super importance of incremental 
deployability and the main issue of IPv6 being formally incompatible 
with IPv4, etc., I posted a feedback there.


https://www.internetgovernance.org/2020/09/23/what-is-the-future-of-internet-architecture/

2) Essentially, I offered our EzIP RAN (Regional Area Network) 
configuration as the "New IP" test bed. So that they could have a real 
life demonstration setup going within the existing Internet environment, 
yet independent of the current operations. It could avoid spending a lot 
of efforts on conceptually convincing others by theoretical analysis and 
reasoning. We had some follow-up exchanges. But, they continued on with 
their original way.





Regards,

Abe (2022-08-12 17:08 EDT)



On 2022-08-11 18:33, b...@theworld.com wrote:

This has been going around for at least two years, makes for some
great scary, click-bait headlines ("they propose an internet kill
switch! For China!", and so forth.)

Besides the obvious question, "by what authority will they move this
forward?" many of us looked at the proposals and they're, in a word,
idiocy.

   
https://www.itu.int/en/ITU-T/studygroups/2017-2020/13/Documents/Internet_2030%20.pdf

(it's only 25 pages and you probably can skip to section 6, maybe look
at section 5, the rest is mostly "what a network is" padding.)

I don't mean I don't like it or just want to criticize it, I mean
rambling, sophomoric idiocy.

But you have to give some credit to their coming up with:

   "Holographic Avatar Centric Communications"

as a core idea.

I'd say, like we said with ISO/OSI, etc etc etc: Implement a test bed
and we'll have a look!

On August 11, 2022 at 13:59n...@nanog.org  (Nanog News) wrote:
  > Proposals at ITU-T for Internet Evolution Raise Serious Concerns; According 
to
  > ISOC
  > Huawei, Chinese Carriers, and China want to Redesign a Prominent Part of the
  > Internet via a set of “New IP” Proposals
  >
  > Any new initiative has pros and cons, but according to ISOC (Internet 
Society),
  > the “New IP” proposals are threatening and should be discussed further.
  >
  > We caught up with Hosein Badran to give us the good, bad, and ugly of the 
“New
  > IP” proposals. Badran is a senior director for ISOC and leads the 
technology,
  > policy, and advocacy initiatives in Internet access, infrastructure, and 
trust
  > domains.
  >
  > READ NOW
  >
  >




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

Re: Scanning the Internet for Vulnerabilities Re: 202207272146.AYC

[Abraham Y. Chen]

Hi, John:

0) Thanks for sharing your thoughts. The IoT identification (IP address) 
versus privacy is a rather convoluted topic. It can quickly get 
distracted and diluted if we look at it by piecemeal. Allow me to go 
through an overview to convey my logic.


1) It is true that a dynamic IoT identification is harder to track down 
than a static one, thus providing some sense of privacy or security, 
theoretically. This went well with the need for dynamic practice due to 
the limited IPv4 address pool. So, this idea sank deep into most 
people's mind as inherent for the Internet.


2) It turned out that there were many ways (as you eluded to) to track 
down an IoT even with a dynamic address. There was a classical research 
paper that outlined various techniques to do so:


https://www.ccsl.carleton.ca/paper-archive/muir-computingsurveys-09.pdf

 To save your time, I extracted part of its conclusions as below:
 "6 Concluding Remarks ... while some commercial organizations have 
claimed that they can do it with 99% accuracy. … It’s meant for the 99 
percent of the general public who are just at home surfing. … We note 
that even if accurate IP geolocation is possible for 99% of IP 
addresses, if the remaining 1% is fixed and predictable by an adversary, 
and such that the adversary can place themselves within this subspace, 
then they can evade geolocation 100% of the time. …"


 We do not need to check its validity quantitatively, today, because 
technology has advanced a lot. However, it is probably still pretty 
accurate qualitatively, judging by how successful "targeted marketing" 
is, while how hard various perpetrators may be identified, not to 
mention physically locating one.


3) As long as the general public embrace the Internet technologists' 
promise of privacy by dynamic addressing, however, the LE (Law 
Enforcement) agencies have the excuse for exercising mass surveillance 
that scoops up everything possible from the Internet for offline 
analysis. Big businesses have been doing the same under the same cover. 
So, most people end up without privacy anyway. (Remember the news that 
German Chancellor's phone call was somehow picked up by the NSA of US? 
For anyone with a little imagination, it was a clear hint for the tip of 
an iceberg.).


4) Static communication terminal (IoT) identification practice will 
remove a significant number of entities (the 99%) from LE's monitor 
operation, enabling them to focus on the 1% as well as requiring them to 
submit justification for court order before doing so. The last part has 
disappeared under the Internet environment. See URL below for an 
example. The static IP address practice will simplify the whole game. 
That is, the LEs can do their job easier, while the general public will 
get the legally protected privacy back.


 
https://www.usatoday.com/story/news/2021/12/08/federal-court-upholds-terrorism-conviction-mass-surveillance-case/6440325001/


Regards,



Abe (2022-07-27 23:28 EDT)







On 2022-07-24 13:57, John Curran wrote:

On 24 Jul 2022, at 10:20 AM, Abraham Y. Chen  wrote:

Hi, John:

1) "...  dynamically assigned IP address space can still be tracked back to a given 
system ... ": I fully agree with this statement. However,
A. You overlooked the critical consideration of the response time. If this 
can not be done in real time for law enforcement purposes, it is meaningless.

Abe -

That’s correct - but that does not require having static addresses to 
accomplish (as you postulated earlier),
rather it just requires having appropriately functioning logging apparatus.


B. Also, the goal is to spot the specific perpetrator, not the "system" which is too 
general to be meaningful. In fact, this would penalize the innocent users who happen to be on the 
same implied "system".

Yes, it is quite obvious that a degree of care is necessary.


C. In addition, for your “whack-a-mole” metaphor, the party in charge is 
the mole, not the party with the mallet. It is a losing game for the mallet 
right from the beginning.

As with all enforcement, it is a question on changing to breakeven point 
calculation on incentives & risks
for the would be perpetrators, and presently there’s almost nearly no risk 
involved.


So, the current Internet practices put us way behind the starting line even 
before the game. Overall, this environment is favored by multi-national 
businesses with perpetrators riding along in the background. When security is 
breached, there are more than enough excuses to point the finger to. No wonder 
the outcome has always been disappointing for the general public.

Indeed.


2) What we need to do is to reverse the roles in every one of the above 
situations, if we hope for any meaningful result, at all. The starting point is 
to review the root differences between the Internet and the traditional 
communication systems. With near half a century of the Intern

Re: Scanning the Internet for Vulnerabilities Re: 202207240927.AYC

[Abraham Y. Chen]

Hi, John:

1) "...  dynamically assigned IP address space can still be tracked back 
to a given system ... ": I fully agree with this statement. However,
   A. You overlooked the critical consideration of the response time. 
If this can not be done in real time for law enforcement purposes, it is 
meaningless.


   B. Also, the goal is to spot the specific perpetrator, not the 
"system" which is too general to be meaningful. In fact, this would 
penalize the innocent users who happen to be on the same implied "system".


   C. In addition, for your “whack-a-mole” metaphor, the party in 
charge is the mole, not the party with the mallet. It is a losing game 
for the mallet right from the beginning.


   So, the current Internet practices put us way behind the starting 
line even before the game. Overall, this environment is favored by 
multi-national businesses with perpetrators riding along in the 
background. When security is breached, there are more than enough 
excuses to point the finger to. No wonder the outcome has always been 
disappointing for the general public.


2) What we need to do is to reverse the roles in every one of the above 
situations, if we hope for any meaningful result, at all. The starting 
point is to review the root differences between the Internet and the 
traditional communication systems. With near half a century of the 
Internet experience, we should be ready to study each issue from its 
source, not by perpetuating its misleading manifestations.


Regards,


Abe (2022-07-24 10:19 EDT)


On 2022-07-24 07:27, John Curran wrote:

Abe -

Static versus dynamic address assignment isn’t the problem - 
dynamically assigned IP address space can
still be tracked back to a given system (reference: RFC6302/BCP162 & 
RFC6269 for discussion of the

requirements and various related issues.)

Tracking back to a particular server doesn’t really matter if all that 
happens is that the service is terminated
(as the culprit will simply appear elsewhere in the Internet with a 
new connection/server and start over.)


Alas, the situation doesn’t change unless/until there’s a willingness 
to engage law enforcement and pursue
the attackers to prevent recurrence.  This is non-trivial, both 
because of the skills necessary, the volume of
attacks, the various jurisdictions involved, etc. – but the greatest 
obstacle is simply the attitude of “Why bother,

that’s just the way it is…”

With zero effective back pressure, we shouldn’t be surprised as 
frequency of attempts grows without bound.


Thanks,
/John

Disclaimers: my views alone – no one else would claim them.  Feel free 
to use/reuse/discard as you see fit.



On 23 Jul 2022, at 10:28 PM, Abraham Y. Chen  wrote:

Hi, John:

1) "... i.e. we’re instead going to engage in the worlds longest 
running game of “whack-a-mole” by just blocking their last known 
website/mail server/botnet and the wishing for the best… ":


Perhaps it is time for us to consider the "Back to the Future" 
strategy, i.e., the Internet should practice static IP address like 
all traditional communication system did?


Regards,

Abe (2022-07-23 22:27 EDT)


On 2022-06-22 10:35, John Curran wrote:

Barry -

There is indeed a metaphor to your “rattling doorknobs", but it’s
not pretty when it comes to the Internet…

If you call the police because someone is creeping around your
property checking doors and windows for
possible entry, then they will indeed come out and attempt to
arrest the perpetrator (I am most certainly
not a lawyer, but as I understand it even the act of opening an
unlocked window or door is sufficient in many
jurisdictions to satisfy the “breaking the seal of the property”
premise and warrant charging under breaking
and entering statues.)

Now welcome to the Internet… paint all your windows black, remove
all lighting save for one small bulb
over your front entry. Sit back and enjoy the continuous sounds
of rattling doorknobs and scratching at
the windows.

If/when you find a digital culprit creeping around inside the
home, your best option is burn down the place
and start anew with the copies you keep offsite in storage
elsewhere. Similarly if you find a “trap” (e.g.,
a phishing email) placed on your patio or amongst your mail…
discard such cautiously and hope your
kids use equal care.

“Best practice” for handling these situations on the Internet is
effectively to cope as best you can despite
being inundated with attempts – i.e. most Internet security
professionals and law enforcement will tell you
that the idea of actually trying to identify and stop any of the
culprits involved is considered rather quaint
at best – i.e. we’re instead going to engage in the worlds longest
running game of “whack-a-mole” by just
blocking their last known website/mail server/botnet and the
wishing for the best…


Enjoy your Internet!
/John

Disclaimers: My views alone - use, reuse, or discard as desired.
This message 

Re: Scanning the Internet for Vulnerabilities Re: 202207232217.AYC

[Abraham Y. Chen]

Hi, John:

1) "... i.e. we’re instead going to engage in the worlds longest running 
game of “whack-a-mole” by just blocking their last known website/mail 
server/botnet and the wishing for the best… ":


Perhaps it is time for us to consider the "Back to the Future" strategy, 
i.e., the Internet should practice static IP address like all 
traditional communication system did?


Regards,

Abe (2022-07-23 22:27 EDT)


On 2022-06-22 10:35, John Curran wrote:

Barry -

There is indeed a metaphor to your “rattling doorknobs", but it’s
not pretty when it comes to the Internet…

If you call the police because someone is creeping around your
property checking doors and windows for
possible entry, then they will indeed come out and attempt to
arrest the perpetrator (I am most certainly
not a lawyer, but as I understand it even the act of opening an
unlocked window or door is sufficient in many
jurisdictions to satisfy the “breaking the seal of the property”
premise and warrant charging under breaking
and entering statues.)

Now welcome to the Internet…  paint all your windows black, remove
all lighting save for one small bulb
over your front entry.   Sit back and enjoy the continuous sounds
of rattling doorknobs and scratching at
the windows.

If/when you find a digital culprit creeping around inside the
home, your best option is burn down the place
and start anew with the copies you keep offsite in storage
elsewhere.   Similarly if you find a “trap” (e.g.,
a phishing email) placed on your patio or amongst your mail…
discard such cautiously and hope your
kids use equal care.

“Best practice” for handling these situations on the Internet is
effectively to cope as best you can despite
being inundated with attempts – i.e. most Internet security
professionals and law enforcement will tell you
that the idea of actually trying to identify and stop any of the
culprits involved is considered rather quaint
at best – i.e. we’re instead going to engage in the worlds longest
running game of “whack-a-mole” by just
blocking their last known website/mail server/botnet and the
wishing for the best…


Enjoy your Internet!
/John

Disclaimers:  My views alone - use, reuse, or discard as desired.
                      This message made of 100% recycled electrons.


On 22 Jun 2022, at 12:04 AM, b...@theworld.com wrote:


When I lock the doors etc to my home I'll often mutter "ya know, if
someone is rattling my door knob I already have a big problem."

I suppose when I'm home it might give me a warning if I hear it.

There must be a metaphor in there somewhere.

I do recall as a teen noticing that one of the closed store's on the
main drag's door was unlocked late one night walking home (this was in
NYC.)

I saw a cop and told him and he scolded me angrily for rattling door
knobs, I could be arrested for that! But verified it, looked around
inside with his flashlight, and called it in.

I forget how I noticed but I wasn't in the habit of rattling stores'
door knobs, I think the door was just a bit ajar.

There must be a metaphor in there somewhere.

On June 21, 2022 at 10:01 mpal...@hezmatt.org (Matt Palmer) wrote:

On Mon, Jun 20, 2022 at 02:18:30AM +, Mel Beckman wrote:
When researchers, or whoever, claim their scanning an altruistic 
service,
I ask them if they would mind someone coming to their home and 
trying to

open all the doors and windows every night.


If there were a few hundred people with nefarious intent trying to 
open your
doors and windows every night, someone doing the same thing with 
altruistic

intent might not be such a bad thing.

- Matt


--
   -Barry Shein

Software Tool & Die    | b...@theworld.com | 
http://www.TheWorld.com 

Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*





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

EzIP Draft Updated to IETF Re: 202206111210.AYC

[Abraham Y. Chen]

Dear Colleagues:

0)    Appreciate very much for the discussion on this platform (and 
others), we learned a lot about Internet topics and considerations.


1)    Two Appendixes, G & H have been added to the latest IETF draft 
revision (URL below). They summarize our digest of the feedback and 
comment. We look forward to your thoughts.


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

Regards,


Abe (2022-06-11 14:12)



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

Re: Let's Focus on Moving Forward Re: V6 still not supported

[Abraham Y. Chen]

Dear John:

0) The below message just popped up in my InBox. And, it appears that 
there has not been any follow-up comments.


1) How about have a look at our work, (URL below), in case you have not 
come across? We propose a very specific way of making use of the 240/4 
netblock. There are a couple manifestations from this approach that will 
enhance the Internet operations. In a sense, EzIP is a ready-to-go 
example that will benefit from the "IPv4 Unicast Extensions Project" 
efforts that Mr. Gilmore was referring to.


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



Your comments and thoughts will be much appreciated.


Regards,


Abe (2022-05-25 11:07)




On 2022-03-30 19:26, John Kristoff wrote:

On Wed, 30 Mar 2022 04:47:08 -0700
John Gilmore  wrote:


   https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-240/
The draft touches on IANA considerations, but this seems inadequate to 
make any more progress and gain wider acceptance. It seems to me there 
has been compelling arguments made about the ability to rx, tx, and 
relay packets with these addresses, but the real challenge remains, 
how should they be allocated? The document should probably request 
that they be changed from reserved to experimental explicitly. 
Suggesting the IETF/IANA just figure out what to do with them later 
seems unsatisfying. Perhaps the equivalent of an IAB-style workshop 
report or position paper that goes into potential allocation choices 
and effects in detail is worthwhile? I'd imagine you'd get lots of 
interesting presentations on a possible allocation strategies and 
challenges if you decide to organize something like this. I'd like to 
see some options for the IANA/IETF. Let's see someone dissect what if 
anything RIRs should get and what the effect of different policies for 
the new blocks might be. Let's hear about some interesting new 
special-use ideas. I'd love to see someone suggest a spectrum-like 
auction to the highest bidder and get doused with rotten fruit... etc 
:-) John 




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

EzIP vs. YADA & YATT Re: Ready to compromise? was RE: V6 still not supported

[Abraham Y. Chen]

Dear Pascal:

Have not heard your follow-up thoughts and comments.

It would be much appreciated if we can carry this dialog forward.

Regards,


Abe (2022-05-05 11:23 EDT)



On 2022-04-21 17:38, Abraham Y. Chen wrote:

Dear Pascal:

0) Thanks for your clarification. It enabled me to study your draft a 
little closer and came up with the following observations to share.


1) "Yes, this is plain IP in IP. For a router does not know about 
YADA, this looks like the most basic form of tunnel you can get.":


Not really. I believe that any networking stack conforming to the 
Options mechanism in RC791 can achieve the same, thus more concise and 
less involved. Please see Figure 4 of EzIP Draft.


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

2) " 1. 
<https://www.ietf.org/archive/id/draft-thubert-v6ops-yada-yatt-03.html#section-1>Introduction 
and Motivation 
<https://www.ietf.org/archive/id/draft-thubert-v6ops-yada-yatt-03.html#name-introduction-and-motivation> 
The proposed benefit is a thousandfold increase of the 
IPv4-addressable domain by building parallel realms each potentially 
the size of the current Internet.


"2.2. 
<https://www.ietf.org/archive/id/draft-thubert-v6ops-yada-yatt-03.html#section-2.2>New 
Terms 
<https://www.ietf.org/archive/id/draft-thubert-v6ops-yada-yatt-03.html#name-new-terms> 


            This document often uses the following new terms:

  # IPv4 realm:

  # A full IPv4 network like the current Internet. YADA does not
affect the traditional IPv4 operations within a realm.":

These are the critical statements that led to one of my two initial 
questions. That is, are you proposing to have N (>250 as an example 
cited in your draft) realms that each has the full IPv4 address pool 
capacity (after deducted for certain special functions)? This will be 
fine if each realm was occupying one floor of a stand-alone  
skyscraper. I can not visualize this architecture when it is expanded 
to cover the whole earth, since each of them can operate with all the 
IPv4 addresses. Not only physically impossible to build such a 
skyscraper, but also how can we form 250 independent overlays on top 
of the entire IPv4 based Internet? Is there any mechanism that can 
isolate the respective transmission media of the 250 realms from one 
another?


3) " 1. 
<https://www.ietf.org/archive/id/draft-thubert-v6ops-yada-yatt-03.html#section-1>Introduction 
and Motivation 
<https://www.ietf.org/archive/id/draft-thubert-v6ops-yada-yatt-03.html#name-introduction-and-motivation> 
 Connectivity between an IPv4-only node and an IPv6-only node, or 
between an IPv4-only node and a YADA node in different realm, still 
requires a CG-NATs as of today,  ":


Since eliminating the CG-NAT practice is one of the general 
motivations for address expansion efforts, I am puzzled by why are you 
still keeping it, and for how long? In contrast, upon the initial RAN 
(Regional Area Network) deployment, the CG-NAT will be retired from 
EzIP environment.


4)   "Figure 2 
<https://www.ietf.org/archive/id/draft-thubert-v6ops-yada-yatt-03.html#figure-2>: 
YADA format in the source realm 
<https://www.ietf.org/archive/id/draft-thubert-v6ops-yada-yatt-03.html#name-yada-format-in-the-source-r> 
YADA also requires a change for the routers that serve the shaft.":


    Are you saying that an IoT in a realm wishing to communicate with 
another in a separate realm does not need to know about this format 
nor something equivalent to convey such inter-realm address information?


5) "Figure 4 
<https://www.ietf.org/archive/id/draft-thubert-v6ops-yada-yatt-03.html#figure-4>: 
YADA format inside the shaft 
<https://www.ietf.org/archive/id/draft-thubert-v6ops-yada-yatt-03.html#name-yada-format-inside-the-shaf> 
":


This particular format closely resembles that of EzIP (see EzIP Draft 
Figure 4 mentioned above), where "outer IPv4 header" part of five 
words carrying the two realms' address information are conveyed by 
words 4 & 5 of a standard IPv4 header, while the IoT (inner) addresses 
are transported by three Options words. The EzIP format enables the 
EzIP implementation to stay within the RFC791 specifications, no need 
to go beyond.


6) Below is my quick digest and comparison of our two projects by 
partially paraphrasing YADA terminology:


A.    Since there is no way to build a 250 floor skyscraper covering 
the entire globe for physical isolation between floors (realms), it is 
difficult to visualize how could the same IP address be used by 250 
separate parties as proposed by YADA without the fundamental address 
conflict issue. How to provide a medium that has 250 fully isolated 
layers, each capable of transporting the full set of IPv4 addresses, 
seems to be the challenge.


B.    The function of YADA format probably can be achieved by mak

Re: FCC to Consider New Rules to Combat International Scam Robocalls

[Abraham Y. Chen]

Hi, Keith:

The root cause of phone spam is because Caller-ID service was first 
deteriorated by a marketing gimmick that enabled the spoofing of the 
Caller-ID. Combined with eMail spam techniques, VoIP operations have now 
become out of hand. Below is an overview of these annoyances. This is a 
topic that I am not sure whether NANOG is the proper forum to deal with. 
Although, certain parameters and considerations are closely related to 
the Internet issues.


https://en.wikipedia.org/wiki/Caller_ID_spoofing


Abe (2022-04-27 22:17)


On 2022-04-27 21:39, Keith Medcalf wrote:

With AT and perhaps others, you can forward the message to 7726
(spells SPAM on the keypad) and they'll reply asking for the originating
phone number or email address.

This is, of course, the root of the problem.  The recipient of the spam does 
not know either the originating phone number or the originating e-mail address. 
 All they know is the Advertizing ID -- and that is useless for everything 
except what it was designed for -- advertizing.

If one knew the originating phone number then one would know who to hunt down and 
which throat to slit from ear to ear, and there would be no need to involve 
AT at all... This, and the fact that the Telco's get bloody rich from 
providing termination for all the crap they have enabled is exactly the reason they 
did it in the first place!




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

Re: Ready to compromise? was RE: V6 still not supported

[Abraham Y. Chen]

e of full IPv4 addresses, 
EzIP works within only one set of IPv4 address pool.


b.    EzIP starts from only realm 1 which occupies a subset of IPv4 
addresses (the full IPv4 pool minus 240/4 netblock).


c.    Realm 2 thru realm N are called RAN (Regional Area Network), each 
reusing a full IPv4 subset of the 240/4 netblock. They are physically 
isolated from one another by restricted use within respective 
geographical boundaries.


d.    Instead of a big elevator shaft threading trough all N floors of 
the realms, Each RAN is individually tethered as a kite from realm 1 
(the current Internet core) via just one (or more if needed) IPv4 address.


e.    After enough RANs are deployed, their boundaries begin to touch 
one another. So that, direct paths between the RANS may be established. 
Thus, an overlay of new networks is formed covering the entire globe for 
becoming a parallel cyberspace to the current Internet core (realm 1). 
The two can operate independently and interact only at arm's length via 
the umbilical cords, when needed.


D.    Unlike YADA & YATT, EzIP has not specifically considered its 
application to IPv6. Although, the feasibility of expanding a finite 
sized address pool such as IPv4, demonstrates that EzIP is equally 
capable of expanding the IPv6 that still has a lot of unassigned addresses.


Please comment.


Regards,



Abe (2022-04-21 17:37 EDT)



On 2022-04-20 03:20, Pascal Thubert (pthubert) wrote:

Dear Abe:

Yes, this is plain IP in IP. For a router does not know about YADA, this looks 
like the most basic form of tunnel you can get. Which is where the inner/outer 
terminology comes from. All very classical. We could do an over-UDP variation 
if people want it.

I used a condensed format to focus the reader on the addresses that get 
swapped; also the visualization clarifies that there cannot be options between 
the outer header and the inner headers.

The only routers that need to understand the fact that this is more than a 
plain tunnel are the routers that connect the realm to the shaft, because they 
have to check that the realm address is correct and do the address swap between 
inner and outer.

The first version of the draft impacted routers for BCP 38 procedures, this is 
now changed. The routers inside a realm can keep operating unmodified, and 
there's no need to deploy new policies for ingress filtering.

Keep safe;

Pascal


-Original Message-
From: Abraham Y. Chen
Sent: vendredi 15 avril 2022 0:47
To: Pascal Thubert (pthubert)
Cc:nanog@nanog.org
Subject: Re: Ready to compromise? was RE: V6 still not supported

Dear Pascal:

1)    I had a quick look at the below updated draft. I presume Figure 2 is
intended to address my request. Since each IPv4 address has 4 bytes, what
are the 12 bytes allocated for IPv4 header fields (outer) and (inner),
each? Aren't they the standard first 12 bytes of packet identifier in an
IPv4 header? If so, why not show it straightforward as defined by RFC791?

2) If my above assumption is correct, you are essentially prefixing the
packet identifying portion (inner) of an IPv4 header with another one (the
"outer"), without making use of the existing Options words like my EzIP
proposal. How could any existing routers handle a packet with this new
header format, without any design related upgrade? If you do expect
upgrade, it would appear to me as too much to ask. Am I missing something?


Regards,


Abe (2022-04-14 18:46)



On 2022-04-08 10:34, Pascal Thubert (pthubert) wrote:

Dear all

Following advice from thus list, I updated the YADA I-Draft (latest

ishttps://www.ietf.org/archive/id/draft-thubert-v6ops-yada-yatt-03.html,
more to come soon if feedback is heard) and proposed it to the v6ops WG at
the IETF.

For memory, the main goal here is to find a compromise as opposed to yet

another transition solution, though it can be used as a side effect to
move along the ladder. The compromise does not change IPv4 or IPv6, tries
not to take side for one or the other, and add features to both sides
which, if implemented, reduce the chasm that leads to dual stack and CG-
NATs.

There's value for the movers, lots more public address space for the

IPv4-only stack/networks and free prefixes per node and new deployment
opportunities for the IPv6-only ones.

One major update from the original text accounts for Dave's comment in

this list on BCP 38 enforcement, I believe it's solved now. I also added
format layouts to Abe Chen's question, and text on the naïve version vs.
all the elasticity that exists there and in IP in general to allow real
world deployments.

Comments welcome, here and/or at v6ops for those who participate there.

Many thanks in advance;

Pascal

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




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

Re: Ready to compromise? was RE: V6 still not supported

[Abraham Y. Chen]

Dear Pascal:

1)    I had a quick look at the below updated draft. I presume Figure 2 
is intended to address my request. Since each IPv4 address has 4 bytes, 
what are the 12 bytes allocated for IPv4 header fields (outer) and 
(inner), each? Aren't they the standard first 12 bytes of packet 
identifier in an IPv4 header? If so, why not show it straightforward as 
defined by RFC791?


2) If my above assumption is correct, you are essentially prefixing the 
packet identifying portion (inner) of an IPv4 header with another one 
(the "outer"), without making use of the existing Options words like my 
EzIP proposal. How could any existing routers handle a packet with this 
new header format, without any design related upgrade? If you do expect 
upgrade, it would appear to me as too much to ask. Am I missing something?



Regards,


Abe (2022-04-14 18:46)



On 2022-04-08 10:34, Pascal Thubert (pthubert) wrote:

Dear all

Following advice from thus list, I updated the YADA I-Draft (latest 
ishttps://www.ietf.org/archive/id/draft-thubert-v6ops-yada-yatt-03.html, more 
to come soon if feedback is heard) and proposed it to the v6ops WG at the IETF.

For memory, the main goal here is to find a compromise as opposed to yet 
another transition solution, though it can be used as a side effect to move 
along the ladder. The compromise does not change IPv4 or IPv6, tries not to 
take side for one or the other, and add features to both sides which, if 
implemented, reduce the chasm that leads to dual stack and CG-NATs.

There's value for the movers, lots more public address space for the IPv4-only 
stack/networks and free prefixes per node and new deployment opportunities for 
the IPv6-only ones.

One major update from the original text accounts for Dave's comment in this 
list on BCP 38 enforcement, I believe it's solved now. I also added format 
layouts to Abe Chen's question, and text on the naïve version vs. all the 
elasticity that exists there and in IP in general to allow real world 
deployments.

Comments welcome, here and/or at v6ops for those who participate there.

Many thanks in advance;

Pascal




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

dule is not expected to make any changes from today's 
configuration for packet transmission between it and the Internet. For 
the CDN operation, the gateway has already been performing the address 
translation between unrelated IP address blocks as a two-port device. 
For packets going through it, it will continue to perform its NAT 
function. There is no reason to announce to the world that its internal 
addresses have been updated to 240/4.


7)    "... IMHI: it would be a very dirty work-around if servers would 
need to teach their capabilities to every NAPT device.   ... ":    
Based on the above description, I hope you will change your conclusion.


I look forward to your further thoughts.


Regards,




Abe (2022-04-04 12:13 EDT)




On 2022-04-04 06:32, Vasilenko Eduard wrote:


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

Re: V6 still not supported

[Abraham Y. Chen]

Hi, Jared:

1)    " For cloud providers your IPv4 blocks become your moat. ":    It 
is interesting that your closing statement summarizing the current 
tactics of keeping customers captive and fending against competition 
mirrors well with the "Towers of Babel" metaphor of the ancient days 
mentioned by Christian a couple days' ago. That is, the cyberspace 
"Towers" are controlled virtually by multi-national businesses that 
extend far beyond conventional geographical / political borders. It 
exceeds the comprehension of most people. So, we must realize this 
situation and stop promoting such.


Regards,


Abe (2022-04-04 09:53)





On 2022-04-04 06:01, Jared Brown wrote:

Owen DeLong via NANOG wrote:
When your ISP starts charging $X/Month for legacy protocol support

Out of interest, how would this come about?

ISPs are facing ever growing costs to continue providing IPv4 services.

  Could you please be more specific about which costs you are referring to?

Costs of address acquisition
Costs of CGNAT systems in lieu of address acquisition costs
Costs of increasing support calls due to IPv4 life support measures in other 
networks.
etc.


  It's not like IP transit providers care if they deliver IPv4 or IPv6 bits to 
you.

True, but adding customers requires additional addresses at some point. IPv6 
addresses are cheap compared to IPv4 addresses.

   As an aside, all this demonstrates quite well one of the impediments to 
accelerated IPv6 adoption:

   None of these costs apply to parties not growing or ones that are only 
growing withing their existing IPv4 allocation.

   The status quo does not promote IPv6 adoption, which is obviously a problem 
since transitioning to IPv6-only requires all parties to be aboard.

   I'll even add that there is a perverse incentive for ISPs and others to 
delay IPv6 adoption in certain segments. As there is a scarcity of IPv4, ISPs 
can charge a premium for access to IPv4 addresses, something you cannot do with 
IPv6. Furthermore as IPv4 blocks are acting like an appreciating asset, there 
is both an incentive to acquire more, regardless of need, and to hoard what you 
have, even if you don't need it. For cloud providers your IPv4 blocks become 
your moat.


- Jared




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

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: Let's Focus on Moving Forward Re: V6 still not supported

[Abraham Y. Chen]

 third party. Any addressing
model that  terminates address space between me and someone I
communicate with also terminates my communications and security and by
so doing introduces a number of uncertainties potentially rather
arbitrary to what would otherwise be under my direct policy domain.

C


"Abraham Y. Chen"  writes:


Hi, Christian:

0)    Allow me following your "towers of babel world" metaphor to tell
a short story.

1)    In the ancient days, peasants labored under the shadow of the
Tower, following the rules of and paid tax to the Lord living in the
Tower. In return, they expected protection from the Lord against
harms. (Sometime ago, I read an archaeological article reporting
certain evidence that the Load somewhere in England during medieval
time might have been expected to protect his peasants from any harm,
including even paid his life for famine.)

2)    In the modern world, the peasants still live around the Tower
following the rules, paying taxes and expecting protection from the
Lord, now represented by the government agencies such as local police,
FCC, FTC, DoD, DHS, etc.

3)    In the Internet era, the peasants roam everywhere around the
cyberspace freely enjoying the Internet way. However, their wealth is
now being siphoned out to the invisible Lords (the multi-national
businesses with virtual presence in each and every Tower). However,
little can be expected in return when perpetrators attack, because no
Lord assumes the responsibility, nor any can be held responsible.

4)    EzIP proposes an overlay cyberspace with geographic flavor to
restore the society infrastructure back to Pt. 2) above, while
providing the daily services of Pt. 3). It essentially offers a
parallel Internet for the peasants who can again expect protection
from their local government who collects taxes, while without losing
the benefits of the digital revolution.

5)    The two cyberspaces are expected to coexist and none-interfering
to each other. Peasants have the freedom of choice by living in either
or try both then decide.

The above is just a quick rough thought, far from polished. It is
intended to be a preliminary framework so that we can hang some meat
on it for starting meaningful discussions.

Regards,


Abe (2022-04-01 14:17)






On 2022-03-27 11:03, Christian de Larrinaga wrote:

On 27 March 2022 15:53:25 Brandon Butterworth
wrote:


On Sun Mar 27, 2022 at 12:31:48AM -0400, Abraham Y. Chen wrote:

EzIP proposes to deploy 240/4
address based RANs, each tethering off the current Internet via
one IPv4
public address.

So each RAN has no possibility of redundant connections? Nobody
of scale would accept such a limitation. It also looks like an
opportunity for telcos/governments to partition their part
of the internet and impose whatever censorship they wish.


As such, the collection of RANs forms an overlay network
layer wrapping around the current Internet core. Consequently, only the
SPRs in the RAN need to be able to transport 240/4 addressed packets.

You previously described this as like connecting CG-NATs together via a
VPN. I don't see why we'd want to add maintaining a global VPN to
already difficult peering relationships. It could be used to exlude non
EzIP club members.


This is why we talk about enabling new (but based on existing design)
routers to use 240/4 netblock for serving as SPRs, but not perturbing
any routers in the current Internet.

As it's a CG-NAT variant why are you delaying yourself by requiring
new address space that will take a long time to become available? Why
not use the already allocated space for CG-NAT? Sure it's only a /10
but that's an already (probably too) large RAN.

It also seems unfeasibly optimistic that if the work was done globally
to make 240/4 useable that they'd want to dedicate it to the as yet
undeployed EzIP. You might stand more chance if you gained some
critical mass using the existing available 100.64/10 & rfc1918 space,
and then those that find they need more in one RAN will make the case
for 240/4 when it becomes necessary for them. Is 240/4 special to
EzIP such that alternative numbers may not be used?


I would like to share one intriguing graphics (see URL below) that
is almost perfect for depicting the EzIP deployment configuration.
Consider the blue sphere as the earth or the current Internet core and
the golden colored land as the RANs. By connecting each continent,
country or all the way down to a Region to the earth via one IPv4
address, we have the EzIP configuration. With this architecture, each
RAN looks like a private network.

That sounds an entirely undesirable goal for the internet.

brandon

It isn't the Internet. It's at best a very poorly connected spur gateway.

Too many today don't remember the towers of Babel world prior to the
Internet. If they did they'd understand that building on this type
of idea is like burying yourself And any customers so unwise to
get involved

C




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

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Abraham Y. Chen]

Hi, Pascal:

0)    As the good old saying stated: "A picture is worth one thousand 
words." Let's take advantage of such a teaching.


1)    Focusing at just the text before and after Figure 1 of your below 
draft, I found:


https://datatracker.ietf.org/doc/html/draft-thubert-v6ops-yada-yatt-01

    A.    " In the analogy of a building, */the ground floor would be 
the Interne/*t, and each additional floor would be */another IPv4 
realm/*.  ...  analog to */the full IPv4/**/addressing /*that is 
available in each realm.  ": Unless there is certain hidden refinement 
that I could not decipher, the combination of the three phrases 
highlighted above by me seems to refer to the entire IPv4 netblock, 
addresses and practices, etc., all inclusive. (By the way, the phrase 
"ground floor" appears to contradict the "(current IPv4 Internet)" label 
in the figure that is on the top floor (realm 1) of a building. Unless, 
you are presenting an underground building? But, we can regard this as a 
minor typo.)


    B.    " ... A single /24 IPv4 prefix assigned allows for*/> 250 
times the capacity of the Internet as we know it /*...   ": Are you 
visualizing that your YADA / YATT draft proposes creating >250 layers of 
cyberspace, each with the same capacity of the current Internet? If so, 
it will be fantastic. Then, how can you physically deploying that many 
layers, each fully covering the entire globe, yet without stepping on 
one another's toes (the identical IP addresses packed >250 deep)? That 
is, I failed to imagine what kind of mechanism that you have for 
isolating the layers, such as populating people accordingly.


Please clarify.

Regards,


Abe (2022-04-02 12:22 EDT)






On 2022-04-02 04:56, Pascal Thubert (pthubert) wrote:


That does not need to be long, Abe.

There’s no minimal interval between version. I already published 01… 
And I do not have a special address format beyond what’s in the draft 
already. It’s only IPv4 and IPv6. No new address format. Just assigned 
ranges, and well known IIDs.


To your point: the addresses in each realm are the full IPv4 that we 
know and they cannot talk directly between realms. They are indeed 
isolated. Nodes in different floors can only communicate through the 
shaft. Think of a human and a stairwell. The physical space reserved 
for the stair well at each level is the same.  What people do with the 
rest of the space is their own. All addresses and AS numbers are reusable.


I do not see you image of a sphere. My image of  a sphere is IPv6, 
that contains all the IPv4 “planes”, the shaft, and all the air in 
between.


You design uses the internet as shaft if you like. In that we differ. 
YADA leaves the internet as is, and allows to build other internets 
that cannot leak in one another. But participating nodes can 
communicate through the shaft.


If end nodes do not participate, then a stateful Nat is still needed. 
For most homes that means an upgrade of the stateful NAT in the 
gateway so the public side has a YATT format, and DNS snooping to 
provide a A record inside. Same for PLATs. For most servers, that 
means an update in the load balancer, and a NAT if there was none, to 
allow to speak to other realms. Whatever happened in the current IPv4 
can still do. Some levels can be created IPv6 only from the start, 
providing YATT addresses to those who need to communicate with the 
other levels.


Keep safe;

Pascal

*From:* Abraham Y. Chen 
*Sent:* vendredi 1 avril 2022 23:45
*To:* Pascal Thubert (pthubert) ; Vasilenko Eduard 
; Justin Streiner 

*Cc:* NANOG 
*Subject:* Re: Let's Focus on Moving Forward Re: V6 still not 
supported re: 202203261833.AYC


Hi, Pascal:

1)    " ... for the next version. ...   ":    I am not sure that I can 
wait for so long, because I am asking for the basics. The reason that 
I asked for an IP packet header example of your proposal is to 
visualize what do you mean by the model of "realms and shafts in a 
multi-level building". The presentation in the draft sounds okay, 
because the floors are physically isolated from one another. And, even 
the building is isolated from other buildings. This is pretty much how 
PBX numbering plan worked.


2)    When you extend each floor to use the whole IPv4 address pool, 
however, you are essential talking about covering the entire surface 
of the earth. Then, there is no isolated buildings with isolated 
floors to deploy your model anymore. There is only one spherical layer 
of physical earth surface for you to use as a realm, which is the 
current IPv4 deployment. How could you still have multiple full IPv4 
address sets deployed, yet not seeing their identical twins, triplets, 
etc.? Are you proposing multiple spherical layers of "realms", one on 
top of the other?


2)    When I cited the DotConnectAfrica graphic logo as a visual model 
for the EzIP deployment over current IPv4, I wa

Re: Let's Focus on Moving Forward Re: V6 still not supported

[Abraham Y. Chen]

Hi, Ant:

1)    " ...  darknet ...  ":    I am not aware of this terminology. 
Nonetheless, I believe that bringing in a not commonly known word into a 
discussion like this is just distraction tactic.


2)    " ...  progress ...  ":    EzIP proposes a parallel cyberspace to 
the current Internet which not only is none interfering to each other, 
but also promises to require bare minimum engineering efforts to deploy. 
This can settle the long debates on which way the Internet should go via 
true experiments. If this is not regarded as progress, I am not sure 
what qualifies so under your definition.



Regards,


Abe (2022-04-02 08:55)



On 2022-04-02 00:21, ant+nanog@antiphase.net wrote:

On 1 Apr 2022, at 11:17, Abraham Y. Chen wrote:


4)    EzIP proposes an overlay cyberspace with geographic flavor to restore the 
society infrastructure back to Pt. 2) above, while providing the daily services 
of Pt. 3). It essentially offers a parallel Internet for the peasants who can 
again expect protection from their local government who collects taxes, while 
without losing the benefits of the digital revolution.

So essentially a darknet whose implementation happens to be patent-encumbered 
by you. This doesn’t sound like progress to me.

Ant




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

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Abraham Y. Chen]

Hi, Pascal:

1)    " ... for the next version. ... ":    I am not sure that I can 
wait for so long, because I am asking for the basics. The reason that I 
asked for an IP packet header example of your proposal is to visualize 
what do you mean by the model of "realms and shafts in a multi-level 
building". The presentation in the draft  sounds okay, because the 
floors are physically isolated from one another. And, even the building 
is isolated from other buildings. This is pretty much how PBX numbering 
plan worked.


2)    When you extend each floor to use the whole IPv4 address pool, 
however, you are essential talking about covering the entire surface of 
the earth. Then, there is no isolated buildings with isolated floors to 
deploy your model anymore. There is only one spherical layer of physical 
earth surface for you to use as a realm, which is the current IPv4 
deployment. How could you still have multiple full IPv4 address sets 
deployed, yet not seeing their identical twins, triplets, etc.? Are you 
proposing multiple spherical layers of "realms", one on top of the other?


2)    When I cited the DotConnectAfrica graphic logo as a visual model 
for the EzIP deployment over current IPv4, I was pretty specific that 
each RAN was tethered from the current Internet core via one IPv4 
address. We were very careful about isolating the netblocks in terms of 
which one does what. In other words, even though the collection of RANs 
form a parallel cyberspace to the Internet, you may look at each RAN as 
an isolated balloon for others. So that each RAN can use up the entire 
240/4 netblock.


Please clarify your configuration.

Thanks,


Abe (2022-04-01 17:44)




On 2022-04-01 10:55, Abraham Y. Chen wrote:

On 2022-04-01 10:00, Pascal Thubert (pthubert) wrote:


Makes sense, Abe, for the next version.

Note that the intention is NOT any to ANY. A native IPv6 IoT device 
can only talk to another IPv6 device, where that other device may use 
a YATT address or any other IPv6 address.


But it cannot talk to a YADA node. That’s what I mean by baby steps 
for those who want to.


Keep safe;

Pascal

*From:* Abraham Y. Chen 
*Sent:* vendredi 1 avril 2022 15:49
*To:* Vasilenko Eduard ; Pascal Thubert 
(pthubert) ; Justin Streiner 

*Cc:* NANOG 
*Subject:* Re: Let's Focus on Moving Forward Re: V6 still not 
supported re: 202203261833.AYC


Hi, Pascal:

What I would appreciate is an IP packet header design/definition 
layout, word-by-word, ideally in bit-map style, of an explicit 
presentation of all IP addresses involved from one IoT in one realm 
to that in the second realm. This will provide a clearer picture of 
how the real world implementation may look like.


Thanks,

Abe (2022-04-01 09:48)

On 2022-04-01 08:49, Vasilenko Eduard wrote:

As I understand: “IPv4 Realms” between “Shaft” should be capable
to have a plain IPv4 header (or else why all of these).

Then Gateway in the Shaft should change headers (from IPv4 to IPv6).

Who should implement this gateway and why? He should be formally
appointed to such an exercise, right?

Map this 2 level hierarchy to the real world – you may fail with
this.

Ed/

*From:* Pascal Thubert (pthubert) [mailto:pthub...@cisco.com
<mailto:pthub...@cisco.com>]
*Sent:* Friday, April 1, 2022 3:41 PM
*To:* Vasilenko Eduard 
<mailto:vasilenko.edu...@huawei.com>; Justin Streiner
     <mailto:strein...@gmail.com>; Abraham Y.
Chen  <mailto:ayc...@avinta.com>
*Subject:* RE: Let's Focus on Moving Forward Re: V6 still not
supported re: 202203261833.AYC

Hello Eduard:

Did you just demonstrate that POPs cannot exist? Or that there
cannot be a Default Free Zone?

I agree with your real world issue that some things will have to
be planned between stake holders, and that it will not be easy.

But you know what the French say about “impossible”.

Or to paraphrase Sir Arthur, now that we have eliminated all the
impossible transition scenarios, whatever remains…

There will be YADA prefixes just like there are root DNS. To be
managed by different players as you point out. And all routable
within the same shaft.

Keep safe;

Pascal

*From:* Vasilenko Eduard 
*Sent:* vendredi 1 avril 2022 14:32
*To:* Pascal Thubert (pthubert) ; Justin
Streiner ; Abraham Y. Chen 
*Subject:* RE: Let's Focus on Moving Forward Re: V6 still not
supported re: 202203261833.AYC

Hi Pascal,

In general, your idea to create a hierarchy is good.

In practice, it would fail because you have created a virtual
hierarchy that does not map to any administrative border. Who
should implement gateways for the “Shaft”? Why?

If you would appoint Carrier as the Shaft responsible then it is
not enough bits for Shaft.

If you would appoint Governments as the Shaft responsible then
would be a so big sca

Re: Let's Focus on Moving Forward Re: V6 still not supported

[Abraham Y. Chen]

Hi, Christian:

0)    Allow me following your "towers of babel world" metaphor to tell a 
short story.


1)    In the ancient days, peasants labored under the shadow of the 
Tower, following the rules of and paid tax to the Lord living in the 
Tower. In return, they expected protection from the Lord against harms. 
(Sometime ago, I read an archaeological article reporting certain 
evidence that the Load somewhere in England during medieval time might 
have been expected to protect his peasants from any harm, including even 
paid his life for famine.)


2)    In the modern world, the peasants still live around the Tower 
following the rules, paying taxes and expecting protection from the 
Lord, now represented by the government agencies such as local police, 
FCC, FTC, DoD, DHS, etc.


3)    In the Internet era, the peasants roam everywhere around the 
cyberspace freely enjoying the Internet way. However, their wealth is 
now being siphoned out to the invisible Lords (the multi-national 
businesses with virtual presence in each and every Tower). However, 
little can be expected in return when perpetrators attack, because no 
Lord assumes the responsibility, nor any can be held responsible.


4)    EzIP proposes an overlay cyberspace with geographic flavor to 
restore the society infrastructure back to Pt. 2) above, while providing 
the daily services of Pt. 3). It essentially offers a parallel Internet 
for the peasants who can again expect protection from their local 
government who collects taxes, while without losing the benefits of the 
digital revolution.


5)    The two cyberspaces are expected to coexist and none-interfering 
to each other. Peasants have the freedom of choice by living in either 
or try both then decide.


The above is just a quick rough thought, far from polished. It is 
intended to be a preliminary framework so that we can hang some meat on 
it for starting meaningful discussions.


Regards,


Abe (2022-04-01 14:17)






On 2022-03-27 11:03, Christian de Larrinaga wrote:



On 27 March 2022 15:53:25 Brandon Butterworth  
wrote:



On Sun Mar 27, 2022 at 12:31:48AM -0400, Abraham Y. Chen wrote:

EzIP proposes to deploy 240/4
address based RANs, each tethering off the current Internet via one 
IPv4

public address.


So each RAN has no possibility of redundant connections? Nobody
of scale would accept such a limitation. It also looks like an
opportunity for telcos/governments to partition their part
of the internet and impose whatever censorship they wish.


As such, the collection of RANs forms an overlay network
layer wrapping around the current Internet core. Consequently, only the
SPRs in the RAN need to be able to transport 240/4 addressed packets.


You previously described this as like connecting CG-NATs together via a
VPN. I don't see why we'd want to add maintaining a global VPN to
already difficult peering relationships. It could be used to exlude non
EzIP club members.


This is why we talk about enabling new (but based on existing design)
routers to use 240/4 netblock for serving as SPRs, but not perturbing
any routers in the current Internet.


As it's a CG-NAT variant why are you delaying yourself by requiring
new address space that will take a long time to become available? Why
not use the already allocated space for CG-NAT? Sure it's only a /10
but that's an already (probably too) large RAN.

It also seems unfeasibly optimistic that if the work was done globally
to make 240/4 useable that they'd want to dedicate it to the as yet
undeployed EzIP. You might stand more chance if you gained some
critical mass using the existing available 100.64/10 & rfc1918 space,
and then those that find they need more in one RAN will make the case
for 240/4 when it becomes necessary for them. Is 240/4 special to
EzIP such that alternative numbers may not be used?


I would like to share one intriguing graphics (see URL below) that
is almost perfect for depicting the EzIP deployment configuration.
Consider the blue sphere as the earth or the current Internet core and
the golden colored land as the RANs. By connecting each continent,
country or all the way down to a Region to the earth via one IPv4
address, we have the EzIP configuration. With this architecture, each
RAN looks like a private network.


That sounds an entirely undesirable goal for the internet.

brandon


It isn't the Internet. It's at best a very poorly connected spur gateway.

Too many today don't remember the towers of Babel world prior to the 
Internet. If they did they'd understand that building on this type of 
idea is like burying yourself And any customers so unwise to get 
involved


C




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

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Abraham Y. Chen]

Hi, Pascal:

What I would appreciate is an IP packet header design/definition layout, 
word-by-word, ideally in bit-map style, of an explicit presentation of 
all IP addresses involved from one IoT in one realm to that in the 
second realm. This will provide a clearer picture of how the real world 
implementation may look like.


Thanks,


Abe (2022-04-01 09:48)


On 2022-04-01 08:49, Vasilenko Eduard wrote:


As I understand: “IPv4 Realms” between “Shaft” should be capable to 
have a plain IPv4 header (or else why all of these).


Then Gateway in the Shaft should change headers (from IPv4 to IPv6).

Who should implement this gateway and why? He should be formally 
appointed to such an exercise, right?


Map this 2 level hierarchy to the real world – you may fail with this.

Ed/

*From:* Pascal Thubert (pthubert) [mailto:pthub...@cisco.com]
*Sent:* Friday, April 1, 2022 3:41 PM
*To:* Vasilenko Eduard ; Justin Streiner 
; Abraham Y. Chen 
*Subject:* RE: Let's Focus on Moving Forward Re: V6 still not 
supported re: 202203261833.AYC


Hello Eduard:

Did you just demonstrate that POPs cannot exist? Or that there cannot 
be a Default Free Zone?


I agree with your real world issue that some things will have to be 
planned between stake holders, and that it will not be easy.


But you know what the French say about “impossible”.

Or to paraphrase Sir Arthur, now that we have eliminated all the 
impossible transition scenarios, whatever remains…


There will be YADA prefixes just like there are root DNS. To be 
managed by different players as you point out. And all routable within 
the same shaft.


Keep safe;

Pascal

*From:* Vasilenko Eduard 
*Sent:* vendredi 1 avril 2022 14:32
*To:* Pascal Thubert (pthubert) ; Justin Streiner 
; Abraham Y. Chen 
*Subject:* RE: Let's Focus on Moving Forward Re: V6 still not 
supported re: 202203261833.AYC


Hi Pascal,

In general, your idea to create a hierarchy is good.

In practice, it would fail because you have created a virtual 
hierarchy that does not map to any administrative border. Who should 
implement gateways for the “Shaft”? Why?


If you would appoint Carrier as the Shaft responsible then it is not 
enough bits for Shaft.


If you would appoint Governments as the Shaft responsible then would 
be a so big scandal that you would regret the proposal.


Hence, I do not see proper mapping for the hierarchy to make YADA 
successful.


Eduard

*From:* NANOG 
[mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org 
<mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org>] *On 
Behalf Of *Pascal Thubert (pthubert) via NANOG

*Sent:* Friday, April 1, 2022 2:26 PM
*To:* Justin Streiner ; Abraham Y. Chen 


*Cc:* NANOG 
*Subject:* RE: Let's Focus on Moving Forward Re: V6 still not 
supported re: 202203261833.AYC


For the sake of it, Justin, I just published 
https://datatracker.ietf.org/doc/draft-thubert-v6ops-yada-yatt/.


The first section of the draft (YADA) extends IPv4 range in an 
IPv4-only world. For some people that might be enough and I’m totally 
fine with that.


Keep safe;

Pascal

*From:* NANOG  *On Behalf 
Of *Justin Streiner

*Sent:* dimanche 27 mars 2022 18:12
*To:* Abraham Y. Chen 
*Cc:* NANOG 
*Subject:* Re: Let's Focus on Moving Forward Re: V6 still not 
supported re: 202203261833.AYC


Abe:

To your first point about denying that anyone is being stopped from 
working on IPv4, I'm referring to users being able to communicate via 
IPv4.  I have seen no evidence of that.


I'm not familiar with the process of submitting ideas to IETF, so I'll 
leave that for others who are more knowledgeable on that to speak up 
if they're so inclined.


Thank you

jms

On Sat, Mar 26, 2022 at 6:43 PM Abraham Y. Chen  wrote:

1)    "... no one is stopping anyone from working on IPv4 ... ":  
After all these discussions, are you still denying this basic
issue? For example, there has not been any straightforward way to
introduce IPv4 enhancement ideas to IETF since at least 2015. If
you know the way, please make it public. I am sure that many are
eager to learn about it. Thanks.




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

Re: V6 still not supported

[Abraham Y. Chen]

Hi, Owen:

The EzIP addresses (the 240/4 netblock) are proposed to be treated as 
"natural resources" without a price tag (or, "free") following the 
old-fashioned PSTN discipline, instead of "personal properties" for 
auction according to the current Internet way.


Regards,


Abe (2022-04-01 09:35)



On 2022-03-31 16:09, Owen DeLong via NANOG wrote:

On Mar 30, 2022, at 08:09 , Jared Brown  wrote:

Owen DeLong via NANOG wrote:

When your ISP starts charging $X/Month for legacy protocol support

Out of interest, how would this come about?

ISPs are facing ever growing costs to continue providing IPv4 services.

  Could you please be more specific about which costs you are referring to?

Costs of address acquisition
Costs of CGNAT systems in lieu of address acquisition costs
Costs of increasing support calls due to IPv4 life support measures in other 
networks.
etc.


  It's not like IP transit providers care if they deliver IPv4 or IPv6 bits to 
you.

True, but adding customers requires additional addresses at some point. IPv6 
addresses are cheap compared to IPv4 addresses.

Owen




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

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Abraham Y. Chen]

Dear Colleagues:

0)    I would like to summarize this thread of discussion with the 
following:


1)    It has been well-known in democracy that too much emphasis on 
"majority consensus" may not be really good for the intended goal. For 
example, if the general opinions in the ancient time prevailed and the 
objectors prosecuted, we probably are still living in a world of 
believing that the earth is flat and the sun rotates around the earth! 
Science and technology make advances due to a few stubborn and forward 
looking hard workers, not by popular wisdom.


2)    No one should be "defending" the decision of going to IPv6 three 
decades ago. There is no need to, because it was based on the best 
information and knowledge at that time. Now, after two decades of 
"experimenting", we have enough data to analyze and a lot of 
alternatives to review. There is nothing improper to revise the current 
Internet course that was set by engineers of at least two generations ago.


3)    It puzzles me deeply that the voices of the "Internet-way 
followers" these days have been so loud. What happened to the rebellion 
behaviors of restless young generations? Or, such voices come from those 
who made the choice three decades ago and refuse to update?


Regards,


Abe (2022-03-31 11:20)



On 2022-03-31 08:35, Vasilenko Eduard via NANOG wrote:

IMHO: IETF is only partially guilty. Who was capable to predict in 1992-1994 
that:

- Wireless would become so popular (WiFi is from 1997) and wireless would 
emulate multicast so badly (hi SLAAC)
- Hardware forwarding (PFE) would be invented (1997) that would have a big 
additional cost to implement Enhanced Headers
- Encryption would never have a small enough cost to make it mandatory
- Router would be available in every smallest thing that makes distributed 
address acquisition redundant (hi SLAAC)

We should be fair - it was not possible to guess.

Ed/
-Original Message-
From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] On 
Behalf Of Joe Maimon
Sent: Thursday, March 31, 2022 3:01 AM
To: Tom Beecher
Cc: NANOG
Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC



Tom Beecher wrote:

 If the IETF has really been unable to achieve consensus on properly
 supporting the currently still dominant internet protocol, that is
 seriously problematic and a huge process failure.


That is not an accurate statement.

The IETF has achieved consensus on this topic. It's explained here by
Brian Carpenter.

https://mailarchive.ietf.org/arch/msg/int-area/qWaHXBKT8BOx208SbwWILDX
yAUA/

As I have explained with my newly introduced consensus standards, there is no 
such consensus.

To reiterate my consensus standards, consensus is only to be considered as 
amongst stakeholders and IPv6 specific related stakes are not relevant to IPv4. 
If you consider the reverse to be true as well, I think my version of consensus 
would achieve a much wider and diverse consensus than the the stated IETF's 
consensus.

Once a consensus has been proven invalid its beyond obnoxious to cling to it as 
though it maintains its own reality field.


He expressly states with many +1s that if something IPv4 related needs
to get worked on , it will be worked on,

IPv4 still needs address exhaustion solutions.


but the consensus solution to V4 address exhaustion was IPng that
became IPv6, so that is considered a solved problem.

IPv6 is not a solution. Its a replacement that does not have the same problem. 
Which could be a solution to the problem, but only if the replacement happens 
on schedule. However, so long as the replacement hasnt happened, we still are 
dealing with the problem.

The IETF made a stupendously bad bet that IPv6 would happen in time.
That is the kind of bet that you better be right about. They were a
decade+ wrong. That they have the audacity and temerity to continue
doubling down on that would be funny if it wasnt so outrageous, wrong and 
harmful.

Let us re-examine the premise. When did it become acceptable to quash work on 
one protocol because of the existence of another one that is preferred by the 
quashers?

Or in other words, the way you are framing things makes it seem as if the IETF 
has with intent and malice chosen to extend or at the very least ignore 
exhaustion issues for actual internet users so as to rig the system for their 
preferred outcome.


Some folks don't LIKE the solution, as is their right to do.

I agree. I like most of IPv6 just fine. Not SLAAC, not multicast l2 resolution, 
not addressing policy, not the chaos of choice of inadequate interoperability 
approaches, not the denial of features desired by users, not the pmtud, not the 
fragmentation, and many other warts. I dont even like the notation schemes. 
They require multiple vision passes.

I do like the extra bits. Just not the way they are being frittered.

The real crux of the matter is that it did not work. Address exhaustion 

Re: PoE, Comcast Modems, and Service OutagesPyle

[Abraham Y. Chen]

Hi, Colleagues:

0)    I would like to share a personal experience of a different setting 
to offer an angle for looking into this puzzling topic.


1)    During my graduate study, I was doing microwave experiments in the 
laboratory. On a six foot bench, I had a series (maybe a dozen or so) of 
waveguide components (made of metal, either solid copper or silver 
plated) connected together as the test bed. With a half dozen or so 
equipment attached to them at various points to serve as the energy 
source or sink as well as detection instruments. The setup exhibited 
randomly and unpredictable behaviors. After awhile, my advisor brought 
up the topic of "Ground Loops" that could introduce the interference in 
mysterious manners. This is a phenomenon whereby minuscule electric 
current flowing along metallic parts (even though they may appear to 
have no "resistance" in between) that are connected to the system common 
potential reference (the "ground") via slightly different paths. These 
could be very small resistance path between two points or high 
resistance leakage source. The resultant electric potentials among the 
subsystems of interest could be significant enough to affect the outputs 
of sensitive instruments.


2)    After much cut-&-try, including plugging all instruments into the 
same electric extension strip with no avail, I finally floated the AC 
power cords of all instruments (using three-to-two prong adapters) but 
kept only the most sensitive node in the system connected to the AC 
power source "ground". Although this was against the electric safety 
code, I finally got consistent results. With clear record of the 
configuration, I even could take the waveguide setup apart and then 
reassembled days later to repeat the same results. Years later, I 
applied the same philosophy to a smart-meter PCB design which got a 
better precision than the chip manufacturer's demon board could.


3)    So, it is possible that the site with the reported "PoE induced" 
issues may be somehow experiencing the above related phenomena. This 
kind of situations are almost impossible to duplicate at another site. 
It has to be diagnosed with pains-taking detective efforts, such as 
inserting isolation subsystems suggested by one colleague. Since this 
phenomenon takes a month or so to show up, discipline and patience are 
the virtue.


4)    On the other hand, a product that can build up certain "memory" of 
the disturbances like the above and to the point of requiring periodical 
power cycling to flush clear the issue is definitely a sign of defect 
design, based on my old school training.


Regards,


Abe (2022-03-31 10:40)


On 2022-03-30 15:57, Joe Greco wrote:

On Wed, Mar 30, 2022 at 05:52:06PM +, Livingood, Jason wrote:

  Their crappy equipment needing rebooting every few weeks, not ridiculous.
Their purchasing gear from incompetent vendors who cannot be standards

 compliant for PoE PD negotiation, tragically plausible.

Many customers buy their own cable modem. You can lease an Xfinity
device as well and those function pretty nicely these days but YMMV.
But typically a device reboot is a way to quickly solve a few
different kinds of problems, which is why techs will often recommend
it as an initial step (you can generally assume that there's data
behind what occurs when any one of tens of thousands of support reps
suggesting something to a customer - support at scale is data-driven).

No one's doubting all of that -- support is best when data-driven, scale
or otherwise.  But that's actually the issue here.  There's no data that
I know of to suggest widespread PoE ghost current buildups, and, given
the audience here, no one else has popped up with a clear "me too".

PoE is typically negotiated by modern switches, 24v Unifi special
jobbies aside, so it's all DC on cables that are already handling
differential signalling.


He's got graphs showing it every 24 hours?  Liar, liar, pants on fire,

 lazy SOB is looking for an excuse to clear you off the line.

Could well be from noise ingress - lots of work goes into finding &
fixing ingress issues. Hard to say unless we look in detail at the
connection in question and the neighborhood node.

No doubt.  There's huge amounts of room for problems to be introduced
into last mile networks.  But, again, this isn't about general problems.
This is about a tech claiming it's due to PoE, and that he's seen it
often before.

I certainly have a lot of sympathy for cable techs, but that doesn't
mean I want to swallow any random garbage they want to blame issues on.
Please just tell me it's the chipmunks getting feisty and nibbling on
the copper if you want to feed me a line...

... JG




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

Re: Let's Focus on Moving Forward Re: V6 still not supported

[Abraham Y. Chen]

Hi, Brandon:

1)    "So each RAN has no possibility of redundant connections?  ..  
":    There is difference between "via one IPv4 public address" and 
"wide bandwidth or multiple channels". The former is called "numbering 
plan". The latter is part of "traffic engineering". The former defines 
the configuration / architecture of the latter, but not restricts its 
capability. One simple analogy is that a corporation headquarters 
publishes only one (representative) telephone number. But, everyone 
knows that there are multiple physical channels to carry the 
simultaneous conversations. So, we discuss about network architecture 
here. Then, the implementation engineering will take care of the details.


2)    " It also looks like an opportunity for telcos/governments to 
partition their part of the internet and impose whatever censorship they 
wish. ...  ":    The EzIP scheme provides an alternative to the current 
"Internet way" operation model and can operate in parallel while 
none-interfering to each other. There is no intention for EzIP to 
replace the current Internet. The hope is to let the two models operate 
in real time for the consumer to make the informed choice, as in a free 
market.


3)    " You previously described this as like connecting CG-NATs 
together via a VPN. ...   ":    I do not believe that I have ever 
mentioned VPN in any of our literature, nor correspondence. I would 
appreciate learning where did you find such a connection.


4)    " As it's a CG-NAT variant why are you delaying yourself by 
requiring new address space that will take a long time to become 
available?    ": As it has become evident recently through various 
posting, the 240/4 netblock has been used "behind-the-scene" by many 
projects without the explicit permission by ICANN. Since packets with 
240/4 addressing get dropped by existing routers, it actually makes the 
deployment of the new project easier. EzIP can be deployed in the same 
fashion as well. However, with the Unicast Extension Project became 
known, we would like to go along with their efforts to make the EzIP 
process more "Kosher".


5)    "... Why not use the already allocated space for CG-NAT? Sure it's 
only a /10 but that's an already (probably too) large RAN    ":    
The CG-NAT netblock of /10 is only one fourth of the largest private 
netblock 10/8. So, it is not big enough for the next level of challenge. 
Making use of the 240/4 netblock allows EzIP to serve a large enough 
geographical area, so that a true "Regional" Area Network characteristic 
may be achieved. A RAN can serve a population of upto 39M, even before 
employing the three conventional private netblocks. So, it is possible 
to experiment the wish of the "Country" networks idea proposed by ITU 
about one decade ago. Whether it is better or worse than the current 
Internet, EzIP provides a separate test bed for such, instead of verbal 
debates forever.


6)    " It also seems unfeasibly optimistic that if the work was done 
globally to make 240/4 useable that they'd want to dedicate it to the as 
yet undeployed EzIP. ...  ":    As have been hinted a couple times 
already on this forum, the ideal EzIP initial deployment beds are the 
existing CG-NAT modules. All we need to do is to enable the routers in a 
CG-NAT module to route 240/4 netblock and retire the 100.64/10 netblock. 
Since every customer premises can have a static 240/4 address, the DHCP 
process in the CG-NAT can fade out. The current communication between 
this CG-NAT with the Internet core remains unchanged. This process can 
be done gradually, one CG-NAT module at a time. No one outside of each 
of such tranistin will even notice something has happened. There is no 
need to do this globally in one shot, at all.


7)    "Is 240/4 special to EzIP such that alternative numbers may not be 
used?   " No, nothing is special here. The only reason that 240/4 is 
attractive is because it is big, continuous as well as being "Reserved 
for Future use" for so long. It is like a never-never land, fresh enough 
to do something really grand and for the long term.


8)    " That sounds an entirely undesirable goal for the internet.    
":    As I state above, EzIP offers a configuration for experimenting a 
(or more) parallel Internet(s). they will not interfere the current 
Internet, nor one another. So, what is your concern or reservation?


Regards,


Abe (2022-03-27 16:35)




On 2022-03-27 10:49, Brandon Butterworth wrote:

On Sun Mar 27, 2022 at 12:31:48AM -0400, Abraham Y. Chen wrote:

EzIP proposes to deploy 240/4
address based RANs, each tethering off the current Internet via one IPv4
public address.

So each RAN has no possibility of redundant connections? Nobody
of scale would accept such a limitation. It also looks like an
o

Re: Let's Focus on Moving Forward Re: V6 still not supported Re: 202203261748.AYC

[Abraham Y. Chen]

Hi, Randy:

1)    " ...  does not mean it is trivial to get it done on *billions* of 
device.  ... ":    It looks that your mind is focused on upgrading 
existing IoTs. They are not to be perturbed according to the initial and 
short term EzIP deployment plans, because it basically is following the 
existing CG-NAT network configuration and master / client service model. 
Many RGs (Residential / Routing Gateways) are already capable of being a 
240/4 DHCP client. (If not, commenting out one single line is likely all 
what is needed.). For the long term, it will be only those*/new/* IoTs 
desiring for end-to-end communication across RAN borders to have the 
ability of handling Option Words in the IP header.


2)    " ... Your refusal to follow simple mailing list etiquette ...  
":    Sorry for the inconvenience that I have caused. Honestly, I am 
still trying to figure out what is the "required" etiquette, since what 
I have received were mostly "complaints" not constructive "instructions" 
(i.e., how about a cheat sheet of what to do and what not to?). So, I 
have been adjusting my writing style. (My best guess of the issue is 
mostly likely due to the Subject line which according to my business 
correspondence training is my own choice. I am baffled by why does it 
cause problems on this mailing list.)


Regards,


Abe (2022-03-27 15:16)



On 2022-03-26 18:53, Randy Carpenter wrote:

- On Mar 26, 2022, at 6:16 PM, Abraham Y. chenayc...@avinta.com  wrote:


Hi, Tom & Paul:
1) " ... hand waved ... ": Through my line of work, I was trained to behave
exactly the opposite. I am surprised at you jumping to the conclusion, even
before challenging me about where did I get my viewpoint from. The fact is, it
has been clearly documented in our IETF draft for the last couple years (since
Rev-06 on 2019 Dec. 1)! For your convenience, please see below a copy of the
potential target code fragment and critique. It appears to me that our software
member suggested to comment out only one line (1047).

Just because it is trivial to make the modification in a single, specific 
firmware for one particular device sdoes not mean it is trivial to get it done 
on *billions* of device. Even if each one was as trivial as your example, it 
would still be ludicrously difficult.

Beyond that, I am still not understanding what you are actually trying to 
propose here. Your refusal to follow simple mailing list etiquette even after 
numerous requests makes it very difficult to decipher what you are saying.

-Randy




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

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Abraham Y. Chen]

Hi, Justin:

1)        "  denying that anyone is being stopped from */working on/* 
IPv4, I'm referring to users being able to */communicate via /*IPv4.    
": The two topics are quite different. It looks that we may have some 
language issues here. So, allow me to stop.


Regards,

Abe (2022-03-27 12:31)


On 2022-03-27 12:11, Justin Streiner wrote:

Abe:

To your first point about denying that anyone is being stopped from 
working on IPv4, I'm referring to users being able to communicate via 
IPv4.  I have seen no evidence of that.


I'm not familiar with the process of submitting ideas to IETF, so I'll 
leave that for others who are more knowledgeable on that to speak up 
if they're so inclined.


Thank you
jms

On Sat, Mar 26, 2022 at 6:43 PM Abraham Y. Chen  wrote:


1)    "... no one is stopping anyone from working on IPv4 ...    
":   After all these discussions, are you still denying this basic
issue? For example, there has not been any straightforward way to
introduce IPv4 enhancement ideas to IETF since at least 2015. If
you know the way, please make it public. I am sure that many are
eager to learn about it. Thanks.




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

Re: Let's Focus on Moving Forward Re: V6 still not supported

[Abraham Y. Chen]

Dear John:

0)    Appreciate very much for your comments.

1)    "A traceroute from my machine to 240.1.2.3 goes through six 
routers at my ISP before stopping (probably at the first 
default-route-free router).   ":    Great, this confirms our experience. 
While our team's skill is far inferior than yours, we did use Xubuntu 
based PCs to send TraceRoute packets with 240/4 addresses into the 
Internet and got records indicating that they had traveled through at 
least a couple routers into Verizon's network a few years ago. Those 
observations kept us going, even though all we heard from the Internet 
community was "240/4 could not and should not be used".


2)    "  What I do understand is that since his effort uses 240/4 
addresses as the outer addresses in IPv4 packets, it couldn't work 
without reaching our goal first:    ":     Exactly, We are in sync. I am 
glad that your team is doing the ground work of enabling 240/4 for 
unicast. EzIP is a specific application of such a capability as a 
private netblock. Yet, due to its size, it is possible to consider a 
global deployment configuration.


3)    " ...  I don't fully understand. ... allowing any site on the 
Internet to send unicast packets to or from 240.0.0.1 and having them 
arrive. ":    Sorry that I have not made our presentation clear enough, 
thus misled you to this uncertainty. EzIP proposes to deploy 240/4 
address based RANs, each tethering off the current Internet via one IPv4 
public address. As such, the collection of RANs forms an overlay network 
layer wrapping around the current Internet core. Consequently, only the 
SPRs in the RAN need to be able to transport 240/4 addressed packets. 
This is why we talk about enabling new (but based on existing design) 
routers to use 240/4 netblock for serving as SPRs, but not perturbing 
any routers in the current Internet.


4)    I would like to share one intriguing graphics (see URL below) that 
is almost perfect for depicting the EzIP deployment configuration. 
Consider the blue sphere as the earth or the current Internet core and 
the golden colored land as the RANs. By connecting each continent, 
country or all the way down to a Region to the earth via one IPv4 
address, we have the EzIP configuration. With this architecture, each 
RAN looks like a private network. Thus, everything proposed by EzIP can 
be done in the RANs, independent of the current Internet.


https://dotconnectafrica.org/icann-wins-by-technical-knockout-dca-blocked-from-being-heard-on-its-merit/

I do realize that the EzIP concept is rather unorthodox, making it 
difficult to visualize at a glance. Hope this clarifies the overall 
picture a bit.



Regards,



Abe (2022-03-27 00:31)



On 2022-03-26 21:42, John Gilmore wrote:

Tom Beecher  wrote:

*/writing/* and */deploying/* the code that will allow the use of 240/4 the
way you expect

While Mr. Chen may have considered that, he has repeatedly hand waved that
it's 'not that big a deal.', so I don't think he adequately grasps the
scale of that challenge.

>From multiple years of patching and testing, the IPv4 Unicast Extensions
Project knows that 240/4 ALREADY WORKS in a large fraction of the
Internet.  Including all the Linux servers and desktops, all the Android
phones and tablets, all the MacOS machines, all the iOS phones, many of
the home wifi gateways.  All the Ethernet switches.  And some less
popular stuff like routers from Cisco, Juniper, and OpenWRT.  Most of
these started working A DECADE AGO.  If others grasp the scale of the
challenge better than we do, I'm happy to learn from them.

A traceroute from my machine to 240.1.2.3 goes through six routers at my
ISP before stopping (probably at the first default-route-free router).

Today Google is documenting to its cloud customers that they should use
240/4 for internal networks.  (Read draft-schoen-intarea-unicast-240 for
the citation.)  We have received inquiries from two other huge Internet
companies, which are investigating or already using 240/4 as private
IPv4 address space.

In short, we are actually making it work, and writing a spec for what
already works.  Our detractors are arguing: not that it doesn't work,
but that we should instead seek to accomplish somebody else's goals.

John

PS: Mr. Abraham Chen's effort is not related to ours.  Our drafts are
agnostic about what 240/4 should be used for after we enable it as
ordinary unicast.  His EzIP overlay network effort is one that I don't
fully understand.  What I do understand is that since his effort uses
240/4 addresses as the outer addresses in IPv4 packets, it couldn't work
without reaching our goal first: allowing any site on the Internet to
send unicast packets to or from 240.0.0.1 and having them arrive.




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

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Abraham Y. Chen]

Hi, Justin:

1)    "... no one is stopping anyone from working on IPv4 ...     ":   
After all these discussions, are you still denying this basic issue? For 
example, there has not been any straightforward way to introduce IPv4 
enhancement ideas to IETF since at least 2015. If you know the way, 
please make it public. I am sure that many are eager to learn about it. 
Thanks.


Regards,


Abe (2022-03-26 18:42)




On 2022-03-26 11:20, Justin Streiner wrote:
While the Internet is intended to allow the free exchange of 
information, the means of getting that information from place to place 
is and has to be defined by protocols that are implemented in a 
consistent manner (see: BGP, among many other examples).  It's 
important to separate the ideas from the plumbing.


That said, no one is stopping anyone from working on IPv4, so what 
personal freedoms are being impacted by working toward deploying IPv6, 
with an eye toward sunsetting IPv4 in the future?


Keep in mind that IPv4 started out as an experiment that found its way 
into wider use.  It's a classic case of a test deployment that 
suddenly mutated into a production service. Why should we continue to 
expend effort to perpetuate the sins of the past, rather work toward 
getting v6 into wider use?


Is IPv6 a perfect protocol?  Absolutely not, but it addresses the key 
pain point of IPv4 - address space exhaustion.


Thank you
jms

On Sat, Mar 26, 2022 at 9:35 AM Abraham Y. Chen  wrote:


3)    Re: Ur. Pts. 5) & 6):    I believe that there is a
philosophic / logic baseline that we need to sort out, first. That
is, we must keep in mind that the Internet community strongly
promotes "*/personal freedom/*". Assuming that by stopping others
from working on IPv4 will shift their energy to IPv6 is totally
contradicting such a principle. A project attracts contributors by
its own merits, not by relying on artificial barriers to the
competitions. Based on my best understanding, IPv6 failed right
after the decision of "not emphasizing the backward compatibility
with IPv4". It broke one of the golden rules in the system
engineering discipline. After nearly three decades, still evading
such fact, but defusing IPv6 issues by various tactics is the real
impedance to progress, not only to IPv4 but also to IPv6.



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




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

Re: Let's Focus on Moving Forward Re: V6 still not supported Re: 202203261748.AYC

[Abraham Y. Chen]

Hi, Tom & Paul:

1)    " ... hand waved ...  ":    Through my line of work, I was trained 
to behave exactly the opposite. I am surprised at you jumping to the 
conclusion, even before challenging me about where did I get my 
viewpoint from. The fact is, it has been clearly documented in our IETF 
draft for the last couple years (since Rev-06 on 2019 Dec. 1)! For your 
convenience, please see below a copy of the potential target code 
fragment and critique. It appears to me that our software member 
suggested to comment out only one line (1047).



Regards,



Abe (2022-03-26 18:16)




D.1 
<https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space#appendix-D.1>. 
Candidate Code for Modification


   The following short JavaScript function named "ifip" in the TP-Link
   Archer C20 V4 source code has been shown to selectively reject
   specific ranges of IP addresses. In particular, Line 1047 uses a "2's
   Complement" technique to identify the 240/4 netblock as "PRESERVED",
   thus rejecting it. A quick scan of the firmware code in the router
   indicates that this function is a popular utility because there are
   numerous processes calling for it. So, this should be the best
   candidate to start testing our concept.

   lib.js:1040:ifip: function(ip, unalert) {
   lib.js-1041-if ((ip = $.ip2num(ip)) === false) return $.alert(ERR_IP_FORMAT, 
unalert);
   lib.js-1042-if (ip == -1) return $.alert(ERR_IP_BROADCAST, unalert);
   lib.js-1043-var net = ip >> 24;
   lib.js-1044-if (net == 0) return $.alert(ERR_IP_SUBNETA_NET_0, unalert);
   lib.js-1045-if (net == 127) return $.alert(ERR_IP_LOOPBACK, unalert);
   lib.js-1046-if (net >= -32 && net < -16) return $.alert(ERR_IP_MULTICAST, 
unalert);
   lib.js-1047-if (net >= -16 && net < 0) return $.alert(ERR_IP_PRESERVED, 
unalert);
   lib.js-1048-return 0;
   lib.js-1049-},

D.2 
<https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space-10#appendix-D.2>. 
Proposed Modification


   To stop rejecting the 240/4 netblock addressed packets, below is a
   modification that comments out Line 1047, a modification that has
   been shown to eliminate javascript pre-validation of 240/4 IP
   addresses, allowing them to be sent within the router, where a second
   layer of validation rejects them in a different way.

   lib.js:1040:   ifip: function(ip, unalert) {
   lib.js-1041- if ((ip = $.ip2num(ip)) === false) return 
$.alert(ERR_IP_FORMAT, unalert);
   lib.js-1042- if (ip == -1) return $.alert(ERR_IP_BROADCAST, unalert);
   lib.js-1043-   var net = ip >> 24;
   lib.js-1044- if (net == 0) return $.alert(ERR_IP_SUBNETA_NET_0, unalert);
   lib.js-1045- if (net == 127) return $.alert(ERR_IP_LOOPBACK, unalert);
   lib.js-1046- if (net >= -32 && net < -16) return $.alert(ERR_IP_MULTICAST, 
unalert);
   lib.js-1047- //if (net >= -16 && net < 0) return $.alert(ERR_IP_PRESERVED, 
unalert);
   lib.js-1048- return 0;
   lib.js-1049-},







On 2022-03-26 12:37, Tom Beecher wrote:


Have you ever considered that this may be in fact:

*/writing/* and */deploying/* the code that will allow the use of
240/4 the
way you expect


While Mr. Chen may have considered that, he has repeatedly hand waved 
that it's 'not that big a deal.', so I don't think he 
adequately grasps the scale of that challenge.


On Sat, Mar 26, 2022 at 9:53 AM Paul Rolland  wrote:

Hello,

On Sat, 26 Mar 2022 09:35:30 -0400
"Abraham Y. Chen"  wrote:

> touching the hardware, by implementing the EzIP technique
(*/disabling/*
> the program code that has been */disabling/* the use of the 240/4
> netblock), an existing CG-NAT module becomes a RAN! As to universal

Have you ever considered that this may be in fact:

*/writing/* and */deploying/* the code that will allow the use of
240/4 the
way you expect


Paul




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

Re: Let's Focus on Moving Forward Re: V6 still not supported Re: 20220326125.AYC

[Abraham Y. Chen]

Hi, Paul:

1)    " ...  may be in fact: /writing/* and */deploying/* the code  ... 
":    Having no idea why and how the 240/4 netblock became so 
mysteriously kept away from being used while the IPv4 was officially 
already on its way to "Sun Set", we started the conventional approach as 
you stated. It was quite frustrating since we did not have the 
background in networking software. One day, we came across a short 
program code fragment that did the function of /*disabling*/ 240/4 
addressed IP packets. It is the "there exists an example" moment for us, 
like proofing a mathematics theorem. After all, there was no magic 
separating 240/4 from the rest of the IPv4 address pool to start with. 
It cleared our mind about this particular task. Now, we only cite this 
reference to challenge those software engineers who may state that using 
the 240/4 in their code is a lot more involved.    Q.E.D.  


Regards,


Abe (2022-03-26 12:37 EDT)




On 2022-03-26 09:52, Paul Rolland wrote:

Hello,

On Sat, 26 Mar 2022 09:35:30 -0400
"Abraham Y. Chen"  wrote:


touching the hardware, by implementing the EzIP technique (*/disabling/*
the program code that has been */disabling/* the use of the 240/4
netblock), an existing CG-NAT module becomes a RAN! As to universal

Have you ever considered that this may be in fact:

*/writing/* and */deploying/* the code that will allow the use of 240/4 the
way you expect


Paul




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

Re: Let's Focus on Moving Forward Re: V6 still not supported

[Abraham Y. Chen]

Hi, Owen:

0)    Re: Ur. Pt. 2): This topic is such a tongue-twister. Let's put it 
aside for now, until I can properly convey the EzIP concept and scheme 
to you.


00)    Re: Ur. Pt. 4):    Okay, I was concerned about how to decipher 
this cryptic exchange. So let's put it aside as well.


1)    Re: Ur. Pt. 1): Yes, you are correct that the EzIP network 
architecture looks like that of CG-NAT. In fact, it is exactly the same. 
This is actually the beauty of the EzIP solution. That is, without 
touching the hardware, by implementing the EzIP technique (*/disabling/* 
the program code that has been */disabling/* the use of the 240/4 
netblock), an existing CG-NAT module becomes a RAN! As to universal 
peer-to-peer, where is any of such today? On the other hand, upon fully 
implemented the EzIP proposal (the second phase: making use of the 
Option Word in RFC791), an IoT in one RAN can directly reach a second 
IoT in another RAN world-wide. So that the original promise of the 
Internet will be finally fulfilled and for the long haul.


2)    Re: Ur. Pt. 3): Similarly, you probably only recognized the part 
that EzIP proposes to classify the 240/4 netblock as the fourth private 
address in RFC1918, but overlooked that such capacity will enable a RAN 
to cover a geographic area as big as Tokyo Metro, or 75% of smaller 
countries around the world, even before utilizing the conventional three 
private netblocks. This puts 240/4 into a different league from the 
other three conventional private netblocks, although all four have 
basically the same technical characteristics. Now, visualizing each RAN 
is tethered from the existing Internet core by one umbilical cord (one 
IPv4 address), it appears like a private network. So that each RAN can 
provide Internet services by utilizing existing technologies, while 
avoiding those undesired. Combining these RANs around the world, an 
*/overlay/* layer of routers (SPRs) can operate in parallel to the 
current Internet. Under such a configuration, the latter no long is 
involved with daily local activities, but only carries inter-RAN 
traffic, very much like the division between national and international 
telephone networks. This creates quite a different operation landscape. 
Please have a look at slide # 11 of the below whitepaper for a rough 
breakdown of the available addresses under the EzIP scheme. Furthermore, 
if used diligently, (treating IP address as "*/natural resources/*" 
instead of "*/personal properties/*"), the assignable "EzIP addresses" 
can last quite awhile.


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

3)    Re: Ur. Pts. 5) & 6):    I believe that there is a philosophic / 
logic baseline that we need to sort out, first. That is, we must keep in 
mind that the Internet community strongly promotes "*/personal 
freedom/*". Assuming that by stopping others from working on IPv4 will 
shift their energy to IPv6 is totally contradicting such a principle. A 
project attracts contributors by its own merits, not by relying on 
artificial barriers to the competitions. Based on my best understanding, 
IPv6 failed right after the decision of "not emphasizing the backward 
compatibility with IPv4". It broke one of the golden rules in the system 
engineering discipline. After nearly three decades, still evading such 
fact, but defusing IPv6 issues by various tactics is the real impedance 
to progress, not only to IPv4 but also to IPv6.


Regards,


Abe (2022-03-26 09:35 EDT)



On 2022-03-25 22:17, Owen DeLong wrote:




On Mar 25, 2022, at 18:47 , Abraham Y. Chen  wrote:

**  Resend to go through NANOG **


On 2022-03-25 12:24, Abraham Y. Chen wrote:

Dear Owen:

0) You rapid fired a few posts in succession yesterday. Some are 
interesting and crucial views that I would like to follow-up on. I 
will start from quoting the earlier ones. I hope that I am picking 
up the correct leads.


1) " ... 240/4 is way more effort than its proponents want to 
believe and even if it were reclassified effectively as GUA, it 
doesn’t buy all that much life for IPv4. ...   ":     Perhaps you 
have not bothered to scan through a two page whitepaper (URL below, 
again) that I submitted a week or so ago? It promises simple 
implementation and significant increase of assignable IPv4 
addresses, even extendable to the similar size of IPv6 if we could 
forgo our mentality about the IP addresses as "Personal Properties", 
by switching to treat them as "Natural Resources".


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


It still looks like NAT to me.

NAT is a disgusting hack and destroys the universal peer to peer 
nature of the internet in favor of a consumer/provider model.


Your proposal perpetuates that problem.

2) " ...  so that content providers can start turning off v4 where 
it’s costing them money to support it.    "

Re: V6 still not supported Re: 202203231017.AYC

[Abraham Y. Chen]

*** Resend to go through NANOG 


On 2022-03-23 11:59, Abraham Y. Chen wrote:

Dear Pascal:

0)    So glad to see your recount of the history and the analysis!

1)    We have recently formulated a proposal called EzIP (Phonetic for 
Easy IPv4) that is very much along the line of what you just described 
below, but with a few twists. I browsed through US patent 7,356,031, 
but failed to spot the key word "240. It appears to me that it was 
more a general concept than practice. Did you submit a draft on your 
work to IETF? Perhaps due to these, our (including patent examiner's) 
prior art search never came across your work. Although, your patent 
was granted in the same year as the Normative Reference [2] of our 
IETF draft. Please have a quick read of the below whitepaper. It 
provides you an overview of EzIP as well as references to US Pat. 
No.11,159,425, the current IETF draft and a feasibility demonstration 
setup.


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

2)    Here is a few quick comparisons between our two teams' work and 
the outline of EzIP benefits:


    A.    Your "Realm" is very much equivalent to our RAN (Regional 
Area Network). However, instead of utilizing 240.0.0/8, we propose to 
use the full 240/4 each to maximize its effectiveness. Each RAN can 
serve up to 39M population as large as Tokyo Metro, even before 
utilizing the three private netblocks.


    B.    Your "Elevator Shaft" making use of part of the 240/4 pool 
is equivalent to our single IPv4 public address to tether a RAN from 
the Internet core. Ours is a "micro" building block approach that 
provides more flexibility. For example, up to 75% of the smaller 
countries around the world need only one IPv4 each to achieve the 
"Elevator Shaft" configuration.
    C.    Your "Inter-Realm Router" is simply the current Internet 
core routers in the EzIP scheme.


    D.   Instead of proposing any modification to the IP packet 
header, EzIP can deploy within the capability of the RFC791. That is, 
when inter-RAN traffic is needed, the Option Word mechanism is 
activated to carry the 240/4 addresses within the RAN, leaving the 
basic source and destination address fields to carry the public IPv4 
addresses of the RANs at either end.


    E.    EzIP implementation is very straightforward. We have 
identified at least one case that only requires "*/disabling/* the 
program code that has been */disabling/* the use of the 240/4 
netblock". With your software expertise, you likely know other 
configurations.


    F.    EzIP essentially proposes to expand the address pool 
currently used by CG-NAT without any hardware change. In addition, the 
simplification in administrating the 240/4 addresses deterministically 
can mitigate the root cause to the cyber insecurity, thus reducing the 
OpEx.


    G.    Treating 240/4 as the fourth netblock in RFC1918 allows the 
RAN to operate pretty much independent of the Internet core. On the 
other hand, being rejected by current routers enables RANs to be 
deployed worldwide by themselves without interference in either 
direction. This forms an */overlay /*network providing Internet-like 
services while having individualized flexibility per RAN.


    H.    As more and more RANs are deployed, there will be increasing 
number of IPv4 public addresses becoming "spares". Each can support 
one RAN to serve other purposes, such as true test beds for 
experimenting new protocols.


    I.    There probably are a few more parallelisms that we can 
identify, as we discuss more.


I look forward to your thoughts and critiques.

Regards,


Abe (2022-03-23 11:59 EDT)



On 2022-03-23 05:01, Pascal Thubert (pthubert) via NANOG wrote:

I see the same thing from the other side, being a S/W developer for switching 
and routing boxes since the early 90's. The PM barrier is a high wall indeed. 
And yet some techs succeed to pass it. What I'm arguing is that we can pass 
that wall if we work together with the same objective.

I've been monitoring this list for a while, very insightful, very happy with 
what I learn in the process. But here I feel compelled to react. I read that 
IPv6 did not succeed in 25 years. But unless I miss something, complaining did 
not succeed either, did it?

My frustration is that indeed (as a dev guy) we have been trying hard to serve users our 
best. We proposed a number of things in the IPv4 evolution direction that I see being 
asked on this list. For larger IPv4 space and smooth migration, I'm personally fond of 
the IP-in-IP variation that filed in 20+ years ago as US patent 7,356,031. Basically we 
reserve a /8, say, since it is so popular at this time, 240.0.0./8, and make it the 
"elevator shaft" between IPv4 realms. Say the current IPv4 Internet is realm 1, 
that Internet would have IP address 240.0.0.1/8 in the shaft, and would continue 
operating as is, w

Re: V6 still not supported R: 202203232156.AYC

[Abraham Y. Chen]

** Resend to go through NANOG ***


On 2022-03-23 23:11, Abraham Y. Chen wrote:

Dear Pascal:

1)    "   Did you propose this work at a WG in Vienna this week?  
":    No, but I was invited to be a coauthor of a HuaWei study 
comparing addressing schemes that was presented there. See material 
attached.


2)    " I coined the term elevator shaft for the description 
below  , but the lawyer language is hard to parse for the rest of 
us so I paraphrased and exemplified. ... ":    Well, the lawyer got 
paid for his legalese. But, I doubt the essence of your patent. (See 
more thoughts below.)


3)    ".. And I just picked 240.0.0.0/8 as an example ...    ":    
This is not the way to link up with another Intellectual Property 
work. You need to present your implementation, before paraphrasing to 
others. Otherwise, it is more than misleading.


4)    " Now that you’re aware of the possible prior art ...   ":    
Not too fast! As I stated, neither myself nor the patent examiner of 
my case found your work. And, I characterize your claim as "more a 
general /*concept*/*//*than practice." So, if the examiner did pick up 
your patent, he probably decided to disregard it. What you need to 
understand is that the basic criterion for granting a patent is:


    "The */first/* party who has the */original idea/* that has been 
reduced to */practice/**//*for teaching the general public."


    I do not believe that yours could pass such a simple test, not to 
mention that the proposed header changes were so extensive compared to 
EzIP's simple no-change approach (using  only the old-fashioned RFC791).


    Note: There was a historical issue about what qualified an 
Internet related work for a patent (at least in US) around the turn of 
this century. The most famous one was the "one-click purchase" scheme 
by Amazon. Yours appear to be close to the other end of the extreme, 
because fourteen years later (the patent life of seventeen years is 
almost over) you are still paraphrasing, without a working model to 
show. I do not want to burden colleagues on this List with the 
details. If you want, I can give you a run-down offline.


5)    " I guess we need to continue that discussion on an IETF ML 
rather than here,   ": Let me know where you feel is more appropriate, 
after you have reviewed the above.


Regards,


Abe (2022-03-23 23:10 EDT)



On 2022-03-23 12:47, Pascal Thubert (pthubert) wrote:


Dear Abe:

Neat  Did you propose this work at a WG in Vienna this week?

Just a few points:

* I coined the term elevator shaft for the description below. I just 
thought that it may help visualize this story; figuring the Internet 
as a 2-D flat in a building, and the special prefix bring a 3^rd 
dimension to interconnect levels as an elevator shaft does in the 
building. The 20 year old IPR did not use that term or that example, 
it was more generic than that, but the lawyer language is hard to 
parse for the rest of us so I paraphrased and exemplified.


* And I just picked 240.0.0.0/8 as an example to show that you can 
easily build 100 parallel Internets because it was discussed in 
another thread that would provide a lot less value off it, which may 
hint that the way we use that prefix should be thought carefully.


* Now that you’re aware of the possible prior art, I believe you are 
required by law to notify the USPTO so they determine what to do with 
the reference. Sorry for the hassle.


* I guess we need to continue that discussion on an IETF ML rather 
than here, unless people in the list ask for more. I’ll read with 
interest the details of your proposal.


The bottom line for NANOG is that the dev guys are willing to help, 
whether by evolving IPv6 or proposing IPv4 ideas like the ones below. 
But we need push / support from your side to pass the PM bar.


Keep safe;

Pascal

*From:* Abraham Y. Chen 
*Sent:* mercredi 23 mars 2022 16:59
*To:* Pascal Thubert (pthubert) 
*Cc:* Michael Thomas ; nanog@nanog.org
*Subject:* Re: V6 still not supported Re: 202203231017.AYC

Dear Pascal:

0)    So glad to see your recount of the history and the analysis!

1)    We have recently formulated a proposal called EzIP (Phonetic 
for Easy IPv4) that is very much along the line of what you just 
described below, but with a few twists. I browsed through US patent 
7,356,031, but failed to spot the key word "240. It appears to me 
that it was more a general concept than practice. Did you submit a 
draft on your work to IETF? Perhaps due to these, our (including 
patent examiner's) prior art search never came across your work. 
Although, your patent was granted in the same year as the Normative 
Reference [2] of our IETF draft. Please have a quick read of the 
below whitepaper. It provides you an overview of EzIP as well as 
references to US Pat. No.11,159,425, the current IETFdraft and a 
feasibility demonstration setu