tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 3315

 
 
 

Dynamic Host Configuration Protocol for IPv6 (DHCPv6)

Part 2 of 5, p. 16 to 38
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 16 
6. Client/Server Message Formats

   All DHCP messages sent between clients and servers share an identical
   fixed format header and a variable format area for options.

   All values in the message header and in options are in network byte
   order.

Top      Up      ToC       Page 17 
   Options are stored serially in the options field, with no padding
   between the options.  Options are byte-aligned but are not aligned in
   any other way such as on 2 or 4 byte boundaries.

   The following diagram illustrates the format of DHCP messages sent
   between clients and servers:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    msg-type   |               transaction-id                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                            options                            .
      .                           (variable)                          .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      msg-type             Identifies the DHCP message type; the
                           available message types are listed in
                           section 5.3.

      transaction-id       The transaction ID for this message exchange.

      options              Options carried in this message; options are
                           described in section 22.

7. Relay Agent/Server Message Formats

   Relay agents exchange messages with servers to relay messages between
   clients and servers that are not connected to the same link.

   All values in the message header and in options are in network byte
   order.

   Options are stored serially in the options field, with no padding
   between the options.  Options are byte-aligned but are not aligned in
   any other way such as on 2 or 4 byte boundaries.

Top      Up      ToC       Page 18 
   There are two relay agent messages, which share the following format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    msg-type   |   hop-count   |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
      |                                                               |
      |                         link-address                          |
      |                                                               |
      |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
      |                               |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
      |                                                               |
      |                         peer-address                          |
      |                                                               |
      |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
      |                               |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
      .                                                               .
      .            options (variable number and length)   ....        .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The following sections describe the use of the Relay Agent message
   header.

7.1. Relay-forward Message

   The following table defines the use of message fields in a Relay-
   forward message.

      msg-type       RELAY-FORW

      hop-count      Number of relay agents that have relayed this
                     message.

      link-address   A global or site-local address that will be used by
                     the server to identify the link on which the client
                     is located.

      peer-address   The address of the client or relay agent from which
                     the message to be relayed was received.

      options        MUST include a "Relay Message option" (see
                     section 22.10); MAY include other options added by
                     the relay agent.

Top      Up      ToC       Page 19 
7.2. Relay-reply Message

   The following table defines the use of message fields in a
   Relay-reply message.

      msg-type       RELAY-REPL

      hop-count      Copied from the Relay-forward message

      link-address   Copied from the Relay-forward message

      peer-address   Copied from the Relay-forward message

      options        MUST include a "Relay Message option"; see
                     section 22.10; MAY include other options

8. Representation and Use of Domain Names

   So that domain names may be encoded uniformly, a domain name or a
   list of domain names is encoded using the technique described in
   section 3.1 of RFC 1035 [10].  A domain name, or list of domain
   names, in DHCP MUST NOT be stored in compressed form, as described in
   section 4.1.4 of RFC 1035.

9. DHCP Unique Identifier (DUID)

   Each DHCP client and server has a DUID.  DHCP servers use DUIDs to
   identify clients for the selection of configuration parameters and in
   the association of IAs with clients.  DHCP clients use DUIDs to
   identify a server in messages where a server needs to be identified.
   See sections 22.2 and 22.3 for the representation of a DUID in a DHCP
   message.

   Clients and servers MUST treat DUIDs as opaque values and MUST only
   compare DUIDs for equality.  Clients and servers MUST NOT in any
   other way interpret DUIDs.  Clients and servers MUST NOT restrict
   DUIDs to the types defined in this document, as additional DUID types
   may be defined in the future.

   The DUID is carried in an option because it may be variable length
   and because it is not required in all DHCP messages.  The DUID is
   designed to be unique across all DHCP clients and servers, and stable
   for any specific client or server - that is, the DUID used by a
   client or server SHOULD NOT change over time if at all possible; for
   example, a device's DUID should not change as a result of a change in
   the device's network hardware.

