Re: [dhcwg] dhcpv6-24: comparing client parameters and server state

Ralph Droms <rdroms@cisco.com> Thu, 09 May 2002 00:02 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 UAA26687 for <dhcwg-archive@odin.ietf.org>; Wed, 8 May 2002 20:02:28 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA06950 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 20:02:36 -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 TAA05852; Wed, 8 May 2002 19:51:22 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA05823 for <dhcwg@optimus.ietf.org>; Wed, 8 May 2002 19:51:20 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26379 for <dhcwg@ietf.org>; Wed, 8 May 2002 19:51:11 -0400 (EDT)
Received: from rdroms-w2k.cisco.com (sjc-vpn1-536.cisco.com [10.21.98.24]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA27813; Wed, 8 May 2002 19:50:34 -0400 (EDT)
Message-Id: <4.3.2.7.2.20020508191124.030e5278@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 08 May 2002 19:19:33 -0400
To: Thomas Narten <narten@us.ibm.com>
From: Ralph Droms <rdroms@cisco.com>
Subject: Re: [dhcwg] dhcpv6-24: comparing client parameters and server state
Cc: dhcwg@ietf.org, rdroms@cisco.com
In-Reply-To: <200205081507.g48F7M819234@rotala.raleigh.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
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

At 11:07 AM 5/8/2002 -0400, Thomas Narten wrote:
> > 18.2.2. Receipt of Confirm messages
> >
> >    When the server receives a Confirm message, the client is requesting
> >    confirmation that the configuration information it will use is valid.
> >    The server locates the binding for that client and compares the
> >    information in the Confirm message from the client to the information
> >    associated with that client.
>
>Couple of thoughts. The document doesn't really define "compare". Do
>the Lifetimes have to be equal? I would assume not, but this is not
>stated...

OK - the clarification should, I think, be that the server compares the
addresses only and ignores the lease expiration time.


>Also, does the Confirm include *only* IAs that were assigned by that
>server? If not, seems like confirm will fail (i.e, if a client has IAs
>from different servers). Is the text clear on this? (I don't bthink
>the text says only include IAs allocated from the server to which the
>confirm is being sent.)
>
>Some clarifying text would seem to be needed here.

The Confirm message is multicast and received by potentially more
than one server.  I think each server only checks the IAs that it
(the server) has a record of.


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


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