RE: Multihoming Issues

Caitlin Bestler <caitlinb@rp.asomi.net> Wed, 04 September 2002 01:31 UTC

Received: from loki.ietf.org (loki [10.27.2.29]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19690; Tue, 3 Sep 2002 21:31:12 -0400 (EDT)
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id VAA06353 for ietf-outbound.09@loki.ietf.org; Tue, 3 Sep 2002 21:10: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 VAA06319 for <ietf-mainout@loki.ietf.org>; Tue, 3 Sep 2002 21:07:49 -0400 (EDT)
Received: by ietf.org (8.9.1a/8.9.1a) id VAA19205 for ietf-mainout@loki.ietf.org; Tue, 3 Sep 2002 21:06:10 -0400 (EDT)
X-Authentication-Warning: ietf.org: majordom set sender to owner-ietf@ietf.org using -f
Received: from rp.asomi.net (64-144-5-25.client.dsl.net [64.144.5.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19201 for <ietf@ietf.org>; Tue, 3 Sep 2002 21:06:06 -0400 (EDT)
Received: from 192.168.0.2 (g4.asomi.net [192.168.0.2]) by rp.asomi.net (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id g83MExt02239; Tue, 3 Sep 2002 17:14:59 -0500
Date: Tue, 03 Sep 2002 20:07:38 -0500
From: Caitlin Bestler <caitlinb@rp.asomi.net>
Subject: RE: Multihoming Issues
To: Christian Huitema <huitema@windows.microsoft.com>, ietf@ietf.org
X-Priority: 3
In-Reply-To: <F66A04C29AD9034A8205949AD0C90104032709DE@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Message-ID: <r01050300-1015-B4A10826BFA211D6B973003065D48EE0@[192.168.0.2]>
MIME-Version: 1.0
Content-Type: text/plain; Charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Mailsmith 1.5.3 (Blindsider)
Content-Transfer-Encoding: 7bit
Sender: owner-ietf@ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
X-Loop: ietf@ietf.org
Content-Transfer-Encoding: 7bit

On 9/3/02, Christian Huitema wrote:

>> The relationship is that DNS is acting as an index
>> service for IPv6 addresses. In doing so it treats them
>> as simple hierarchical  addresses, i.e. like fat IPv4
>> addresses.
>> 
>> The question as to whether that is the correct handling
>> of IPv6 addresses is a valid one. This thread started
>> with exactly such a question being raised, but the
>> rationale on how DNS *could* be optimized for IPV6 was
>> not spelled out.
>
>There is no IPv6 service that guarantees that the
>identifiers are actually world-wide unique. In fact, there
>is ample evidence that they often will not be. Poorly
>configured interface cards are known to have phony
>IEEE-802 addresses; privacy addresses are random numbers
>that are only statistically unique; configured addresses
>may use user assigned values. In all these cases, local
>collisions can be detected, global collisions cannot be. 
>

By "no IPv6 service" do you mean there is no active protocol
and/or entity that will detect a spoofed EUI-64 address? If
so, I agree with you. The fact that the interface ID must be
EUI-64 compliant is abundantly clear in the RFC, however.

Link-local interface IDs MUST be unique for the local
network, although the mechanism for ensuring this is not
specified.

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."

As for local Interface IDs. RFC2373 specifies in Appendix A:
"If there is no global interface identifier available for
use on the link the implementation needs to create a local
scope interface identifier.  The only requirement is that it
be unique on the link."

>There is also no requirement that a given multi-homed
>hosts combines the same identifier with different
>prefixes. Privacy advocates will no doubt argue that a
>multi-homed host should associate different identifiers
>with different provider prefixes, so it cannot be tracked
>by big-brother.

It can also be argued that a given link should have exactly
one Interface ID. It is specified as an attribute of the
Interface. Although obviously there would be little to
prevent someone from spoofing that. The question would be
whether it was permissiable to declare the same port on the
same NIC to be two different "NICs".

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.



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 are
differences. It was not a nonsensical question, as it was
being treated. However, there is far from enough
justification for handling IPv6 differently.