[dhcwg] DHCPv6 spec text for retransmission

[Ralph Droms <[e-mail]>]

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

      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.


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.

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


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

   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.


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:

    -  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

    -  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
[e-mail]
http://www1.ietf.org/mailman/listinfo/dhcwg