> While I think an implementation does not have to explicitly be
> concerned about Prefix Format bits, since the bits are automatically
> included in a prefix, I am quite concerned about the fact that at
> this moment the entire IPv6 space is allocated, with no
> experimental, or reserved space for future development.
"allocated" is probably the wrong word. "assigned (and in use)" is
what I think is important. Once a swath of address space is assigned
(and used) for some purpose, it's hard to take it back for some other
use.
The current ID defines some ranges of address for special purposes,
but says the rest should be treated (from an implementation
perspective) as global unicast. I.e., treat them all the same.
If, at some future point, someone wants to experiment and needs a
range of address that it will treat "differently", all that needs to
happen is that it obtain a big enough range of addresses for its
purpose. As long as there is such a range of addresses that is not in
use by anyone, this isn't a problem.
As Randy has pointed out, the IANA considerations section in the ID
makes it clear that only 1/8th of the available space is being made
available for usage and assignment. So we still have lots of space to
use differently, should someone make the case that we need to.
> Carving out such a space ahead of time, like in IPv4, worked well. It
> provides the benefit that if people experiment with a number of
> addresses, they know ahead of time, what they have available, and will
> not conflict with global addresses, or other addresses, already
> in use.
Actually, reserving an experimental range in advance, is not the best
way to do it. You might reserve too much or too little. Hard to tell
in advance what the future will bring. The better approach is to
assign address space for use in a way that allows one to put off for
as long as possible making the decision on how big a range to reserve
for one purpose vs. another. Leave things flexible for a future that
is hard to predict.
Thomas
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
