[dhcwg] Comments on draft-ietf-dhc-dual-stack-01

"Dave Thaler" <dthaler@windows.microsoft.com> Wed, 04 August 2004 16:33 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16433; Wed, 4 Aug 2004 12:33:28 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsOGU-0004lB-R3; Wed, 04 Aug 2004 12:05:18 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs6W4-0003U8-9P for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 17:08:12 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12125 for <dhcwg@ietf.org>; Tue, 3 Aug 2004 17:08:10 -0400 (EDT)
Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs6ZC-0001TN-Ha for dhcwg@ietf.org; Tue, 03 Aug 2004 17:11:27 -0400
Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Tue, 3 Aug 2004 14:08:03 -0700
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Aug 2004 14:07:31 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Aug 2004 14:07:43 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 3 Aug 2004 14:07:02 -0700
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 3 Aug 2004 14:07:36 -0700
Message-ID: <C9588551DE135A41AA2626CB645309370A70351F@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: Comments on draft-ietf-dhc-dual-stack-01
thread-index: AcR4eCq1jb72togVQ56ZwYkNOtjSkABH2TogAAEk7GA=
From: "Dave Thaler" <dthaler@windows.microsoft.com>
To: <dhcwg@ietf.org>
X-OriginalArrivalTime: 03 Aug 2004 21:07:02.0960 (UTC) FILETIME=[D2F95B00:01C4799D]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Wed, 04 Aug 2004 12:05:16 -0400
Subject: [dhcwg] Comments on draft-ietf-dhc-dual-stack-01
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
Content-Transfer-Encoding: quoted-printable

This draft is still missing a discussion of one of the issues that has
been raised a couple times in the past, including during the WG
discussion of this draft last IETF.

Specifically, the issue occurs with any option that includes a list of
addresses of servers (e.g., DNS server addresses).  The reason for
having a list in the first place is to allow the client to try an
alternate address in the event that the first one it tries fails.  When
such a failure occurs, it may be for either of two reasons:
a) The server has failed
b) Connectivity via IPv4 or IPv6 has failed

When you have a set of dual-stack servers and dual-stack clients, and
the first attempt fails, to maximize the chance that the next attempt
will succeed in the absence of being able to distinguish between (a) and
(b), the client should try a different server, via a different protocol.

The problem today is that you get the IPv4 list via DHCPv4 and the IPv6
list via DHCPv6, and the client has no way to really "try a different
server", since that information is lost by the protocol, even though it
may be known by the server.

Just putting merging heuristics in the client cannot provide the best
behavior, since information is lost.  By comparison, if IPv4-mapped
addresses were included in the DHCPv6 option along with IPv6 addresses,
the DHCP server can give an intelligent order that takes into account
which addresses are of the same DNS/whatever server.  Of course, v6-only
clients have to know to discard the v4-mapped addresses in this
solution, and it's much easier to solve this in the combined-DHCP-server
case than in the two-server case.

I believe this draft needs to discuss this dual-stack issue and its
implications.

-Dave

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg