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

[Ralph Droms <[e-mail]>]

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
compares 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 ----
***************
*** 2794,2816 ****
     server may choose to change the list of addresses and the lifetimes
     of addresses in IAs that are returned to the client.
  
!    The server constructs a Reply message by setting the "msg-type" field
     to REPLY, copying the transaction ID from the Renew message into the
     transaction-ID field.
  
  
  
  
  
  
- Droms (ed.), et al.            Expires 22 Oct 2002             [Page 42]
- 
- Internet Draft              DHCP for IPv6 (-24)              22 Apr 2002
  
  
!    The server MUST include a Server Identifier option containing the
!    server's DUID and the Client Identifier option from the Renew message
!    in the Reply message.
  
  
  18.2.4. Receipt of Rebind messages

_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg