Option Descriptions
The following sections describe the DHCP options in detail:
- IP Layer Parameters Per Host
- IP Layer Parameters Per Interface
- Link Layer Parameters Per Interface
- TCP Parameters
- Application and Service Parameters
- DHCPv4 Extension Options
- DHCPv6 Options
- Microsoft Client Options
- Options by Number
- Options by Cisco Prime Network Registrar Name
- Option Validation Types
RFC 1497 Vendor Extensions
The table below lists the vendor extensions as defined in RFC 1497.
Option Name |
No. |
Length |
Description |
---|---|---|---|
Pad |
0 |
1 octet |
Causes the subsequent fields to align on word boundaries. |
End |
255 |
1 octet |
End of valid information in the vendor field. Subsequent octets should be filled with the Pad options. |
Subnet Mask |
1 |
4 octets |
Client subnet mask, as per RFC 950. If both the Subnet Mask and the Router option are specified in a DHCP reply, the Subnet Mask option must be first. |
Time Offset |
2 |
4 octets |
Offset of the client subnet, in seconds, from Universal Time (UT). The offset is expressed as a twos-complement 32-bit integer. A positive offset indicates a location east of the zero meridian and a negative offset indicates a location west of the zero meridian. |
Router |
3 |
4 octets minimum; multiples of 4 |
List of IP addresses for routers on the client subnet. Routers should be in order of preference. |
Time Server |
4 |
4 octets minimum; multiples of 4 |
List of RFC 868 compliant time servers available to the client. Servers should be in order of preference. |
Name Server Option |
5 |
4 octets minimum; multiples of 4 |
List of IEN 116 name servers available to the client. Servers should be in order of preference. |
Domain Name Server |
6 |
4 octets minimum; multiples of 4 |
List of Domain Name System (STD 13, RFC 1035) name servers available to the client. Servers should be in order of preference. |
Log Server |
7 |
4 octets minimum; multiples of 4 |
List of MIT-LCS UDP log servers available to the client. Servers should be in order of preference. |
Cookie Server |
8 |
4 octets minimum; multiples of 4 |
List of RFC 865-compliant cookie servers available to the client. Servers should be in order of preference. |
LPR Server |
9 |
4 octets minimum; multiples of 4 |
List of RFC 1179-compliant line printer servers available to the client. Servers should be in order of preference. |
Impress Server |
10 |
4 octets minimum; multiples of 4 |
List of Imagen Impress servers available to the client. Servers should be in order of preference. |
Resource Location Server |
11 |
4 octets minimum; multiples of 4 |
List of RFC 887-compliant resource location servers available to the client. Servers should be in order of preference. |
Host Name |
12 |
1 octet minimum |
Name of the client. The name may or may not be qualified with the local domain name. See RFC 1035 for the character set restrictions. |
Boot File Size |
13 |
2 octets |
Number of 512-octet blocks in the default boot file. |
Merit Dump File |
14 |
1 octet minimum |
Path name of a file to which the client core image should be placed in the event the client crashes. The path is formatted as a character string consisting of characters from the NVT ASCII character set. |
Domain Name |
15 |
1 octet minimum |
Domain name that the client should use when resolving hostnames through the Domain Name System. |
Swap Server |
16 |
4 octets |
IP address of the client swap server. |
Root Path |
17 |
1 octet minimum |
Path name that contains the client root disk. The path is formatted as a character string consisting of characters from the NVT ASCII character set. |
Extensions Path |
18 |
1 octet minimum |
Uses a string to specify a file, retrievable through TFTP. The file contains information that can be interpreted in the same way as the 64-octet vendor-extension field within the BOOTP response, with these exceptions: the length of the file is unconstrained, and all references to instances of this option in the file are ignored. |
IP Layer Parameters Per Host
The table below lists the options that affect the operation of the IP layer on a per-host basis.
Option Name |
No. |
Length |
Description |
---|---|---|---|
IP Forwarding Enable/Disable |
19 |
1 octet |
Specifies whether the client should configure its IP layer for packet forwarding. Values: 0=disable; 1=enable |
Non-Local Source Routing Enable/Disable |
20 |
1 octet |
Specifies whether the client should configure its IP layer to allow forwarding of datagrams with non-local source routes. Values: 0=disable; 1=enable |
Policy Filter |
21 |
8 octets minimum; multiples of 8 |
Policy filters for non-local source routing. The filters consist of a list of IP addresses and masks that specify destination/mask pairs with which to filter incoming source routes. Any source-routed datagram whose next-hop address does not match one of the filters should be discarded by the client. |
Maximum Datagram Reassembly Size |
22 |
2 octets |
Maximum size datagram that the client should be prepared to reassemble. Value: 576 minimum |
Default IP Time-to-live |
23 |
1 octet |
Default TTL that the client should use on outgoing datagrams. Values: 1 to 255 |
Path MTU Aging Timeout |
24 |
4 octets |
Timeout (in seconds) to use when aging Path MTU values (defined in RFC 1191). |
Path MTU Plateau Table |
25 |
2 octets minimum; multiples of 2 |
Table of MTU sizes to use when performing Path MTU Discovery as defined in RFC 1191. The table is formatted as a list of 16-bit unsigned integers, ordered from smallest to largest. Value: 68 minimum |
IP Layer Parameters Per Interface
The table below lists the options that affect the operation of the IP layer on a per-interface basis. A client can issue multiple requests, one per interface, to configure interfaces with their specific parameters.
Option Name |
No. |
Length |
Description |
---|---|---|---|
Interface MTU |
26 |
2 octets |
MTU to use on this interface.The minimum legal value for the MTU is 68. |
All Subnets are Local |
27 |
1 octet |
Specifies whether or not the client can assume that all subnets of the IP network to which the client is connected use the same MTU as the subnet of that network to which the client is directly connected. Values: 1=all subnets share same MTU; 0=some directly-connected subnets can have smaller MTUs |
Broadcast Address |
28 |
4 octets |
Broadcast address in use on the client subnet. |
Perform Mask Discovery |
29 |
1 octet |
Specifies whether or not the client should perform subnet mask discovery using ICMP. Values: 0=disable; 1=enable |
Mask Supplier |
30 |
1 octet |
Specifies whether or not the client should respond to subnet mask requests using ICMP. Values: 0=do not respond; 1=respond |
Perform Router Discovery |
31 |
1 octet |
Specifies whether or not the client should solicit routers using the Router Discovery mechanism defined in RFC 1256. Values: 0=disable; 1=enable |
Router Solicitation Address |
32 |
4 octets |
Address to which the client should transmit router solicitation requests. |
Static Route |
33 |
8 octets minimum; multiples of 8 |
List of static routes that the client should install in its routing cache. If multiple routes to the same destination are specified, they are in descending order of priority. The routes consist of a list of IP address pairs. The first address is the destination address, and the second address is the router for the destination. The default route (0.0.0.0) is an illegal destination for a static route. |
Link Layer Parameters Per Interface
The table below lists the options that affect the operation of the data link layer on a per-interface basis.
Option Name |
No. |
Length |
Description |
---|---|---|---|
Trailer Encapsulation |
34 |
1 octet |
Specifies whether or not the client should negotiate the use of trailers (RFC 893) when using the ARP protocol. Values: 0=do not use; 1=use |
ARP Cache Timeout |
35 |
4 octets |
Timeout in seconds for ARP cache entries. |
Ethernet Encapsulation |
36 |
1 octet |
Specifies whether or not the client should use Ethernet Version 2 (RFC 894) or IEEE 802.3 (RFC 1042) encapsulation if the interface is an Ethernet. Value: 0=use RFC 894 encapsulation; 1=use RFC 1042 encapsulation |
TCP Parameters
The table below lists the options that affect the operation of the TCP layer on a per-interface basis.
Option Name |
No. |
Length |
Description |
---|---|---|---|
TCP Default TTL |
37 |
1 octet |
Default TTL that the client should use when sending TCP segments. Value: minimum 1 |
TCP Keepalive Interval |
38 |
4 octets |
Interval (in seconds) that the client TCP should wait before sending a keepalive message on a TCP connection. The time is specified as a 32-bit unsigned integer. A value of zero indicates that the client should not generate keepalive messages on connections unless specifically requested by an application. Value: 32-bit unsigned; 0=do not generate keepalive messages unless specifically requested. |
TCP Keepalive Garbage |
39 |
1 octet |
Specifies the whether or not the client should send TCP keep-alive messages with an octet of garbage for compatibility with older implementations. Values: 0=do not send; 1=send |
Application and Service Parameters
The table below lists some miscellaneous options used to configure miscellaneous applications and services.
Option Name |
No. |
Length |
Description |
---|---|---|---|
Network Information Service (NIS) Domain |
40 |
1 octet minimum |
Name of the client NIS domain. The domain is formatted as a character string consisting of characters from the NVT ASCII character set. |
Network Information Service (NIS) Servers |
41 |
4 octets minimum; multiples of 4 |
List of IP addresses indicating NIS servers available to the client. Servers should be in order of preference. |
Network Time Protocol Servers |
42 |
4 octets minimum; multiples of 4 |
List of IP addresses indicating NTP servers that are available to the client. Servers should be in order of preference. |
Vendor-Specific Information |
43 |
1 octet minimum |
This option is used by clients and servers to exchange vendor-specific information. The information is an opaque object of n octets, presumably interpreted by vendor-specific code on the clients and servers. The definition of this information is vendor specific. The vendor is indicated in the dhcp-class-identifier option. Servers not equipped to interpret the vendor-specific information sent by a client must ignore it (although it can be reported). Clients that do not receive desired vendor-specific information should make an attempt to operate without it, although they can do so (and announce they are doing so) in a degraded mode. If a vendor potentially encodes more than one item of information in this option, then the vendor should encode the option using encapsulated vendor-specific options as described here. The encapsulated vendor-specific options field should be encoded as a sequence of code, length, and value fields of identical syntax to the DHCP options field with these exceptions:
Code 255 (END), if present, signifies the end of the encapsulated vendor extensions, not the end of the vendor extensions field. If the code 255 is not present, then the end of the enclosing vendor-specific information field is taken as the end of the encapsulated vendor-specific extensions field. |
NetBIOS over TCP/IP Name Server |
44 |
4 octets minimum; multiples of 4 |
List of RFC 1001/1002 NBNS name servers in order of preference. |
NetBIOS over TCP/IP Datagram Distribution Server |
45 |
4 octets minimum; multiples of 4 |
List of RFC 1001/1002 NBDD servers in order of preference. |
NetBIOS over TCP/IP Node Type |
46 |
1 octet |
Allows NetBIOS over TCP/IP client, which are configured as described in RFC 1001/1002. Values: Single hexadecimal octet that identifies the client type:
|
NetBIOS over TCP/IP Scope |
47 |
1 octet minimum |
NetBIOS over TCP/IP scope parameter for the client as specified in RFC 1001/1002. |
X Window System Font Server |
48 |
4 octets minimum; multiples of 4 |
List of X Window System Font servers available to the client. Servers should be in order of preference. |
X Window System Display Manager |
49 |
4 octets minimum; multiples of 4 |
List of IP addresses of systems that are running the X Window System Display Manager and are available to the client. Addresses should be in order of preference. |
Network Information Service (NIS+) Domain |
64 |
1 octet minimum |
Name of the client NIS+ domain. The domain is formatted as a character string consisting of characters from the NVT ASCII character set. |
Network Information Service (NIS+) Servers |
65 |
4 octets minimum; multiples of 4 |
List of IP addresses indicating NIS+ servers available to the client. Servers should be in order of preference. |
Mobile IP Home Agent |
68 |
0 octet minimum; multiples of 4; expected, 4 octets containing a single home agent address |
List of IP addresses indicating mobile IP home agents available to the client. Agents should be in order of preference. Value: 32-bit address; 0=no home agents available |
Simple Mail Transport Protocol (SMTP) Server |
69 |
4 octets minimum; multiples of 4 |
List of SMTP servers available to the client. Servers should be in order of preference. |
Post Office Protocol (POP3) Server |
70 |
4 octets minimum; multiples of 4 |
List of POP3 servers available to the client. Servers should be in order of preference. |
Network News Transport Protocol (NNTP) Server |
71 |
4 octets minimum; multiples of 4 |
List of NNTP servers available to the client. Servers should be in order of preference. |
Default World Wide Web (WWW) Server |
72 |
4 octets minimum; multiples of 4 |
List of World Wide Web (WWW) servers available to the client. Servers should be in order of preference. |
Default Finger Server |
73 |
4 octets minimum; multiples of 4 |
List of Finger servers available to the client. Servers should be in order of preference. |
Default Internet Relay Chat (IRC) Server |
74 |
4 octets minimum; multiples of 4 |
List of IRC servers available to the client. Servers should be in order of preference. |
StreetTalk Server |
75 |
4 octets minimum; multiples of 4 |
List of StreetTalk servers available to the client. Servers should be in order of preference. |
StreetTalk Directory Assistance (STDA) Server |
76 |
4 octets minimum; multiples of 4 |
List of STDA servers available to the client. Servers should be in order of preference. |
DHCPv4 Extension Options
The table below lists the DHCPv4 extension options.
Option Name |
No. |
Length |
Description |
---|---|---|---|
Requested IP Address |
50 |
4 octets |
Used in a client request (DHCPDISCOVER) to allow the client to request that a particular IP address be assigned. |
IP Address Lease Time |
51 |
4 octets |
Used in a client request (DHCPDISCOVER or DHCPREQUEST) to allow the client to request a lease time for the IP address. In a server reply (DHCPOFFER), a DHCP server uses this option to specify the lease time it is willing to offer. Value: seconds, as 32-bit unsigned integer |
Option Overload |
52 |
1 octet |
Indicates that the DHCP sname or file fields are being overloaded by using them to carry DHCP options. A DHCP server inserts this option if the returned parameters will exceed the usual space allotted for options. If this option is present, the client interprets the specified additional fields after it concludes interpretation of the standard option fields. Values: 1=file field is used to hold options; 2=sname field is used to hold options; 3=both fields are used to hold options |
DHCP Message Type |
53 |
1 octet |
Used to convey the type of DHCP message. The preset value is 1 (DHCPDISCOVER). Values: 1=DHCPDISCOVER; 2=DHCPOFFER; 3=DHCPREQUEST; 4=DHCPDECLINE; 5=DHCPACK; 6=DHCPNAK; 7=DHCPRELEASE; 8=DHCPINFORM; 13=LEASEQUERY |
Server Identifier |
54 |
4 octets |
Used in DHCPOFFER and DHCPREQUEST messages, and can optionally be included in the DHCPACK and DHCPNAK messages. DHCP servers include this option in the DHCPOFFER in order to allow the client to distinguish between lease offers. DHCP clients use the contents of the server identifier field as the destination address for any DHCP messages unicast to the DHCP server. DHCP clients also indicate which of several lease offers is being accepted by including this option in a DHCPREQUEST message. The identifier is the IP address of the selected server. |
Parameter Request List |
55 |
1 octet minimum |
Used by a DHCP client to request values for specified configuration parameters. The list of requested parameters is specified as n octets, where each octet is a valid DHCP option code as defined in this document. The client can list the options in order of preference. The DHCP server does not have to return the options in the requested order, but must try to insert the options in the order that the client requested. |
Message |
56 |
1 octet minimum |
Used by a DHCP server to provide an error message to a DHCP client in a DHCPNAK message in the event of a failure. A client can use this option in a DHCPDECLINE message to indicate why the client declined the offered parameters. The message consists of n octets of NVT ASCII text, which the client can display on an available output device. |
Maximum DHCP Message Size |
57 |
2 octets |
Maximum-length DHCP message that a server is willing to accept. The length is specified as an unsigned 16-bit integer. A client can use the maximum DHCP message size option in DHCPDISCOVER or DHCPREQUEST messages, but should not use the option in DHCPDECLINE messages. Value: 576 minimum |
Renewal (T1) Time Value |
58 |
4 octets |
Time interval from address assignment until the client transitions to RENEWING state. Value: seconds, as 32-bit unsigned integer |
Rebinding (T2) Time Value |
59 |
4 octets |
Time interval from address assignment until the client transitions to REBINDING state. Value: seconds, as 32-bit unsigned integer |
Vendor Class Identifier |
60 |
1 octet minimum |
Used by DHCP clients to optionally identify the vendor type and configuration of a DHCP client. The information is a string of n octets, interpreted by servers. Vendors can choose to define specific vendor class identifiers to convey particular configuration or other identification information about a client. For example, the identifier can encode the client hardware configuration. Servers not equipped to interpret the class-specific information sent by a client must ignore it (although it can be reported). Servers that respond should only use option 43 to return the vendor-specific information to the client. |
Client-Identifier |
61 |
2 octets minimum |
Used by DHCP clients to specify their unique identifier. DHCP servers use this value to index their database of address bindings. This value is expected to be unique for all clients in an administrative domain. DHCP servers should treat identifiers as opaque objects. The client identifier can consist of type-value pairs similar to the htype /chaddr fields. For instance, it can consist of a hardware type and hardware address. In this case, the type field should be one of the ARP hardware types defined in STD2. A hardware type of 0 (zero) should be used when the value field contains an identifier other than a hardware address (for example, a fully qualified domain name). For correct identification of clients, each client-identifier must be unique among the client-identifiers used on the subnet to which the client is attached. Vendors and system administrators are responsible for choosing client-identifiers that meet this requirement for uniqueness. |
TFTP Server name |
66 |
1 octet minimum |
Identifies a TFTP server when the sname field in the DHCP header has been used for DHCP options. |
Bootfile name |
67 |
1 octet minimum |
Identifies a bootfile when the file field is the DHCP header that has been used for DHCP options. |
Relay Agent Information |
82 |
Identifies the DHCP relay agent information (see RFC 3046) |
|
iSNS |
83 |
14 bytes minimum |
Identifies the Internet Storage Name Service (see RFC 4174) |
BCMCS Controller Domain |
88 |
Variable |
List of Broadcast and Multicast Service (BCMCS) controller domains (see RFC 4280) |
BCMCS Address |
89 |
4 octets minimum |
List of IP addresses for the BCMCS controller (see RFC 4280) |
Lease Query Client Last Transaction Time |
91 |
4 octets |
Time of the most recent access of the client sending a DHCPLEASEQUERY (see RFC 4388). |
Lease Query Associated IP Addresses |
92 |
4 octets minimum |
All IP addresses associated with the client specified in a particular DHCPLEASEQUERY message (see RFC 4388). |
Microsoft Client Options
The table below lists the standard Microsoft client options.
Option Name |
No. |
Description |
---|---|---|
dhcp-lease-time |
51 |
14 days |
domain-name |
15 |
A domain name such as cisco.com |
domain-name-servers |
6 |
IP address of the name servers |
netbios-name-servers |
44 |
WINS server address |
netbios-node-type |
46 |
Identifies the NetBIOS client type; note that Cisco Prime Network Registrar displays a warning if it is not present |
routers |
3 |
IP address of the router for this subnet |
DHCPv6 Options
The table below lists the DHCPv6 options, along with their defined data types. All the option packets include at least an option length (option-len) and a variable length data field. There can also be additional parameter settings, as described in the table. Many of these options are described in RFC 3315.
Cisco Prime Network Registrar Name (Type) |
No. |
Description |
---|---|---|
client-identifier |
1 |
DUID identifying a client between a client and a server. See RFC 3315. |
server-identifier |
2 |
DUID identifying a server between a client and a server. See RFC 3315. |
ia-na |
3 |
Nontemporary Addresses option with the associated parameters and addresses. Parameters are the unique ID, time the client contacts the addresses in the IA to extend the lifetime, and time the client contacts any available server to extend the lifetime of the addresses. See RFC 3315. |
ia-ta |
4 |
Temporary Addresses option with the associated parameters and addresses. See RFC 3315. |
iaaddr |
5 |
IPv6 addresses associated with an IA_NA or IA_TA. (The IAADRR must be encapsulated in the options field of an IA_NA or IA_TA option.) The IAADDR option includes preferred and valid lifetime fields, and the options field that encapsulates the options specific to this address. See RFC 3315. |
oro |
6 |
Option Request option (ORO) that identifies a list of options in a message between a client and a server. A client can include this option in a Solicit, Request, Renew, Rebind, Confirm, or Information-request message to inform the server about options the client wants from the server. A server can include this option in a Reconfigure message to indicate which option updates the client should request. See RFC 3315. |
preference |
7 |
A server sends this option to a client to affect what server the client selects. See RFC 3315. |
elapsed-time |
8 |
A client sends this option to a server to indicate how long the client has been trying to complete a message exchange. See RFC 3315. |
relay-message |
9 |
DHCP message in a Relay-forward or Relay-reply message. See RFC 3315. |
auth |
11 |
Authenticates the identity and contents of a DHCP message. The parameters are the authentication protocol, the authentication algorithm, the replay detection method (RDM), and the authentication information. See RFC 3315. |
server-unicast |
12 |
The server sends this option to a client to indicate that the client can unicast messages to the server. See RFC 3315. |
status-code |
13 |
Returns a status indication related to the DHCP message or option in which it appears. The parameters are the status code and status message. See RFC 3315. |
rapid-commit |
14 |
Signals use of the two-message exchange for address assignment. See RFC 3315. |
user-class |
15 |
Clients use this option to identify the type or category of user or applications it represents. A zero type count value field followed by user data (as a blob). See RFC 3315. |
vendor-class |
16 |
Clients use this option to identify the vendor that manufactured the hardware on which they are running. See RFC 3315. |
vendor-opts |
17 |
Clients and servers use this option to exchange vendor-specific information. The enterprise ID for the CableLabs vendor is 4491; the suboptions for CableLabs are listed in Table 4. See RFC 3315. |
interface-id |
18 |
Relay agents use this option to identify the interface on which the client message is received. See RFC 3315. |
reconfigure-message |
19 |
The server includes this in a Reconfigure message to indicate whether the client should respond with a Renew or Information-request message. See RFC 3315. |
reconfigure-accept |
20 |
Clients use this option to announce to the server whether the client is willing to accept Reconfigure messages. See RFC 3315. |
sip-servers-name |
21 |
Domain names of the SIP outbound proxy servers for the client. See RFC 3319. |
sip-servers-address |
22 |
IPv6 addresses of the SIP outbound proxy servers for the client. See RFC 3319. |
dns-servers |
23 |
IPv6 addresses of DNS recursive name servers. See RFC 3646. |
domain-list |
24 |
Domain names in the domain search list. See RFC 3646. |
ia-pd |
25 |
IPv6 prefix delegation identity association and its associated parameters and prefixes. Parameters are the unique ID, time the client contacts the addresses in the IA to extend the lifetime, and time the client contacts any available server to extend the lifetime of the addresses. See RFC 3633. |
iaprefix |
26 |
IPv6 prefixes associated with an IA_PD. The prefix must be encapsulated in the options field of an IA_PD option. Parameters are the valid and preferred lifetimes, prefix length, and the prefix. See RFC 3633. |
nis-servers |
27 |
List of IPv6 addresses of Network Information Service (NIS) servers available to the client. See RFC 3898. |
nisp-servers |
28 |
List of IPv6 addresses of NIS+ servers available to the client. See RFC 3898. |
nis-domain-name |
29 |
Conveys the NIS domain name to the client. See RFC 3898. |
nisp-domain-name |
30 |
Conveys the NIS+ domain name to the client. See RFC 3898. |
sntp-servers |
31 |
List of Simple Network Time Protocol (SNTP) servers available to the client. See RFC 4075. |
info-refresh-time |
32 |
Sets an upper bound for how long a client should wait before refreshing DHCPv6 information. See RFC 4242. |
bcmcs-server-d |
33 |
List of BCMCS controller domains. See RFC 4280. |
bcmcs-server-a |
34 |
List of IPv6 addresses for the Broadcast and Multicast Service (BCMCS) controller. See RFC 4280. |
geoconf-civic |
36 |
DHCP civic addresses configuration. See RFC 4776. |
remote-id |
37 |
Relay agents that terminate switched or permanent circuits can add this option to identify remote hosts. See RFC 4649. |
relay-agent-subscriber-id |
38 |
Allows assignment and activation of subscriber-specific actions. See RFC 4580. |
client-fqdn |
39 |
DHCP client FQDN. See RFC 4704. |
pana-agent |
40 |
Carries a list of 32-bit (binary) IPv4 addresses indicating PANA Authentication Agents (PAAs) available to the PANA client (PaC). See RFC 5192. |
new-posix-timezone |
41 |
POSIX time zone, for example, EST5EDT4, M3.2.0/02:00,M11.1.0/02:00. See RFC 4833. |
new-tzdb-timezone |
42 |
POSIX time zone database name, for example, Europe/Zurich. See RFC 4833. |
ero |
43 |
Relay agent Echo Request option to inform the server of the list of relay agent options to echo back. See RFC 4994. |
lq-query |
44 |
Used only in a LEASEQUERY message; identifies the query being performed. The option includes the query type, link-address (or 0::0), and options to provide data needed for the query. See RFC 5007. |
client-data |
45 |
Encapsulates the data for a single client on a single link in a LEASEQUERY-REPLY message. See RFC 5007. |
clt-time |
46 |
Client last transaction time encapsulated in the client-data option; identifies how long ago the server last communicated with the client (in seconds). See RFC 5007. |
lq-relay-data |
47 |
Used only in a LEASEQUERY-REPLY message; provides the relay agent data used when the client last communicated with the server. See RFC 5007. |
lq-client-links |
48 |
Used only in a LEASEQUERY-REPLY message; identifies the links on which the client has one or more bindings. It is used in reply to a query when no link-address was specified and the client is found to be on more than one link. See RFC 5007. |
mip6-hnidf |
49 |
Defines the Home Network ID FQDN option. See RFC 6610. |
mip6-vdinf |
50 |
Defines the Visited Home Network Information option. See RFC 6610. |
lost-server |
51 |
A DHCPv6 client will request a LoST server domain name in an Options Request Option (ORO) (see RFC 3315). This option contains a single domain name and must contain precisely one root label. See RFC 5223. |
capwap-ac-v6 |
52 |
Carries a list of 128-bit (binary) IPv6 addresses indicating one or more Control and Provisioning of Wireless Access Point (CAPWAP) Access Controllers (ACs) available to the Wireless Termination Point (WTP). Ssee RFC 5417. |
relay-id |
53 |
A DHCPv6 server MAY associate Relay-ID options from Relay-Forward messages it processes with prefix delegations and/or lease bindings that result. See RFC 5460. |
mos-address |
54 |
Mobility Sever (MoS) IPv6 Address for DHCP v4. See RFC 5678. |
mos-fqdn |
55 |
Mobility Sever (MoS) Domain Name List for DHCPv6. See RFC 5678. |
ntp-server |
56 |
Serves as a container for server location information related to one Network Time Protocol (NTP) server or Simple Network Time Protocol (SNTP) server. This option can appear multiple times in a DHCPv6 message. Each instance of this option is to be considered by the NTP client or SNTP client as a server to include in its configuration. The option itself does not contain any value. Instead, it contains one or several suboptions that carry NTP server or SNTP server location. See RFC 5908. |
access-domain |
57 |
Defines the domain name associated with the access network. This option contains a single domain name and, as such, must contain precisely one root label. See RFC 5986. |
sip-ua-cs-domains |
58 |
Defines the list of domain names in the Session Initiation Protocol (SIP) User Agent Configuration Service Domains. See RFC 6011. |
bootfile-url |
59 |
Informs the client about a URL to a boot file. See RFC 5970. |
bootfile-param |
60 |
Sent by the server to the client. It consists of multiple UTF-8 (see RFC 3629) strings for specifying parameters for the boot file. See RFC 5970. |
client-arch-type |
61 |
Provides parity with the Client System Architecture Type option (option 93) defined for DHCPv4. See RFC 5970. |
nii |
62 |
Provides parity with the Client Network Interface Identifier option (option 94) defined for DHCPv4. See RFC 5970. |
geoloc |
63 |
Specifies the coordinate-based geographic location of the client, to be provided by the server. See RFC 6225. |
aftr-name |
64 |
Defines a fully qualified domain name of the AFTR tunnel endpoint. See RFC 6334. |
erp-local-domain-name |
65 |
Contains the name of the local ERP domain. See RFC 6440. |
rsoo |
66 |
Encapsulates whatever options the relay agent wishes to provide to the DHCPv6 server. See RFC 6422. |
pd-exclude |
67 |
Used to exclude exactly one prefix from a delegated prefix. See RFC 6603. |
vpn-id |
68 |
Used to identify a VPN. See RFC 6607. |
mip6-idinf |
69 |
Used by relay agents and DHCP servers to provide information about the home network identified. See RFC 6610. |
mip6-udinf |
70 |
Provides information about a home network specified by the DHCP server administrator. See RFC 6610. |
mip6-hnp |
71 |
Defines the prefix for a home network. See RFC 6610. |
mip6-haa |
72 |
Used by DHCP servers and relay agents to specify the home agent IP address. See RFC 6610. |
mip6-haf |
73 |
Specifies the Home Agent FQDN to look up one or more A or AAAA records containing IPv4 or IPv6 addresses for the home agent, as needed. See RFC 6610. |
rdnss-selection |
74 |
Informs resolvers which RDNSS can be contacted when initiating forward or reverse DNS lookup procedures. See RFC 6731. |
krb-principal-name |
75 |
Sent by the client to the DHCPv6 server, which uses it to select a specific set of configuration parameters, either for a client or for a Kerberos application server. See RFC 6784. |
krb-realm-name |
76 |
Specifies to a DHCPv6 server which realm the client wants to access. See RFC 6784. |
krb-default-realm-name |
77 |
Specifies a default realm name for the Kerberos system (clients and Kerberos application servers). See RFC 6784. |
krb-kdc |
78 |
Provides configuration information about a KDC. See RFC 6784. |
client-linklayer-address |
79 |
Indicates the client link layer address. See RFC 6939. |
link-address |
80 |
Indicates to the server the link on which the client is located. See RFC 6977. |
radius |
81 |
Provides a mechanism to exchange authorization and identification information between the DHCPv6 relay agent and DHCPv6 server. See RFC 7037. |
sol-max-rt |
82 |
Overrides the default value of sol-max-rt. See RFC 7083. |
inf-max-rt |
83 |
Overrides the default value of inf-max-rt. See RFC 7083. |
addrsel |
84 |
Provides the policy table and some other configuration parameters. See RFC 7078. |
addrsel-table |
85 |
Provides the Address Selection Policy Table options. See RFC 7078. |
v6-pcp-server |
86 |
Configures a list of IPv6 addresses of a PCP server. This option supports only single instance. See RFC 7291. |
dhcpv4-msg |
87 |
Carries a DHCPv4 message that is sent by the client or the server. Such messages exclude any IP or UDP headers. See RFC 7341. |
dhcp4-o-dhcp6-server |
88 |
Carries a list of DHCP 4o6 servers' IPv6 addresses that the client should contact to obtain IPv4 configuration. See RFC 7341. |
s46-rule |
89 |
Conveys the Basic Mapping Rule (BMR) and Forwarding Mapping Rule (FMR). See RFC 7598. |
s46-br |
90 |
Conveys the the IPv6 address of the Border Relay. See RFC 7598. |
s46-dmr |
91 |
Conveys values for the Default Mapping Rule (DMR). See RFC 7598. |
s46-v4v6bind |
92 |
Specifies the full or shared IPv4 address of the CE. The IPv6 prefix field is used by the CE to identify the correct prefix to use for the tunnel source. See RFC 7598. |
s46-portparams |
93 |
Specifies optional port set information that MAY be provided to CEs. See RFC 7598. |
s46-cont-mape |
94 |
Specifies the container used to group all rules and optional port parameters for a specified domain (Softwire46 MAP-E domain). See RFC 7598. |
s46-cont-mapt |
95 |
Specifies the container used to group all rules and optional port parameters for a specified domain (Softwire46 MAP-T domain). See RFC 7598. |
s46-cont-lw |
96 |
Specifies the container used to group all rules and optional port parameters for a specified domain (Softwire46 Lightweight 4over6 domain). See RFC 7598. |
4rd |
97 |
Indicates the DHCPv6 option for 4rd (IPv4 Residual Deployment). See RFC 7600. |
4rd-map-rule |
98 |
Indicates the Mapping-Rule Parameters of 4rd domains. See RFC 7600. |
4rd-non-map-rule |
99 |
Indicates the Non-Mapping-Rule Parameters of 4rd domains. See RFC 7600. |
lq-base-time |
100 |
Current time the message was created to be sent by the DHCPv6 server to the requestor of the Active or Bulk Leasequery if the requestor asked for the same in an Active or Bulk Leasequery request. See RFC 7653. |
lq-start-time |
101 |
Specifies a query start time to the DHCPv6 server. See RFC 7653. |
lq-end-time |
102 |
Specifies a query end time to the DHCPv6 server. See RFC 7653. |
captive-portal |
103 |
Informs the client that it is behind a captive portal and provides the URI to access an authentication page. See RFC 7710. |
mpl-parameters |
104 |
Provides a means to distribute a configuration of an MPL Domain or a default value for all MPL Domains (a wildcard) within the network managed by the DHCP server. See RFC 7774. |
ani-att |
105 |
Used for exchanging the type of access technology the client uses to attach to the network. See RFC 7839. |
ani-network-name |
106 |
Name of the access network to which the mobile node is attached. See RFC 7839. |
ani-ap-name |
107 |
Name of the access point (physical device name) to which the mobile node is attached. See RFC 7839. |
ani-ap-bssid |
108 |
48-bit Basic SSSID (BSSID) of the access point to which the mobile node is attached. See RFC 7839. |
ani-operator-id |
109 |
Variable-length Private Enterprise Number (PEN) encoded in a network byte order. See RFC 7839. |
ani-operator-realm |
110 |
Realm of the operator. See RFC 7839. |
s46-priority |
111 |
Conveys a priority order of IPv4 service continuity mechanisms. See RFC 8026. |
prefix64 |
113 |
Conveys the IPv6 prefix(es) to be used (for example, by an mB4) to synthesize IPv4-embedded IPv6 addresses. See RFC 8115. |
relay-port |
135 |
Relay Source Port Option for DHCPv6. This requires specialized server processing and is not a "configurable" option - the option is added by a relay agent and must be echoed by the server in the Relay-Reply, and requires specialized processing in the server to return the response to the relay via the relayed packet's source port. See RFC 8357. |
ipv6-address-andsf |
143 |
Allows the mobile node (MN) to locate an ANDSF server. See RFC 6153. |