Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8415

Dynamic Host Configuration Protocol for IPv6 (DHCPv6)

Pages: 154
Proposed Standard
Errata
Obsoletes:  3315363337364242708372837550
Part 12 of 14 – Pages 121 to 129
First   Prev   Next

Top   ToC   RFC8415 - Page 121   prevText

21.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, a Rebind message, or an Information-request message. The format of the Reconfigure 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_RECONF_MSG | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | msg-type | +-+-+-+-+-+-+-+-+ Figure 33: Reconfigure Message Option Format option-code OPTION_RECONF_MSG (19). option-len 1. msg-type 5 for Renew message, 6 for Rebind message, 11 for Information-request message. A 1-octet unsigned integer. The Reconfigure Message option can only appear in a Reconfigure message.

21.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. In the absence of this option, the default behavior is that the client is unwilling to accept Reconfigure messages. The format of the Reconfigure Accept 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_ACCEPT | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 34: Reconfigure Accept Option Format option-code OPTION_RECONF_ACCEPT (20). option-len 0.
Top   ToC   RFC8415 - Page 122

21.21. Identity Association for Prefix Delegation Option

The IA_PD option is used to carry a prefix delegation identity association, the parameters associated with the IA_PD, and the prefixes associated with it. The format of the IA_PD 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_PD | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IAID (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . IA_PD-options . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 35: Identity Association for Prefix Delegation Option Format option-code OPTION_IA_PD (25). option-len 12 + length of IA_PD-options field. IAID The unique identifier for this IA_PD; the IAID must be unique among the identifiers for all of this client's IA_PDs. The number space for IA_PD IAIDs is separate from the number space for other IA option types (i.e., IA_NA and IA_TA). A 4-octet field containing an unsigned integer. T1 The time interval after which the client should contact the server from which the prefixes in the IA_PD were obtained to extend the lifetimes of the prefixes delegated to the IA_PD; T1 is a time duration relative to the message reception time expressed in units of seconds. A 4-octet field containing an unsigned integer.
Top   ToC   RFC8415 - Page 123
      T2                   The time interval after which the client
                           should contact any available server to extend
                           the lifetimes of the prefixes assigned to the
                           IA_PD; T2 is a time duration relative to the
                           message reception time expressed in units of
                           seconds.  A 4-octet field containing an
                           unsigned integer.

      IA_PD-options        Options associated with this IA_PD.  A
                           variable-length field (12 octets less than
                           the value in the option-len field).

   The IA_PD-options field encapsulates those options that are specific
   to this IA_PD.  For example, all of the IA Prefix options (see
   Section 21.22) carrying the prefixes associated with this IA_PD are
   in the IA_PD-options field.

   An IA_PD option may only appear in the options area of a DHCP
   message.  A DHCP message may contain multiple IA_PD options (though
   each must have a unique IAID).

   The status of any operations involving this IA_PD is indicated in a
   Status Code option (see Section 21.13) in the IA_PD-options field.

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

   In a message sent by a client to a server, the T1 and T2 fields
   SHOULD be set to 0.  The server MUST ignore any values in these
   fields in messages received from a client.

   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 timers, unless
   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 prefixes in the IA_PD before the lifetimes
   expire, even if the server is unavailable for some short period of
   time.  Recommended values for T1 and T2 are 0.5 and 0.8 times the
   shortest preferred lifetime of the prefixes in the IA_PD that the
   server is willing to extend, respectively.  If the time at which the
   prefixes in an IA_PD are to be renewed is to be left to the
   discretion of the client, the server sets T1 and T2 to 0.  The client
   MUST follow the rules defined in Section 14.2.
Top   ToC   RFC8415 - Page 124
   If a client receives an IA_PD with T1 greater than T2 and both T1 and
   T2 are greater than 0, the client discards the IA_PD option and
   processes the remainder of the message as though the server had not
   included the IA_PD option.

21.22. IA Prefix Option

The IA Prefix option is used to specify a prefix associated with an IA_PD. The IA Prefix option must be encapsulated in the IA_PD-options field of an IA_PD option (see Section 21.21). 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_IAPREFIX | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | preferred-lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | valid-lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | prefix-length | | +-+-+-+-+-+-+-+-+ IPv6-prefix | | (16 octets) | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . +-+-+-+-+-+-+-+-+ . . IAprefix-options . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 36: IA Prefix Option Format option-code OPTION_IAPREFIX (26). option-len 25 + length of IAprefix-options field. preferred-lifetime The preferred lifetime for the prefix in the option, expressed in units of seconds. A value of 0xffffffff represents "infinity" (see Section 7.7). A 4-octet field containing an unsigned integer.
Top   ToC   RFC8415 - Page 125
      valid-lifetime       The valid lifetime for the prefix in the
                           option, expressed in units of seconds.  A
                           value of 0xffffffff represents "infinity".  A
                           4-octet field containing an unsigned integer.

      prefix-length        Length for this prefix in bits.  A 1-octet
                           unsigned integer.

      IPv6-prefix          An IPv6 prefix.  A 16-octet field.

      IAprefix-options     Options associated with this prefix.  A
                           variable-length field (25 octets less than
                           the value in the option-len field).

   In a message sent by a client to a server, the preferred-lifetime and
   valid-lifetime fields SHOULD be set to 0.  The server MUST ignore any
   received values in these lifetime fields.

   The client SHOULD NOT send an IA Prefix option with 0 in the
   "prefix-length" field (and an unspecified value (::) in the
   "IPv6-prefix" field).  A client MAY send a non-zero value in the
   "prefix-length" field and the unspecified value (::) in the
   "IPv6-prefix" field to indicate a preference for the size of the
   prefix to be delegated.  See [RFC8168] for further details on prefix-
   length hints.

   The client MUST discard any prefixes for which the preferred lifetime
   is greater than the valid lifetime.

   The values in the preferred-lifetime and valid-lifetime fields are
   the number of seconds remaining in each lifetime.  See
   Section 18.2.10.1 for more details on how these values are used for
   delegated prefixes.

   As per Section 7.7, the value of 0xffffffff for the preferred
   lifetime or the valid lifetime is taken to mean "infinity" and should
   be used carefully.

   An IA Prefix option may appear only in an IA_PD option.  More than
   one IA Prefix option can appear in a single IA_PD option.

   The status of any operations involving this IA Prefix option is
   indicated in a Status Code option (see Section 21.13) in the
   IAprefix-options field.
Top   ToC   RFC8415 - Page 126

21.23. Information Refresh Time Option

This option is requested by clients and returned by servers to specify an upper bound for how long a client should wait before refreshing information retrieved from a DHCP server. It is only used in Reply messages in response to Information-request messages. In other messages, there will usually be other information that indicates when the client should contact the server, e.g., T1/T2 times and lifetimes. This option is useful when the configuration parameters change or during a renumbering event, as clients running in the stateless mode will be able to update their configuration. The format of the Information Refresh Time 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_INFORMATION_REFRESH_TIME| option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | information-refresh-time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 37: Information Refresh Time Option Format option-code OPTION_INFORMATION_REFRESH_TIME (32). option-len 4. information-refresh-time Time duration relative to the current time, expressed in units of seconds. A 4-octet field containing an unsigned integer. A DHCP client MUST request this option in the Option Request option (see Section 21.7) when sending Information-request messages. A client MUST NOT request this option in the Option Request option in any other messages. A server sending a Reply to an Information-request message SHOULD include this option if it is requested in the Option Request option of the Information-request. The option value MUST NOT be smaller than IRT_MINIMUM. This option MUST only appear in the top-level options area of Reply messages. If the Reply to an Information-request message does not contain this option, the client MUST behave as if the option with the value IRT_DEFAULT was provided.
Top   ToC   RFC8415 - Page 127
   A client MUST use the refresh time IRT_MINIMUM if it receives the
   option with a value less than IRT_MINIMUM.

   As per Section 7.7, the value 0xffffffff is taken to mean "infinity"
   and implies that the client should not refresh its configuration data
   without some other trigger (such as detecting movement to a new
   link).

   If a client contacts the server to obtain new data or refresh some
   existing data before the refresh time expires, then it SHOULD also
   refresh all data covered by this option.

   When the client detects that the refresh time has expired, it SHOULD
   try to update its configuration data by sending an
   Information-request as specified in Section 18.2.6, except that the
   client MUST delay sending the first Information-request by a random
   amount of time between 0 and INF_MAX_DELAY.

   A client MAY have a maximum value for the refresh time, where that
   value is used whenever the client receives this option with a value
   higher than the maximum.  This also means that the maximum value is
   used when the received value is "infinity".  A maximum value might
   make the client less vulnerable to attacks based on forged DHCP
   messages.  Without a maximum value, a client may be made to use wrong
   information for a possibly infinite period of time.  There may,
   however, be reasons for having a very long refresh time, so it may be
   useful for this maximum value to be configurable.

21.24. SOL_MAX_RT Option

A DHCP server sends the SOL_MAX_RT option to a client to override the default value of SOL_MAX_RT. The value of SOL_MAX_RT in the option replaces the default value defined in Section 7.6. One use for the SOL_MAX_RT option is to set a higher value for SOL_MAX_RT; this reduces the Solicit traffic from a client that has not received a response to its Solicit messages. The format of the SOL_MAX_RT 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_SOL_MAX_RT | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SOL_MAX_RT value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 38: SOL_MAX_RT Option Format
Top   ToC   RFC8415 - Page 128
      option-code          OPTION_SOL_MAX_RT (82).

      option-len           4.

      SOL_MAX_RT value     Overriding value for SOL_MAX_RT in seconds;
                           MUST be in this range: 60 <= "value" <= 86400
                           (1 day).  A 4-octet field containing an
                           unsigned integer.

   A DHCP client MUST include the SOL_MAX_RT option code in any Option
   Request option (see Section 21.7) it sends in a Solicit message.

   The DHCP server MAY include the SOL_MAX_RT option in any response it
   sends to a client that has included the SOL_MAX_RT option code in an
   Option Request option.  The SOL_MAX_RT option is sent as a top-level
   option in the message to the client.

   A DHCP client MUST ignore any SOL_MAX_RT option values that are less
   than 60 or more than 86400.

   If a DHCP client receives a message containing a SOL_MAX_RT option
   that has a valid value for SOL_MAX_RT, the client MUST set its
   internal SOL_MAX_RT parameter to the value contained in the
   SOL_MAX_RT option.  This value of SOL_MAX_RT is then used by the
   retransmission mechanism defined in Sections 15 and 18.2.1.

   The purpose of this mechanism is to give network administrators a way
   to avoid excessive DHCP traffic if all DHCP servers become
   unavailable.  Therefore, this value is expected to be retained for as
   long as practically possible.

   An updated SOL_MAX_RT value applies only to the network interface on
   which the client received the SOL_MAX_RT option.

21.25. INF_MAX_RT Option

A DHCP server sends the INF_MAX_RT option to a client to override the default value of INF_MAX_RT. The value of INF_MAX_RT in the option replaces the default value defined in Section 7.6. One use for the INF_MAX_RT option is to set a higher value for INF_MAX_RT; this reduces the Information-request traffic from a client that has not received a response to its Information-request messages.
Top   ToC   RFC8415 - Page 129
   The format of the INF_MAX_RT 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_INF_MAX_RT        |         option-len            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       INF_MAX_RT value                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 39: INF_MAX_RT Option Format

      option-code          OPTION_INF_MAX_RT (83).

      option-len           4.

      INF_MAX_RT value     Overriding value for INF_MAX_RT in seconds;
                           MUST be in this range: 60 <= "value" <= 86400
                           (1 day).  A 4-octet field containing an
                           unsigned integer.

   A DHCP client MUST include the INF_MAX_RT option code in any Option
   Request option (see Section 21.7) it sends in an Information-request
   message.

   The DHCP server MAY include the INF_MAX_RT option in any response it
   sends to a client that has included the INF_MAX_RT option code in an
   Option Request option.  The INF_MAX_RT option is a top-level option
   in the message to the client.

   A DHCP client MUST ignore any INF_MAX_RT option values that are less
   than 60 or more than 86400.

   If a DHCP client receives a message containing an INF_MAX_RT option
   that has a valid value for INF_MAX_RT, the client MUST set its
   internal INF_MAX_RT parameter to the value contained in the
   INF_MAX_RT option.  This value of INF_MAX_RT is then used by the
   retransmission mechanism defined in Sections 15 and 18.2.6.

   An updated INF_MAX_RT value applies only to the network interface on
   which the client received the INF_MAX_RT option.


(next page on part 13)

Next Section