tech-invite   World Map
3GPP     Specs     Glossaries     UICC       IETF     RFCs     Groups     SIP     ABNFs       T+       Search     Home

RFC 3315

 
 
 

Dynamic Host Configuration Protocol for IPv6 (DHCPv6)

Part 4 of 5, p. 61 to 89
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 61 
21. Authentication of DHCP Messages

   Some network administrators may wish to provide authentication of the
   source and contents of DHCP messages.  For example, clients may be
   subject to denial of service attacks through the use of bogus DHCP
   servers, or may simply be misconfigured due to unintentionally
   instantiated DHCP servers.  Network administrators may wish to
   constrain the allocation of addresses to authorized hosts to avoid
   denial of service attacks in "hostile" environments where the network
   medium is not physically secured, such as wireless networks or
   college residence halls.

   The DHCP authentication mechanism is based on the design of
   authentication for DHCPv4 [4].

21.1. Security of Messages Sent Between Servers and Relay Agents

   Relay agents and servers that exchange messages securely use the
   IPsec mechanisms for IPv6 [7].  If a client message is relayed
   through multiple relay agents, each of the relay agents must have
   established independent, pairwise trust relationships.  That is, if
   messages from client C will be relayed by relay agent A to relay

Top      Up      ToC       Page 62 
   agent B and then to the server, relay agents A and B must be
   configured to use IPSec for the messages they exchange, and relay
   agent B and the server must be configured to use IPSec for the
   messages they exchange.

   Relay agents and servers that support secure relay agent to server or
   relay agent to relay agent communication use IPsec under the
   following conditions:

      Selectors        Relay agents are manually configured with the
                       addresses of the relay agent or server to which
                       DHCP messages are to be forwarded.  Each relay
                       agent and server that will be using IPsec for
                       securing DHCP messages must also be configured
                       with a list of the relay agents to which messages
                       will be returned.  The selectors for the relay
                       agents and servers will be the pairs of addresses
                       defining relay agents and servers that exchange
                       DHCP messages on the DHCPv6 UDP ports 546 and
                       547.

      Mode             Relay agents and servers use transport mode and
                       ESP. The information in DHCP messages is not
                       generally considered confidential, so encryption
                       need not be used (i.e., NULL encryption can be
                       used).

      Key management   Because the relay agents and servers are used
                       within an organization, public key schemes are
                       not necessary.  Because the relay agents and
                       servers must be manually configured, manually
                       configured key management may suffice, but does
                       not provide defense against replayed messages.
                       Accordingly, IKE with preshared secrets SHOULD be
                       supported.  IKE with public keys MAY be
                       supported.

      Security policy  DHCP messages between relay agents and servers
                       should only be accepted from DHCP peers as
                       identified in the local configuration.

      Authentication   Shared keys, indexed to the source IP address of
                       the received DHCP message, are adequate in this
                       application.

      Availability     Appropriate IPsec implementations are likely to
                       be available for servers and for relay agents in
                       more featureful devices used in enterprise and

Top      Up      ToC       Page 63 
                       core ISP networks.  IPsec is less likely to be
                       available for relay agents in low end devices
                       primarily used in the home or small office
                       markets.

21.2. Summary of DHCP Authentication

   Authentication of DHCP messages is accomplished through the use of
   the Authentication option (see section 22.11).  The authentication
   information carried in the Authentication option can be used to
   reliably identify the source of a DHCP message and to confirm that
   the contents of the DHCP message have not been tampered with.

   The Authentication option provides a framework for multiple
   authentication protocols.  Two such protocols are defined here.
   Other protocols defined in the future will be specified in separate
   documents.

   Any DHCP message MUST NOT include more than one Authentication
   option.

   The protocol field in the Authentication option identifies the
   specific protocol used to generate the authentication information
   carried in the option.  The algorithm field identifies a specific
   algorithm within the authentication protocol; for example, the
   algorithm field specifies the hash algorithm used to generate the
   message authentication code (MAC) in the authentication option.  The
   replay detection method (RDM) field specifies the type of replay
   detection used in the replay detection field.

21.3. Replay Detection

   The Replay Detection Method (RDM) field determines the type of replay
   detection used in the Replay Detection field.

   If the RDM field contains 0x00, the replay detection field MUST be
   set to the value of a monotonically increasing counter.  Using a
   counter value, such as the current time of day (for example, an NTP-
   format timestamp [9]), can reduce the danger of replay attacks.  This
   method MUST be supported by all protocols.

21.4. Delayed Authentication Protocol

   If the protocol field is 2, the message is using the "delayed
   authentication" mechanism.  In delayed authentication, the client
   requests authentication in its Solicit message, and the server
   replies with an Advertise message that includes authentication

Top      Up      ToC       Page 64 
   information.  This authentication information contains a nonce value
   generated by the source as a message authentication code (MAC) to
   provide message authentication and entity authentication.

   The use of a particular technique based on the HMAC protocol [8]
   using the MD5 hash [16] is defined here.

