Date: Wed, 13 Mar 2002 10:43:40 -0800
From: Steve Deering <[EMAIL PROTECTED]>
Message-ID: <v04220804b8b54ccaa44e@[10.34.255.54]>
| The u bit in the current IID definition indicates whether or not the
| IID can be considered globally unique.
If that were to be true, then we would require u==0 in all IPv6
addresses, as there's no possible way for anyone to know if their
IID is globally unique or not.
We don't even need to resort to postulating manufacturing errors
(sloppiness, whatever) to see that the 'u' bit defined this way is
useless. Though that is certainly part of the potential problem.
The obvious case that breaks this is address reassignment. That is,
I have some system or other, it has used autoconfig, and allocated itself
an EUI-64 based address, and so, following the rules, has set u==1.
Then the system's net interface breaks in some way (which might mean that
the switch it is connected to breaks, not necessarily the hardware in the
system). I desire my DNS advertised address to keep on working, so I
assign that address to another interface in the system (or perhaps I install
some new interface type, replace a 100baseTX with GigaE or something).
As I want to avoid all service disruption, this interface gets the
IPv6 address that the system has always had. The same IID. And because
the address always had u==1 in the past, it has to keep u==1 now.
Sometime later, my old interface card, with its burned in MAC addr, is
plugged into some other system, connected most likely to some distant
net (distant enough), it does its DAD, finds it can use the address
based upon the EUI from the card, and does so, u==1.
Now we have two systems both using IPv6 addresses with u==1, and both
with the same IID. Thus, u==1 does not imply a globally unique IID,
and cannot.
The only way we could change that would be to refuse to allow an address
to be used which didn't match the IEEE addr of the card, if it has u==1.
That is, all stacks everywhere (including that in all those shipping XP's)
would have to enforce that rule. Some hope (too late...).
But I'd object to any attempt to do that in any case, even if it were
feasible. There's no current use for globally unique IIDs - they're
just a frill "it looks like we can get this for free, so let's define it".
Adding mechanism for no purpose, and while doing so, prohibiting reassignment
of addresses (which is useful functionality) would be absurd.
Not only is there no use for globally unique IIDs currently, it is unlikely
there ever will be one. No IPv6 address is required to have one of those,
so nothing can ever depend on their existence (and with more and more people
jumping on the "privacy address" band waggon - for reasons that aren't clear
to me, but that's beside the point - it seems that less IPv6 addresses will
have u==1 than might have initially seemed likely). Further, even if you
find an address with u==1, there's no way to know if it really is globally
unique - there's no testing mechanism - so it would be unreasonable to
rely on its uniqueness for anything important.
So, let's just end this pretence that u==1 has any special meaning, and
revert to the earlier situation, where we no natural EUI-64 is going to
have (the inverted) u==0, so we define things like randomly generated
addresses to always set u==0, so that there's no chance that someone's
randomly generated address is going to be occupying your EUI-64 address
space on your link (the chance is tiny anyway, this removes it completely,
and makes it reasonable for a system using autoconf of EUI-64 based addresses
to simply give up and cry if its DAD fails, rather than requiring a recovery
mechanism).
Finally - if there were to be any kind of reasonable way to test an ID for
uniqueness, then we'd be using EIDs now. Getting unique EIDs was the major
problem that inhibited us from choosing a protocol that used them (8+8
being one of the contenders - the nearest to IPv6). And that was a problem
when the EID would have been completely under our control, and so could
have had any properties we desired, unlike EUI-64's, that we're just stuck
with.
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]
--------------------------------------------------------------------
