RE: [dhcwg] DHCPv6 spec text for retransmission

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 UAA13042; Thu, 6 Sep 2001 20:59:28 -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 UAA12609; Thu, 6 Sep 2001 20:57:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07421 for ; Thu, 6 Sep 2001 18:25:09 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10245 for ; Thu, 6 Sep 2001 18:23:41 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f86MOc518839 for ; Thu, 6 Sep 2001 17:24:38 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f86MOcq29144 for ; Thu, 6 Sep 2001 17:24:38 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Thu Sep 06 17:24:37 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Sep 2001 17:24:37 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B354D@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: "'Ralph Droms'" , dhcwg@ietf.org Subject: RE: [dhcwg] DHCPv6 spec text for retransmission Date: Thu, 6 Sep 2001 17:24:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C13722.B5E8E780" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C13722.B5E8E780 Content-Type: text/plain; charset="iso-8859-1" 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:rdroms@cisco.com] Sent: Tuesday, September 04, 2001 9:49 PM To: dhcwg@ietf.org 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). * 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? 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 DHCP clients are responsible for reliable delivery of messages in the client-initiated message exchanges described in sections 14 and 15. If a DHCP client fails to receive an expected response from a server, the client must retransmit its message. This section describes the retransmission strategy to be used by clients in client-initiated message exchanges. The client begins the message exchange by transmitting a message to the server. The message exchange terminates when either the client successfully receives the appropriate response or responses from a server or servers, or when the message exchange is considered to have failed according to the retransmission mechanism described below. The client retransmission behavior is controlled and describe by five variables: RT Retransmission timeout IRT Initial retransmission time MRC Maximum retransmission count MRT Maximum retransmission time MRD Maximum retransmission duration RAND Randomization factor With each message transmission or retransmission, the client sets RT according to the rules given below. If RT expires before the message exchange terminates, the client recomputes RT and retransmits the message. Each of the computations of a new RT include a randomization factor (RAND), which is a random number chosen with a uniform distribution between -0.0625 and +0.0625. The randomization factor is included to minimize synchronization of messages transmitted by DHCP clients. The algorithm for choosing a random number does not need to be cryptographically sound. The algorithm SHOULD produce a different sequence of numbers from each invocation of the DHCP client. RT for the first message transmission is based on IRT: RT = IRT + RAND*IRT RT for each subsequent message transmission is based on the previous value of RT: RT = RTprev + RAND*RTprev MRT specifies an upper bound on the value of RT. If MRT has a value of 0, there is no upper limit on the value of RT. Otherwise: if (RT > MRT) RT = MRT + RAND*MRT 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. 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. 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. 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? 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." 14.3.3. Receipt of Advertise messages A client MUST wait for SRVR_PREF_WAIT seconds after sending a DHCP Solicit message to collect Advertise messages, unless it receives an Advertise message with a preference value of 255. The preference value is carried in the Preference option (section 19.5). Any Solicit that does not include a Preference option is considered to have a preference value of 0. If the client receives an Advertise message with a preference value of 255, then the client MAY act immediately on that Advertise message without waiting for any more additional Advertise messages. Upon receipt of one or more validated Advertise messages, the client selects one or more Advertise messages based upon the following criteria. - Those Advertise messages with the highest server preference value are preferred over all other Advertise messages. - Within a group of Advertise messages with the same server preference value, a client MAY select those servers whose Advertise messages advertise information of interest to the client. For example, the client may choose a server that returned an advertisement with configuration options of interest to the client. Once a client has selected Advertise message(s), the client will typically store information about each server, such as server preference value, addresses advertised, when the advertisement was received, and so on. Depending on the requirements of the client's invoking user, the client MAY initiate a configuration exchange with the server(s) immediately, or MAY defer this exchange until later. If the client needs to select an alternate server in the case that a chosen server does not respond, the client chooses the server with the next highest preference value. The client MAY choose a less-preferred server if that server has a better set of advertised parameters, such as the available addresses advertised in IAs. [...] 15. DHCP Client-Initiated Configuration Exchange [...] 15.3. Client Behavior [...] 15.3.1. Creation and transmission of Request messages If the client is using stateful address configuration and needs either an initial set of addresses or additional addresses, it MUST send a Request message to obtain new addresses and other configuration information. 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. 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 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 client transmits the message according to section 13, using the following parameters: IRT REP_TIMEOUT MRC REQ_MAX_ATTEMPTS MRT REP_MAX_RT MRD 0 If the message exchange fails, the client MAY choose one of the following actions: - Select another server from a list of servers known to the client; e. g., servers that responded with an Advertise message - Initiate the server discovery described in section 14 - Terminate the configuration process and report failure 15.3.2. Creation and transmission of Confirm messages Whenever a client may have moved to a new link, its IPv6 addresses and other configuration information may no longer be valid. Examples of times when a client may have moved to a new link include: o The client reboots o The client is physically disconnected from a wired connection o The client returns from sleep mode o The client using a wireless technology changes cells In any situation when a client may have moved to a new link, the client MUST initiate a Confirm/Reply message exchange. The client includes any IAs, along with the addresses associated with those IAs, in its Confirm message. Any responding servers will indicate the acceptability of the addresses with the status in the IA it returns to the client. The client sets the "msg-type" field to CONFIRM. The client generates a transaction ID and inserts this value in the "transaction-ID" field. The client sets the "server-address" field to 0. 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 confirm the validity of some network addresses). 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 Confirm message to the All DHCP Agents multicast address through the interface for which the client is interested in confirming 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 REQ_MSG_ATTEMPTS MRT REP_MAX_RT MRD 0 If the message exchange fails, the client MUST restart the configuration process by locating a DHCP server as described in section 14. The client SHOULD report the failure of the configuration process to the application layer. 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! "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". 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. 15.3.4. Creation and transmission of Rebind messages At time T2 for an IA (which will only be reached if the server to which the Renew message was sent at time T1 has not responded), the client initiates a Rebind/Reply message exchange. The client includes an IA option with all addresses currently assigned to the IA in its Rebind message. The client sends this message to the All DHCP Agents multicast address. The client sets the "msg-type" field to REBIND. The client generates a transaction ID inserts this value in the "transaction-ID" field. The client sets the "server-address" field to 0. 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 does include any 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), it MUST include the list of addresses the client currently has associated with that IA. The client sends the Rebind 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 the lease for the IA expires (see section 11), at which time the client has several alternative actions to choose from: BV> Hum. This has some interesting problems (I don't know what Section BV> 11 refers to at this time, but don't recall the -19 draft having BV> much text in this area). The reason for the interesting problems BV> is because of the lifetime issue vs the T2 and renewal time. BV> What happens if an IA has two addresses. One has a valid lifetime BV> of 2 weeks. The other has a valid lifetime of 3 days. The T2 time BV> is 2 days. So, suppose the servers are non-responsive for 4 days. BV> When does the client stop retransmitting the message? When does it BV> alter it to remove the address with the expired lifetime (after 3 BV> days). Does this change to the message mean it MUST change the BV> XID? BV> I would suggest we say that MRD is shortest-valid-lifetime - T2. BV> Once that retransmission expires, the client must generate a BV> new Rebind message if there are *ANY* addresses still valid. It BV> stops only after all addresses are no longer valid. BV> We should also fix all the terminology such as "when the lease BV> on the IA expires"? It is really the valid lifetimes on the BV> individual addresses. BV> NOTE: The above issue for Rebind is *ALSO* a problem for Renew! BV> What if you had a third address with a 1 day valid lifetime BV> and T1 was 12 hours. 12 hours into the renew this third address BV> is gone and should be removed from the Renew. Hence, new message! BV> Hence, new transaction ID. Messy, messy, messy! - When the lease on the IA expires, the client may choose to use a Solicit message to locate a new DHCP server and send a Request for the expired IA to the new server - Some addresses in the IA may have lifetimes that extend beyond the lease of the IA, so the client may choose to continue to use those addresses; once all of the addresses have expired, the client may choose to locate a new DHCP server BV> Huh? How is this possible? There is no "lease" to an IA. An IA BV> dies when all of the addresses in that IA are no longer valid. There BV> is no other time that an IA dies. There is no "expire" time. - The client may have other addresses in other IAs, so the client may choose to discard the expired IA and use the addresses in the other 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 The client sets the "msg-type" field to RELEASE. The client generates a transaction ID and places this value in the "transaction-ID" field. The client places the IP address of the server that allocated the address(es) in the "server-address" field. The client adds a DUID option to identify itself to the server. The client includes options containing the IAs it is releasing in the "options" field. The addresses to be released MUST be included in the IAs. The appropriate "status" field in the options MUST be set to indicate the reason for the release. The client sends the Release message to the All DHCP Agents multicast address through the interface for which the client is interested in releasing 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. A client MAY choose to wait for a Reply message from the server in response to the Release message. If the client does wait for a Reply, the client MAY choose to retransmit the Release message. The client transmits the message according to section 13, using the following parameters: IRT REP_TIMEOUT MRC REL_MSG_ATTEMPTS MRT REP_MAX_RT MRD 0 The client MUST abandon the attempt to release addresses if the Release message exchange fails. The client MUST stop using all of the addresses in the IA(s) being released as soon as the client begins the Release message exchange process. If an IA is released but the Reply from a DHCP server is lost, the client will retransmit the Release message, and the server may respond with a Reply indicating a status of "Nobinding". Therefore, the client must not treat a Reply message with a status of "Nobinding" in a Release message exchange as if it indicates an error. Note that if the client fails to release the IA, the addresses assigned to the IA will be reclaimed by the server when the lease associated with it expires. 15.3.7. Receipt of Reply message in response to a Release message Upon receipt of a valid Reply message, the client can consider the Release event successful, and SHOULD return the successful status to the application layer, if an application initiated the release. 15.3.8. Creation and transmission of Decline messages The client sets the "msg-type" field to DECLINE. The client generates a transaction ID and places this value in the "transaction-ID" field. The client places the IP address of the server that allocated the address(es) in the "server-address" field. The client adds a DUID option to identify itself to the server. The client includes options containing the IAs it is declining in the "options" field. The addresses to be released MUST be included in the IAs. The appropriate "status" field in the options MUST be set to indicate the reason for declining the address. The client sends the Decline message to the All DHCP Agents multicast address through the interface for which the client is interested in declining addresses, 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 REL_ATTEMPTS MRT REP_MAX_RT MRD 0 The client MUST abandon the attempt to decline addresses if the Decline message exchange fails. 15.3.9. Receipt of Reply message in response to a Decline message Upon receipt of a valid Reply message, the client can consider the Decline event successful. [...] _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C13722.B5E8E780 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] DHCPv6 spec text for retransmission

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:rdroms@cisco.com]
Sent: Tuesday, September 04, 2001 9:49 PM
To: dhcwg@ietf.org
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).
* 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?

      = 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          &n= bsp; 30 MAX timer value (secs)
   = SOL_MAX_ATTEMPTS        0 MAX = attempts (0 =3D infinite)
   = REP_TIMEOUT           = 250 Retrans timer (msecs) for Reply
   = REP_MAX_RT          &n= bsp;   0 MAX Retrans time (0 =3D 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

   DHCP clients are responsible for = reliable delivery of messages in the
   client-initiated message exchanges = described in sections 14 and 15.
   If a DHCP client fails to receive an = expected response from a server,
   the client must retransmit its = message. This section describes the
   retransmission strategy to be used by = clients in client-initiated
   message exchanges.

   The client begins the message exchange = by transmitting a message to
   the server. The message exchange = terminates when either the client
   successfully receives the appropriate = response or responses from a
   server or servers, or when the message = exchange is considered to have
   failed according to the retransmission = mechanism described below.

The client retransmission behavior is = controlled and describe by five
variables:

= RT Retransmission timeout

IRT = Initial retransmission time

MRC = Maximum retransmission count

MRT = Maximum retransmission time

MRD = Maximum retransmission duration

RAND = Randomization factor

   With each message transmission or = retransmission, the client sets RT
   according to the rules given = below. If RT expires before the message
   exchange terminates, the client = recomputes RT and retransmits the
   message.

   Each of the computations of a new RT = include a randomization factor
   (RAND), which is a random number chosen = with a uniform distribution
   between -0.0625 and +0.0625. The = randomization factor is included
   to minimize synchronization of messages = transmitted by DHCP clients.
   The algorithm for choosing a random = number does not need to be
   cryptographically sound. The = algorithm SHOULD produce a different
   sequence of numbers from each = invocation of the DHCP client.

RT for the first message transmission is = based on IRT:

RT =3D IRT + = RAND*IRT

RT for each subsequent message = transmission is based on the previous
value of RT:

RT =3D RTprev + = RAND*RTprev

MRT specifies an upper bound on the = value of RT. If MRT has a value
of 0, there is no upper limit on the = value of RT. Otherwise:

if (RT > MRT)
RT =3D MRT + = RAND*MRT

   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.

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.

   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.
   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?

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."

14.3.3. Receipt of Advertise messages

   A client MUST wait for SRVR_PREF_WAIT = seconds after sending a DHCP
   Solicit message to collect Advertise = messages, unless it receives an
   Advertise message with a preference = value of 255. The preference
   value is carried in the Preference = option (section 19.5). Any
   Solicit that does not include a = Preference option is considered to
   have a preference value of 0. If = the client receives an Advertise
   message with a preference value of 255, = then the client MAY act
   immediately on that Advertise message = without waiting for any more
   additional Advertise messages.

   Upon receipt of one or more validated = Advertise messages, the client
   selects one or more Advertise messages = based upon the following
   criteria.

- Those Advertise messages = with the highest server preference value
are preferred = over all other Advertise messages.

    - Within a group of = Advertise messages with the same server
       preference = value, a client MAY select those servers whose
       Advertise = messages advertise information of interest to the
       client. = For example, the client may choose a server that
       returned an = advertisement with configuration options of interest
       to the = client.

   Once a client has selected Advertise = message(s), the client will
   typically store information about each = server, such as server
   preference value, addresses advertised, = when the advertisement was
   received, and so on. Depending on = the requirements of the client's
   invoking user, the client MAY initiate = a configuration exchange with
   the server(s) immediately, or MAY defer = this exchange until later.

   If the client needs to select an = alternate server in the case that a
   chosen server does not respond, the = client chooses the server with
   the next highest preference = value.

   The client MAY choose a less-preferred = server if that server has a
   better set of advertised parameters, = such as the available addresses
   advertised in IAs.

[...]

15. DHCP Client-Initiated Configuration = Exchange

[...]

15.3. Client Behavior

[...]

15.3.1. Creation and transmission of Request = messages

   If the client is using stateful address = configuration and needs either
   an initial set of addresses or = additional addresses, it MUST send
   a Request message to obtain new = addresses and other configuration
   information. 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.

   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
   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 client transmits the message = according to section 13, using the
following parameters:

IRT = REP_TIMEOUT

MRC = REQ_MAX_ATTEMPTS

MRT = REP_MAX_RT

MRD = 0

If the message exchange fails, the = client MAY choose one of the
following actions:

- Select another server from = a list of servers known to the client;
e. g., = servers that responded with an Advertise message

- Initiate the server = discovery described in section 14

- Terminate the = configuration process and report failure

15.3.2. Creation and transmission of Confirm = messages

   Whenever a client may have moved to a = new link, its IPv6 addresses
   and other configuration information may = no longer be valid. Examples
   of times when a client may have moved = to a new link include:

o The client reboots

o The client is physically = disconnected from a wired connection

o The client returns from = sleep mode

o The client using a = wireless technology changes cells

   In any situation when a client may have = moved to a new link, the
   client MUST initiate a Confirm/Reply = message exchange. The client
   includes any IAs, along with the = addresses associated with those IAs,
   in its Confirm message. Any = responding servers will indicate the
   acceptability of the addresses with the = status in the IA it returns
   to the client.

   The client sets the "msg-type" = field to CONFIRM. The client generates
   a transaction ID and inserts this value = in the "transaction-ID"
   field.

The client sets the = "server-address" field to 0.

   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 confirm the validity of
   some network addresses). 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 Confirm message to = the All DHCP Agents multicast
   address through the interface for which = the client is interested in
   confirming 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 = REQ_MSG_ATTEMPTS

