RE: Multihoming Issues

Caitlin Bestler <caitlinb@rp.asomi.net> Tue, 03 September 2002 19:53 UTC

Received: from loki.ietf.org (loki [10.27.2.29]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12093; Tue, 3 Sep 2002 15:53:41 -0400 (EDT)
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA04671 for ietf-outbound.09@loki.ietf.org; Tue, 3 Sep 2002 15:30: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 PAA04642 for <ietf-mainout@loki.ietf.org>; Tue, 3 Sep 2002 15:29:18 -0400 (EDT)
Received: by ietf.org (8.9.1a/8.9.1a) id PAA10713 for ietf-mainout@loki.ietf.org; Tue, 3 Sep 2002 15:27:42 -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 PAA10707 for <ietf@IETF.ORG>; Tue, 3 Sep 2002 15:27:37 -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 g83GaBt01244; Tue, 3 Sep 2002 11:36:11 -0500
Date: Tue, 03 Sep 2002 14:28:51 -0500
From: Caitlin Bestler <caitlinb@rp.asomi.net>
Subject: RE: Multihoming Issues
To: Michel Py <michel@arneill-py.sacramento.ca.us>
cc: ietf@ietf.org
X-Priority: 3
In-Reply-To: <2B81403386729140A3A899A8B39B04640BD057@server2000>
Message-ID: <r01050300-1015-6100B3F6BF7311D6A664003065D48EE0@[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/2/02, Michel Py wrote:

>> Caitlin Bestler wrote:
>> IPv4 is silent on how the lower portion is formed. IPv6
>> describes two techniques. Under IPv4 there is no reason
>> to presume that the same host will have the same network
>> identifier on multiple networks (other than the desire
>> of some network administrators to maintain some shred of
>> sanity). The method of generating the interface ID under
>> IPv6 would appear to be independent of the number of
>> identities that the network itself has.
>
>I still fail to see the relation with DNS. What is the
>point you are trying to make here?
>
>Michel.
>

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.

The current IPv6 mapping is a "false" data structuring, in
that it can represent data that could not exist in the real
world:

1 - It can represent the same globally unique EUI-64 as
having multiple contradictory meanings on multiple networks.

2 - It can represent the same local interface ID as having
multiple contradictory meanings via different aliases for
the same local network.

These are both releated to the fact that an IPv6 address is
not just 128 bits. It has a structure, in fact quite a bit
more structure than an IPv4 address has.

That is why a naming or discovery service COULD be optimized
specifically for IPv6. That does not mean that it should be.
In fact, I fully agree that treating IPv6 addresses as
nothing more than really fat IPv4 addresses is the best
migration strategy available.

However, as noted earlier, the fact that an optimization is
*possible* is not the same thing as justifying it. The
benefit of the "just a fat IPv4 address" approach is that it
simplified migration of existing IPv4 DNS code to IPv6. This
should not be overlooked. I doubt that there are more than a
few machine with access to an IPV6 local network that do no
have IPv6 stack and DNS software already installed on them.

If, at some future date, we discover that name servers are
cluttered with redundant information about multi-homed IPv6
hosts we could consider optimizing based upon the structure
of the IPv6 address.