RE: [dhcwg] DHCPv6 spec text for retransmission

[Ralph Droms <[e-mail]>]

My responses to Bernie's comments are inline (prefixed by RD>).  I've deleted much of the text that Bernie didn't comment on.

- Ralph

=====


Ralph: 

See my comments inline below (prefixed by BV>). 

Please do look at my comments in 15.3.4 (also applies to Renew). We have a protocol problem we likely need to correct! 

-----Original Message----- 
From: Ralph Droms [mailto:[e-mail]] 
Sent: Tuesday, September 04, 2001 9:49 PM 
To: [e-mail] 
Subject: [dhcwg] DHCPv6 spec text for retransmission 

Here is the new text in the DHCPv6 spec describing the 
transmission and retransmission mechanism for client 
messages.  Thanks to Ted for writing the first draft 
of this text. 

Notes: 
* I chose +-0.0625 (2^-4) as the limits on the 
  randomization factor to (potentially) make the 
  arithmetic a little easier.  Perhaps I misspent 
  too much of my youth writing 8080 assembler 
  code and it's just not important to worry about 
  setting those limits around powers of two.  If 
  +-0.1 makes more sense, that's fine with me. 
BV> I'd go with +/- 0.1 because almost all systems can do 
BV> floating point math these days and you likely need to 
BV> anyway. If a system can't, it can always fall back to 
BV> a "close" approximatation (such as +/- 0.0625). 
RD> OK - maybe a "SHOULD" (with some add'l text)
RD> rather than a "MUST"
RD> for clarity
* I did not choose to base the server 
  Reconfigure-init retransmission mechanism 
  on section 13.  I don't think the DHCPv6 spec 
  needs to dictate the behavior of the server when 
  retransmitting Reconfigure-init messages. 
* There are some references to the use of IAs; the 
  new IA text has not been finalized and does not 
  yet appear in the doc. 

Please review this new text and reply with comments... 

- Ralph 

7.5. Configuration Variables 

   This section presents a table of client and server configuration 
   variables and the default or initial values for these variables.  The 
   client-specific variables MAY be configured on the server and MAY be 
   delivered to the client through the "DHCP Retransmission Parameter 
   Option" in a Reply message. 
BV> Didn't we want to drop this retransmission parameter option 
BV> since it opens up many cans of worms as per the San Diego IETF?
RD>Right; I'll delete this text. 

      Parameter      Default Description 
   ------------------------------------- 
   MIN_SOL_DELAY           1 MIN (secs) to delay 1st mesg 
   MAX_SOL_DELAY           5 MAX (secs) to delay 1st mesg 
   ADV_TIMEOUT           500 SOL Retrans timer (msecs) 
   ADV_MAX_RT             30 MAX timer value (secs) 
   SOL_MAX_ATTEMPTS        0 MAX attempts (0 = infinite) 
   REP_TIMEOUT           250 Retrans timer (msecs) for Reply 
   REP_MAX_RT              0 MAX Retrans time (0 = infinite) 
   REQ_MAX_ATTEMPTS       10 MAX Request/Confirm/Renew/Rebind attempts 
   REL_MSG_ATTEMPTS        5 MAX Release/Decline attempts 
   SRVR_PREF_WAIT          2 Advertise Collect timer (secs) 


13. Reliability of Client Initiated Message Exchanges 

 [...]

   MRC specifies an upper bound on the number of times a client may 
   retransmit a message.  If MRC has a value of 0, the client MUST 
   continue to retransmit the original message until a response is 
   received.  Otherwise, the message exchange fails if the client 
   attempts to transmit the original message more than MRC times. 

   MRD specifies an upper bound on the length of time a client may 
   retransmit a message.  If MRD has a value of 0, the client MUST 
   continue to retransmit the original message until a response is 
   received.  Otherwise, the message exchange fails if the client 
   attempts to transmit the original message more than MRD seconds. 

BV> Just to be clear, might be good to say that EITHER or BOTH of 
BV> MRC or MRD can stop retransmissions? In most cases it appears 
BV> that only one is active, but it is always possible that both 
BV> could be. 
RD> OK.

14. DHCP Server Solicitation 

   This section describes how a client locates servers.  The behavior 
   of client and server implementations is discussed, along with the 
   messages they use. 

[...] 

14.3. Client Behavior 

   A client uses the Solicit message to discover DHCP servers configured 
   to serve addresses on the link to which the client is attached. 

14.3.1. Creation of Solicit messages 

   The client sets the "msg-type" field to SOLICIT. The client generates 
   a transaction ID and inserts this value in the "transaction-ID" 
   field. 
BV> While probably not something that is needed in this section, we 
BV> really don't have much text to describe the "transaction-ID". All 
BV> we generally say is to "generate a transaction ID". However, we 
BV> should make it clear to clients that they should attempt to 
BV> generate "unique" transaction ids. Unique here is best if it is 
BV> over a long period of time, but it must be longer than any cache 
BV> times in servers. Probably the best rule of thumb is for clients 
BV> to use to generate this number by incrementing it. Then the only 
BV> issue is what to set it to when (re)booting - especially if there 
BV> is no means to remember the last used number. 
RD>OK, I'll add text as you suggest...

   The client includes a DUID option to identify itself to the server. 
   The client MUST include options for any IAs to which it wants the 
   server to assign addresses.  The client may include addresses in the 
   IAs as a hint to the server about addresses for which the client 
   may have a preference.  The client MAY include an Option Request 
   Option in the Solicit message.  The client MUST NOT include any other 
   options except those specifically allowed as defined by specific 
   options. 

14.3.2. Transmission of Solicit Messages 

   The client sends the Solicit 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 client's first Solicit message on the interface MUST be delayed 
   by a random amount of time between MIN_SOL_DELAY and MAX_SOL_DELAY. 
   This random delay desynchronizes clients which start at the same time 
   (e.g., after a power outage). 

   The client transmits the message according to section 13, using the 
   following parameters: 

      IRT   ADV_TIMEOUT 

      MRC   SOL_MAX_ATTEMPTS 

      MRT   ADV_MAX_RT 

      MRD   0 

   The mechanism in section 13 is modified as follows for use in the 
   transmission of Solicit messages.  The message exchange is not 
   terminated by the receipt of an Advertise before ADV_MSG_TIMEOUT 
BV> ADV_MSG_TIMEOUT doesn't exist. I think you renamed it to 
BV> ADV_TIMEOUT? ADV_MSG_TIMEOUT is used many times. 
RD>Right; good catch.  I'll make those changes...

   has elapsed.  Rather, the client collects Advertise messages until 
   ADV_MSG_TIMEOUT has elapsed.  The first RT MUST be selected to be 
   strictly greater than ADV_MSG_TIMEOUT by choosing RAND to be strictly 
   greater than 0. 

   A DHCP client SHOULD choose MRC and MRT to be 0.  If the DHCP 
   client is otherwise configured, it MUST stop trying to configure 
   the interface if the message exchange fails.  After the DHCP client 
   stops trying to configure the interface, it MAY choose to restart 
   the reconfiguration process after some external event, such as user 
   input, system restart, or when the client is attached to a new link. 

BV> Did you mean MRD, not MRT? MRT limits the time of a single 
BV> retransmission. Also, the "If the DHCP client is otherwise configured" 
BV> made me re-read the paragraph several times. Perhaps there is a better 
BV> way to state this? "If the DHCP client is configured with a non-zero 
BV> MRC or MRD, ...". 
BV> Oh, might you want to say "SOL_MAX_ATTEMPTS" instead of MRC? 
RD>Yeah; on rereading, this isn't exactly clear.  I'll fix
RD>it.

BV> Also, this Retransmit logic is a bit weird beause of SRVR_PREF_WAIT. 
BV> Does it make sense to state something like "A client only retransmits 
BV> a Solicit if it fails to receive any Advertises before the retransmission 
BV> timer expires. If a client receives one or more Advertise messages, it 
BV> then must wait SRVR_PERF_WAIT seconds from the time of the transmit 
BV> for any additional Advertise messages before proceeding." 
RD>OK...

14.3.3. Receipt of Advertise messages 

[...] 

15. DHCP Client-Initiated Configuration Exchange 

[...] 

15.3. Client Behavior 

[...] 

15.3.1. Creation and transmission of Request messages 

[...]

15.3.2. Creation and transmission of Confirm messages 

[...]

15.3.3. Creation and transmission of Renew messages 

   IPv6 addresses assigned to a client through an IA use the same 
   preferred and valid lifetimes as IPv6 addresses obtained through 
   stateless autoconfiguration.  The server assigns preferred and valid 
   lifetimes to the IPv6 addresses it assigns to an IA. To extend those 
   lifetimes, the client sends a Request to the server containing an 
BV>                               Renew! 
RD>OK.
   "IA option" for the IA and its associated addresses.  The server 
   determines new lifetimes for the addresses in the IA according to the 
   server's administrative configuration.  The server may also add new 
   addresses to the IA. The server may remove addresses from the IA by 
   setting the preferred and valid lifetimes of those addresses to zero. 
   The server controls the time at which the client contacts the server 
   to extend the lifetimes on assigned addresses through the T1 and 
   T2 parameters assigned to an IA. If the server does not assign an 
   explicit value to T1 or T2 for an IA, T1 defaults to 0.5 times the 
   shortest preferred lifetime of any address assigned to the IA and 
   T2 defaults to 0.875 times the shortest preferred lifetime of any 
   address assigned to the IA. 
BV> Perhaps this is "not in this set of edits", but I think we did 
BV> decide to always have the server send T1/T2 times. Therefore, 
BV> there should be no need to have "defaults". 
RD>Yeah - I'm waiting until text on IA format and semantics is
RD>complete before doing final text here.

   At time T1 for an IA, the client initiates a Request/Reply message 
   exchange to extend the lifetimes on any addresses in the IA. The 
   client includes an IA option with all addresses currently assigned to 
   the IA in its Request message. 

   The client sets the "msg-type" field to RENEW. 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. 

   The client adds a DUID option to identify itself to the server.  The 
   client adds any appropriate options, including one or more IA options 
   (if the client is requesting that the server extend the lease on some 
   IAs; note that the client may check the status of other configuration 
   parameters without asking for lease extensions).  If the client does 
   include any IA options, it MUST include the list of addresses the 
   client currently has associated with that IA. 

   The client sends the Renew message to the All DHCP Agents multicast 
   address through the interface for which the client is interested 
   in extending 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 client transmits the message 
   according to section 13, using the following parameters: 

      IRT   REP_TIMEOUT 

      MRC   0 

      MRT   REP_MAX_RT 

      MRD   0 

   The mechanism in section 13 is modified as follows for use in the 
   transmission of Renew messages.  The message exchange is terminated 
   when time T2 is reached (see section 15.3.4), at which time the 
   client begins a Rebind message exchange. 
BV> One can also set MRD = T2-T1. The only issue there is that the 
BV> recovery step from the timeout is to start a REBIND. It should 
BV> be noted that the REBIND is a new message and not a retransmission 
BV> and therefore a new transaction ID must be chosen.
RD>I thought it was simpler to just use T1 and T2 directly
RD>rather than adjusting MRD.  I'll make the note about
RD>the transaction ID. 

15.3.4. Creation and transmission of Rebind messages 

[comments on 15.3.4 waiting for text on IAs...]

15.3.5. Receipt of Reply message in response to a Request, Confirm, 
   Renew or Rebind message 

[...] 

15.3.6. Creation and transmission of Release messages 

[...]

15.3.7. Receipt of Reply message in response to a Release message 

[...]

15.3.8. Creation and transmission of Decline messages 

[...]

15.3.9. Receipt of Reply message in response to a Decline message 

[...] 

b


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