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