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.

------------------------------

NANOG Digest, Vol 170, Issue 19

Message: 9 Date: Wed, 16 Mar 2022 11:38:51 -0400 From: Tom Beecher <beecher@beecher.cc> To: "Abraham Y. Chen" <aychen@avinta.com> Cc: Mark Andrews <marka@isc.org>, NANOG <nanog@nanog.org> Subject: Re: Making Use of 240/4 NetBlock Re: 202203161019.AYC Message-ID: <CAL9Qcx46RzdqYWRQ+Fo_+a8L9Kr=ZQi9J2Ej+FNtzTFs=eSpuA@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 <aychen@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)