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
- RE: [dhcwg] Changes to remove "client-link-local-… Bernie Volz (EUD)
- RE: [dhcwg] Changes to remove "client-link-local-… Bernie Volz (EUD)
- RE: [dhcwg] Changes to remove "client-link-local-… Bernie Volz (EUD)
- Re: [dhcwg] Changes to remove "client-link-local-… Josh Littlefield
- RE: [dhcwg] Changes to remove "client-link-local-… Ralph Droms
- RE: [dhcwg] Changes to remove "client-link-local-… Bernie Volz (EUD)
- Re: [dhcwg] Changes to remove "client-link-local-… Ralph Droms
- RE: [dhcwg] Changes to remove "client-link-local-… Bernie Volz (EUD)
- Re: [dhcwg] Changes to remove "client-link-local-… Ted Lemon
- RE: [dhcwg] Changes to remove "client-link-local-… Bernie Volz (EUD)
- RE: [dhcwg] Changes to remove "client-link-local-… Bernie Volz (EUD)
- Re: [dhcwg] Changes to remove "client-link-local-… Josh Littlefield
- Re: [dhcwg] Changes to remove "client-link-local-… Ted Lemon
- Re: [dhcwg] Changes to remove "client-link-local-… Ralph Droms
- Re: [dhcwg] client unicast/client unicast option Ted Lemon
- Re: [dhcwg] Incorporation of WG last call comment… Ted Lemon
- Re: [dhcwg] Assigning DHCPv6 option codes Thomas Narten
- Re: FW: [dhcwg] co-existence of temp and normal a… Thomas Narten
- Re: FW: [dhcwg] co-existence of temp and normal a… Thomas Narten
- Re: [dhcwg] dhcpv6-24: Rapid Commit Thomas Narten
- Re: [dhcwg] dhcpv6-24: movement detection and Con… Thomas Narten
- Re: [dhcwg] dhcpv6-24: movement detection and Con… Thomas Narten
- Re: [dhcwg] dhcpv6-24: use of anycast Thomas Narten
- Re: [dhcwg] dhcpv6-24: Interface-ID option Thomas Narten
- Re: [dhcwg] dhcpv6-24: Temporary addresses Thomas Narten
- Re: [dhcwg] dhcpv6-24: movement detection and Con… Thomas Narten
- Re: [dhcwg] dhcpv6-24: movement detection and Con… Ted Lemon
- Re: [dhcwg] DHCP Option for CableLabs Client Conf… Thomas Narten
- Re: [dhcwg] status of draft-ietf-dhc-agent-subnet… Thomas Narten
- Re: [dhcwg] Conflicting information regarding DHC… Thomas Narten
- Re: [dhcwg] RE: I-D ACTION:draft-droms-dhcp-relay… Thomas Narten