Top      Up      ToC       Page 20 
   The motivation for having more than one type of DUID is that the DUID
   must be globally unique, and must also be easy to generate.  The sort
   of globally-unique identifier that is easy to generate for any given
   device can differ quite widely.  Also, some devices may not contain
   any persistent storage.  Retaining a generated DUID in such a device
   is not possible, so the DUID scheme must accommodate such devices.

9.1. DUID Contents

   A DUID consists of a two-octet type code represented in network byte
   order, followed by a variable number of octets that make up the
   actual identifier.  A DUID can be no more than 128 octets long (not
   including the type code).  The following types are currently defined:

      1        Link-layer address plus time
      2        Vendor-assigned unique ID based on Enterprise Number
      3        Link-layer address

   Formats for the variable field of the DUID for each of the above
   types are shown below.

9.2. DUID Based on Link-layer Address Plus Time [DUID-LLT]

   This type of DUID consists of a two octet type field containing the
   value 1, a two octet hardware type code, four octets containing a
   time value, followed by link-layer address of any one network
   interface that is connected to the DHCP device at the time that the
   DUID is generated.  The time value is the time that the DUID is
   generated represented in seconds since midnight (UTC), January 1,
   2000, modulo 2^32.  The hardware type MUST be a valid hardware type
   assigned by the IANA as described in RFC 826 [14].  Both the time and
   the hardware type are stored in network byte order.  The link-layer
   address is stored in canonical form, as described in RFC 2464 [2].

   The following diagram illustrates the format of a DUID-LLT:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               1               |    hardware type (16 bits)    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        time (32 bits)                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                               .
    .             link-layer address (variable length)              .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 21 
   The choice of network interface can be completely arbitrary, as long
   as that interface provides a globally unique link-layer address for
   the link type, and the same DUID-LLT SHOULD be used in configuring
   all network interfaces connected to the device, regardless of which
   interface's link-layer address was used to generate the DUID-LLT.

   Clients and servers using this type of DUID MUST store the DUID-LLT
   in stable storage, and MUST continue to use this DUID-LLT even if the
   network interface used to generate the DUID-LLT is removed.  Clients
   and servers that do not have any stable storage MUST NOT use this
   type of DUID.

   Clients and servers that use this DUID SHOULD attempt to configure
   the time prior to generating the DUID, if that is possible, and MUST
   use some sort of time source (for example, a real-time clock) in
   generating the DUID, even if that time source could not be configured
   prior to generating the DUID.  The use of a time source makes it
   unlikely that two identical DUID-LLTs will be generated if the
   network interface is removed from the client and another client then
   uses the same network interface to generate a DUID-LLT.  A collision
   between two DUID-LLTs is very unlikely even if the clocks have not
   been configured prior to generating the DUID.

   This method of DUID generation is recommended for all general purpose
   computing devices such as desktop computers and laptop computers, and
   also for devices such as printers, routers, and so on, that contain
   some form of writable non-volatile storage.

   Despite our best efforts, it is possible that this algorithm for
   generating a DUID could result in a client identifier collision.  A
   DHCP client that generates a DUID-LLT using this mechanism MUST
   provide an administrative interface that replaces the existing DUID
   with a newly-generated DUID-LLT.