21.4.1. Use of the Authentication Option in the Delayed Authentication
        Protocol

   In a Solicit message, the client fills in the protocol, algorithm and
   RDM fields in the Authentication option with the client's
   preferences.  The client sets the replay detection field to zero and
   omits the authentication information field.  The client sets the
   option-len field to 11.

   In all other messages, the protocol and algorithm fields identify the
   method used to construct the contents of the authentication
   information field.  The RDM field identifies the method used to
   construct the contents of the replay detection field.

   The format of the Authentication information is:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          DHCP realm                           |
    |                      (variable length)                        |
    .                                                               .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            key ID                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                           HMAC-MD5                            |
    |                          (128 bits)                           |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      DHCP realm  The DHCP realm that identifies the key used to
                  generate the HMAC-MD5 value.

      key ID      The key identifier that identified the key used to
                  generate the HMAC-MD5 value.

      HMAC-MD5    The message authentication code generated by applying
                  MD5 to the DHCP message using the key identified by
                  the DHCP realm, client DUID, and key ID.

Top      Up      ToC       Page 65 
   The sender computes the MAC using the HMAC generation algorithm [8]
   and the MD5 hash function [16].  The entire DHCP message (setting the
   MAC field of the authentication option to zero), including the DHCP
   message header and the options field, is used as input to the HMAC-
   MD5 computation function.

   DISCUSSION:

      Algorithm 1 specifies the use of HMAC-MD5.  Use of a different
      technique, such as HMAC-SHA, will be specified as a separate
      protocol.

      The DHCP realm used to identify authentication keys is chosen to
      be unique among administrative domains.  Use of the DHCP realm
      allows DHCP administrators to avoid conflict in the use of key
      identifiers, and allows a host using DHCP to use authenticated
      DHCP while roaming among DHCP administrative domains.

21.4.2. Message Validation

   Any DHCP message that includes more than one authentication option
   MUST be discarded.

   To validate an incoming message, the receiver first checks that the
   value in the replay detection field is acceptable according to the
   replay detection method specified by the RDM field.  Next, the
   receiver computes the MAC as described in [8].  The entire DHCP
   message (setting the MAC field of the authentication option to 0) is
   used as input to the HMAC-MD5 computation function.  If the MAC
   computed by the receiver does not match the MAC contained in the
   authentication option, the receiver MUST discard the DHCP message.

21.4.3. Key Utilization

   Each DHCP client has a set of keys.  Each key is identified by <DHCP
   realm, client DUID, key id>.  Each key also has a lifetime.  The key
   may not be used past the end of its lifetime.  The client's keys are
   initially distributed to the client through some out-of-band
   mechanism.  The lifetime for each key is distributed with the key.
   Mechanisms for key distribution and lifetime specification are beyond
   the scope of this document.

   The client and server use one of the client's keys to authenticate
   DHCP messages during a session (until the next Solicit message sent
   by the client).

Top      Up      ToC       Page 66 
21.4.4. Client Considerations for Delayed Authentication Protocol

   The client announces its intention to use DHCP authentication by
   including an Authentication option in its Solicit message.  The
   server selects a key for the client based on the client's DUID.  The
   client and server use that key to authenticate all DHCP messages
   exchanged during the session.

21.4.4.1. Sending Solicit Messages

   When the client sends a Solicit message and wishes to use
   authentication, it includes an Authentication option with the desired
   protocol, algorithm and RDM as described in section 21.4.  The client
   does not include any replay detection or authentication information
   in the Authentication option.

21.4.4.2. Receiving Advertise Messages

   The client validates any Advertise messages containing an
   Authentication option specifying the delayed authentication protocol
   using the validation test described in section 21.4.2.

   Client behavior, if no Advertise messages include authentication
   information or pass the validation test, is controlled by local
   policy on the client.  According to client policy, the client MAY
   choose to respond to an Advertise message that has not been
   authenticated.

   The decision to set local policy to accept unauthenticated messages
   should be made with care.  Accepting an unauthenticated Advertise
   message can make the client vulnerable to spoofing and other attacks.
   If local users are not explicitly informed that the client has
   accepted an unauthenticated Advertise message, the users may
   incorrectly assume that the client has received an authenticated
   address and is not subject to DHCP attacks through unauthenticated
   messages.

   A client MUST be configurable to discard unauthenticated messages,
   and SHOULD be configured by default to discard unauthenticated
   messages if the client has been configured with an authentication key
   or other authentication information.  A client MAY choose to
   differentiate between Advertise messages with no authentication
   information and Advertise messages that do not pass the validation
   test; for example, a client might accept the former and discard the
   latter.  If a client does accept an unauthenticated message, the
   client SHOULD inform any local users and SHOULD log the event.

Top      Up      ToC       Page 67 
21.4.4.3. Sending Request, Confirm, Renew, Rebind, Decline or Release
          Messages

   If the client authenticated the Advertise message through which the
   client selected the server, the client MUST generate authentication
   information for subsequent Request, Confirm, Renew, Rebind or Release
   messages sent to the server, as described in section 21.4.  When the
   client sends a subsequent message, it MUST use the same key used by
   the server to generate the authentication information.

21.4.4.4. Sending Information-request Messages

   If the server has selected a key for the client in a previous message
   exchange (see section 21.4.5.1), the client MUST use the same key to
   generate the authentication information throughout the session.

21.4.4.5. Receiving Reply Messages

   If the client authenticated the Advertise it accepted, the client
   MUST validate the associated Reply message from the server.  The
   client MUST discard the Reply if the message fails to pass the
   validation test and MAY log the validation failure.  If the Reply
   fails to pass the validation test, the client MUST restart the DHCP
   configuration process by sending a Solicit message.

   If the client accepted an Advertise message that did not include
   authentication information or did not pass the validation test, the
   client MAY accept an unauthenticated Reply message from the server.

21.4.4.6. Receiving Reconfigure Messages

   The client MUST discard the Reconfigure if the message fails to pass
   the validation test and MAY log the validation failure.

21.4.5. Server Considerations for Delayed Authentication Protocol

   After receiving a Solicit message that contains an Authentication
   option, the server selects a key for the client, based on the
   client's DUID and key selection policies with which the server has
   been configured.  The server identifies the selected key in the
   Advertise message and uses the key to validate subsequent messages
   between the client and the server.

Top      Up      ToC       Page 68 
21.4.5.1. Receiving Solicit Messages and Sending Advertise Messages

   The server selects a key for the client and includes authentication
   information in the Advertise message returned to the client as
   specified in section 21.4.  The server MUST record the identifier of
   the key selected for the client and use that same key for validating
   subsequent messages with the client.

21.4.5.2. Receiving Request, Confirm, Renew, Rebind or Release Messages
          and Sending Reply Messages

   The server uses the key identified in the message and validates the
   message as specified in section 21.4.2.  If the message fails to pass
   the validation test or the server does not know the key identified by
   the 'key ID' field, the server MUST discard the message and MAY
   choose to log the validation failure.

   If the message passes the validation test, the server responds to the
   specific message as described in section 18.2.  The server MUST
   include authentication information generated using the key identified
   in the received message, as specified in section 21.4.

21.5. Reconfigure Key Authentication Protocol

   The Reconfigure key authentication protocol provides protection
   against misconfiguration of a client caused by a Reconfigure message
   sent by a malicious DHCP server.  In this protocol, a DHCP server
   sends a Reconfigure Key to the client in the initial exchange of DHCP
   messages.  The client records the Reconfigure Key for use in
   authenticating subsequent Reconfigure messages from that server.  The
   server then includes an HMAC computed from the Reconfigure Key in
   subsequent Reconfigure messages.

   Both the Reconfigure Key sent from the server to the client and the
   HMAC in subsequent Reconfigure messages are carried as the
   Authentication information in an Authentication option.  The format
   of the Authentication information is defined in the following
   section.

   The Reconfigure Key protocol is used (initiated by the server) only
   if the client and server are not using any other authentication
   protocol and the client and server have negotiated to use Reconfigure
   messages.

Top      Up      ToC       Page 69 
21.5.1. Use of the Authentication Option in the Reconfigure Key
        Authentication Protocol

   The following fields are set in an Authentication option for the
   Reconfigure Key Authentication Protocol:

      protocol    3

      algorithm   1

      RDM         0

   The format of the Authentication information for the Reconfigure Key
   Authentication Protocol is:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |                 Value (128 bits)              |
    +-+-+-+-+-+-+-+-+                                               |
    .                                                               .
    .                                                               .
    .                                               +-+-+-+-+-+-+-+-+
    |                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type    Type of data in Value field carried in this option:

                 1   Reconfigure Key value (used in Reply message).

                 2   HMAC-MD5 digest of the message (used in Reconfigure
                     message).

      Value   Data as defined by field.

21.5.2. Server considerations for Reconfigure Key protocol

   The server selects a Reconfigure Key for a client during the
   Request/Reply, Solicit/Reply or Information-request/Reply message
   exchange.  The server records the Reconfigure Key and transmits that
   key to the client in an Authentication option in the Reply message.

   The Reconfigure Key is 128 bits long, and MUST be a cryptographically
   strong random or pseudo-random number that cannot easily be
   predicted.

Top      Up      ToC       Page 70 
   To provide authentication for a Reconfigure message, the server
   selects a replay detection value according to the RDM selected by the
   server, and computes an HMAC-MD5 of the Reconfigure message using the
   Reconfigure Key for the client.  The server computes the HMAC-MD5
   over the entire DHCP Reconfigure message, including the
   Authentication option; the HMAC-MD5 field in the Authentication
   option is set to zero for the HMAC-MD5 computation.  The server
   includes the HMAC-MD5 in the authentication information field in an
   Authentication option included in the Reconfigure message sent to the
   client.

