202203071610.AYC Re: Making Use of 240/4 NetBlock
beecher at beecher.cc
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
> 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.
> Abe (2022-03-07 17:14 EST)
> VP Engineering
> Avinta Communications, Inc.
> Milpitas, CA 95035 USA
> Skype: Abraham.Y.Chen
> eMail: AYChen at Avinta.com
> WebSite: www.Avinta.com
> 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 ]
> <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 ]
> >* 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 188.8.131.52/8 <http://184.108.40.206/8> was allocated to APNIC
> *>>* and they said similar things when 220.127.116.11/24 <http://18.104.22.168/24> was stood up as an
> *>>* experiment by Cloudflare and APNIC, yet 22.214.171.124 seems to be pretty popular.
> *> >* Hi David,
> *> >* I don't recall there being any equipment or software compatibility
> *>* concerns with 126.96.36.199/8 <http://188.8.131.52/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 184.108.40.206/8 <http://220.127.116.11/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.
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon> Virus-free.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NANOG