From: "Brian E Carpenter" <brian@hursley.ibm.com> > Could we switch this thread to where it belongs (the multi6 WG)? ============================= Would it not be more appropriate on an IPv6-based network ? Why would IPv4 users (here) care about A6 ? AAAA DNS records work just fine for IPv4++.... People remain ONLINE and migrate from 32-bits to 128-bits... 0:203 ONLINE http://www.adns.net/NEWS/2002070101.html http://www.name-space.com Jim Fleming 2002:[IPv4]:000X:03DB:...IPv8 is closer than you think... http://ipv8.dyndns.tv http://ipv8.yi.org http://ipv8.dyns.cx http://ipv8.no-ip.com http://ipv8.no-ip.org http://ipv8.no-ip.biz http://ipv8.no-ip.info http://www.iana.org/assignments/ipv4-address-space http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt ----- Original Message ----- From: "Brian E Carpenter" <brian@hursley.ibm.com> To: "Robert Elz" <kre@munnari.OZ.AU> Cc: "Caitlin Bestler" <caitlinb@RP.ASOMI.NET>; "Christian Huitema" <huitema@windows.microsoft.com>; <ietf@ietf.org> Sent: Wednesday, September 04, 2002 6:03 AM Subject: Re: Multihoming Issues > 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 >