Top      Up      ToC       Page 22 
9.3. DUID Assigned by Vendor Based on Enterprise Number [DUID-EN]

   This form of DUID is assigned by the vendor to the device.  It
   consists of the vendor's registered Private Enterprise Number as
   maintained by IANA [6] followed by a unique identifier assigned by
   the vendor.  The following diagram summarizes the structure of a
   DUID-EN:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               2               |       enterprise-number       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   enterprise-number (contd)   |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
    .                           identifier                          .
    .                       (variable length)                       .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The source of the identifier is left up to the vendor defining it,
   but each identifier part of each DUID-EN MUST be unique to the device
   that is using it, and MUST be assigned to the device at the time it
   is manufactured and stored in some form of non-volatile storage.  The
   generated DUID SHOULD be recorded in non-erasable storage.  The
   enterprise-number is the vendor's registered Private Enterprise
   Number as maintained by IANA [6].  The enterprise-number is stored as
   an unsigned 32 bit number.

   An example DUID of this type might look like this:

    +---+---+---+---+---+---+---+---+
    | 0 | 2 | 0 | 0 | 0 |  9| 12|192|
    +---+---+---+---+---+---+---+---+
    |132|221| 3 | 0 | 9 | 18|
    +---+---+---+---+---+---+

   This example includes the two-octet type of 2, the Enterprise Number
   (9), followed by eight octets of identifier data
   (0x0CC084D303000912).

9.4. DUID Based on Link-layer Address [DUID-LL]

   This type of DUID consists of two octets containing the DUID type 3,
   a two octet network hardware type code, followed by the link-layer
   address of any one network interface that is permanently connected to
   the client or server device.  For example, a host that has a network
   interface implemented in a chip that is unlikely to be removed and

Top      Up      ToC       Page 23 
   used elsewhere could use a DUID-LL.  The hardware type MUST be a
   valid hardware type assigned by the IANA, as described in RFC 826
   [14].  The hardware type is stored in network byte order.  The
   link-layer address is stored in canonical form, as described in RFC
   2464 [2].  The following diagram illustrates the format of a DUID-LL:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               3               |    hardware type (16 bits)    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                               .
    .             link-layer address (variable length)              .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The choice of network interface can be completely arbitrary, as long
   as that interface provides a unique link-layer address and is
   permanently attached to the device on which the DUID-LL is being
   generated.  The same DUID-LL SHOULD be used in configuring all
   network interfaces connected to the device, regardless of which
   interface's link-layer address was used to generate the DUID.

   DUID-LL is recommended for devices that have a permanently-connected
   network interface with a link-layer address, and do not have
   nonvolatile, writable stable storage.  DUID-LL MUST NOT be used by
   DHCP clients or servers that cannot tell whether or not a network
   interface is permanently attached to the device on which the DHCP
   client is running.

10. Identity Association

   An "identity-association" (IA) is a construct through which a server
   and a client can identify, group, and manage a set of related IPv6
   addresses.  Each IA consists of an IAID and associated configuration
   information.

   A client must associate at least one distinct IA with each of its
   network interfaces for which it is to request the assignment of IPv6
   addresses from a DHCP server.  The client uses the IAs assigned to an
   interface to obtain configuration information from a server for that
   interface.  Each IA must be associated with exactly one interface.

   The IAID uniquely identifies the IA and must be chosen to be unique
   among the IAIDs on the client.  The IAID is chosen by the client.
   For any given use of an IA by the client, the IAID for that IA MUST
   be consistent across restarts of the DHCP client.  The client may
   maintain consistency either by storing the IAID in non-volatile

Top      Up      ToC       Page 24 
   storage or by using an algorithm that will consistently produce the
   same IAID as long as the configuration of the client has not changed.
   There may be no way for a client to maintain consistency of the IAIDs
   if it does not have non-volatile storage and the client's hardware
   configuration changes.

   The configuration information in an IA consists of one or more IPv6
   addresses along with the times T1 and T2 for the IA.  See section
   22.4 for the representation of an IA in a DHCP message.

   Each address in an IA has a preferred lifetime and a valid lifetime,
   as defined in RFC 2462 [17].  The lifetimes are transmitted from the
   DHCP server to the client in the IA option.  The lifetimes apply to
   the use of IPv6 addresses, as described in section 5.5.4 of RFC 2462.

