Making Use of 240/4 NetBlock Re: 202203171153.AYC

Thu Mar 17 16:21:08 UTC 2022

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 
<beecher at beecher.cc> To: "Abraham Y. Chen" <aychen at avinta.com> Cc: Mark 
Andrews <marka at isc.org>, NANOG <nanog at nanog.org> Subject: Re: Making Use 
of 240/4 NetBlock Re: 202203161019.AYC Message-ID: 
<CAL9Qcx46RzdqYWRQ+Fo_+a8L9Kr=ZQi9J2Ej+FNtzTFs=eSpuA at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20220317/f6429dae/attachment.html>