> Cc: NANOG <[email protected]>, Greg Skinner <[email protected]>, > "Karandikar, Abhay" <[email protected]>, Rama Ati <[email protected]>, > Bob Corner GMAIL <[email protected]>, "Hsing, T. Russell" > <[email protected]>, "Chen, Henry C.J." <[email protected]>, ST Hsieh > <[email protected]>, "Chen, Abraham Y." <[email protected]> >
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 <[email protected]> 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 <[email protected]> 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: [email protected] >> 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 > >
