Re: [dhcwg] dhcpv6-24: movement detection and Confirm message

Ted Lemon <Ted.Lemon@nominum.com> Wed, 08 May 2002 15:40 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13410 for <dhcwg-archive@odin.ietf.org>; Wed, 8 May 2002 11:40:08 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA07636 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 11:40:14 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07370; Wed, 8 May 2002 11:37:33 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07341 for <dhcwg@optimus.ietf.org>; Wed, 8 May 2002 11:37:32 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13242 for <dhcwg@ietf.org>; Wed, 8 May 2002 11:37:24 -0400 (EDT)
Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id g48FaGS09590; Wed, 8 May 2002 08:36:17 -0700 (PDT)
Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g48FbE600335; Wed, 8 May 2002 10:37:14 -0500 (CDT)
Date: Wed, 08 May 2002 10:37:14 -0500
Subject: Re: [dhcwg] dhcpv6-24: movement detection and Confirm message
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Mime-Version: 1.0 (Apple Message framework v481)
Cc: dhcwg@ietf.org
To: Thomas Narten <narten@us.ibm.com>
From: Ted Lemon <Ted.Lemon@nominum.com>
In-Reply-To: <200205081506.g48F6aB19222@rotala.raleigh.ibm.com>
Message-Id: <789B7E2C-6299-11D6-A5AB-00039367340A@nominum.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.481)
Content-Transfer-Encoding: 7bit
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org
Content-Transfer-Encoding: 7bit

What we've described in this section is precisely how the most functional 
DHCPv4 clients operate today - e.g., the Apple DHCPv4 client does link 
change detection, and in practice the user experience is much better than 
what you get with the ISC dhcp client, which does not do link change 
detection.   The confirm message is necessary.   Using RA messages to do 
link change detection is great, and we talked about it, but as you say, it 
requires an additional RA option on whose presence we cannot count at this 
time.

So I would say we should leave this just the way it is.


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