Re: [Ietf] 240.0.0.0/4

At 06:53 PM 4/20/2004, Bob Hinden wrote:
> Iljitsch,
>
> > My comfort level would be much higher if by the time that we need the 
> > extra address space, we have a fighting chance of actually being able to 
> > use it. So I think it would be a good idea to make it very clear that 
> > implementations must, in the absence of more specific information, regard 
> > class E space as regular unicast space, the same way the IPv6 addressing 
> > RFCs spell this out for IPv6 address space that hasn't received a 
> > specific purpose yet. If we do this now we have ten years or more to 
> > clean up implementations.
> The only way to make this happen would be to start assigning them to some 
> real users.  Otherwise, the bugs will not be found, reported, and 
> fixed.  Just publishing an RFC with a MUST in it won't be sufficient.
No, it won't. What's being suggested is that we get such a document out 
SOON, so that by the time there's a need to use this space, there's a 
chance of having it be usable.
Devices grow old and die, just as companies do. If a document were 
published today, it might be 5 or 10 years before devices that treat class 
E space specially are either upgraded or face end of life.
If we do nothing now, then there's no chance of ever using the space. 
Please take a step back and look at a calendar covering the next decade or 
two. I know lots of folks would like that calendar to show a timeline for 
IPv6 deployment.

> The challenge here is that there may be a lot of IPv4 implementations may 
> have little or any support, and may not be possible to upgrade.
Will they be around in 10 years? Some, perhaps. Others may well have died 
by then. The document has to set a target, not define the path.
>   This would put anyone receiving a Class-E address at a big 
> disadvantage.  These addresses might have to be used behind a NAT to be 
> useful (i.e., allow direct communication to the rest of the Internet) and 
> this, of course, defeats the purpose of using them in the first place.
I don't think this is the only alternative.

My suggestion:

1) Move forward with a document as proposed, requiring implementations to 
treat class E space as unicast space. Target 5 or 10 years after 
publication as the earliest time space from the block could be allocated 
for use by RIRs.
2) Make available several chunks of space for RFC1918 usage, perhaps a few 
/8's, a whole mess of /12's, and many /16's. This space does two things: 
First, it provides additional private address space, which is needed. 
Second, it provides a usage battleground for class E space testing. There 
is the very real possibility users of these blocks will run into trouble as 
vendors have special handling for class E. By allowing these to be 
discovered during use in private networks, there is a much better chance of 
public usage of these blocks later.
I do NOT agree that the entire class E space should go to RFC 1918. That 
seems wasteful. But using some large chunks of space for that purpose 
clearly provides a test bed to prove out equipment before eventual public 
address usage in that region of IP address space.
Dan


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf