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.
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 RFC3041 [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.
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 RFC3041. 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.
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.
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.
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
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
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
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:
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.
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
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.
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].
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.
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 |
+-+-+-+-+-+-+-+-+
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.
23. Security Considerations
The threat to DHCP is inherently an insider threat (assuming a
properly configured network where DHCPv6 ports are blocked on the
perimeter gateways of the enterprise). Regardless of the gateway
configuration, however, the potential attacks by insiders and
outsiders are the same.
Use of manually configured preshared keys for IPsec between relay
agents and servers does not defend against replayed DHCP messages.
Replayed messages can represent a DOS attack through exhaustion of
processing resources, but not through mis-configuration or exhaustion
of other resources such as assignable addresses.
One attack specific to a DHCP client is the establishment of a
malicious server with the intent of providing incorrect configuration
information to the client. The motivation for doing so may be to
mount a "man in the middle" attack that causes the client to
communicate with a malicious server instead of a valid server for
some service such as DNS or NTP. The malicious server may also mount
a denial of service attack through misconfiguration of the client
that causes all network communication from the client to fail.
There is another threat to DHCP clients from mistakenly or
accidentally configured DHCP servers that answer DHCP client requests
with unintentionally incorrect configuration parameters.
A DHCP client may also be subject to attack through the receipt of a
Reconfigure message from a malicious server that causes the client to
obtain incorrect configuration information from that server. Note
that although a client sends its response (Renew or
Information-request message) through a relay agent and, therefore,
that response will only be received by servers to which DHCP messages
are relayed, a malicious server could send a Reconfigure message to a
client, followed (after an appropriate delay) by a Reply message that
would be accepted by the client. Thus, a malicious server that is
not on the network path between the client and the server may still
be able to mount a Reconfigure attack on a client. The use of
transaction IDs that are cryptographically sound and cannot easily be
predicted will also reduce the probability that such an attack will
be successful.
The threat specific to a DHCP server is an invalid client
masquerading as a valid client. The motivation for this may be for
theft of service, or to circumvent auditing for any number of
nefarious purposes.
The threat common to both the client and the server is the resource
"denial of service" (DoS) attack. These attacks typically involve
the exhaustion of available addresses, or the exhaustion of CPU or
network bandwidth, and are present anytime there is a shared
resource.
In the case where relay agents add additional options to Relay
Forward messages, the messages exchanged between relay agents and
servers may be used to mount a "man in the middle" or denial of
service attack.
This threat model does not consider the privacy of the contents of
DHCP messages to be important. DHCP is not used to exchange
authentication or configuration information that must be kept secret
from other networks nodes.
DHCP authentication provides for authentication of the identity of
DHCP clients and servers, and for the integrity of messages delivered
between DHCP clients and servers. DHCP authentication does not
provide any privacy for the contents of DHCP messages.
The Delayed Authentication protocol described in section 21.4 uses a
secret key that is shared between a client and a server. The use of
a "DHCP realm" in the shared key allows identification of
administrative domains so that a client can select the appropriate
key or keys when roaming between administrative domains. However,
the Delayed Authentication protocol does not define any mechanism for
sharing of keys, so a client may require separate keys for each
administrative domain it encounters. The use of shared keys may not
scale well and does not provide for repudiation of compromised keys.
This protocol is focused on solving the intradomain problem where the
out-of-band exchange of a shared key is feasible.
Because of the opportunity for attack through the Reconfigure
message, a DHCP client MUST discard any Reconfigure message that does
not include authentication or that does not pass the validation
process for the authentication protocol.
The Reconfigure Key protocol described in section 21.5 provides
protection against the use of a Reconfigure message by a malicious
DHCP server to mount a denial of service or man-in-the-middle attack
on a client. This protocol can be compromised by an attacker that
can intercept the initial message in which the DHCP server sends the
key to the client.
Communication between a server and a relay agent, and communication
between relay agents, can be secured through the use of IPSec, as
described in section 21.1. The use of manual configuration and
installation of static keys are acceptable in this instance because
relay agents and the server will belong to the same administrative
domain and the relay agents will require other specific configuration
(for example, configuration of the DHCP server address) as well as
the IPSec configuration.
24. IANA Considerations
This document defines several new name spaces associated with DHCPv6
and DHCPv6 options:
- Message types
- Status codes
- DUID
- Option codes
IANA has established a registry of values for each of these name
spaces, which are described in the remainder of this section. These
name spaces will be managed by the IANA and all will be managed
separately from the name spaces defined for DHCPv4.
New multicast addresses, message types, status codes, and DUID types
are assigned via Standards Action [11].
New DHCP option codes are tentatively assigned after the
specification for the associated option, published as an Internet
Draft, has received expert review by a designated expert [11]. The
final assignment of DHCP option codes is through Standards Action, as
defined in RFC2434 [11].
This document also references three name spaces in section 21 that
are associated with the Authentication Option (section 22.11). These
name spaces are defined by the authentication mechanism for DHCPv4 in
RFC3118 [4].
The authentication name spaces currently registered by IANA will
apply to both DHCPv6 and DHCPv4. In the future, specifications that
define new Protocol, Algorithm and RDM mechanisms will explicitly
define whether the new mechanisms are used with DHCPv4, DHCPv6 or
both.
24.1. Multicast Addresses
Section 5.1 defines the following multicast addresses, which have
been assigned by IANA for use by DHCPv6:
All_DHCP_Relay_Agents_and_Servers address: FF02::1:2
All_DHCP_Servers address: FF05::1:3
24.2. DHCP Message Types
IANA has recorded the following message types (defined in section
5.3). IANA will maintain the registry of DHCP message types.
SOLICIT 1
ADVERTISE 2
REQUEST 3
CONFIRM 4
RENEW 5
REBIND 6
REPLY 7
RELEASE 8
DECLINE 9
RECONFIGURE 10
INFORMATION-REQUEST 11
RELAY-FORW 12
RELAY-REPL 13
24.3. DHCP Options
IANA has recorded the following option-codes (as defined in section
22). IANA will maintain the registry of DHCP option codes.
OPTION_CLIENTID 1
OPTION_SERVERID 2
OPTION_IA_NA 3
OPTION_IA_TA 4
OPTION_IAADDR 5
OPTION_ORO 6
OPTION_PREFERENCE 7
OPTION_ELAPSED_TIME 8
OPTION_RELAY_MSG 9
OPTION_AUTH 11
OPTION_UNICAST 12
OPTION_STATUS_CODE 13
OPTION_RAPID_COMMIT 14
OPTION_USER_CLASS 15
OPTION_VENDOR_CLASS 16
OPTION_VENDOR_OPTS 17
OPTION_INTERFACE_ID 18
OPTION_RECONF_MSG 19
OPTION_RECONF_ACCEPT 20
24.4. Status Codes
IANA has recorded the status codes defined in the following table.
IANA will manage the definition of additional status codes in the
future.
Name Code Description
---------- ---- -----------
Success 0 Success.
UnspecFail 1 Failure, reason unspecified; this
status code is sent by either a client
or a server to indicate a failure
not explicitly specified in this
document.
NoAddrsAvail 2 Server has no addresses available to assign to
the IA(s).
NoBinding 3 Client record (binding) unavailable.
NotOnLink 4 The prefix for the address is not appropriate for
the link to which the client is attached.
UseMulticast 5 Sent by a server to a client to force the
client to send messages to the server.
using the All_DHCP_Relay_Agents_and_Servers
address.
24.5. DUID
IANA has recorded the following DUID types (as defined in section
9.1). IANA will manage the definition of additional DUID types in
the future.
DUID-LLT 1
DUID-EN 2
DUID-LL 3
25. Acknowledgments
Thanks to the DHC Working Group and the members of the IETF for their
time and input into the specification. In particular, thanks also
for the consistent input, ideas, and review by (in alphabetical
order) Bernard Aboba, Bill Arbaugh, Thirumalesh Bhat, Steve Bellovin,
A. K. Vijayabhaskar, Brian Carpenter, Matt Crawford, Francis Dupont,
Richard Hussong, Kim Kinnear, Fredrik Lindholm, Tony Lindstrom, Josh
Littlefield, Gerald Maguire, Jack McCann, Shin Miyakawa, Thomas
Narten, Erik Nordmark, Jarno Rajahalme, Yakov Rekhter, Mark Stapp,
Matt Thomas, Sue Thomson, Tatuya Jinmei and Phil Wells.
Thanks to Steve Deering and Bob Hinden, who have consistently taken
the time to discuss the more complex parts of the IPv6
specifications.
And, thanks to Steve Deering for pointing out at IETF 51 in London
that the DHCPv6 specification has the highest revision number of any
Internet Draft.
26. References
26.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC2119, March 1997.
[2] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC2464, December 1998.
[3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC2460, December 1998.
[4] Droms, R., Ed. and W. Arbaugh, Ed., "Authentication for DHCP
Messages", RFC3118, June 2001.
[5] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC2373, July 1998.
[6] IANA. Private Enterprise Numbers.
http://www.iana.org/assignments/enterprise-numbers.html.
[7] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC2401, November 1998.
[8] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC2104, February 1997.
[9] Mills, D., "Network Time Protocol (Version 3) Specification,
Implementation", RFC1305, March 1992.
[10] Mockapetris, P., "Domain names - implementation and
specification", RFC1035, November 1987.
[11] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC2434, October 1998.
[12] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC3041, January 2001.
[13] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for
IP Version 6 (IPv6)", RFC2461, December 1998.
[14] Plummer, D.C., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet address
for transmission on Ethernet hardware", STD 37, RFC826,
November 1982.
[15] Postel, J., "User Datagram Protocol", STD 6, RFC768, August
1980.
[16] Rivest, R., "The MD5 Message-Digest Algorithm", RFC1321, April
1992.
[17] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC2462, December 1998.
26.2. Informative References
[18] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC2132, March 1997.
[19] Droms, R., "Dynamic Host Configuration Protocol", RFC2131,
March 1997.
[20] R. Droms, Ed. DNS Configuration options for DHCPv6. April
2002. Work in Progress.
[21] A. K. Vijayabhaskar. Time Configuration Options for DHCPv6.
May 2002. Work in Progress.
[22] Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", RFC2136, April
1997.
A. Appearance of Options in Message Types
The following table indicates with a "*" the options are allowed in
each DHCP message type:
Client Server IA_NA Option Pref Time Relay Auth. Server
ID ID IA_TA Request Msg. Unica.
Solicit * * * * *
Advert. * * * * *
Request * * * * * *
Confirm * * * * *
Renew * * * * * *
Rebind * * * * *
Decline * * * * * *
Release * * * * * *
Reply * * * * * *
Reconf. * * * *
Inform. * (see note) * * *
R-forw. * *
R-repl. * *
NOTE:
Only included in Information-Request messages that are sent
in response to a Reconfigure (see section 19.4.3).
Status Rap. User Vendor Vendor Inter. Recon. Recon.
Code Comm. Class Class Spec. ID Msg. Accept
Solicit * * * * *
Advert. * * * * *
Request * * * *
Confirm * * *
Renew * * * *
Rebind * * * *
Decline * * *
Release * * *
Reply * * * * * *
Reconf. *
Inform. * * * *
R-forw. * * * *
R-repl. * * * *
B. Appearance of Options in the Options Field of DHCP Options
The following table indicates with a "*" where options can appear in
the options field of other options:
Option IA_NA/ IAADDR Relay Relay
Field IA_TA Forw. Reply
Client ID *
Server ID *
IA_NA/IA_TA *
IAADDR *
ORO *
Preference *
Elapsed Time *
Relay Message * *
Authentic. *
Server Uni. *
Status Code * * *
Rapid Comm. *
User Class *
Vendor Class *
Vendor Info. *
Interf. ID * *
Reconf. MSG. *
Reconf. Accept *
Note: "Relay Forw" / "Relay Reply" options appear in the options
field of the message but may only appear in these messages.
Chair's Address
The working group can be contacted via the current chair:
Ralph Droms
Cisco Systems
1414 Massachusetts Avenue
Boxborough, MA 01719
Phone: (978) 936-1674
EMail: rdroms@cisco.com
Authors' Addresses
Jim Bound
Hewlett Packard Corporation
ZK3-3/W20
110 Spit Brook Road
Nashua, NH 03062-2698
USA
Phone: +1 603 884 0062
EMail: Jim.Bound@hp.com
Bernie Volz
116 Hawkins Pond Road
Center Harbor, NH 03226-3103
USA
Phone: +1-508-259-3734
EMail: volz@metrocast.net
Ted Lemon
Nominum, Inc.
950 Charter Street
Redwood City, CA 94043
USA
EMail: Ted.Lemon@nominum.com
Charles E. Perkins
Communications Systems Lab
Nokia Research Center
313 Fairchild Drive
Mountain View, California 94043
USA
Phone: +1-650 625-2986
EMail: charles.perkins@nokia.com
Mike Carney
Sun Microsystems, Inc
17 Network Circle
Menlo Park, CA 94025
USA
Phone: +1-650-786-4171
EMail: michael.carney@sun.com
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.