21.5.3. Client considerations for Reconfigure Key protocol

   The client will receive a Reconfigure Key from the server in the
   initial Reply message from the server.  The client records the
   Reconfigure Key for use in authenticating subsequent Reconfigure
   messages.

   To authenticate a Reconfigure message, the client computes an
   HMAC-MD5 over the DHCP Reconfigure message, using the Reconfigure Key
   received from the server.  If this computed HMAC-MD5 matches the
   value in the Authentication option, the client accepts the
   Reconfigure message.

22. DHCP Options

   Options are used to carry additional information and parameters in
   DHCP messages.  Every option shares a common base format, as
   described in section 22.1.  All values in options are represented in
   network byte order.

   This document describes the DHCP options defined as part of the base
   DHCP specification.  Other options may be defined in the future in
   separate documents.

   Unless otherwise noted, each option may appear only in the options
   area of a DHCP message and may appear only once.  If an option does
   appear multiple times, each instance is considered separate and the
   data areas of the options MUST NOT be concatenated or otherwise
   combined.

Top      Up      ToC       Page 71 
22.1. Format of DHCP Options

   The format of DHCP options is:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          option-code          |           option-len          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          option-data                          |
      |                      (option-len octets)                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code   An unsigned integer identifying the specific option
                    type carried in this option.

      option-len    An unsigned integer giving the length of the
                    option-data field in this option in octets.

      option-data   The data for the option; the format of this data
                    depends on the definition of the option.

   DHCPv6 options are scoped by using encapsulation.  Some options apply
   generally to the client, some are specific to an IA, and some are
   specific to the addresses within an IA.  These latter two cases are
   discussed in sections 22.4 and 22.6.

22.2. Client Identifier Option

   The Client Identifier option is used to carry a DUID (see section 9)
   identifying a client between a client and a server.  The format of
   the Client Identifier option is:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        OPTION_CLIENTID        |          option-len           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                                                               .
      .                              DUID                             .
      .                        (variable length)                      .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code   OPTION_CLIENTID (1).

      option-len    Length of DUID in octets.

Top      Up      ToC       Page 72 
      DUID          The DUID for the client.

22.3. Server Identifier Option

   The Server Identifier option is used to carry a DUID (see section 9)
   identifying a server between a client and a server.  The format of
   the Server Identifier option is:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        OPTION_SERVERID        |          option-len           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                                                               .
      .                              DUID                             .
      .                        (variable length)                      .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code   OPTION_SERVERID (2).

      option-len    Length of DUID in octets.

      DUID          The DUID for the server.

22.4. Identity Association for Non-temporary Addresses Option

   The Identity Association for Non-temporary Addresses option (IA_NA
   option) is used to carry an IA_NA, the parameters associated with the
   IA_NA, and the non-temporary addresses associated with the IA_NA.

   Addresses appearing in an IA_NA option are not temporary addresses
   (see section 22.5).

Top      Up      ToC       Page 73 
   The format of the IA_NA option is:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          OPTION_IA_NA         |          option-len           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        IAID (4 octets)                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              T1                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              T2                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                         IA_NA-options                         .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code          OPTION_IA_NA (3).

      option-len           12 + length of IA_NA-options field.

      IAID                 The unique identifier for this IA_NA; the
                           IAID must be unique among the identifiers for
                           all of this client's IA_NAs.  The number
                           space for IA_NA IAIDs is separate from the
                           number space for IA_TA IAIDs.

      T1                   The time at which the client contacts the
                           server from which the addresses in the IA_NA
                           were obtained to extend the lifetimes of the
                           addresses assigned to the IA_NA; T1 is a
                           time duration relative to the current time
                           expressed in units of seconds.

      T2                   The time at which the client contacts any
                           available server to extend the lifetimes of
                           the addresses assigned to the IA_NA; T2 is a
                           time duration relative to the current time
                           expressed in units of seconds.

      IA_NA-options        Options associated with this IA_NA.

   The IA_NA-options field encapsulates those options that are specific
   to this IA_NA.  For example, all of the IA Address Options carrying
   the addresses associated with this IA_NA are in the IA_NA-options
   field.

Top      Up      ToC       Page 74 
   An IA_NA option may only appear in the options area of a DHCP
   message.  A DHCP message may contain multiple IA_NA options.

   The status of any operations involving this IA_NA is indicated in a
   Status Code option in the IA_NA-options field.

   Note that an IA_NA has no explicit "lifetime" or "lease length" of
   its own.  When the valid lifetimes of all of the addresses in an
   IA_NA have expired, the IA_NA can be considered as having expired.
   T1 and T2 are included to give servers explicit control over when a
   client recontacts the server about a specific IA_NA.

   In a message sent by a client to a server, values in the T1 and T2
   fields indicate the client's preference for those parameters.  The
   client sets T1 and T2 to 0 if it has no preference for those values.
   In a message sent by a server to a client, the client MUST use the
   values in the T1 and T2 fields for the T1 and T2 parameters, unless
   those values in those fields are 0.  The values in the T1 and T2
   fields are the number of seconds until T1 and T2.

   The server selects the T1 and T2 times to allow the client to extend
   the lifetimes of any addresses in the IA_NA before the lifetimes
   expire, even if the server is unavailable for some short period of
   time.  Recommended values for T1 and T2 are .5 and .8 times the
   shortest preferred lifetime of the addresses in the IA that the
   server is willing to extend, respectively.  If the "shortest"
   preferred lifetime is 0xffffffff ("infinity"), the recommended T1 and
   T2 values are also 0xffffffff.  If the time at which the addresses in
   an IA_NA are to be renewed is to be left to the discretion of the
   client, the server sets T1 and T2 to 0.

   If a server receives an IA_NA with T1 greater than T2, and both T1
   and T2 are greater than 0, the server ignores the invalid values of
   T1 and T2 and processes the IA_NA as though the client had set T1 and
   T2 to 0.

   If a client receives an IA_NA with T1 greater than T2, and both T1
   and T2 are greater than 0, the client discards the IA_NA option and
   processes the remainder of the message as though the server had not
   included the invalid IA_NA option.

   Care should be taken in setting T1 or T2 to 0xffffffff ("infinity").
   A client will never attempt to extend the lifetimes of any addresses
   in an IA with T1 set to 0xffffffff.  A client will never attempt to
   use a Rebind message to locate a different server to extend the
   lifetimes of any addresses in an IA with T2 set to 0xffffffff.

Top      Up      ToC       Page 75 
22.5. Identity Association for Temporary Addresses Option

   The Identity Association for the Temporary Addresses (IA_TA) option
   is used to carry an IA_TA, the parameters associated with the IA_TA
   and the addresses associated with the IA_TA.  All of the addresses in
   this option are used by the client as temporary addresses, as defined
   in RFC 3041 [12].  The format of the IA_TA option is:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         OPTION_IA_TA          |          option-len           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        IAID (4 octets)                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                         IA_TA-options                         .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code          OPTION_IA_TA (4).

      option-len           4 + length of IA_TA-options field.

      IAID                 The unique identifier for this IA_TA; the
                           IAID must be unique among the identifiers
                           for all of this client's IA_TAs.  The number
                           space for IA_TA IAIDs is separate from the
                           number space for IA_NA IAIDs.

      IA_TA-options        Options associated with this IA_TA.

   The IA_TA-Options field encapsulates those options that are specific
   to this IA_TA.  For example, all of the IA Address Options carrying
   the addresses associated with this IA_TA are in the IA_TA-options
   field.

   Each IA_TA carries one "set" of temporary addresses; that is, at most
   one address from each prefix assigned to the link to which the client
   is attached.

   An IA_TA option may only appear in the options area of a DHCP
   message.  A DHCP message may contain multiple IA_TA options.

   The status of any operations involving this IA_TA is indicated in a
   Status Code option in the IA_TA-options field.

Top      Up      ToC       Page 76 
   Note that an IA has no explicit "lifetime" or "lease length" of its
   own.  When the valid lifetimes of all of the addresses in an IA_TA
   have expired, the IA can be considered as having expired.

   An IA_TA option does not include values for T1 and T2.  A client MAY
   request that the lifetimes on temporary addresses be extended by
   including the addresses in a IA_TA option sent in a Renew or Rebind
   message to a server.  For example, a client would request an
   extension on the lifetime of a temporary address to allow an
   application to continue to use an established TCP connection.

   The client obtains new temporary addresses by sending an IA_TA option
   with a new IAID to a server.  Requesting new temporary addresses from
   the server is the equivalent of generating new temporary addresses as
   described in RFC 3041.  The server will generate new temporary
   addresses and return them to the client.  The client should request
   new temporary addresses before the lifetimes on the previously
   assigned addresses expire.

   A server MUST return the same set of temporary address for the same
   IA_TA (as identified by the IAID) as long as those addresses are
   still valid.  After the lifetimes of the addresses in an IA_TA have
   expired, the IAID may be reused to identify a new IA_TA with new
   temporary addresses.

   This option MAY appear in a Confirm message if the lifetimes on the
   temporary addresses in the associated IA have not expired.

22.6. IA Address Option

   The IA Address option is used to specify IPv6 addresses associated
   with an IA_NA or an IA_TA.  The IA Address option must be
   encapsulated in the Options field of an IA_NA or IA_TA option.  The
   Options field encapsulates those options that are specific to this
   address.

Top      Up      ToC       Page 77 
   The format of the IA Address option is:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          OPTION_IAADDR        |          option-len           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                         IPv6 address                          |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      preferred-lifetime                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        valid-lifetime                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                                                               .
      .                        IAaddr-options                         .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code   OPTION_IAADDR (5).

      option-len    24 + length of IAaddr-options field.

      IPv6 address  An IPv6 address.

      preferred-lifetime The preferred lifetime for the IPv6 address in
                    the option, expressed in units of seconds.

      valid-lifetime The valid lifetime for the IPv6 address in the
                    option, expressed in units of seconds.

      IAaddr-options Options associated with this address.

   In a message sent by a client to a server, values in the preferred
   and valid lifetime fields indicate the client's preference for those
   parameters.  The client may send 0 if it has no preference for the
   preferred and valid lifetimes.  In a message sent by a server to a
   client, the client MUST use the values in the preferred and valid
   lifetime fields for the preferred and valid lifetimes.  The values in
   the preferred and valid lifetimes are the number of seconds remaining
   in each lifetime.

Top      Up      ToC       Page 78 
   A client discards any addresses for which the preferred lifetime is
   greater than the valid lifetime.  A server ignores the lifetimes set
   by the client if the preferred lifetime is greater than the valid
   lifetime and ignores the values for T1 and T2 set by the client if
   those values are greater than the preferred lifetime.

   Care should be taken in setting the valid lifetime of an address to
   0xffffffff ("infinity"), which amounts to a permanent assignment of
   an address to a client.

   An IA Address option may appear only in an IA_NA option or an IA_TA
   option.  More than one IA Address Option can appear in an IA_NA
   option or an IA_TA option.

   The status of any operations involving this IA Address is indicated
   in a Status Code option in the IAaddr-options field.

22.7. Option Request Option

   The Option Request option is used to identify a list of options in a
   message between a client and a server.  The format of the Option
   Request option is:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           OPTION_ORO          |           option-len          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    requested-option-code-1    |    requested-option-code-2    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              ...                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code   OPTION_ORO (6).

      option-len    2 * number of requested options.

      requested-option-code-n The option code for an option requested by
                    the client.

   A client MAY include an Option Request option in a Solicit, Request,
   Renew, Rebind, Confirm or Information-request message to inform the
   server about options the client wants the server to send to the
   client.  A server MAY include an Option Request option in a
   Reconfigure option to indicate which options the client should
   request from the server.

Top      Up      ToC       Page 79 
22.8. Preference Option

   The Preference option is sent by a server to a client to affect the
   selection of a server by the client.

   The format of the Preference option is:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       OPTION_PREFERENCE       |          option-len           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  pref-value   |
      +-+-+-+-+-+-+-+-+

      option-code   OPTION_PREFERENCE (7).

      option-len    1.

      pref-value    The preference value for the server in this message.

   A server MAY include a Preference option in an Advertise message to
   control the selection of a server by the client.  See section 17.1.3
   for the use of the Preference option by the client and the
   interpretation of Preference option data value.

22.9. Elapsed Time Option

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      OPTION_ELAPSED_TIME      |           option-len          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          elapsed-time         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code   OPTION_ELAPSED_TIME (8).

      option-len    2.

      elapsed-time  The amount of time since the client began its
                    current DHCP transaction.  This time is expressed in
                    hundredths of a second (10^-2 seconds).

   A client MUST include an Elapsed Time option in messages to indicate
   how long the client has been trying to complete a DHCP message
   exchange.  The elapsed time is measured from the time at which the
   client sent the first message in the message exchange, and the

Top      Up      ToC       Page 80 
   elapsed-time field is set to 0 in the first message in the message
   exchange.  Servers and Relay Agents use the data value in this option
   as input to policy controlling how a server responds to a client
   message.  For example, the elapsed time option allows a secondary
   DHCP server to respond to a request when a primary server has not
   answered in a reasonable time.  The elapsed time value is an
   unsigned, 16 bit integer.  The client uses the value 0xffff to
   represent any elapsed time values greater than the largest time value
   that can be represented in the Elapsed Time option.

22.10. Relay Message Option

   The Relay Message option carries a DHCP message in a Relay-forward or
   Relay-reply message.

   The format of the Relay Message option is:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        OPTION_RELAY_MSG       |           option-len          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                       DHCP-relay-message                      .
      .                                                               .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code   OPTION_RELAY_MSG (9)

      option-len    Length of DHCP-relay-message

      DHCP-relay-message In a Relay-forward message, the received
                    message, relayed verbatim to the next relay agent
                    or server; in a Relay-reply message, the message to
                    be copied and relayed to the relay agent or client
                    whose address is in the peer-address field of the
                    Relay-reply message

Top      Up      ToC       Page 81 
22.11. Authentication Option

   The Authentication option carries authentication information to
   authenticate the identity and contents of DHCP messages.  The use of
   the Authentication option is described in section 21.  The format of
   the Authentication option is:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          OPTION_AUTH          |          option-len           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   protocol    |   algorithm   |      RDM      |               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
    |                                                               |
    |          replay detection (64 bits)           +-+-+-+-+-+-+-+-+
    |                                               |   auth-info   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
    .                   authentication information                  .
    .                       (variable length)                       .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code                  OPTION_AUTH (11)

      option-len                   11 + length of authentication
                                   information field

      protocol                     The authentication protocol used in
                                   this authentication option

      algorithm                    The algorithm used in the
                                   authentication protocol

      RDM                          The replay detection method used in
                                   this authentication option

      Replay detection             The replay detection information for
                                   the RDM

      authentication information   The authentication information,
                                   as specified by the protocol and
                                   algorithm used in this authentication
                                   option

Top      Up      ToC       Page 82 
22.12. Server Unicast Option

   The server sends this option to a client to indicate to the client
   that it is allowed to unicast messages to the server.  The format of
   the Server Unicast option is:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          OPTION_UNICAST       |        option-len             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                       server-address                          |
    |                                                               |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code     OPTION_UNICAST (12).

      option-len      16.

      server-address  The IP address to which the client should send
                      messages delivered using unicast.

   The server specifies the IPv6 address to which the client is to send
   unicast messages in the server-address field.  When a client receives
   this option, where permissible and appropriate, the client sends
   messages directly to the server using the IPv6 address specified in
   the server-address field of the option.

   When the server sends a Unicast option to the client, some messages
   from the client will not be relayed by Relay Agents, and will not
   include Relay Agent options from the Relay Agents.  Therefore, a
   server should only send a Unicast option to a client when Relay
   Agents are not sending Relay Agent options.  A DHCP server rejects
   any messages sent inappropriately using unicast to ensure that
   messages are relayed by Relay Agents when Relay Agent options are in
   use.

   Details about when the client may send messages to the server using
   unicast are in section 18.

22.13. Status Code Option

   This option returns a status indication related to the DHCP message
   or option in which it appears.  The format of the Status Code option
   is:

Top      Up      ToC       Page 83 
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       OPTION_STATUS_CODE      |         option-len            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          status-code          |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
    .                                                               .
    .                        status-message                         .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code          OPTION_STATUS_CODE (13).

      option-len           2 + length of status-message.

      status-code          The numeric code for the status encoded in
                           this option.  The status codes are defined in
                           section 24.4.

      status-message       A UTF-8 encoded text string suitable for
                           display to an end user, which MUST NOT be
                           null-terminated.

   A Status Code option may appear in the options field of a DHCP
   message and/or in the options field of another option.  If the Status
   Code option does not appear in a message in which the option could
   appear, the status of the message is assumed to be Success.

22.14. Rapid Commit Option

   The Rapid Commit option is used to signal the use of the two message
   exchange for address assignment.  The format of the Rapid Commit
   option is:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      OPTION_RAPID_COMMIT      |               0               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code     OPTION_RAPID_COMMIT (14).

      option-len      0.

   A client MAY include this option in a Solicit message if the client
   is prepared to perform the Solicit-Reply message exchange described
   in section 17.1.1.

Top      Up      ToC       Page 84 
   A server MUST include this option in a Reply message sent in response
   to a Solicit message when completing the Solicit-Reply message
   exchange.

   DISCUSSION:

      Each server that responds with a Reply to a Solicit that includes
      a Rapid Commit option will commit the assigned addresses in the
      Reply message to the client, and will not receive any confirmation
      that the client has received the Reply message.  Therefore, if
      more than one server responds to a Solicit that includes a Rapid
      Commit option, some servers will commit addresses that are not
      actually used by the client.

      The problem of unused addresses can be minimized, for example, by
      designing the DHCP service so that only one server responds to the
      Solicit or by using relatively short lifetimes for assigned
      addresses.

22.15. User Class Option

   The User Class option is used by a client to identify the type or
   category of user or applications it represents.

   The format of the User Class option is:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       OPTION_USER_CLASS       |          option-len           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                                                               .
      .                          user-class-data                      .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code          OPTION_USER_CLASS (15).

      option-len           Length of user class data field.

      user-class-data      The user classes carried by the client.

   The information contained in the data area of this option is
   contained in one or more opaque fields that represent the user class
   or classes of which the client is a member.  A server selects
   configuration information for the client based on the classes
   identified in this option.  For example, the User Class option can be
   used to configure all clients of people in the accounting department

Top      Up      ToC       Page 85 
   with a different printer than clients of people in the marketing
   department.  The user class information carried in this option MUST
   be configurable on the client.

   The data area of the user class option MUST contain one or more
   instances of user class data.  Each instance of the user class data
   is formatted as follows:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
      |        user-class-len         |          opaque-data          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+

   The user-class-len is two octets long and specifies the length of the
   opaque user class data in network byte order.

   A server interprets the classes identified in this option according
   to its configuration to select the appropriate configuration
   information for the client.  A server may use only those user classes
   that it is configured to interpret in selecting configuration
   information for a client and ignore any other user classes.  In
   response to a message containing a User Class option, a server
   includes a User Class option containing those classes that were
   successfully interpreted by the server, so that the client can be
   informed of the classes interpreted by the server.

22.16. Vendor Class Option

   This option is used by a client to identify the vendor that
   manufactured the hardware on which the client is running.  The
   information contained in the data area of this option is contained in
   one or more opaque fields that identify details of the hardware
   configuration.  The format of the Vendor Class option is:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      OPTION_VENDOR_CLASS      |           option-len          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       enterprise-number                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                                                               .
      .                       vendor-class-data                       .
      .                             . . .                             .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code          OPTION_VENDOR_CLASS (16).

      option-len           4 + length of vendor class data field.

