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

Tue Mar 8 14:09:44 UTC 2022

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 at 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 at 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>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20220308/7d845543/attachment.html>