Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3315

Dynamic Host Configuration Protocol for IPv6 (DHCPv6)

Pages: 101
Obsoleted by:  8415
Updated by:  436154946221642266447083722772837550
Part 4 of 5 – Pages 61 to 89
First   Prev   Next

ToP   noToC   RFC3315 - Page 61   prevText

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   noToC   RFC3315 - 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   noToC   RFC3315 - 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   noToC   RFC3315 - 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   noToC   RFC3315 - 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   noToC   RFC3315 - 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   noToC   RFC3315 - 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   noToC   RFC3315 - 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   noToC   RFC3315 - 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   noToC   RFC3315 - 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   noToC   RFC3315 - 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   noToC   RFC3315 - 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   noToC   RFC3315 - 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   noToC   RFC3315 - 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   noToC   RFC3315 - 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   noToC   RFC3315 - 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   noToC   RFC3315 - 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   noToC   RFC3315 - 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   noToC   RFC3315 - 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   noToC   RFC3315 - 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   noToC   RFC3315 - 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   noToC   RFC3315 - 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   noToC   RFC3315 - 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   noToC   RFC3315 - 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   noToC   RFC3315 - 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   noToC   RFC3315 - 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   noToC   RFC3315 - 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   noToC   RFC3315 - 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   noToC   RFC3315 - 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 Section