Re: [Int-area] Expanding Assignable IPv4 Public Address Re: 202112030945.AYC

["Abraham Y. Chen" <[e-mail]>]

Hi, Brian:

0)    For some reason, your comment did not reach me, nor the Int-Area 
distribution list. Courtesy of Greg (on Cc:) who spotted your MSG in the 
Mail Archive and regenerated it into the following eMail format for me. 
Since I just joined the Int-Area forum and this is my first post, I have 
no idea what happened to your message. Nevertheless, allow me to respond 
to your thoughts by attempting to make this as an ordinary follow-up 
eMail. Let's see what may happen next.

1)   " ... the minor wastage of IPv4 address space that this set of 
drafts addresses... ":    This observation may be applicable to 
proposals by the "Unicast" project. I would like to describe what the 
EzIP project is proposing, so that you may see some difference. Instead 
of identifying the unused IPv4 addresses to become new Unicast resources 
yet still operating within the same current Internet environment, EzIP 
proposes to create a full spherical overlay of new routers (called SPR - 
Semi-Public Router) around the entire WWW proper to interface the 
Internet fabric (core and edge routers) with the end-users (private 
networks and directly connected IoTs). With such an arrangement, 
desirable mature IPv4 technologies may be reused without engineering 
efforts, while undesired conventions and practices can be discontinued. 
This opens up a lot of potentials. To start with, the IPv4 address pool 
when managed as proposed, is capable of nearly as many assignable IPv4 
addresses as that of IPv6 with the same 128-bit full address length. 
Please have a look at Section 5, in particular Sub-Section 5. C. of our 
IETF Draft:

https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space#page-18

2)    In addition, since the EzIP environment is new and independent of 
the existing Internet, except interconnected via "umbilical cords" (each 
representing one IPv4 address), many issues that have been in debate but 
without facility to experiment with may be studied. This will lead to 
quite a few manifestations. We can get into such later.

Regards,


Abe (2021-12-06 22:23 EST)



> Begin forwarded message:
>
> *From: *Brian E Carpenter <[e-mail]>
> *Subject: **Re: [Int-area] Expanding Assignable IPv4 Public Address 
> Re: 202112030945.AYC*
> *Date: *December 3, 2021 at 5:27:03 PM PST
> *To: *[e-mail]
>
> Abe mentions "more efficient and productive use of our resources" and 
> I think we all wish for that.
>
> I think this WG should discuss the general question whether the minor 
> wastage of IPv4 address space that this set of drafts addresses is an 
> efficient and productive use of our resources. In other words, where 
> are we with respect to conditions (1) - (5) in the WG charter 
> (https://datatracker.ietf.org/wg/intarea/about/)?
>
> Incidentally, the WG milestones look a bit OBE.
>
> Regards
>   Brian
>
> On 04-Dec-21 12:09, Abraham Y. Chen wrote:
>> Dear Colleagues:
>> 0)    I was just made aware of a current IETF Draft discussion on 
>> reducing the 127/8 netblock allocated for Local Loopback to 127/16 in 
>> order to free up mostly unused resources in that portion of the IPv4 
>> address pool. In studying this lead, I discovered that there are at 
>> least a few similar ongoing IETF Drafts being proposed by the "IPv4 
>> Unicast
> Extensions Project":
>> A. Unicast Use of the Formerly Reserved 0/8 (Version 00: 2021-11-07):
>> https://datatracker.ietf.org/doc/html/draft-schoen-intarea-unicast-0-00
>> B.    Unicast Use of the Formerly Reserved 127/8 (Version 00: 2021-11-08)
>> https://datatracker.ietf.org/doc/html/draft-schoen-intarea-unicast-127-00
>> C.    Unicast Use of the Lowest Address in an IPv4 Subnet (Version 
>> 00: 2021-10-20)
>> https://datatracker.ietf.org/doc/html/draft-schoen-intarea-unicast-lowest-address-01
>> D.    Unicast Use of the Formerly Reserved 240/4 (Version 00: 2021-10-19)
>> https://datatracker.ietf.org/doc/html/draft-schoen-intarea-unicast-240-01
>> 1)    In particular, the last Draft deals with the same netblock that 
>> our team has been reporting since 2016:
>> Adaptive IPv4 Address Space (Version 00: 2016-12-14)
>> https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space
>> Since we were advised several times in the past that IPv4 related 
>> topics were no longer active IETF tasks, we have been only updating 
>> our drafts
> as lab notes about our progress. Upon a quick scan, I believe that our 
> scheme, nicknamed EzIP (Phonetic for Easy IPv4) is more concise and 
> capable than, while avoiding most of the considerations expressed by,  
> the other drafts.
>> 2)    Now that the correlation have been established, may I request 
>> to include our proposal with the above discussions so that we
> can have a more efficient and productive use of our resources?
>> Regards,
>> Abe (2021-12-03 18:09 EST)
>> VP Engineering
>> Avinta Communications
>> Milpitas CA 95035 USA
>> eMail: [e-mail] <mailto:[e-mail]>
>> WebSite: www.Avinta.com
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon 
>> <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 
>> <http://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 
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link>>
>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>> _______________________________________________
>> Int-area mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/int-area


-- 
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus