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

Ted Lemon <Ted.Lemon@nominum.com> Thu, 09 May 2002 16:51 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 MAA29406 for <dhcwg-archive@odin.ietf.org>; Thu, 9 May 2002 12:51:48 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA08805 for dhcwg-archive@odin.ietf.org; Thu, 9 May 2002 12:51:56 -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 MAA08371; Thu, 9 May 2002 12:47:24 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08351 for <dhcwg@optimus.ietf.org>; Thu, 9 May 2002 12:47:22 -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 MAA29133 for <dhcwg@ietf.org>; Thu, 9 May 2002 12:47:13 -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 g49GkIS13356; Thu, 9 May 2002 09:46:18 -0700 (PDT)
Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g49GlJ600685; Thu, 9 May 2002 11:47:19 -0500 (CDT)
Date: Thu, 09 May 2002 11:47:19 -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: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>, Ralph Droms <rdroms@cisco.com>, dhcwg@ietf.org
To: Thomas Narten <narten@us.ibm.com>
From: Ted Lemon <Ted.Lemon@nominum.com>
In-Reply-To: <200205091342.g49DgF205830@cichlid.adsl.duke.edu>
Message-Id: <6CFD3458-636C-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

> Hmm. If this message is OPTIONAL to implement, this needs to be made
> clear in the spec. I assumed it was mandatory. I think it should be
> mandatory. If it is not, there is little point in clients implementing
> it. I.e., it doesn't make sense for clients to implement basic
> features that servers aren't required to implement. This leads to bad
> interoperability.

This is a case where the market will quickly punish servers that don't 
implement it that should.   We aren't even insisting that address 
allocation is mandatory, AFAIK, so saying that confirm is mandatory seems 
inconsistent.   That is, it is fine to implement a DHCPv6 server that only 
responds to information requests and that does not allocate IP addresses.   
A DHCP server configured to just provide information might not even have 
enough information to determine whether or not a client is on the link on 
which its addresses are valid.


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