11. Selecting Addresses for Assignment to an IA

   A server selects addresses to be assigned to an IA according to the
   address assignment policies determined by the server administrator
   and the specific information the server determines about the client
   from some combination of the following sources:

   -  The link to which the client is attached.  The server determines
      the link as follows:

      *  If the server receives the message directly from the client and
         the source address in the IP datagram in which the message was
         received is a link-local address, then the client is on the
         same link to which the interface over which the message was
         received is attached.

      *  If the server receives the message from a forwarding relay
         agent, then the client is on the same link as the one to which
         the interface, identified by the link-address field in the
         message from the relay agent, is attached.

      *  If the server receives the message directly from the client and
         the source address in the IP datagram in which the message was
         received is not a link-local address, then the client is on the
         link identified by the source address in the IP datagram (note
         that this situation can occur only if the server has enabled
         the use of unicast message delivery by the client and the
         client has sent a message for which unicast delivery is
         allowed).

   -  The DUID supplied by the client.

   -  Other information in options supplied by the client.

Top      Up      ToC       Page 25 
   -  Other information in options supplied by the relay agent.

   Any address assigned by a server that is based on an EUI-64
   identifier MUST include an interface identifier with the "u"
   (universal/local) and "g" (individual/group) bits of the interface
   identifier set appropriately, as indicated in section 2.5.1 of RFC
   2373 [5].

   A server MUST NOT assign an address that is otherwise reserved for
   some other purpose.  For example, a server MUST NOT assign reserved
   anycast addresses, as defined in RFC 2526, from any subnet.

12. Management of Temporary Addresses

   A client may request the assignment of temporary addresses (see RFC
   3041 [12] for the definition of temporary addresses).  DHCPv6
   handling of address assignment is no different for temporary
   addresses.  DHCPv6 says nothing about details of temporary addresses
   like lifetimes, how clients use temporary addresses, rules for
   generating successive temporary addresses, etc.

   Clients ask for temporary addresses and servers assign them.
   Temporary addresses are carried in the Identity Association for
   Temporary Addresses (IA_TA) option (see section 22.5).  Each IA_TA
   option contains at most one temporary address for each of the
   prefixes on the link to which the client is attached.

   The IAID number space for the IA_TA option IAID number space is
   separate from the IA_NA option IAID number space.

   The server MAY update the DNS for a temporary address, as described
   in section 4 of RFC 3041.

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

   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 22.3) in the client's message
   (all servers will receive this message but only the indicated server
   will respond).  All servers are indicated by not supplying this
   option.

Top      Up      ToC       Page 26 
   A client may send some messages directly to a server using unicast,
   as described in section 22.12.

14. Reliability of Client Initiated Message Exchanges

   DHCP clients are responsible for reliable delivery of messages in the
   client-initiated message exchanges described in sections 17 and 18.
   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.

   Note that the procedure described in this section is slightly
   modified when used with the Solicit message.  The modified procedure
   is described in section 17.1.2.

   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 described by the
   following 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.1 and +0.1.  The randomization factor is included to
   minimize synchronization of messages transmitted by DHCP clients.

Top      Up      ToC       Page 27 
   The algorithm for choosing a random number does not need to be
   cryptographically sound.  The algorithm SHOULD produce a different
   sequence of random 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 = 2*RTprev + RAND*RTprev

   MRT specifies an upper bound on the value of RT (disregarding the
   randomization added by the use of RAND).  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.  Unless MRC is zero, the message exchange fails
   once the client has transmitted the message MRC times.

   MRD specifies an upper bound on the length of time a client may
   retransmit a message.  Unless MRD is zero, the message exchange fails
   once MRD seconds have elapsed since the client first transmitted the
   message.

   If both MRC and MRD are non-zero, the message exchange fails whenever
   either of the conditions specified in the previous two paragraphs are
   met.

   If both MRC and MRD are zero, the client continues to transmit the
   message until it receives a response.

15. Message Validation

   Clients and servers SHOULD discard any messages that contain options
   that are not allowed to appear in the received message.  For example,
   an IA option is not allowed to appear in an Information-request
   message.  Clients and servers MAY choose to extract information from
   such a message if the information is of use to the recipient.

   A server MUST discard any Solicit, Confirm, Rebind or
   Information-request messages it receives with a unicast destination
   address.

Top      Up      ToC       Page 28 
   Message validation based on DHCP authentication is discussed in
   section 21.4.2.

   If a server receives a message that contains options it should not
   contain (such as an Information-request message with an IA option),
   is missing options that it should contain, or is otherwise not valid,
   it MAY send a Reply (or Advertise as appropriate) with a Server
   Identifier option, a Client Identifier option if one was included in
   the message and a Status Code option with status UnSpecFail.

15.1. Use of Transaction IDs

   The "transaction-id" field holds a value used by clients and servers
   to synchronize server responses to client messages.  A client SHOULD
   generate a random number that cannot easily be guessed or predicted
   to use as the transaction ID for each new message it sends.  Note
   that if a client generates easily predictable transaction
   identifiers, it may become more vulnerable to certain kinds of
   attacks from off-path intruders.  A client MUST leave the transaction
   ID unchanged in retransmissions of a message.

15.2. Solicit Message

   Clients MUST discard any received Solicit messages.

   Servers MUST discard any Solicit messages that do not include a
   Client Identifier option or that do include a Server Identifier
   option.

15.3. Advertise Message

   Clients MUST discard any received Advertise messages that meet any of
   the following conditions:

   -  the message does not include a Server Identifier option.

   -  the message does not include a Client Identifier option.

   -  the contents of the Client Identifier option does not match the
      client's DUID.

   -  the "transaction-id" field value does not match the value the
      client used in its Solicit message.

   Servers and relay agents MUST discard any received Advertise
   messages.

Top      Up      ToC       Page 29 
15.4. Request Message

   Clients MUST discard any received Request messages.

   Servers MUST discard any received Request message that meet any of
   the following conditions:

   -  the message does not include a Server Identifier option.

   -  the contents of the Server Identifier option do not match the
      server's DUID.

   -  the message does not include a Client Identifier option.

15.5. Confirm Message

   Clients MUST discard any received Confirm messages.

   Servers MUST discard any received Confirm messages that do not
   include a Client Identifier option or that do include a Server
   Identifier option.

15.6. Renew Message

   Clients MUST discard any received Renew messages.

   Servers MUST discard any received Renew message that meets any of the
   following conditions:

   -  the message does not include a Server Identifier option.

   -  the contents of the Server Identifier option does not match the
      server's identifier.

   -  the message does not include a Client Identifier option.

15.7. Rebind Message

   Clients MUST discard any received Rebind messages.

   Servers MUST discard any received Rebind messages that do not include
   a Client Identifier option or that do include a Server Identifier
   option.

Top      Up      ToC       Page 30 
15.8. Decline Messages

   Clients MUST discard any received Decline messages.

   Servers MUST discard any received Decline message that meets any of
   the following conditions:

   -  the message does not include a Server Identifier option.

   -  the contents of the Server Identifier option does not match the
      server's identifier.

   -  the message does not include a Client Identifier option.

15.9. Release Message

   Clients MUST discard any received Release messages.

   Servers MUST discard any received Release message that meets any of
   the following conditions:

   -  the message does not include a Server Identifier option.

   -  the contents of the Server Identifier option does not match the
      server's identifier.

   -  the message does not include a Client Identifier option.

15.10. Reply Message

   Clients MUST discard any received Reply message that meets any of the
   following conditions:

   -  the message does not include a Server Identifier option.

   -  the "transaction-id" field in the message does not match the value
      used in the original message.

   If the client included a Client Identifier option in the original
   message, the Reply message MUST include a Client Identifier option
   and the contents of the Client Identifier option MUST match the DUID
   of the client; OR, if the client did not include a Client Identifier
   option in the original message, the Reply message MUST NOT include a
   Client Identifier option.

   Servers and relay agents MUST discard any received Reply messages.

Top      Up      ToC       Page 31 
15.11. Reconfigure Message

   Servers and relay agents MUST discard any received Reconfigure
   messages.

   Clients MUST discard any Reconfigure messages that meets any of the
   following conditions:

   -  the message was not unicast to the client.

   -  the message does not include a Server Identifier option.

   -  the message does not include a Client Identifier option that
      contains the client's DUID.

   -  the message does not contain a Reconfigure Message option and the
      msg-type must be a valid value.

   -  the message includes any IA options and the msg-type in the
      Reconfigure Message option is INFORMATION-REQUEST.

   -  the message does not include DHCP authentication:

      *  the message does not contain an authentication option.

      *  the message does not pass the authentication validation
         performed by the client.

15.12. Information-request Message

   Clients MUST discard any received Information-request messages.

   Servers MUST discard any received Information-request message that
   meets any of the following conditions:

   -  The message includes a Server Identifier option and the DUID in
      the option does not match the server's DUID.

   -  The message includes an IA option.

15.13. Relay-forward Message

   Clients MUST discard any received Relay-forward messages.

15.14. Relay-reply Message

   Clients and servers MUST discard any received Relay-reply messages.

Top      Up      ToC       Page 32 
16. Client Source Address and Interface Selection

   When a client sends a DHCP message to the
   All_DHCP_Relay_Agents_and_Servers address, it SHOULD send the message
   through the interface for which configuration information is being
   requested.  However, the client MAY send the message through another
   interface attached to the same link, if and only if the client is
   certain the two interfaces are attached to the same link.  The client
   MUST use a link-local address assigned to the interface for which it
   is requesting configuration information as the source address in the
   header of the IP datagram.

   When a client sends a DHCP message directly to a server using unicast
   (after receiving the Server Unicast option from that server), the
   source address in the header of the IP datagram MUST be an address
   assigned to the interface for which the client is interested in
   obtaining configuration and which is suitable for use by the server
   in responding to the client.

17. DHCP Server Solicitation

   This section describes how a client locates servers that will assign
   addresses to IAs belonging to the client.

   The client is responsible for creating IAs and requesting that a
   server assign IPv6 addresses to the IA.  The client first creates an
   IA and assigns it an IAID.  The client then transmits a Solicit
   message containing an IA option describing the IA.  Servers that can
   assign addresses to the IA respond to the client with an Advertise
   message.  The client then initiates a configuration exchange as
   described in section 18.

   If the client will accept a Reply message with committed address
   assignments and other resources in response to the Solicit message,
   the client includes a Rapid Commit option (see section 22.14) in the
   Solicit message.

17.1. Client Behavior

   A client uses the Solicit message to discover DHCP servers configured
   to assign addresses or return other configuration parameters on the
   link to which the client is attached.

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

Top      Up      ToC       Page 33 
   The client MUST include a Client Identifier option to identify itself
   to the server.  The client includes IA 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 has a preference.  The client MUST NOT include any
   other options in the Solicit message, except as specifically allowed
   in the definition of individual options.

   The client uses IA_NA options to request the assignment of non-
   temporary addresses and uses IA_TA options to request the assignment
   of temporary addresses.  Either IA_NA or IA_TA options, or a
   combination of both, can be included in DHCP messages.

   The client SHOULD include an Option Request option (see section 22.7)
   to indicate the options the client is interested in receiving.  The
   client MAY additionally include instances of those options that are
   identified in the Option Request option, with data values as hints to
   the server about parameter values the client would like to have
   returned.

   The client includes a Reconfigure Accept option (see section 22.20)
   if the client is willing to accept Reconfigure messages from the
   server.

17.1.2. Transmission of Solicit Messages

   The first Solicit message from the client on the interface MUST be
   delayed by a random amount of time between 0 and SOL_MAX_DELAY.  In
   the case of a Solicit message transmitted when DHCP is initiated by
   IPv6 Neighbor Discovery, the delay gives the amount of time to wait
   after IPv6 Neighbor Discovery causes the client to invoke the
   stateful address autoconfiguration protocol (see section 5.5.3 of RFC
   2462).  This random delay desynchronizes clients which start at the
   same time (for example, after a power outage).

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

      IRT   SOL_TIMEOUT

      MRT   SOL_MAX_RT

      MRC   0

      MRD   0

Top      Up      ToC       Page 34 
   If the client has included a Rapid Commit option in its Solicit
   message, the client terminates the waiting process as soon as a Reply
   message with a Rapid Commit option is received.

   If the client is waiting for an Advertise message, the mechanism in
   section 14 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 the first RT has elapsed.  Rather, the
   client collects Advertise messages until the first RT has elapsed.
   Also, the first RT MUST be selected to be strictly greater than IRT
   by choosing RAND to be strictly greater than 0.

   A client MUST collect Advertise messages for the first RT seconds,
   unless it receives an Advertise message with a preference value of
   255.  The preference value is carried in the Preference option
   (section 22.8).  Any Advertise that does not include a Preference
   option is considered to have a preference value of 0.  If the client
   receives an Advertise message that includes a Preference option with
   a preference value of 255, the client immediately begins a client-
   initiated message exchange (as described in section 18) by sending a
   Request message to the server from which the Advertise message was
   received.  If the client receives an Advertise message that does not
   include a Preference option with a preference value of 255, the
   client continues to wait until the first RT elapses.  If the first RT
   elapses and the client has received an Advertise message, the client
   SHOULD continue with a client-initiated message exchange by sending a
   Request message.

   If the client does not receive any Advertise messages before the
   first RT has elapsed, it begins the retransmission mechanism
   described in section 14.  The client terminates the retransmission
   process as soon as it receives any Advertise message, and the client
   acts on the received Advertise message without waiting for any
   additional Advertise messages.

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

Top      Up      ToC       Page 35 
17.1.3. Receipt of Advertise Messages

   The client MUST ignore any Advertise message that includes a Status
   Code option containing the value NoAddrsAvail, with the exception
   that the client MAY display the associated status message to the
   user.

   Upon receipt of one or more valid 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.

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

   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.

   If the client needs to select an alternate server in the case that a
   chosen server does not respond, the client chooses the next server
   according to the criteria given above.

17.1.4. Receipt of Reply Message

   If the client includes a Rapid Commit option in the Solicit message,
   it will expect a Reply message that includes a Rapid Commit option in
   response.  The client discards any Reply messages it receives that do
   not include a Rapid Commit option.  If the client receives a valid
   Reply message that includes a Rapid Commit option, it processes the
   message as described in section 18.1.8.  If it does not receive such
   a Reply message and does receive a valid Advertise message, the
   client processes the Advertise message as described in section
   17.1.3.

Top      Up      ToC       Page 36 
   If the client subsequently receives a valid Reply message that
   includes a Rapid Commit option, it either:

      processes the Reply message as described in section 18.1.8, and
      discards any Reply messages received in response to the Request
      message, or

      processes any Reply messages received in response to the Request
      message and discards the Reply message that includes the Rapid
      Commit option.

17.2. Server Behavior

   A server sends an Advertise message in response to valid Solicit
   messages it receives to announce the availability of the server to
   the client.

17.2.1. Receipt of Solicit Messages

   The server determines the information about the client and its
   location as described in section 11 and checks its administrative
   policy about responding to the client.  If the server is not
   permitted to respond to the client, the server discards the Solicit
   message.  For example, if the administrative policy for the server is
   that it may only respond to a client that is willing to accept a
   Reconfigure message, if the client indicates with a Reconfigure
   Accept option in the Solicit message that it will not accept a
   Reconfigure message, the servers discard the Solicit message.

   If the client has included a Rapid Commit option in the Solicit
   message and the server has been configured to respond with committed
   address assignments and other resources, the server responds to the
   Solicit with a Reply message as described in section 17.2.3.
   Otherwise, the server ignores the Rapid Commit option and processes
   the remainder of the message as if no Rapid Commit option were
   present.