MRT = REP_MAX_RT

MRD = 0

   If the message exchange fails, the = client MUST restart the
   configuration process by locating a = DHCP server as described
   in section 14. The client SHOULD = report the failure of the
   configuration process to the = application layer.

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>         &nb= sp;           &nb= sp;         Renew!
   "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".

   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 =3D 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.

15.3.4. Creation and transmission of Rebind = messages

   At time T2 for an IA (which will only be = reached if the server to
   which the Renew message was sent at = time T1 has not responded),
   the client initiates a Rebind/Reply = message exchange. The client
   includes an IA option with all = addresses currently assigned to the IA
   in its Rebind message. The client = sends this message to the All DHCP
   Agents multicast address.

The client sets the "msg-type" = field to REBIND. The client generates
a transaction ID inserts this value in = the "transaction-ID" field.

The client sets the = "server-address" field to 0.

   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 does = include any 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), = it MUST include the list of
   addresses the client currently has = associated with that IA.

   The client sends the Rebind 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 the lease for the IA expires (see = section 11), at which time the
   client has several alternative actions = to choose from:
BV> Hum. This has some interesting problems (I = don't know what Section
BV> 11 refers to at this time, but don't recall = the -19 draft having
BV> much text in this area). The reason for the = interesting problems
BV> is because of the lifetime issue vs the T2 = and renewal time.
BV> What happens if an IA has two addresses. One = has a valid lifetime
BV> of 2 weeks. The other has a valid lifetime of = 3 days. The T2 time
BV> is 2 days. So, suppose the servers are = non-responsive for 4 days.
BV> When does the client stop retransmitting the = message? When does it
BV> alter it to remove the address with the = expired lifetime (after 3
BV> days). Does this change to the message mean = it MUST change the
BV> XID?
BV> I would suggest we say that MRD is = shortest-valid-lifetime - T2.
BV> Once that retransmission expires, the client = must generate a
BV> new Rebind message if there are *ANY* = addresses still valid. It
BV> stops only after all addresses are no longer = valid.
BV> We should also fix all the terminology such = as "when the lease
BV> on the IA expires"? It is really the = valid lifetimes on the
BV> individual addresses.
BV> NOTE: The above issue for Rebind is *ALSO* a = problem for Renew!
BV> What if you had a third address with a 1 day = valid lifetime
BV> and T1 was 12 hours. 12 hours into the renew = this third address
BV> is gone and should be removed from the Renew. = Hence, new message!
BV> Hence, new transaction ID. Messy, messy, = messy!

    - When the lease on the IA = expires, the client may choose to use a
       Solicit message = to locate a new DHCP server and send a Request
       for the expired = IA to the new server

    - Some addresses in the IA = may have lifetimes that extend beyond
       the lease of = the IA, so the client may choose to continue to use
       those = addresses; once all of the addresses have expired, the
       client may = choose to locate a new DHCP server
