[dhcwg] dhcpv6-24: comparing client parameters and server state
Ralph Droms <rdroms@dhcp-161-44-149-149.cisco.com> Thu, 16 May 2002 13:14 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 JAA23652 for <dhcwg-archive@odin.ietf.org>; Thu, 16 May 2002 09:14:54 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA11561 for dhcwg-archive@odin.ietf.org; Thu, 16 May 2002 09:15:08 -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 JAA11492; Thu, 16 May 2002 09:12:43 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA11467 for <dhcwg@optimus.ietf.org>; Thu, 16 May 2002 09:12:41 -0400 (EDT)
Received: from dhcp-161-44-149-149.cisco.com (dhcp-161-44-149-149.cisco.com [161.44.149.149]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23566 for <dhcwg@ietf.org>; Thu, 16 May 2002 09:12:27 -0400 (EDT)
Received: (from rdroms@localhost) by dhcp-161-44-149-149.cisco.com (8.11.6/8.11.6) id g4GDC9P01719; Thu, 16 May 2002 09:12:09 -0400
Date: Thu, 16 May 2002 09:12:09 -0400
Message-Id: <200205161312.g4GDC9P01719@dhcp-161-44-149-149.cisco.com>
From: Ralph Droms <rdroms@dhcp-161-44-149-149.cisco.com>
To: dhcwg@ietf.org
CC: rdroms@cisco.com
Reply-to: rdroms@cisco.com
Subject: [dhcwg] dhcpv6-24: comparing client parameters and server state
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
Narten: > 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... 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. Response: Changed use of T1/T2 and lifetimes in Confirm message from client. Client uses those fields for preferred values or sets to 0. Server checks only addresses for correctness and returns values chosen by server for T1/T2 and lifetimes. *** dhcpv6.tty Thu May 16 08:44:51 2002 --- dhcpv6-24.txt Tue Apr 23 15:35:14 2002 *************** *** 2220,2229 **** The client MUST include a Client Identifier option to identify itself to the server. The client adds any appropriate options, including one or more IA options. The client MUST include the addresses the ! client currently has associated with those IAs. The client fills in ! the T1 and T2 fields in the IA options and the preferred-lifetime and ! valid-lifetime fields in the IA Address options with preferred values ! or 0 if the client has no preference about those values. If the client chooses to request specific options from the server, it does so by including an Option Request option (see section 22.7, --- 2287,2293 ---- The client MUST include a Client Identifier option to identify itself to the server. The client adds any appropriate options, including one or more IA options. The client MUST include the addresses the ! client currently has associated with those IAs. If the client chooses to request specific options from the server, it does so by including an Option Request option (see section 22.7, *************** *** 2721,2756 **** When the server receives a Confirm message, the client is requesting confirmation that the configuration information it will use is valid. ! The server compares the addresses in the IA Address options in the ! Confirm message from the client with the addresses in the binding for ! the client. ! ! If the server finds that the addresses in the Confirm message do not ! match what is in the binding for that client or the addresses in ! the Confirm message are not appropriate for the link from which the ! client sent the Confirm message, the server sends a Reply message ! containing a Status Code option with the value ConfNoMatch. ! If the server finds that the addresses in the Confirm message match ! the addresses in the binding for that client, and the configuration information is still valid, the server sends a Reply message containing a Status Code option with the value Success. - If the server cannot determine if the information in the Confirm - message is valid or invalid, the server MUST NOT send a reply to the - client. For example, if the server does not have a binding for the ! Droms (ed.), et al. Expires 22 Oct 2002 [Page 41] Internet Draft DHCP for IPv6 (-24) 22 Apr 2002 client, but the configuration information in the Confirm message appears valid, the server does not reply. ! The server constructs a Reply message by setting the "msg-type" field to REPLY, copying the transaction ID from the Confirm message into the transaction-ID field. --- 2785,2820 ---- 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. ! ! If the server finds that the information for the client does not ! match what is in the binding for that client or the configuration ! information is not valid, the server sends a Reply message containing ! a Status Code option with the value ConfNoMatch. ! If the server finds that the information for the client does match ! the information in the binding for that client, and the configuration information is still valid, the server sends a Reply message containing a Status Code option with the value Success. ! ! Droms (ed.), et al. Expires 22 Oct 2002 [Page 42] Internet Draft DHCP for IPv6 (-24) 22 Apr 2002 + If the server cannot determine if the information in the Confirm + message is valid or invalid, the server MUST NOT send a reply to the + client. For example, if the server does not have a binding for the client, but the configuration information in the Confirm message appears valid, the server does not reply. ! The server contructs a Reply message by setting the "msg-type" field to REPLY, copying the transaction ID from the Confirm message into the transaction-ID field. *************** *** 2758,2771 **** server's DUID and the Client Identifier option from the Confirm message in the Reply message. - The server includes IA options for each of the IA options in the - Confirm message. The server chooses values for T1, T2 and lifetimes - for each of the addresses in the IAs according to the server's - configured policies. The values for T1, T2 and the lifetimes sent by - the client are the client's preferences for those values. The server - also includes options for any other configuration information to be - sent to the client. - The Reply message from the server MUST include a Status Code option. --- 2822,2827 ---- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] dhcpv6-24: comparing client parameters an… Thomas Narten
- Re: [dhcwg] dhcpv6-24: comparing client parameter… Ralph Droms
- [dhcwg] dhcpv6-24: comparing client parameters an… Ralph Droms
- [dhcwg] dhcpv6-24: comparing client parameters an… Ralph Droms