Re: [Ietf] 240.0.0.0/4
2004-04-23 05:57:46
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
|
|