In a previous Infoblox IPv6 Center of Excellence (COE) article, the commonalities and differences between DHCP (RFC 2131) and DHCPv6 (RFC 8415) were covered. It was briefly mentioned that the options were different between these two dynamic addressing protocols, specifically that DHCP has an 8-bit (one octet) option code while DHCPv6 has a 16-bit option space. The DHCP and DHCPv6 option numbers and types have different names, and these two protocols have different options for different purposes.
It is frequently recommended that organizations have similar operational practices for IPv4 and IPv6. For example, if you are setting specific DHCP options for your IPv4 networks, then you’ll want to set the equivalent DHCPv6 options for your IPv6 networks. Therefore, it is important to know how the DHCP and DHCPv6 are aligned or different.
DHCPv6 Options in Infoblox NIOS
Infoblox Network Identity Operating System (NIOS) can function as both a DHCP server and a DHCPv6 server simultaneously. NIOS has built-in default DHCP and DHCPv6 options and you can configure custom options and apply those to network ranges. If you have access to an Infoblox Grid Manager, you can log into the web interface and view the standard IPv4 DHCP options and the standard IPv6 DHCPv6 options already there by default. To do this: Select: Grid > Grid Manager > Services > Click the Edit/Pencil next to the “DHCP” service.
In the Infoblox (Grid DHCP Properties) you can select “IPv4 DHCP Options” or “IPv6 DHCP Options” on the left menu.
On this screen, there are a few basic properties for the DHCPv6 service and default options. At the top of the list is the Valid Lifetime (default is 12 hours) and the Preferred Lifetime (default is 450 minutes, or 7.5 hours). These lifetimes were discussed in the blog “Understanding DHCPv6 Lease Times”. From the Infoblox DHCPv6 Properties documentation:
- “Valid Lifetime: Specify the length of time addresses that are assigned to DHCP clients remain in the valid state. When this time expires, an address becomes invalid and can be assigned to another interface.”
- “Preferred Lifetime: Specify the length of time that a valid address is preferred. A preferred address can be used with no restrictions. When this time expires, the address becomes deprecated.”
The next item is “Domain Name,” which is the DHCPv6 Option 24 (OPTION_DOMAIN_LIST). This is the default domain name that the Infoblox Grid serves to clients in the DHCPv6 data for the client’s FQDN. This is, equivalent to DHCP option 15.
The next item is “DNS Servers,” which is the list of IPv6 addresses of the recursive DNS servers the DHCPv6 client should use. This is DHCPv6 Option 23 (OPTION_DNS_SERVERS). This is, equivalent to DHCP option 6.
DHCPv6 options 23 and 24 are specified in “DNS Configuration options for DHCPv6” (RFC 3646).
You can then select “Custom IPv6 DHCP Options” and click on “Choose option” and you’ll see a small list of some of the standard options that are available. You can also create other options globally and then apply those to IPv6 prefix address ranges for various networks in your environment. It is also easy to configure these DHCPv6 options on Infoblox or create your own custom options as defined in “Guidelines for Creating New DHCPv6 Options” (RFC 7227). Here is a zoomed-in picture of these built-in options.
Default Gateway Option
It is customary to configure the router’s IPv4 address in a DHCP scope, so the clients learn the address of their default gateway. An IPv4 subnet’s router is set with DHCP option 3. However, for IPv6 networks, this is done differently.
On an IPv6 network, the first-hop router sends an ICMPv6 Type 134 Router Advertisement (RA) to the all-nodes link-local multicast address, ff02::1. This RA message contains information about the local router, the IPv6 prefix used on this network, and other valuable pieces of information for the end-nodes to utilize. When the router is configured for DHCPv6, the RA has the Managed-Config Flag set to “1,” which indicates to the host that this access network segment supports stateful address assignment using DHCPv6. The first-hop router then performs the function of a DHCPv6 relay and forwards the client’s DHCPv6 messages to the Infoblox DHCPv6 server. Because the router’s information is provided to end nodes in the RA, then there is no need for a DHCPv6 option to convey the default router for the segment. The DHCPv6 client will then use the router’s IPv6 address and link-layer MAC address as its default gateway.
There was a proposed IETF draft to make DHCPv6 function equivalent to DHCP by adding a DHCPv6 route option. However, while this draft expired, there are mentions of DHCPv6 option 242 and 243 to convey route information to IPv6 end nodes.
There are also methods on IPv4 networks to provide additional routing information to the DHCP clients. DHCP option 33 can share Static Route information with the client and DHCP option 121 sets a classless static route on the host (Classless Route Option Format). If both DHCP options are present, then DHCP 121 takes precedence over DHCP option 33. DHCP option 121 has been in the news recently as an attack on VPNs. This attack has been called the “TunnelVision” attack (CVE-2024-3661).
On IPv6 networks, the Router Advertisement (RA) can contain route information using RA option 24 (RFC 4191). Sometimes RA option 24 can contain the unspecified address ::/0 or the entire global unicast address space 2000::/3.
Fully-Qualified Domain Name Option
FQDN support comes into play with Dynamic DNS (DDNS), whereby the DHCP server updates DNS to reflect the FQDN for the DHCP client (depending on whether the client requests it or not). The DHCP server combines the hostname from the client with the domain name to create the client’s FQDN. On IPv4 networks, the client sends DHCP Option 81 (Client FQDN Option) in the DHCPDISCOVER and DHCPREQUEST messages.
For IPv6 networks, this same functionality is defined in “The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option” (RFC 4704). The equivalent DHCPv6 option is 39 (OPTION_CLIENT_FQDN) and it’s sent by the client in the SOLICIT and REQUEST messages. In the Infoblox NIOS DHCPv6 Options list shown above, there is a built-in option 39 (dhcp6.fqdn) which is a string data type.
Vendor-Specific Options
DHCP also provides a method for vendors to create their own options and provide information to clients that indicate that they want to receive vendor-specific information. Vendors can even create their own nested options using this technique to share even more data with the client devices. It is possible to define data that is longer than 255 bytes using “Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)” (RFC 3396).
On an IPv4 network, the DHCP client reports option 60 in the DHCPDISCOVER and DHCPREQUEST messages with the Vendor Class Identifier (VCI). The DHCP server replies with DHCP option 43 with any Vendor-Specific Information (VSI). The server also responds with DHCP option 43 and 60 for the matching Vendor Class Identifier (VCI) and these options are used to note the vendor-specific information.
IPv4 networks also have another method for conveying vendor-specific information which is defined in “Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)” (RFC 3925). IPv4 DHCP networks can use DHCP option 124 (Vendor-Identifying Vendor Class) and DHCP option 125 (Vendor-Identifying Vendor-Specific Information). For example, Cisco devices can leverage these DHCP options for Software-Defined WAN (SD-WAN), Zero-Touch Provisioning (ZTP), Cisco Plug-and-Play (PnP), and Identity Services Engine (ISE) configuration information to remote network devices.
On an Infoblox system you can configure “option spaces” that contain a collection of DHCP options for use with DHCP option 43 or 125.
In an IPv6 network, the client will report DHCPv6 option 16 (OPTION_VENDOR_CLASS) with the vendor class and the DHCPv6 server will reply with option 17 (OPTION_VENDOR_OPTS) containing any vendor-specific information.
VoIP Options
DHCP clients are not only laptops and handheld mobile devices. They can be Voice over IP (VoIP) phones that boot up and must learn configuration options for their call processing and signaling servers from the network.
In IPv4 networks using DHCP, the option that sets the IPv4 SIP Servers DHCP Option is 120. In IPv6 networks, DHCPv6 uses option 21 (OPTION_SIP_SERVER_D), option 22 (OPTION_SIP_SERVER_A), and option 58 (OPTION_SIP_UA_CS_LIST) to deliver the SIP server information to the VoIP device.
The DHCPv6 options 21 and 22 are defined in “Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers” (RFC 3319). DHCPv6 option 58 is documented in “Session Initiation Protocol (SIP) User Agent Configuration” RFC 6011).
Wireless Network Options
Similar to VoIP phones, when Wireless Access Points (APs) boot up they need to gather other configuration information like their wireless controller’s IP address. For example, the APs could request DHCP option 138 (OPTION_CAPWAP_AC_V4) to find the address of the controller they are going to contact. The DHCPv6 equivalent of this is option 52 (OPTION_CAPWAP_AC_V6). On IPv6 networks, CAPWAP discovery is also performed by the AP on the local LAN segment using the “all controller IPv6 multicast address,” ff01::18c.
Client devices may also need to be provided information about any form of Captive Portal that they must connect to first to request access to the wireless network. On IPv4 networks, the DHCP Captive-Portal option is 114, and on IPv6 networks, the DHCPv6 Captive-Portal option is 103.
On IPv6 networks, there is also an ICMPv6 Type 134 Router Advertisement (RA) Option 37 that can share with the client the URI for the captive portal API endpoint to which the user should connect. This is defined in “Captive-Portal Identification in DHCP and Router Advertisements (RAs)” (RFC 8910).
TFTP and PXE Options
VoIP phones and Wireless Access Points may need to be informed about the location of a Trivial File Transfer Protocol (TFTP) server to download new firmware. TFTP parameters are also shared with service provider subscriber CPE devices when they boot up to upgrade their firmware. In DHCP, option 66 sets the TFTP server name and DHCP option 67 sets the bootfile name that the client will attempt to retrieve on bootup. Sometimes, DHCP option 150 can provide Etherboot information and contain the TFTP server’s IPv4 address. Preboot eXecution Environment (PXE) Options exist for IPv4 networks using DHCP options 128, 129, 130, 131, 132, 133, 134, and 135. Vendor Specific Information DHCP options can also be used for PXE boot operations. This process is defined in “Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE)” (RFC 4578).
In DHCPv6, there isn’t any option that specifically has TFTP in its name. However, there are a set of DHCPv6 options that are specified in “DHCPv6 Options for Network Boot” (RFC 5970). DHCPv6 option 59 (OPT_BOOTFILE_URL), option 60 (OPT_BOOTFILE_PARAM), option 61 (OPTION_CLIENT_ARCH_TYPE), and option 62 (OPTION_NII) provide information to clients to use HTTP or TFTP to download files. The other bit of information that goes along with DHCPv6 option 61 is the Processor Architecture Types, which are defined by IANA.
For Cisco collaboration environments, vendor-specific DHCPv6 options are used to convey the TFTP server address(es) to the VoIP phone. The Cisco’s Enterprise Number (vendor ID) used is 9, while suboption 1 provides the TFTP server’s address, and suboption 2 provides the TFTP service name option.
Network Time Protocol Option
DHCP clients may also need to be provided with information about their time servers so they can maintain accurate clocks. For DHCP, option 4 was used to indicate the legacy (RFC 868) time server the DHCP client could use. DHCP now uses option 42 for sharing the Simple Network Time Protocol (SNTP) (RFC 1769) server’s IPv4 addresses with the DHCP clients.
On IPv6 networks, DHCPv6 option 31 (OPTION_SNTP_SERVERS) indicates the time server. This is specified in “Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6” (RFC 4075). DHCPv6 can also use option 56 (OPTION_NTP_SERVER) to indicate the IP address of the NTP server. This is specified in “Network Time Protocol (NTP) Server Option for DHCPv6” (RFC 5908). There is also an NTP time source sub-option which convey the FQDN of the SNTP server, or the unicast or multicast IPv6 address of the NTP/SNTP server to the client.
DHCP Relay Agent Information Option
DHCP relay devices can append additional information to send onward to the DHCP server when a client is requesting address assignments. IPv4 DHCP relays can add DHCP option 82 with additional information such as Circuit-ID and Remote-ID sent onward to the server. This process is defined in “DHCP Relay Agent Information Option” (RFC 3046). The Infoblox documentation “About the DHCP Relay Agent Option (Option 82)” shows how this is used.
On an IPv6 DHCPv6 relay device, this same function can be achieved using DHCPv6 option 43 (OPTION_ERO). This process is defined in “DHCPv6 Relay Agent Echo Request Option” (RFC 4994).
DHCPv6 Prefix Delegation
One unique characteristic of DHCPv6 is that it can facilitate assignment of an entire prefix to a downstream router or node. With DHCPv6-PD, an entire prefix can be assigned to a downstream router. For example, the DHCPv6 server could have an IPv6 prefix pool of size /40 and then delegate individual /56s downstream to remote routers. Those downstream routers take that /56 and divide it up into /64s to assign to their downstream interfaces. Tom Coffeen covers this in “Introducing DHCPv6 Prefix Delegation”.
Typically, individual DHCPv6 clients communicate their DHCP Unique Identifier (DUID) and Identity Association Identifier (IAID) which identifies the interface on the host. The DHCPv6 server stores these in the lease information. The DUID and the IAID are concatenated together to create a unique client ID. In DHCPv6, the Identity Association (IA) identifies the client. There are three different types of IA and the third is the one that is relevant to DHCPv6-PD.
- IA_NA = Identity Association for a non-temporary address
- IA_TA = Identity Association for a temporary address
- IA_PD = Identity Association for a prefix delegation
The IA_PD is used by the downstream client device when it asks the DHCPv6 server for a prefix. DHCPv6 uses option 25 (OPTION_IA_PD) to perform this process and it is defined in “DHCPv6-Options for DHCPv6-PD” (RFC 3633).
Most typically this is the method that is used to assign a /64 prefix to a residential broadband Internet subscriber CPE device for use within the home network. DHCPv6-PD could also be used to assign a /64 (or larger prefixes such as a /60 or a /56) to a downstream host likely for use in some type of software container virtual network.
This is a function that is unique to DHCPv6. You can’t do that with IPv4 DHCP. You can’t do prefix delegation with IPv4 DHCP.
Using DHCP Option 108 to Disable IPv4
When operating IPv6-only networks, it may be necessary to indicate to the end nodes that they should disable their IPv4 protocols and solely use IPv6. The RFC “IPv6-Only Preferred Option for DHCPv4” (RFC 8925) specifies a method to use a DHCP option (over IPv4) to disable the IPv4 protocol on a host (resulting in it being IPv6-only). This is IPv4 DHCP option 108 which has a 32-bit unsigned integer value indicating the number of seconds for which the client should disable DHCPv4. The two parameters documented in the RFC are V6ONLY_WAIT (default = 1800 seconds, 30 min), and MIN_V6ONLY_WAIT (default = 300 seconds, 5 min).
The steps to configure this DHCP Option 108 on an Infoblox system are shown in “Configuring Infoblox vNIOS for IPv6-Only Networks”. We have also recorded an IPv6 Buzz podcast discussing DHCP Option 108. Currently, the limitation of DHCP option 108 is that it only works on a few OSs today (Apple macOS, Apple iOS, Android versions 12, 13, and 14). However, Microsoft has committed to produce an update to Windows 11 clients and introduce a 464XLAT CLAT into the standard desktop operating system. One of the methods to activate that CLAT function on the IPv6-only Windows 11 computer is to use IPv4 DHCP option 108.
DHCPv6 Option for PREF64
When using IPv6-only networks, nodes may need a way to discover the NAT64 prefix (PREF64) that is being used so they can perform their own protocol translation (e.g. 464XLAT CLAT). PREF64 defines the DNS64 synthetic prefix used on the network.
One method for activating the CLAT on an IPv6-only end node is “Discovering PREF64 in Router Advertisements” (RFC 8781), whereby the PREF64 is sent as RA Option 38 as an 8-bit identifier of the PREF64 prefix. Another method is “Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis” (RFC 7050), whereby the end node sends a AAAA query for ipv4only.arpa to learn the prefix (RFC 8880). And yet another method is “Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP)” (RFC7225), which defines a new PREFIX64 (option code 129) object that contains the PREF64 prefix in the PCP info to the client.
One final method that the IETF is currently working on is a draft titled “DHCPv6 Options for Discovery NAT64 Prefixes”. This RFC defines DHCPv6 option 113 (OPTION_V6_PREFIX64) to be used to indicate the DNS64 prefix the end node may use. Even though this is just an IETF draft document, IANA has already assigned DHCPv6 option 113 for this method for an end node to learn the PREF64 IPv6 prefix.
Link-Layer Addresses with DHCPv6
There can be certain circumstances where an organization will want to have nodes use non-random Interface Identifiers (IIDs) (or to avoid SLAAC with EUI-64). DHCPv6 servers will return IIDs that are randomized within the scope/range. When it comes to link-layer MAC addresses, many expect them to be unique but in some environments, like data centers, software container environments, and IoT networks, an implementer may want another scalable method to perform link-layer address assignments.
IPv6 provides a method for this defined in “Link-Layer Address Assignment Mechanism for DHCPv6” (RFC 8947). Just like in the discussion of DHCPv6-PD above, this RFC introduces a new “Identity Association for Link-Layer Address” (IA_LL). The client will send DHCPv6 option 138 (OPTION_IA_LL) and DHCPv6 option 139 (OPTION_LLADDR) in the SOLICIT message to the DHCPv6 relay/server. The DHCPv6 server will send back the link-local address in the ADVERTISE message.
There isn’t an equivalent method in IPv4 with DHCP to perform this same function.
DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)
The requirement for DNS privacy is important to preserve personal privacy and protect an organization’s end-user information. The U.S. Federal government Office of Management and Budget’s (OMB) Memorandum M-22-09 specifies a requirement for encrypting DNS traffic. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has also documented it in “Encrypted DNS Implementation Guidance”.
There are three primary methods/protocols of providing DNS privacy: DNS Queries over HTTPS, abbreviated as DoH (RFC 8484); Specification for DNS over Transport Layer Security (TLS) (RFC 7858), or DoT; and DNS over Dedicated QUIC Connections (RFC 9250), or DoQ. DoH uses the default TCP port number 443, TCP port 853 is used for DoT, and UDP port 853 is used for DoQ.
To automate this configuration, end nodes need a method for discovering their encrypted DNS resolvers (e.g., DNS over HTTPS, DNS over TLS, and DNS over QUIC). Fortunately, this can now be done in IPv4 networks using DHCP and on IPv6 networks using DHCPv6 or Router Advertisements. These methods are documented in “DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)” (RFC 9463). It specifies how DHCPv6 and RAs can transmit encrypted DNS resolver information to clients. Information in this RA option contains the DNS Authentication Domain Name (ADN), a list of IP addresses, and a set of service parameters (protocol, port number, and DoH path).
For IPv4, this uses DHCP option 162 (OPTION_V4_DNR). For IPv6 networks, DHCPv6 option 144 (OPTION_V6_DNR) provides the ADN and the list of IPv6 addresses. Also, on IPv6 networks, ICMPv6 Type 134 RA Option 144 contains the Encrypted DNS Option information.
RA Options
The other method of dynamically assigning addresses to IPv6-capable end nodes is with StateLess Address AutoConfiguration (SLAAC). For devices that are unable to support DHCPv6, they may need other configuration information besides their IPv6 address to properly function on a network. For example, an IPv6 node needs DNS server information to learn IPv6 addresses of FQDN destinations.
Common RA options are the Prefix Information (Option 3), the router’s Source Link-Layer Address (Option 1), the link MTU (Option 5), and possibly Route Information (Option 24). However, there are several other RA options that have been defined in RFCs and documented in the IANA ICMPv6 Parameters list.
- Default Router List and Prefix List RA Option 24 (RFC 4191)
- Recursive DNS Server (RDNSS) RA Option 25 (RFC 8106)
- DNS Search List (DNSSL) RA Option 31 (RFC 8106)
- DHCPv6 Captive Portal RA Option 37 (RFC 8910)
- PREF64 RA Option 38 (RFC 8781)
- Encrypted DNS Option 144 (RFC 9463)
DHCPv6 provides a broader and richer set of information to hosts than could be conveyed inside the single Router Advertisement packet from the router. You also can create your own custom DHCPv6 options. By comparison, you don’t have the ability to create your own RA options in SLAAC. RA options would need to be standardized by the IETF (similar to IPv6 extension headers) and would need to be implemented in all the host operating systems, which could take years or never happen at all.
Summary
As you are preparing for your IPv6 deployment, you will want to determine if you have specific configurations for IPv4 that you will want replicate in IPv6. This holds true for DHCP and DHCPv6. You’ll want to make sure that your DHCPv6 server is configured for the functionally equivalent options you supply to your current DHCP clients. The Internet Assigned Number Authority (IANA) maintains the current list of DHCP options and DHCPv6 options in case you need to find the option number you are looking for. You can also consult Infoblox documents on DHCP options and DHCPv6 options as you prepare for configuration. Hopefully this article adds to your ability to achieve the same operational practices for IPv4 and IPv6.
