Re: Multihoming Issues

"Caitlin Bestler" <caitlinb@rp.asomi.net> Sat, 31 August 2002 13:02 UTC

Received: from loki.ietf.org (loki [10.27.2.29]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02206; Sat, 31 Aug 2002 09:02:04 -0400 (EDT)
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA13495 for ietf-outbound.10@loki.ietf.org; Sat, 31 Aug 2002 09:00: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 IAA13468 for <ietf-mainout@loki.ietf.org>; Sat, 31 Aug 2002 08:58:39 -0400 (EDT)
Received: by ietf.org (8.9.1a/8.9.1a) id IAA02122 for ietf-mainout@loki.ietf.org; Sat, 31 Aug 2002 08:57:05 -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 IAA02112 for <ietf@ietf.org>; Sat, 31 Aug 2002 08:56:40 -0400 (EDT)
Received: from julian (208-41-143-203.client.dsl.net [208.41.143.203]) by rp.asomi.net (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with SMTP id g7VA93p17782 for <ietf@ietf.org>; Sat, 31 Aug 2002 05:09:03 -0500
Message-ID: <001501c250ed$c7a8e0c0$cb00a8c0@asomi.net>
From: Caitlin Bestler <caitlinb@rp.asomi.net>
To: ietf@ietf.org
References: <Pine.LNX.4.44.0208301955410.6840-100000@filesrv1.baby-dragons.com>
Subject: Re: Multihoming Issues
Date: Sat, 31 Aug 2002 07:56:09 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: owner-ietf@ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
X-Loop: ietf@ietf.org
Content-Transfer-Encoding: 7bit

>
> Hello Scott ,  A little more definition to the picture would be
> nice .  Tia ,  JImL
>

The potential mismatch between IPv6 and classic DNS is that
an IPv6 unicast address is structured in two parts: the network
identifier (the high 64 bits) and an Interface ID (the low 64 bits).

Half of the Interface IDs are globally unique, the other half are
assigned locally within the network.

For the half that are globally unique, a query system could be defined
to look up that address and return the network(s) where it was found.
Even if it is a local identifier, if the host network is known by multiple
network identifiers the interface id would still be the same across all
of the possible identities. (There may be a loophole there, but that
is clearly the intent of the spec.) Again, a directory service could
optimize its representation of the data to take advantage of these
correlations.

If such optimizations are done, the question remains of whether they should
be part of the DNS service. The "non-optimizing" solution minimizes the code
impact and encourages early support for IPv6 on networks that remain
primarily IPv4.

In my opinion, any optimizations are best left until after a measurable
problem is starting to develop and mobile IP solutions are fully deployed,
as that the solution is likely to overlap with mobile support.