BV> Huh? How is this possible? There is no = "lease" to an IA. An IA
BV> dies when all of the addresses in that IA are = no longer valid. There
BV> is no other time that an IA dies. There is no = "expire" time.

    - The client may have other = addresses in other IAs, so the client
       may choose to = discard the expired IA and use the addresses in the
       other = 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

The client sets the "msg-type" = field to RELEASE. The client generates
a transaction ID and places this value = in the "transaction-ID" field.

The client places the IP address of the = server that allocated the
address(es) in the = "server-address" field.

   The client adds a DUID option to = identify itself to the server. The
   client includes options containing the = IAs it is releasing in the
   "options" field. The = addresses to be released MUST be included in
   the IAs. The appropriate = "status" field in the options MUST be set
   to indicate the reason for the = release.

   The client sends the Release message to = the All DHCP Agents multicast
   address through the interface for which = the client is interested in
   releasing 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.

   A client MAY choose to wait for a Reply = message from the server in
   response to the Release message. = If the client does wait for a
   Reply, the client MAY choose to = retransmit the Release message.

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

IRT = REP_TIMEOUT

MRC = REL_MSG_ATTEMPTS

MRT = REP_MAX_RT

MRD = 0

The client MUST abandon the attempt to = release addresses if the
Release message exchange fails.

   The client MUST stop using all of the = addresses in the IA(s) being
   released as soon as the client begins = the Release message exchange
   process. If an IA is released but = the Reply from a DHCP server
   is lost, the client will retransmit the = Release message, and the
   server may respond with a Reply = indicating a status of "Nobinding".
   Therefore, the client must not treat a = Reply message with a status
   of "Nobinding" in a Release = message exchange as if it indicates an
   error.

   Note that if the client fails to release = the IA, the addresses
   assigned to the IA will be reclaimed by = the server when the lease
   associated with it expires.

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

   Upon receipt of a valid Reply message, = the client can consider the
   Release event successful, and SHOULD = return the successful status to
   the application layer, if an = application initiated the release.

15.3.8. Creation and transmission of Decline = messages

The client sets the "msg-type" = field to DECLINE. The client generates
a transaction ID and places this value = in the "transaction-ID" field.

The client places the IP address of the = server that allocated the
address(es) in the = "server-address" field.

   The client adds a DUID option to = identify itself to the server. The
   client includes options containing the = IAs it is declining in the
   "options" field. The = addresses to be released MUST be included in
   the IAs. The appropriate = "status" field in the options MUST be set
   to indicate the reason for declining = the address.

   The client sends the Decline message to = the All DHCP Agents multicast
   address through the interface for which = the client is interested
   in declining addresses, 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 = REL_ATTEMPTS

MRT = REP_MAX_RT

MRD = 0

The client MUST abandon the attempt to = decline addresses if the
Decline message exchange fails.

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

Upon receipt of a valid Reply message, = the client can consider the
Decline event successful.

[...]

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

------_=_NextPart_001_01C13722.B5E8E780-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg