RE: V6 still not supported Re: 202203231017.AYC

["Pascal Thubert \(pthubert\) via NANOG" <nanog () nanog org>]

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 3rd 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 1000000 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 <aychen () avinta com>
Sent: mercredi 23 mars 2022 16:59
To: Pascal Thubert (pthubert) <pthubert () cisco com>
Cc: Michael Thomas <mike () mtcc com>; 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 
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, without a change in hosts and routers for traffic staying inside the current Internet. Now say China 
builds realm 2; that Internet would have IP address 240.0.0.2/8 in the shaft. A host in the Internet that wants to talk 
to a host in China would require an update to parse new DNS double-A (realm, address) records to encapsulate the packet 
IP-in-IP, outer src= 240.0.0.1 outer dest=240.0.0.2. The router that serves the shaft at level 1 attracts 240.0.0.0/8 
within realm 1 and routes up the elevator for more specific (host) routes within that prefix. The router that serves 
the shaft at level 2 attracts 240.0.0.2/32 inside the shaft; upon the said packet it would swap the inner and outer 
destination and the packet would reach the Chinese address with classical routing within realm 2. Routers serving the 
shaft need an update, but then, only those do. Obviously the host in China can only reply if its stack is updated to 
understand the format. But all the other hosts and routers in China can be classical IPv4 as we know them long as their 
traffic stays in China. To migrate to IPv6 what you can do is map the elevator shaft prefix in, say, 400::/3 (sadly 
cannot use F00/3 that would map 240 neatly but is already assigned). The current internet would own 400:1::/32, China 
would own 400:2::/32, etc... You encode the double-A of the host in the prefix, reserve a well known suffix for IPv4 
mapped double-A, and you have an IPv6 address that can be mapped both ways statelessly. When migrating to v6, each IPv4 
node that owns a public IPv4 address in one realm gets a full IPv6 /64 for free.



This kind of ideas have existed for long but apparently did not meet their public.



So we tried evolving IPv6 instead. And we did. I've witnessed deep evolution in networking technology with, e.g., IoT 
and SRv6. I've seen both being despised on this list and I'm not asking for more fuel on that fire. I just want to use 
these techs as a proof that evolution is indeed possible, that it happens in the context of IPv6, and that done in your 
direction it could make some folks happier than the current state of affairs. On the side, since I see the name, please 
consider that Cisco ships both techs above, so it is indeed capable of risk taking, the PM wall can indeed be passed, 
as long as there's enough pressure from both side.



For those interested, I'd be happy to chat on how IPv6 ND has evolved (on paper) but is stuck behind the PM wall as 
well.



Keep safe;



Pascal



Message-----

From: NANOG <nanog-bounces+pthubert=cisco.com () nanog org><mailto:nanog-bounces+pthubert=cisco.com () nanog org> On 
Behalf Of

Michael Thomas

Sent: mardi 22 mars 2022 22:37

To: nanog () nanog org<mailto:nanog () nanog org>

Subject: Re: V6 still not supported





On 3/22/22 5:45 AM, Randy Bush wrote:

john,



fwiw your story matches what is left of my memory.  one nuance



That’s not to say that there wasn’t "IETF politics” involved, but

rather that such politics were expressed as enormous pressure to

“make a decision”

my take was that cidr had done a lot to relieve the immediate

technical pressure for the short term; but there was a deep fear that

the industry press was stirring a major poolpah about the end of the

internet due to

ipv4 exhaustion.  i.e. a seriously flawed technical compromise was

pushed on us in reaction to a perception of bad press.



i have learned that, when i am under great pressure to DO SOMETHING,

it's time to step back, go make a cup of tea, and think.  the ietf did

not.  and here we are, a quarter of a century later, still trying to

clean up the mess.



So are you saying that an ipng that came out in, say, 2000 which was

according to you was vastly superior having taken the time to get it

right would have had any better chance of being adopted? My experience

with Cisco product managers at the time is that they couldn't give a

shit about the technical aspects of an ipng. If their silicon forwarding

couldn't handle it, they weren't interested unless customers were

clamoring for it. I can't see how that negative feedback loop could have

ever been prevented other than other ipng being done in, oh say, 1993

when it was all still software forwarding.



Mike



[Image removed by 
sender.]<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon>
Virus-free. 
www.avast.com<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link>