<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix"><font size="4">Dear Pascal:</font></div>
<div class="moz-cite-prefix"><font size="4"><br>
</font></div>
<div class="moz-cite-prefix"><font size="4">0) So glad to see
your recount of the history and the analysis!<br>
</font></div>
<div class="moz-cite-prefix"><font size="4"><br>
</font></div>
<div class="moz-cite-prefix"><font size="4">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.<span style="left:
455.2px; top: 552.999px; font-size: 23.2px; transform:
scaleX(1.00766);" role="presentation" dir="ltr"> 11,159,425,
the current IETF</span> draft and a feasibility demonstration
setup. </font></div>
<div class="moz-cite-prefix"><font size="4"><br>
</font></div>
<div class="moz-cite-prefix"><font size="4">
<a class="moz-txt-link-freetext" href="https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf">https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf</a></font></div>
<div class="moz-cite-prefix"><font size="4"> <br>
</font></div>
<div class="moz-cite-prefix"><font size="4">2) Here is a few
quick comparisons between our two teams' work and the outline of
EzIP benefits:</font></div>
<div class="moz-cite-prefix"><font size="4"><br>
</font></div>
<div class="moz-cite-prefix"><font size="4"> 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.<br>
</font></div>
<div class="moz-cite-prefix"><font size="4"><br>
</font></div>
<div class="moz-cite-prefix"><font size="4"> 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.<br>
</font></div>
<div class="moz-cite-prefix"><font size="4"> C. Your
"Inter-Realm Router" is simply the current Internet core routers
in the EzIP scheme.</font></div>
<div class="moz-cite-prefix"><font size="4"><br>
</font></div>
<div class="moz-cite-prefix"><font size="4"> 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.</font></div>
<div class="moz-cite-prefix"><font size="4"><br>
</font></div>
<div class="moz-cite-prefix"><font size="4"> E. EzIP
implementation is very straightforward. We have identified at
least one case that only requires "<b><i>disabling</i></b> the
program code that has been <b><i>disabling</i></b> the use of
the 240/4 netblock". With your software expertise, you likely
know other configurations.</font></div>
<div class="moz-cite-prefix"><font size="4"><br>
</font></div>
<div class="moz-cite-prefix"><font size="4"> 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.<br>
</font></div>
<div class="moz-cite-prefix"><font size="4"><br>
</font></div>
<div class="moz-cite-prefix"><font size="4"> 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 <b><i>overlay </i></b>network
providing Internet-like services while having individualized
flexibility per RAN.</font></div>
<div class="moz-cite-prefix"><font size="4"><br>
</font></div>
<div class="moz-cite-prefix"><font size="4"> 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.</font></div>
<div class="moz-cite-prefix"><font size="4"><br>
</font></div>
<div class="moz-cite-prefix"><font size="4"> I. There probably
are a few more parallelisms that we can identify, as we discuss
more.<br>
</font></div>
<div class="moz-cite-prefix"><font size="4"><br>
</font></div>
<div class="moz-cite-prefix"><font size="4">I look forward to your
thoughts and critiques.</font></div>
<div class="moz-cite-prefix"><font size="4"><br>
</font></div>
<div class="moz-cite-prefix"><font size="4">Regards,</font></div>
<div class="moz-cite-prefix"><font size="4"><br>
</font></div>
<div class="moz-cite-prefix"><font size="4"><br>
</font></div>
<div class="moz-cite-prefix"><font size="4">Abe (2022-03-23 11:59
EDT)</font></div>
<div class="moz-cite-prefix"><font size="4"><br>
</font></div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 2022-03-23 05:01, Pascal Thubert
(pthubert) via NANOG wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CO1PR11MB4881C035A309859379DFCFB7D8189@CO1PR11MB4881.namprd11.prod.outlook.com">
<pre class="moz-quote-pre" wrap="">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-----
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">From: NANOG <a class="moz-txt-link-rfc2396E" href="mailto:nanog-bounces+pthubert=cisco.com@nanog.org"><nanog-bounces+pthubert=cisco.com@nanog.org></a> On Behalf Of
Michael Thomas
Sent: mardi 22 mars 2022 22:37
To: <a class="moz-txt-link-abbreviated moz-txt-link-freetext" href="mailto:nanog@nanog.org">nanog@nanog.org</a>
Subject: Re: V6 still not supported
On 3/22/22 5:45 AM, Randy Bush wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">john,
fwiw your story matches what is left of my memory. one nuance
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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”
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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
</pre>
</blockquote>
</blockquote>
<p><br>
</p>
<div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br />
<table style="border-top: 1px solid #D3D4DE;">
<tr>
<td style="width: 55px; padding-top: 13px;"><a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon" target="_blank"><img src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif" alt="" width="46" height="29" style="width: 46px; height: 29px;" /></a></td>
<td style="width: 470px; padding-top: 12px; color: #41424e; font-size: 13px; font-family: Arial, Helvetica, sans-serif; line-height: 18px;">Virus-free. <a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link" target="_blank" style="color: #4453ea;">www.avast.com</a>
</td>
</tr>
</table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1" height="1"> </a></div></body>
</html>