Could we switch this thread to where it belongs (the multi6 WG)? Brian Robert Elz wrote: > > Date: Tue, 3 Sep 2002 20:07:38 -0500 > From: Caitlin Bestler <caitlinb@rp.asomi.net> > Message-ID: <r01050300-1015-B4A10826BFA211D6B973003065D48EE0@[192.168.0.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 -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland