RE: [dhcwg] Changes to remove "client-link-local-address" from th e DHCPv6 header

["Bernie Volz (EUD)" <[e-mail]>]

Ralph:

RD> Why the change?

Just thought it was clearer where the server address comes from.

RD> I leave this for the IA option and semantics design.

No problem.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:[e-mail]]
Sent: Wednesday, August 29, 2001 7:45 PM
To: Bernie Volz (EUD)
Cc: [e-mail]
Subject: RE: [dhcwg] Changes to remove "client-link-local-address" from
th e DHCPv6 header


Bernie,

Thanks for you careful review of the new text.  I made all
of the changes you suggested, except as noted below (RD>)

- Ralph

14.3.1. Creation and sending of Request messages 

   If a client has no valid IPv6 addresses of sufficient scope to 
   communicate with a DHCP server, it may send a Request message to 
BV> Why "communicate with a DHCP server"? And the client could well 
BV> have many addresses of sufficient scope - that's not the point 
BV> of the request. We really should just say that "If the client 
BV> is using stateful address configuration and either needs an 
BV> initial set of address or additional addresses, it MUST send a 
BV> Request message to obtain new addresses." (or something like that) 
   obtain new addresses.  The client includes one or more IAs in the 
   Request message, to which the server assigns new addresses.  The 
   server then returns IA(s) to the client in a Reply message. 

   The client generates a transaction ID and inserts this value in the 
   "transaction-ID" field. 

   The client places the address of the destination server in the 
   "server-address" field. 
BV> How about "The client copies the "server-address" field as received in 
BV> the selected Advertise message to the "server-address" field of the 
BV> Request." 

RD> Why the change?

   The client adds a DUID option to identify itself to the server.  The 
   client adds any other appropriate options, including one or more IA 
   options (if the client is requesting that the server assign it some 
   network addresses).  The list of addresses in each included IA MUST 
   be empty.  If the client is not requesting that the server assign it 
BV> IA MUST be empty? This wasn't what we had been discussing?? Wasn't 
BV> it that people wanted the addresses received in the Advertise to be 
BV> used here? 

RD> I leave this for the IA option and semantics design.

   any addresses, the client omits the IA option. 

   The client sends the Request message to the All DHCP Agents multicast 
   address through the interface for which the client is interested in 
   obtaining configuration information, with the destination port set 
   to 547.  The source port selection can be arbitrary, although it 
   SHOULD be possible using a client configuration facility to set a 
   specific source port value. 

   The server will respond to the Request message with a Reply 
   message.  If no Reply message is received within REP_MSG_TIMEOUT 
   milliseconds, the client retransmits the Request with the same 
   transaction-ID, and doubles the REP_MSG_TIMEOUT value, and waits 
   again.  The client continues this process until a Reply is received 
   or REQUEST_MSG_ATTEMPTS unsuccessful attempts have been made, at 
   which time the client MUST abort the configuration attempt.  The 
   client SHOULD report the abort status to the application layer. 

   Default and initial values for REP_MSG_TIMEOUT and REQ_MSG_ATTEMPTS 
   are documented in section 7.5.