Hi, Tom:
1) " I've read the draft. ... ": Then, you still overlooked the
essence of the keyword "overlay":
A. The EzIP project started with the goal of getting enough IP
addresses for end-to-end communication according to the old fashioned
definition in telecommunications, such as PSTN. Upon correlated the
three private netblocks to the reusable PBX numbering convention and
discovered the availability of the 240/4 netblock, we enlisted the
Option Word for carrying such additional information to accomplish this
goal.
B. Next, we realized that since 240/4 is so big, we can deploy
it over a much larger area than a commonly known private premises. The
concept of RAN (Regional Area Network) was born. Since the existing
Internet routers will drop any 240/4 addressed packets, RANs can deploy
on their own, without interference in either direction. With each RAN
served from one IPv4 public address, the entire RAN can be viewed as an
isolated island or a piece of land floating in the air and tethered to
the Internet core via one umbilical cord.
C. This configuration frees up the need for updating any current
Internet equipment while growing by expanding from one IPv4 address.
That is, the RAN deployment can be done via SPRs (Semi-Public Routers)
as needed. All of these introductory activities do not need to use the
Option Word, at all. This phase of the deployment can use the
degenerated EzIP header mentioned in the Draft which is actually the
conventional basic IPv4 header (without Option Word).
D. Only when direct communication between IoTs residing in
separate RANs is desired, IoTs capable of the full EzIP header will be
used. (These are not wide spread requirement, but case-by-case for elite
users.) Since the number of umbilical cords is finite, interconnecting
RANs for this purpose can be achieved by deploying SPRs where is needed.
Of course, if existing routers are wiling to support (by "trimming down"
the existing code), the deployment will go much faster. But, it is not
necessary.
2) The above is why "overlay" network can be used to characterize the
EzIP architecture. One interesting online graphics that we recently came
across depicts this configuration very nicely (see URL below). One can
visualize that each continent, country, and even all the way down a
Region or an island is floated above the earth core (the Internet) and
tethered to it via an umbilical cord (IPv4 address). With this
architecture, everything in the RAN can start fresh, yet supported by
the core all the time. The involvement of the latter is optional. This
relationship is the same as national versus international telephony
networks in the PSTN world. In other words, the current Internet proper
will serve just the current type of interconnections among RANs, if no
update is made to its routers.
https://dotconnectafrica.org/icann-wins-by-technical-knockout-dca-blocked-from-being-heard-on-its-merit/
Hope I am not boring you by being too wordy.
Regards,
Abe (2022-03-17 12:20)
------------------------------
NANOG Digest, Vol 170, Issue 19
Message: 9 Date: Wed, 16 Mar 2022 11:38:51 -0400 From: Tom Beecher
<beec...@beecher.cc> To: "Abraham Y. Chen" <ayc...@avinta.com> Cc: Mark
Andrews <ma...@isc.org>, NANOG <nanog@nanog.org> Subject: Re: Making Use
of 240/4 NetBlock Re: 202203161019.AYC Message-ID:
<CAL9Qcx46RzdqYWRQ+Fo_+a8L9Kr=ZQi9J2Ej+FNtzTFs=es...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
2) Re: Ur. Pt. 2) " So replace every CPE device, including ... ":
It is evident that you even did not glance at the EzIP Draft Abstract
before commenting, but just relying on your recollection of the past 240/4
efforts. Please spend a minute or two on reading the EzIP Abstract. In
particular, please look for a keyword "overlay". Hint, this was not our
invention. It was a concise characterization by an authoritative Internet
figure. So, we imported it into our latest IETF draft update. Hopefully,
this keyword will steer your opinion on EzIP.
I've read the draft. Your proposal appears to rely on a specific value in
the IP option header to create your overlay. While that sounds good on
paper, it's operationally been best practice for at least the last decade
(maybe longer) 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, so any substantive traffic flow with options
set could knock devices over. I can't speak to the current state of router
processing, but I'd bet dollars to donuts most of those filters are still
in place.
So, assuming your proposal were to eventually become an adopted standard,
before it could reliably work across the general internet :
- Any device that still treated 240/4 differently would need to be updated
to treat it like anything else.
- Any existing filters that dropped packets with*any* IP option set would
have to be modified to permit the ones you define for EzIP
- At least some router software would have to have IP option handling
adjusted in some way. ( 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. )
This is a LOT of work and time for an overlay.
On Wed, Mar 16, 2022 at 10:51 AM Abraham Y. Chen<ayc...@avinta.com> wrote:
Hi, Mark:
1) Re: Ur. Pt. 1) " ISE != IETF. ... ": On a public forum like
NANOG, it is much more expeditious to provide forward guidance than
reciting past failures, especially those of a third party due to improper
system setup.
2) Re: Ur. Pt. 2) " So replace every CPE device, including ... ":
It is evident that you even did not glance at the EzIP Draft Abstract
before commenting, but just relying on your recollection of the past 240/4
efforts. Please spend a minute or two on reading the EzIP Abstract. In
particular, please look for a keyword "overlay". Hint, this was not our
invention. It was a concise characterization by an authoritative Internet
figure. So, we imported it into our latest IETF draft update. Hopefully,
this keyword will steer your opinion on EzIP.
Regards,
Abe (2022-03-16 10:49)
--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
