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.
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.
Carving out space at a later time, experience showed, is a difficult
thing to do, it is controversial, and the effort to standardize such an
address block allocation may hamper the essential part of the work,
which needs the address block. Additionally, when would one
ask for such address space? when a projects starts, when is well
underway? The model is quite questionable.
Alex
Brian E Carpenter wrote:
>
> Well, I miswrote slightly - the fact is that an implementation has to
> first check if the address is any of the non-global-unicast cases, and that
> involves doing a sequence of matches which involve the bits
> Formerly Known as the Format Prefix (not just 3 of them of course).
> I think the new text makes this harder to understand. It doesn't change
> what implementors should do.
>
> Feel free to ignore my comment if nobody else has the same reaction.
>
> Brian
>
> Erik Nordmark wrote:
> >
> > > I also think that abolishing the term "format prefix" is obfuscation. The
> > > fact is that the leading bits of an address *are* a format prefix and
> > > implementors *will* look at those bits before processing an address. Why
> > > obscure that fact?
> >
> > Brian,
> > It is exactly this that we want to avoid - implementors thinking that they
> > need to inspect the first 3 bits of the addresses.
> > There is no need to do this and we need to reduce the probability that
> > implementors hard-code any knowledge of any leading 3 bit combinations
> > since it will make it harder to use the other 15/16th of the address space
> > in the future.
> >
> > Erik
> --------------------------------------------------------------------
> 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]
> --------------------------------------------------------------------
S/MIME Cryptographic Signature
