Date: Tue, 3 Sep 2002 20:07:38 -0500
From: Caitlin Bestler <caitlinb(_at_)rp(_dot_)asomi(_dot_)net>
Message-ID:
<r01050300-1015-B4A10826BFA211D6B973003065D48EE0(_at_)[192(_dot_)168(_dot_)0(_dot_)2]>
| The fact that the interface ID must be
| EUI-64 compliant is abundantly clear in the RFC, however.
No, go and read it again. That's only an option.
| Link-local interface IDs MUST be unique for the local
| network, although the mechanism for ensuring this is not
| specified.
That's DAD, and though "ensure" might be a bit much, it will
generally work. But what LL addresses do, and what others do,
are pretty much irrelevant, "1" as an interface ID might be
just fine on its link, but it certainly isn't going to be unique
anywhere else.
| RFC2464 is specific on the handling of emulation MAC
| addresses: "A different MAC address set manually or by
| software should not be used to derive the Interface
| Identifier. If such a MAC address mustbe used, its global
| uniqueness property should be reflected in the value of the
| U/L bit."
Yes, it says that. And it shouldn't. That's a completely bogus and
unimplementable requirement. Nor is it useful for anything.
To show unimplementable, note that on many systems, the way (or at least,
a way) to change the MAC address, is via the boot prom, when no OS (or
network stack) yet exists. When the OS, and its net stack is booted,
all it sees is a MAC address in a flash, or eeprom, or something, with
no knowledge at all of how it got there, or who put the thing there.
There's no way that the software implementing IPv6 can possibly know that
this particular MAC address was set "manually" and avoid using it, or even
alter the U/L bit.
Nor does anything try.
| It can also be argued that a given link should have exactly
| one Interface ID.
Almost anything can be argued, but there's no rational reason for that.
And lots of reasons for not imposing any such requirement. Aside from
rfc3041 type addresses, there's also the case where a node is running as
a "hot standby" for another. When the other node crashes, the standby
takes over all of the crashed node's functions - which includes all its
addresses and interface ID's (in addition to its own).
| In full privacy paranoia mode, "how many ports I really have
| is none of your business" is a predictable and perhaps
| defendable response. However, in such a mode, the hostmaster
| would not have declared these two 'totally seperate'
| intrfaces to have the same name.
But in the situation above, often the two nodes will have had the
same name, they're both "www.whatever". The DNS returns 2 addresses
(the primary, and the standby) and the client picks one at random and
used it, so the load gets split. Then one of the nodes goes down,
and the other takes over both addresses. So, they're two totally
separate interfaces (sometimes), two totally separate IIDs (always)
and the same name.
| Lastly, I am NOT advocating any change. I merely responded
| to an implication that there was no justification for
| handling DNS for IPV6 differently than for IPv4.
There should have been, we should be doing A6 for IPv6, that would
have made lots of sense.
Nothing you're suggesting seems to be useful though.
kre