Date: Thu, 21 Mar 2002 15:25:58 +0100 (CET)
From: Erik Nordmark <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| Without going into history, the current state
| is that the U/L bit has semantics in the sense that we point out [somewhere]
| that e.g. future transport protocols might use the knowledge that
| the interface ID is globally unique when the U bit is set.
Yes, that is written down, but nonsense written down is still nonsense.
A IID does not become globally unique just because it has the U bit set,
and any future protocol that attempted to assume that it did would be
quite rightly laughed out of the I-D directories (if it even made it
that far).
There can never be such a protocol, the very idea is ludicrous - those
words should be deleted from 2373bis.
| FWIW we seem to, for whatever reasons, already have embarked on the path
| of having semantics associated with the interface ID.
There's nothing wrong with that, when people are agreeing to make use
of them (it isn't a very good choice, but people can do what they want with
their addresses). What you can't do is take some random address, and assume
anything at all about it (other than the way to route to it) merely from its
bit pattern (nb: issues of link local, site local, IPv4 mapped, ... are all
related to "how to route to it").
| While I'm not advocating removing the U/L bit,
No, it serves a useful purpose, when we define when it should be set,
and when it shouldn't - and allows better interoperation between
implementations that all follow those standards. The problems only come
when we pretend we can interpret what it means when we see it, as distint
from set it (or not) to achieve a particular outcome.
| it sure would be interesting
| to know whether we think assigning the globally unique semantics is
| a bad idea.
It isn't that it is a bad idea, it is that it is an impossible idea.
It might actually be nice to know if the IID is globally unique, but
there's no way you can discover that.
I have been pondering collecting the IIDs of all nodes I communicate with
and using those exact same IIDs in addresses I assign... Guaranteed
non-unique IIDs (with the U bit in either state). There's nothing anyone
can do to prevent me from doing that. Except if yours happens by some
fluke to be one of the IIDs I make use of, there's not any way for you
to tell that an address has been formed that way.
| If so perhaps we should make it clear that U=1 means
| "assigned by the IEEE according to EUI-64" and nothing more.
No, that's not right either. U=1 *means* nothing at all. Or no more
than if the bit to the left of it (in the normal printed representation,
that is, not the G bit) is set. It is just a bit.
But it is a bit that we set when we make use of an EUI-64 for creating
an address, and don't set otherwise - and which thus, when we create the
address, is extremely unlikely to be a duplicate on the link. That is,
we set (or clear) it to achieve a purpose - once that has been achieved,
we cannot read any more into the address (bit) than that.
| My interpretation is that this is not the current state of things.
Probably not - but that's because people seem to be dreaming of some
state where they could tell that this IID was unique, and use it without
its prefix in some (currently unstated) way. If it were possible, that
would be nice. It just isn't possible.
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]
--------------------------------------------------------------------
