There are many enterprise companies who are still using DHCP for IPv4 on their routers/switches. This is typically done by the network administrator who needs to get a DHCP capability up and running quickly but does not have access to a DHCP server. More often than not, this is done by an IP Telephony engineer who needs to get a set of VoIP phones up and going quickly on a new voice VLAN and only needs to send some simple DHCP options to the phones. In other cases, the network engineer does not want to (or does not have time to) reach across the aisle to the system administrator and set up a scope on a proper DHCP server. Most vendor’s routers/switches have the ability to function as:
a DHCP client and obtain an interface IPv4 address from an upstream DHCP service,
a DHCP relay and forward UDP DHCP messages from clients on a LAN to and from a DHCP server,
a DHCP server whereby the router/switch services DHCP requests directly.
There are several reasons why running a DHCP server on a network device is not a best practice or provides limited capabilities. Following are a few of the limitations with using a router/switch as a DHCP server.
Running a DHCP server on a router/switch consumes resources on the network device. These DHCP packets are handled in software (not hardware accelerated forwarding). The resources required make this practice not suitable for a network with a large number (> 150) of DHCP clients.
Does not support dynamic DNS. The router/switch DHCP server cannot create an entry into DNS on behalf of the client based on the IPv4 address that was leased to the client.
No ability to easily manage the scope and see the current DHCP bindings and leases across multiple routers. Administrator must log into the switch/router individually to get information about DHCP bindings.
No high availability or redundancy of the DHCP bindings. This could cause problems if the current DHCP server and default gateway fails.
It is more difficult to configure DHCP options on router/switch platform.
The DHCP service running on a router/switch is not integrated with IP address management (IPAM) for address tracking and scope utilization or security forensics.
When it comes to IPv6, things are done slightly differently. IPv6 uses a method of using ICMPv6 and multicast messages on a LAN to help nodes on a LAN bootstrap themselves and learn their IPv6 address, default gateway, and other useful information about the LAN environment. This process starts by the client joining a network and sending an ICMPv6 type 133 Router Solicitation (RS) message and then receiving an ICMPv6 type 134 Router Advertisement (RA) message. The lowest-common-denominator method of assigning IPv6 addresses to client is the method of Stateless Address Auto-configuration (SLAAC) (RFC 4862). SLAAC has virtually universal support in all IPv6-capable clients, however, there can be security implications to using privacy/temporary interface identifiers (RFC 4941). There is a 4-part Infoblox IPv6 Center of Excellence (COE) blog on the topic of how SLAAC and DHCPv6 operate. (part 1, part 2, part 3, part 4). For these reasons, most enterprises would prefer to use DHCPv6 (RFC 3315) on their end-user access LANs. (Note: for servers and data center environments, organizations would likely prefer static IPv6 address assignment similar to how static IPv4 addresses are used on data center equipment).
Similar to the way enterprises prefer to use DHCP for IPv4, enterprises will prefer to use DHCPv6 for assigning dynamic addresses to client devices. DHCPv6 functions much the same way as DHCP for IPv4 in that DHCPv6 supports the client, relay and server model. However, there are many subtle differences between DHCPv6 and DHCP for IPv4.
ICMPv6 RA messages are used to convey to clients that they should use Stateful address auto-configuration (DHCPv6) by setting the M-bit in the RA.
DHCPv6 uses different UDP port numbers (UDP port 546 for clients and UDP port 547 for servers).
DHCPv6 uses link-local (fe80::/10) IPv6 addresses when communicating between client and relay/server.
DHCPv6 has different message types and message names than DHCP for IPv4. (e.g. DHCP for IPv4 DISCOVER message is similar to the DHCPv6 SOLICIT message)
DHCPv6 uses a DHCP Unique Identifier (DUID) where DHCP for IPv4 uses the MAC address of the client.
DHCPv6 does not provide the IPv6 address of the default gateway to the client, this is provided by the ICMPv6 RA message. DHCP for IPv4 provides the default gateway IP address to the client.
DHCPv6 uses multicast for clients to send SOLICIT messages All_DHCP_Relay_Agents_and_Servers (FF02::1:2), All_DHCP_Servers (FF05::1:3). DHCP for IPv4 uses UDP broadcast packets.
One final difference between DHCP for IPv4 and DHCPv6 is that DHCPv6 is not configured on the router/switch operating as the first-hop gateway. Virtually all vendors of routers, switches, firewalls, load balancers or other Network functions Virtualization (NfV) systems that operate as a default gateway for a node do not operate as DHCPv6 servers. The vendors have not integrated the DHCPv6 feature in their software. For example, it is not possible to configure a DHCPv6 server on a Cisco router or switch and virtually all other manufacturers operate the same way. You can configure the router/switch/firewall to operate as a DHCPv6 relay and forward the multicast DHCPv6 messages coming from DHCPv6 clients toward a centralized DHCPv6 server. Therefore, if you are currently using DHCP for IPv4 on your router/switch, you will not be able to use this same practice for your IPv6 deployment.
A better approach than trying to use DHCP on your router/switch is to use a centralized DHCP server that supports DHCP for IPv4 and DHCP for IPv6 at the same time. Virtually all DHCP server vendors support both protocols so you can use the same management interface for IPv4 and IPv6. There are several benefits that make it advantageous for an enterprise to use DHCPv6.
Having a DHCPv6 server that is integrated into your IP Address Management (IPAM) system for IPv6 gives visibility to the IPv6-enabled client nodes.
You also would want this same functionality for IPv4. As IPv4 address space becomes increasingly constrained, you will want to keep track of your DHCP scopes and determine if your lease time is adequate with the plethora of BYOD systems joining your networked environment.
DHCP servers provide logging and management interfaces that aid administrators manage their IP address scopes. Your organization will want an accounting of what is on your network regardless of IP version being used.
DHCP servers can provide redundancy and high availability. If one DHCP server were to fail, the clients will preserve their current IP addresses and not cause an interruption for the end-nodes.
Organizations will prefer a DHCPv6 server that has been tried and tested. For example, The Infoblox DHCPv6 server has been certified as “IPv6 Ready” by the USGv6 certification laboratory.
Most enterprise deployments of IPv6 will start at their Internet edge security perimeter environment. When it comes time for your organization to start to implement IPv6 at your end-user LAN networks, then you should be using DHCPv6 on a legitimate DHCPv6 server. This change will also mean that your organization would want to have DHCP operate the same for both protocols. Enterprise organizations will want to take advantage of the centralized dual-protocol DHCP server to provide IPv4 and IPv6 addresses to client devices. When you deploy your DHCPv6 configurations on your DHCP server, this is probably the time when you will want to migrate your DHCP for IPv4 scopes off the routers/switches and put them on a more robust DHCP server infrastructure.