17.2.2. Creation and Transmission of Advertise Messages

   The server sets the "msg-type" field to ADVERTISE and copies the
   contents of the transaction-id field from the Solicit message
   received from the client to the Advertise message.  The server
   includes its server identifier in a Server Identifier option and
   copies the Client Identifier from the Solicit message into the
   Advertise message.

Top      Up      ToC       Page 37 
   The server MAY add a Preference option to carry the preference value
   for the Advertise message.  The server implementation SHOULD allow
   the setting of a server preference value by the administrator.  The
   server preference value MUST default to zero unless otherwise
   configured by the server administrator.

   The server includes a Reconfigure Accept option if the server wants
   to require that the client accept Reconfigure messages.

   The server includes options the server will return to the client in a
   subsequent Reply message.  The information in these options may be
   used by the client in the selection of a server if the client
   receives more than one Advertise message.  If the client has included
   an Option Request option in the Solicit message, the server includes
   options in the Advertise message containing configuration parameters
   for all of the options identified in the Option Request option that
   the server has been configured to return to the client.  The server
   MAY return additional options to the client if it has been configured
   to do so.  The server must be aware of the recommendations on packet
   sizes and the use of fragmentation in section 5 of RFC 2460.

   If the Solicit message from the client included one or more IA
   options, the server MUST include IA options in the Advertise message
   containing any addresses that would be assigned to IAs contained in
   the Solicit message from the client.  If the client has included
   addresses in the IAs in the Solicit message, the server uses those
   addresses as hints about the addresses the client would like to
   receive.

   If the server will not assign any addresses to any IAs in a
   subsequent Request from the client, the server MUST send an Advertise
   message to the client that includes only a Status Code option with
   code NoAddrsAvail and a status message for the user, a Server
   Identifier option with the server's DUID, and a Client Identifier
   option with the client's DUID.

   If the Solicit message was received directly by the server, the
   server unicasts the Advertise message directly to the client using
   the address in the source address field from the IP datagram in which
   the Solicit message was received.  The Advertise message MUST be
   unicast on the link from which the Solicit message was received.

   If the Solicit message was received in a Relay-forward message, the
   server constructs a Relay-reply message with the Advertise message in
   the payload of a "relay-message" option.  If the Relay-forward
   messages included an Interface-id option, the server copies that
   option to the Relay-reply message.  The server unicasts the
   Relay-reply message directly to the relay agent using the address in

Top      Up      ToC       Page 38 
   the source address field from the IP datagram in which the Relay-
   forward message was received.

17.2.3. Creation and Transmission of Reply Messages

   The server MUST commit the assignment of any addresses or other
   configuration information message before sending a Reply message to a
   client in response to a Solicit message.

   DISCUSSION:

      When using the Solicit-Reply message exchange, the server commits
      the assignment of any addresses before sending the Reply message.
      The client can assume it has been assigned the addresses in the
      Reply message and does not need to send a Request message for
      those addresses.

      Typically, servers that are configured to use the Solicit-Reply
      message exchange will be deployed so that only one server will
      respond to a Solicit message.  If more than one server responds,
      the client will only use the addresses from one of the servers,
      while the addresses from the other servers will be committed to
      the client but not used by the client.

   The server includes a Rapid Commit option in the Reply message to
   indicate that the Reply is in response to a Solicit message.

   The server includes a Reconfigure Accept option if the server wants
   to require that the client accept Reconfigure messages.

   The server produces the Reply message as though it had received a
   Request message, as described in section 18.2.1.  The server
   transmits the Reply message as described in section 18.2.8.



(page 38 continued on part 3)

Next RFC Part