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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf