At 11:02 AM -0500 1/23/02, Keith Moore wrote:
> > 1) Is it safe to assume that all IPv6 prefixes will be between 16 and 64 bits
> > long?
>
>no. because nothing requires a site to use the lower 64 bits as an
>interface ID - a site is free to subnet that space if it wishes.
Actually, there *is* something that requires a site to use the lower 64
bits as an interface ID: the IPv6 address architecture spec. RFC-2373
says on the top of page 7:
(2) The format prefixes 001 through 111, except for Multicast
Addresses (1111 1111), are all required to have to have 64-bit
interface identifiers in EUI-64 format.
That wording has been revised in the most recent version of that spec,
draft-ietf-ipngwg-addr-arch-v3-07.txt, removing the reference to
"format prefixes" and introducing the term "Modified EUI-64 format" to
distinguish the format we use in which we invert the value of one of
the bits from the real EUI-64 format, but still saying the same
thing (on the bottom of page 8):
For all unicast addresses, except those that start with binary value
000, Interface IDs are required to be 64 bits long and to be
constructed in Modified EUI-64 format.
Note that there is an exception for addresses beginning with binary 000,
which is where we have put things like the embedded NSAP addresses and
several of the many forms of IPv6 addresses with embedded IPv4 addresses,
which obviously don't have 64-bit interface IDs.
So, in answer to Irina's question "Is it safe to assume that all IPv6
prefixes will be between 16 and 64 bits long?" the answer is no:
prefixes starting with 000 may well be longer than 64 bits. (Prefixes
may also be shorter than 16 bits, since we have also removed the TLA,
NLA notions from the updated address architecture, those properly being
in the realm of address assignment policy, not architecture.)
If Keith and kre want to ignore the requirement for 64-bit interface
IDs, and can find implementations that will satisfy that desire, fine.
But if they choose to use prefixes longer than /70, they'll have the
additional operational headache of ensuring that the "u" bit which
indicates whether or not the interface ID is globally unique is correctly
set to zero, even though that bit now falls within the subnet (or
higher-level) field of the address. Doesn't seem worth the hassle,
and the need for longer prefixes for address conservation is not
persuasive, to me.
When I get asked about what assumptions can be made about unicast prefix
lengths (e.g., by people designing route look-up implementations), I
tell them that they should be prepared to handle any prefix length,
but that it will probably be OK if prefixes between 65 and 127, inclusive,
are handled in a slower path (i.e., if you can't build the fully-general
mechanism at an acceptable cost, you probably won't get burned if you
optimize for prefixes between 0 and 64, plus 128 (for "host routes")).
Steve
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
