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 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 <[email protected]>
*Sent:* mercredi 23 mars 2022 16:59
*To:* Pascal Thubert (pthubert) <[email protected]>
*Cc:* Michael Thomas <[email protected]>; [email protected]
*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 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 <[email protected]>
<mailto:[email protected]> On Behalf Of
Michael Thomas
Sent: mardi 22 mars 2022 22:37
To: [email protected]
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>
