8 Mar
2022
8 Mar
'22
9:09 a.m.
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 > <nanog%40nanog.org?Subject=Re%3A%20Class%20D%20addresses%3F%20was%3A%20Redploying%20most%20of%20127/8%20as%20unicast%20public&In-Reply-To=%3CFEDBF677-BC75-47F3-A92D-2611F43283BA%40icloud.com%3E> > *Mon Nov 29 18:47:14 UTC 2021* > > - Previous message (by thread): Class D addresses? was: Redploying > most of 127/8 as unicast public > <https://mailman.nanog.org/pipermail/nanog/2021-November/216640.html> > - Next message (by thread): Class E addresses? 240/4 history > <https://mailman.nanog.org/pipermail/nanog/2021-November/216602.html> > - *Messages sorted by:* [ date ] > <https://mailman.nanog.org/pipermail/nanog/2021-November/date.html#216766> [ > thread ] > <https://mailman.nanog.org/pipermail/nanog/2021-November/thread.html#216766> [ > subject ] > <https://mailman.nanog.org/pipermail/nanog/2021-November/subject.html#216766> [ > author ] > <https://mailman.nanog.org/pipermail/nanog/2021-November/author.html#216766> > > ------------------------------ > > >* On Nov 24, 2021, at 5:08 PM, William Herrin <bill at herrin.us <https://mailman.nanog.org/mailman/listinfo/nanog>> wrote: > *> >* On Wed, Nov 24, 2021 at 4:36 PM David Conrad <drc at virtualized.org <https://mailman.nanog.org/mailman/listinfo/nanog>> 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 <http://1.0.0.0/8> was allocated to APNIC > *>>* and they said similar things when 1.1.1.0/24 <http://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 <http://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 <http://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://mailman.nanog.org/mailman/listinfo/nanog> > *>* https://bill.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 > > ******************* > > > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon> Virus-free. > www.avast.com > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link> > <#m_-6939840509531889009_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >