Feasibility of using Class E space for public unicast (was re: 44/8)

Sat Jul 27 04:19:50 UTC 2019

On 2019-07-22 6:09 PM, Owen DeLong wrote:

>> On Jul 22, 2019, at 12:15 , Naslund, Steve <SNaslund at medline.com 
>> <mailto:SNaslund at medline.com>> wrote:
>>
>> I think the Class E block has been covered before.  There were two 
>> reasons to not re-allocate it.
>> 1.A lot of existing code base does not know how to handle those 
>> addresses and may refuse to route them or will otherwise mishandle them.
>> 2.It was decided that squeezing every bit of space out of the v4 
>> allocations only served to delay the desired v6 deployment.
>
>
> Close, but there is a subtle error…
>
> 2.It was decided that the effort to modify each and every IP stack in 
> order to facilitate use of this relatively small block (16 /8s being 
> evaluated against a global
> run rate at the time of roughly 2.5 /8s per month, mostly to RIPE and 
> APNIC) vs. putting that same effort into modifying each and every IP 
> stack to support
> IPv6 was an equation of very small benefit for slightly smaller cost. 
> (Less than 8 additional months of IPv4 free pool vs. hopefully making 
> IPv6 deployable
> before IPv4 ran out).

All of this, plus what Fred Baker said upthread.

When I was running the IANA in the early 2000's we discussed this issue 
with many different experts, hardware company reps, etc. Not only was 
there a software issue that was insurmountable for all practical 
purposes (pretty much every TCP/IP stack has "Class E space is not 
unicast" built in), in the case of basically all network hardware, this 
limitation is also in the silicon. So even if it were possible to fix 
the software issue, it would not be possible to fix the hardware issue 
without replacing pretty much all the hardware.

... and even if some magical forces appeared and gave every open source 
software project, and every company, and every consumer in the developed 
world the means and opportunity to do all of the above; doing so would 
have left the developing world out in the cold, since in many cases 
there is reliance on older, second/third/fourth hand equipment that they 
could never afford to replace.

So the decision was made to start tooting the IPv4 runout horns in the 
hopes that folks would start taking conservation of the space seriously 
(which happened more often than not), and accelerate the adoption of 
IPv6. *cough*

Personally, I also pushed to bring IPv6 support from ICANN up to par, 
including going the last mile on putting the IPv6 addresses of the root 
servers in the zone, creating and socializing a long-term plan for 
allocating to the RIRs, etc.

So no, there were exactly zero "IPv6 loons" involved in this decision. :-)

Doug

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190726/d82312de/attachment.html>