CC:s to Non List Members (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock)

[Anne Mitchell <amitchell () isipp com>]

> Cc: NANOG <nanog () nanog org>, Greg Skinner <gregskinner0 () icloud com>, "Karandikar, Abhay" <Director () iitk ac 
> in>, Rama Ati <rama_ati () outlook com>, Bob Corner GMAIL <bobbiecorner () gmail com>, "Hsing, T. Russell" <tHsing () 
> ieee org>, "Chen, Henry C.J." <hcjchen () avinta com>, ST Hsieh <uschinaeetc () gmail com>, "Chen, Abraham Y." 
> <AYChen () alum mit edu>

This is a whole lot of cc:s to people who aren't even part of this group/list.  One wonders with this many cc:s, how 
many bcc:s there also were, and to whom.

Anne

--
Anne P. Mitchell, Attorney at Law
CEO Get to the Inbox by SuretyMail
Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal email marketing law)
Author: The Email Deliverability Handbook
Board of Directors, Denver Internet Exchange
Dean Emeritus, Cyberlaw & Cybersecurity, Lincoln Law School
Prof. Emeritus, Lincoln Law School
Chair Emeritus, Asilomar Microcomputer Workshop
Legal Counsel: The CyberGreen Institute
In-house Counsel: Mail Abuse Prevention System (MAPS) (Closed in 2004)


> On Mar 8, 2022, at 8:46 AM, Abraham Y. Chen <aychen () avinta com> wrote:
>
> Hi, Tom:
>
> 0)    Thanks to your thoughts.
>
> 1)    First, logistics: Since this was my first post to this Forum, I got an auto-response stating that my post was 
> being moderated. Then, I got your message even before I received any follow-up notice from such, nor my writing being 
> published. Are you responding to the general distribution or acting as a moderator?
>
> 2)    " .... an overly convoluted mechanism to tunnel 240/4. ....    ":    We started our work due to curiosity. As 
> we made progresses in various areas, quite a few topics have distilled to a different yet much clearer picture. Allow 
> me to describe the current EzIP proposal with respect to these aspects:   
>
>     A.    "overly convoluted":    EzIP proposes to make use of the long-reserved 240/4 NetBlock by utilizing the 
> RFC791 to carry it.  However, this is only needed for the long term full end-to-end deployment. For the immediate 
> EzIP configuration that is for supporting the current Server / Client (Master /Slave) model (similar to the current 
> CG-NAT, or CDN), EzIP will be using a degenerated configuration which we call it RAN (Regional Area Network) where 
> the standard IPv4 packet header will be suffice, even without the RFC791. I believe these schemes are opposite to 
> "convoluted".  
>
>     B.    "tunnel":    Instead of tunneling in the current sense of 6to4 tunneling, or similar, which interacts with 
> the parameters of transmission environment, EzIP is an overlay network consisting of RANs (Regional Area Networks), 
> each is tethered from the current Internet via one IPv4 public address. Since each RAN appears to be a private 
> network to the Internet core, pretty much everything in the RAN is independent of the latter.  Direct communications 
> between IoTs residing in separate RANs, when needed, will still be carried by native IPv4 packets (with the addition 
> of Option Words carrying IoTs' Source and Destination addresses within the host RANs, respectively).      
>     
>     Could you please clarify your characterizations of the above?
>
>
>
> Regards,
>
>
>
>
>
> Abe (2022-03-08 10:46)
>
>
>
>
>
> On 2022-03-08 09:09, Tom Beecher wrote:
> > I recall reading the IETF draft some time ago. It seemed like an overly convoluted mechanism to tunnel 240/4. 
> >
> > On Tue, Mar 8, 2022 at 8:50 AM Abraham Y. Chen <aychen () avinta com> wrote:
> > Dear Colleagues:
> >
> > 0)    I was made aware of a recent discussion on this Forum that cited our work on the 240/4 NetBlock, nicknamed 
> > EzIP (Phonetic for Easy IPv4). (Please see, at the end of this MSG, the URL to the discussion and the highlighted 
> > text where the citation was made.)
> >
> > 1)    As the lead investigator of the EzIP Project, I would like to  formally introduce our solution by bringing 
> > your attention to an overview whitepaper:
> >
> >     https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf
> >
> >     In a nutshell, EzIP proposes to disable the program codes in current routers that have been disabling the use of 
> > the 240/4 NetBlock. The cost of this software engineering should be minimal. The EzIP deployment architecture is the 
> > same as that of the existing CG-NAT (Carrier Grade Network Address Translation). Consequently, there is no need to 
> > modify any hardware equipment. There is an online setup description (Reference II), called RAN (Regional Area 
> > Network), that demonstrates the feasibility of this approach.
> >
> > 2)    There are additional consequential benefits by deploying EzIP, such as those mentioned by our comment to 
> > Reference III in the above whitepaper.
> >
> > I look forward to addressing your thoughts.
> >
> >
> > Regards,
> >
> >
> >
> > Abe (2022-03-07 17:14 EST)
> > VP Engineering
> > Avinta Communications, Inc.
> > Milpitas, CA 95035 USA
> > +1(408)942-1485
> > Skype: Abraham.Y.Chen
> > eMail: AYChen () Avinta com
> > WebSite: www.Avinta.com
> >
> >
> > ***********************
> >
> > https://mailman.nanog.org/pipermail/nanog/2021-November/216766.html
> >
> > Class D addresses? was: Redploying most of 127/8 as unicast public
> >
> > Greg Skinner gregskinner0 at icloud.com 
> > Mon Nov 29 18:47:14 UTC 2021
> >      • Previous message (by thread): Class D addresses? was: Redploying most of 127/8 as unicast public
> >      • Next message (by thread): Class E addresses? 240/4 history
> >      • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> > > On Nov 24, 2021, at 5:08 PM, William Herrin <bill at herrin.us
> > > wrote:
> >
> > >
> >  
> >
> > > On Wed, Nov 24, 2021 at 4:36 PM David Conrad <drc at virtualized.org
> > > wrote:
> >
> > > > >
> >  I like research but what would the RIRs study? The percentage of the
> >
> > > >
> >  
> >
> > > > Lots of people said similar things when 1.0.0.0/8
> >  was allocated to APNIC
> >
> > > > and they said similar things when 1.1.1.0/24
> >  was stood up as an
> >
> > > >
> >  experiment by Cloudflare and APNIC, yet 1.1.1.1 seems to be pretty popular.
> >
> > >
> >  
> >
> > >
> >  Hi David,
> >
> > >
> >  
> >
> > >
> >  I don't recall there being any equipment or software compatibility
> >
> > > concerns with 1.0.0.0/8
> > . If you do, feel free to refresh my memory. As
> >
> > >
> >  I recall it, there were concerns with prior local use and potential
> >
> > >
> >  trash traffic. It seemed likely those concerns could be addressed with
> >
> > >
> >  experiments, and the experiments in fact addressed them.
> >
> > >
> >  
> >
> > >
> >  The prior local use worry reared its head again with 240/4 but given
> >
> > > the prior experience with 1.0.0.0/8
> >  I don't personally believe we need
> >
> > >
> >  to re-run that experiment just because the numbers are part of a
> >
> > >
> >  different block.
> >
> > >
> >  
> >
> > >
> >  
> >
> > > >
> >  Seems to me that a number of folks on this list and during this
> >
> > > >
> >  discussion would disagree with a blanket assertion that 240/4
> >
> > > >
> >  is “dysfunctional on the 2021 Internet” - some of them even
> >
> > > >
> >  wrote a draft discussing the possibility.
> >
> > >
> >  
> >
> > >
> >  Line them up. Show of hands. Who really thinks that if we assign
> >
> > >
> >  240.0.0.1 to a customer tomorrow without waiting for anyone to clean
> >
> > >
> >  up their software and hardware, you won't get enough complaints about
> >
> > >
> >  things not working that you have to take it back and assign a
> >
> > >
> >  different address instead?
> >
> > >
> >  
> >
> > >
> >  
> >
> > > >
> >  1. Move 240/4 from "reserved" to "unallocated unicast"
> >
> > > >
> >  
> >
> > > >
> >  OK, but this seems like a quibble.  The status for 240/4 is “
> >
> > > >
> >  RESERVED: designated by the IETF for specific non-global-unicast
> >
> > > >
> >  purposes as noted.”  The “as noted” part is “Future Use”.
> >
> > >
> >  
> >
> > >
> >  It's not a quibble. Some vendors take the current status to mean
> >
> > >
> >  "treat it like unicast until we're told otherwise." Others take the
> >
> > >
> >  status to mean, "packets with these addresses are bogons without a
> >
> > >
> >  defined routing behavior until we're told otherwise." The result is
> >
> > >
> >  incompatible behavior between vendors. Changing that direction to
> >
> > >
> >  "treat it like unicast" without ambiguity is not a quibble.
> >
> > >
> >  
> >
> > >
> >  Regards,
> >
> > >
> >  Bill Herrin
> >
> > >
> >  
> >
> > >
> >  --
> >
> > >
> >  William Herrin
> >
> > > bill at herrin.us
> > > https://bill.herrin.us/
> >
> > For what it’s worth, I’ve been tracking this issue on other netops mailing lists.  There is a recent post on the 
> > LACNOG list from Leandro Bertholdo
> >  <
> > https://mail.lacnic.net/pipermail/lacnog/2021-November/008895.html> referencing 
> > https://datatracker.ietf.org/doc/draft-chen-ati-adaptive-ipv4-address-space/
> >  
> > <
> > https://datatracker.ietf.org/doc/draft-chen-ati-adaptive-ipv4-address-space/
> > > , a draft proposing another way to make additional IPv4 address space available
> > I haven’t had time to read the draft closely, but I noticed that it involves the use of 240/4.  Subsequent googling 
> > about the draft turned up a presentation 
> > <
> > https://www.avinta.com/phoenix-1/home/RegionalAreaNetworkArchitecture.pdf> describing how the techniques described 
> > could be deployed.
> >   I noticed that the presentation 
> > made reference to OpenWRT, so perhaps the authors are aware of the work that the authors of the IPv4 Unicast 
> > Extensions Project have done in that area.
> >
> > The adaptive-ipv4 draft will expire sometime next month, so anyone interested in seeing it move forward should 
> > contact the authors.
> >
> > —gregbo
> >
> > *******************
> >
> >
> >      Virus-free. www.avast.com