Re: Multihoming Issues

["Jim Fleming" <[e-mail]>]

From: "Brian E Carpenter" <[e-mail]>
> 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" <[e-mail]>
To: "Robert Elz" <[e-mail]>
Cc: "Caitlin Bestler" <[e-mail]>; "Christian Huitema" <[e-mail]>; <[e-mail]>
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 <[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
>