[ppml] 256/3 was Re: 240/4

Durand, Alain Alain_Durand at cable.comcast.com
Fri May 4 04:43:36 EDT 2007


In the spirit of "let's write an RFC to free up some space and the problem will go away", I would like to suggest to write an RFC opening up 256/3.

That would free up 64 new /8, enough to delay IPv4 exhaustion by several years. And if we still ran out after that, we can later on open up the next block, 320/3.

Oh, it has been reported that many systems today do not support those addresses, but this is clearly a software update issue that can be addressed by a simple patch, and anyway by the time that space will be needed, all those legacy systems will be retired. Of course, greenfield deployment will have no problem using it today.

    - Alain.


----- Original Message -----
From: ppml-bounces at arin.net <ppml-bounces at arin.net>
To: ppml at arin.net <ppml at arin.net>
Sent: Fri May 04 03:40:24 2007
Subject: Re: [ppml] 240/4

> > If the RFC tells people that there MAY be problems routing 240/4
> > addresses on the open Internet, and that there MAY be technical
> > problems

> You seriously underestimate the problem space by making it sound like
> simply
> a routing problem.

No I don't! This is not a technical mailing list and there is no need to
get into such technical details here. In fact, an RFC that releases
240/4 from bondage also does not need to directly address these
technical issues, merely point out that there MAY be problems and that
there is need for further work, an maybe future RFCs to cover those
issues.


> That space was undefined at the time of testing so
> every
> Windows system will not even initiate traffic to that block through
the
> default route because it was not clear if there should have been some
> other
> path that was special for that block. 

Windows software is regularly patched, more often than server software
in my experience. I am not concerned about any specific behaviour in
Windows because I know that once the 240/4 RFC goes out, MS will be
motivated to fix them.

> It is not a matter of fixing the code, it is about the reality of
getting
> the old systems weeded out of deployment. 

That is an issue for the organizations that decide they want to try
using the newly available 240/4 space. I am not going to try and second
guess their motives or how they might deploy the space. Networks are not
as homogenous as you imagine. The RFC that releases 240/4 is not
directed at Joe Sixpack which is why the RIRs will be instructed to warn
applicants an get them to state that they are aware of the technical
problems with 240/4.

> but it should be made clear that use of that space has to be for a
> completely self-contained collection of new end systems with no
> expectation
> of it every working to interact with the rest of the IPv4 address
space
> (including 1918). 

The RFC should not say that the 240/4 space MUST be used for a
self-contained deployment, but it SHOULD warn that this MAY be the only
useful way of using such addresses.

--Michael Dillon

_______________________________________________
This message sent to you through the ARIN Public Policy Mailing List
(PPML at arin.net).
Manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/ppml


More information about the ARIN-PPML mailing list