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

Ted Lemon <> Thu, 09 May 2002 16:51 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id MAA29406 for <>; Thu, 9 May 2002 12:51:48 -0400 (EDT)
Received: (from daemon@localhost) by (8.9.1a/8.9.1) id MAA08805 for; Thu, 9 May 2002 12:51:56 -0400 (EDT)
Received: from (localhost []) by (8.9.1a/8.9.1) with ESMTP id MAA08371; Thu, 9 May 2002 12:47:24 -0400 (EDT)
Received: from (odin []) by (8.9.1a/8.9.1) with ESMTP id MAA08351 for <>; Thu, 9 May 2002 12:47:22 -0400 (EDT)
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id MAA29133 for <>; Thu, 9 May 2002 12:47:13 -0400 (EDT)
Received: from ( []) by (8.11.3/8.6.11) with ESMTP id g49GkIS13356; Thu, 9 May 2002 09:46:18 -0700 (PDT)
Received: from tongpanyi (localhost []) by (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)" <>, Ralph Droms <>,
To: Thomas Narten <>
From: Ted Lemon <>
In-Reply-To: <>
Message-Id: <>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.481)
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <>
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