Date: Thu, 7 Feb 2002 16:49:59 -0800
From: Steve Deering <[EMAIL PROTECTED]>
Message-ID: <v04220801b888c8d632ef@[10.34.255.54]>
| 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:
That is a mistake. Requiring this for the addresses that we're currently
allocating is a mistake of its own, pretending that we know how addresses
are to be allocated forever into the future is just plain insane.
Just look backwards a little - when IPv6 was first designed (even the
first versions with 128 bit addresses - the SIPP stuff), the interface
identifier was a 48 bit MAC address (or at least that's what we were
assuming that would be enough for everything).
Then we found out that the rest of the world had moved on, and this new
thing called the EUI-64 was to be the new standard for future network
technologies. So we changed.
We have to retain the flexibility to change again, when the rest of the
world invents some other new format of link level identification. It
makes no sense to pretend that we own that specification, and that we
are not going to allow anything other than an EUI-64 (or something that
can be converted into one) to ever be used.
What's more, there's nothing at all in IPv6 as we know it now that depends
upon this - apart from auto-configuration of addresses, which is a very
much link dependent activity (relies upon the link supporting multicast
so addresses can be verified, lookups can be done, ...). Some potential
new medium won't necessarily support this (and point to point links certainly
don't need anything nearly so complex).
Of course, it does no real harm to have statements like this in the spec
(and having such things makes it easier to deal with organisations which
would prefer to be more miserly than we would like in the allocation of
numbers) - provided that no-one starts building code that actually depends
upon this never being changed into the future.
We can easily change the spec as soon as it becomes apparent that a change
is needed - provided that no-one has relied upon it too heavily. That's
what I am requesting - that implementors simply ignore all these pretend to
be boundaries, except where they are actually important for something.
| 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
Huh? Thanks all the same, but unless that 'u' bit ever actually gets a
use that matters, I don't think I'll care too much. Nothing (certainly
not anything outside my local network) has any business at all caring in
the slightest what the internal format of my "interface identifiers" is.
Sure - when I'm doing something like allocating some static addresses (or
some randomly assigned ones) and mixing those with ones that are
auto-configured that bit helps avoid unnecessary collisions, so it is
useful to have. Beyond that it is a waste of space (that is, if it
wasn't already in the EUI-64 format, we wouldn't be inventing it for IPv6).
| indicates whether or not the interface ID is globally unique is correctly
Since absolutely nothing cares if the interface ID is globally unique
or not, this cannot really matter. What's more, since we allow addresses
with 'u' == 0, nothing can really ever demand that we have globally unique
addresses. That is, it simply isn't possible to retro-fit 8+8 onto IPv6
as we have it now, there are already too many non-unique "interface IDs"
for there to be any chance of that at all.
| 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")).
I have no particular problem with that - though I'd expect that where people
will optimise will also be determined by their target market. For some, host
routes (/128) won't be worth optimising either. For some, perhaps only prefixes
up to /48 will need to be handled really quickly. For others, everything
between 0 and /128 is likely to be equally important. All this just results
in situating different implementations into different market niches.
kre
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