Top      Up      ToC       Page 86 
      enterprise-number    The vendor's registered Enterprise Number as
                           registered with IANA [6].

      vendor-class-data    The hardware configuration of the host on
                           which the client is running.

   The vendor-class-data is composed of a series of separate items, each
   of which describes some characteristic of the client's hardware
   configuration.  Examples of vendor-class-data instances might include
   the version of the operating system the client is running or the
   amount of memory installed on the client.

   Each instance of the vendor-class-data is formatted as follows:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
      |       vendor-class-len        |          opaque-data          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+

   The vendor-class-len is two octets long and specifies the length of
   the opaque vendor class data in network byte order.

22.17. Vendor-specific Information Option

   This option is used by clients and servers to exchange
   vendor-specific information.

   The format of the Vendor-specific Information option is:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      OPTION_VENDOR_OPTS       |           option-len          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       enterprise-number                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                                                               .
      .                          option-data                          .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code          OPTION_VENDOR_OPTS (17)

      option-len           4 + length of option-data field

      enterprise-number    The vendor's registered Enterprise Number as
                           registered with IANA [6].

Top      Up      ToC       Page 87 
      option-data          An opaque object of option-len octets,
                           interpreted by vendor-specific code on the
                           clients and servers

   The definition of the information carried in this option is vendor
   specific.  The vendor is indicated in the enterprise-number field.
   Use of vendor-specific information allows enhanced operation,
   utilizing additional features in a vendor's DHCP implementation.  A
   DHCP client that does not receive requested vendor-specific
   information will still configure the host device's IPv6 stack to be
   functional.

   The encapsulated vendor-specific options field MUST be encoded as a
   sequence of code/length/value fields of identical format to the DHCP
   options field.  The option codes are defined by the vendor identified
   in the enterprise-number field and are not managed by IANA.  Each of
   the encapsulated options is formatted as follows:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          opt-code             |             option-len        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                                                               .
      .                          option-data                          .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      opt-code             The code for the encapsulated option.

      option-len           An unsigned integer giving the length of the
                           option-data field in this encapsulated option
                           in octets.

      option-data          The data area for the encapsulated option.

   Multiple instances of the Vendor-specific Information option may
   appear in a DHCP message.  Each instance of the option is interpreted
   according to the option codes defined by the vendor identified by the
   Enterprise Number in that option.

22.18. Interface-Id Option

   The relay agent MAY send the Interface-id option to identify the
   interface on which the client message was received.  If a relay agent
   receives a Relay-reply message with an Interface-id option, the relay
   agent relays the message to the client through the interface
   identified by the option.

Top      Up      ToC       Page 88 
   The format of the Interface ID option is:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      OPTION_INTERFACE_ID      |         option-len            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                               .
    .                         interface-id                          .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code          OPTION_INTERFACE_ID (18).

      option-len           Length of interface-id field.

      interface-id         An opaque value of arbitrary length generated
                           by the relay agent to identify one of the
                           relay agent's interfaces.

   The server MUST copy the Interface-Id option from the Relay-Forward
   message into the Relay-Reply message the server sends to the relay
   agent in response to the Relay-Forward message.  This option MUST NOT
   appear in any message except a Relay-Forward or Relay-Reply message.

   Servers MAY use the Interface-ID for parameter assignment policies.
   The Interface-ID SHOULD be considered an opaque value, with policies
   based on exact match only; that is, the Interface-ID SHOULD NOT be
   internally parsed by the server.  The Interface-ID value for an
   interface SHOULD be stable and remain unchanged, for example, after
   the relay agent is restarted; if the Interface-ID changes, a server
   will not be able to use it reliably in parameter assignment policies.

22.19. Reconfigure Message Option

   A server includes a Reconfigure Message option in a Reconfigure
   message to indicate to the client whether the client responds with a
   Renew message or an Information-request message.  The format of this
   option is:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      OPTION_RECONF_MSG        |         option-len            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    msg-type   |
    +-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 89 
      option-code          OPTION_RECONF_MSG (19).

      option-len           1.

      msg-type             5 for Renew message, 11 for
                           Information-request message.

   The Reconfigure Message option can only appear in a Reconfigure
   message.

22.20. Reconfigure Accept Option

   A client uses the Reconfigure Accept option to announce to the server
   whether the client is willing to accept Reconfigure messages, and a
   server uses this option to tell the client whether or not to accept
   Reconfigure messages.  The default behavior, in the absence of this
   option, means unwillingness to accept Reconfigure messages, or
   instruction not to accept Reconfigure messages, for the client and
   server messages, respectively.  The following figure gives the format
   of the Reconfigure Accept option:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     OPTION_RECONF_ACCEPT      |               0               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code   OPTION_RECONF_ACCEPT (20).

      option-len    0.



(page 89 continued on part 5)

Next RFC Part