Re: Multihoming Issues
Robert Elz <kre@munnari.OZ.AU> Wed, 04 September 2002 07:55 UTC
Received: from loki.ietf.org (loki [10.27.2.29]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19883; Wed, 4 Sep 2002 03:55:08 -0400 (EDT)
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id DAA22530 for ietf-outbound.09@loki.ietf.org; Wed, 4 Sep 2002 03:24:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id DAA22504 for <ietf-mainout@loki.ietf.org>; Wed, 4 Sep 2002 03:21:05 -0400 (EDT)
Received: by ietf.org (8.9.1a/8.9.1a) id DAA19484 for ietf-mainout@loki.ietf.org; Wed, 4 Sep 2002 03:19:28 -0400 (EDT)
X-Authentication-Warning: ietf.org: majordom set sender to owner-ietf@ietf.org using -f
Received: from ratree.psu.ac.th ([202.28.97.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19465 for <ietf@ietf.org>; Wed, 4 Sep 2002 03:18:22 -0400 (EDT)
Received: from delta.cs.mu.OZ.AU ([172.30.0.189]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g847Isg26942; Wed, 4 Sep 2002 14:18:55 +0700 (ICT)
Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g847Fxu03360; Wed, 4 Sep 2002 14:16:05 +0700 (ICT)
From: Robert Elz <kre@munnari.OZ.AU>
To: Caitlin Bestler <caitlinb@rp.asomi.net>
cc: Christian Huitema <huitema@windows.microsoft.com>, ietf@ietf.org
Subject: Re: Multihoming Issues
In-Reply-To: <r01050300-1015-B4A10826BFA211D6B973003065D48EE0@[192.168.0.2]>
References: <r01050300-1015-B4A10826BFA211D6B973003065D48EE0@[192.168.0.2]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 04 Sep 2002 14:15:59 +0700
Message-ID: <3358.1031123759@munnari.OZ.AU>
Sender: owner-ietf@ietf.org
Precedence: bulk
X-Loop: ietf@ietf.org
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
- Multihoming Issues Sister Sibling
- Re: Multihoming Issues Valdis.Kletnieks
- Re: Multihoming Issues Joe Abley
- Re: Multihoming Issues Fred Baker
- Re: Multihoming Issues David Conrad
- Re: Multihoming Issues Scott Bradner
- Re: Multihoming Issues J. Noel Chiappa
- Re: Multihoming Issues Mr. James W. Laferriere
- RE: Multihoming Issues Michel Py
- Re: Multihoming Issues Caitlin Bestler
- RE: Multihoming Issues Michel Py
- Re: Multihoming Issues Simon Leinen
- RE: Multihoming Issues Caitlin Bestler
- RE: Multihoming Issues Michel Py
- RE: Multihoming Issues Caitlin Bestler
- RE: Multihoming Issues Michel Py
- Re: Multihoming Issues Jim Fleming
- RE: Multihoming Issues Christian Huitema
- RE: Multihoming Issues Caitlin Bestler
- Re: Multihoming Issues Keith Moore
- Re: Multihoming Issues David Conrad
- Re: Multihoming Issues Robert Elz
- Re: Multihoming Issues Jim Fleming
- Re: Multihoming Issues Brian E Carpenter
- Re: Multihoming Issues Jim Fleming
- Re: Multihoming Issues Caitlin Bestler
- Re: Multihoming Issues Jim Fleming
- Re: Multihoming Issues Valdis.Kletnieks
- Re: Multihoming Issues Jim Fleming
- Re: Multihoming Issues Simon Leinen
- RE: Multihoming Issues Tony Hain
- RE: Multihoming Issues Michel Py