Re: Multihoming Issues

[Brian E Carpenter <[e-mail]>]

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 <[e-mail]>
>     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