14. Transmission of Messages by a Client

This section preserves the RFC text for DHCPv6, including message exchanges, relay behavior, DUIDs, IA_NA, IA_TA, IA_PD, DHCP options, RKAP authentication, IANA registries, normative requirements, and appendix option-appearance matrices.

Original RFC Text

14.  Transmission of Messages by a Client

   Unless otherwise specified in this document or in a document that
   describes how IPv6 is carried over a specific type of link (for link
   types that do not support multicast), a client sends DHCP messages to
   the All_DHCP_Relay_Agents_and_Servers multicast address.

   DHCP servers SHOULD NOT check to see whether the Layer 2 address used
   was multicast or not, as long as the Layer 3 address was correct.

   A client uses multicast to reach all servers or an individual server.
   An individual server is indicated by specifying that server's DUID in
   a Server Identifier option (see Section 21.3) in the client's
   message.  (All servers will receive this message, but only the
   indicated server will respond.)  All servers are indicated when this
   option is not supplied.

14.1.  Rate Limiting

   A DHCPv6 client MUST limit the rate of DHCP messages it transmits or
   retransmits.  This will minimize the impact of prolonged message
   bursts or loops, for example when a client rejects a server's
   response, repeats the request and gets the same server response,
   which, again, gets rejected by the client.

   This loop can repeat infinitely if there is not a quit/stop
   mechanism.  Therefore, a client must not initiate transmissions too
   frequently.

   A recommended method for implementing the rate-limiting function is a
   token bucket (see Appendix A of [RFC3290]), limiting the average rate
   of transmission to a certain number in a certain time interval.  This
   method of bounding burstiness also guarantees that the long-term
   transmission rate will not be exceeded.

   A transmission rate limit SHOULD be configurable.  A possible default
   could be 20 messages in 20 seconds.

   For a device that has multiple interfaces, the limit MUST be enforced
   on a per-interface basis.

   Rate limiting of forwarded DHCP messages and server-side messages is
   out of scope for this specification.

14.2.  Client Behavior when T1 and/or T2 Are 0

   In certain cases, T1 and/or T2 values may be set to 0.  Currently,
   there are two such cases:

   1.  a client received an IA_NA option (see Section 21.4) with a zero
       value

   2.  a client received an IA_PD option (see Section 21.21) with a zero
       value

   This is an indication that the renew and rebind times are left to the
   discretion of the client.  However, they are not completely
   discretionary.

   When T1 and/or T2 values are set to 0, the client MUST choose a time
   to avoid message storms.  In particular, it MUST NOT transmit
   immediately.  If the client received multiple IA options, it SHOULD
   pick renew and/or rebind transmission times so all IA options are
   handled in one exchange, if possible.  The client MUST choose renew
   and rebind times to not violate rate-limiting restrictions as defined
   in Section 14.1.