Requesting DHCP for Networks

Terminology

This page uses “autoconfiguration” as a generic term (more general than DHCP) for empowering end hosts on your network to automatically configure themselves with an IP address and other network configuration parameters.

Requesting Autoconfiguration Service

To enable autoconfiguration for your existing network, email net-trouble@illinois.edu with the following information:

  • The name and IP CIDR of the network
  • Which type of autoconfiguration you would like to enable (see below for details)
  • If the network already has a DHCP server, let us know and provide details so that we can assist you in migrating your existing DHCP configuration into IPAM.
  • Optionally, any other special configuration changes you require at this time (e.g. DHCP options set at the network level)

Sample requests:

“Please enable DHCPv4 for uiuc-example-net 192.0.2.0/24”

“Please enable IPv6 Stateless autoconfiguration for uiuc-example-net 2001:db8:abcd::/64”

“Please enable IPv6 Stateful autoconfiguration for uiuc-example-net 2001:db8:abcd::/64”

“I would like to migrate uiuc-example-net 192.0.2.0/24 to campus DHCP from an existing local DHCP server.  (details)”

Please note: merely enabling DHCPv4 or IPv6 Stateful autoconfiguration is not sufficient to allow your DHCP clients to obtain leases!  You must also use IPAM to configure DHCP for your network.  Read on for more information.  (IPv6 Stateless autoconfiguration is different, and does not require you to configure anything in IPAM)

For new networks, work with your network designer to request autoconfiguration service as part of the network creation process.

Autoconfiguration Design Guide

There is no one-size-fits-all optimal approach to autoconfiguration; which type you choose, and which DHCP objects you configure in IPAM, will vary depending on how you want to use and administer your network.

The first step is to determine which of the following client behaviors you want to support:

  • dynamic address allocation: each client automatically obtains an available IP address which is arbitrary and unpredictable. It doesn’t matter which client gets which IP, or if a particular client gets a different IP next time it comes back. This behavior is the easiest to configure, and requires very little administrative maintenance once set up.
  • fixed address allocation: each client automatically obtains an IP address which has been administratively reserved for that client’s exclusive use.  This behavior requires more configuration work in IPAM (new clients must be added and old ones removed), but allows individual client IPs to be stable and predictable.
  • manual client configuration: each client device is manually configured with the necessary network parameters, and does not use autoconfiguration at all. This is usually only necessary for devices which do not support autoconfiguration.

It is possible to mix and match, using different behaviors for different clients on the same network, but care must be taken to avoid conflicts!

In particular, if your network includes any manually-configured devices, it is very important that DHCP not be configured to hand out those IP addresses to other clients!

Next, select the autoconfiguration type that best supports your desired behavior(s) – these are covered in detail in the following sections – and request that type of autoconfiguration service on your network.

Finally, if you’ve chosen DHCPv4 and/or IPv6 Stateful autoconfiguration, configure the desired DHCP objects in IPAM (see Using IPAM for detailed instructions):

  • DHCP Ranges (Dynamic Pools) for dynamic address allocation
  • DHCP-enabled Host Records and/or DHCP Fixed Addresses for fixed address allocation

    Notes for Microsoft DHCP users

    A Microsoft DHCP “Reservation” corresponds to a “Fixed Address” in IPAM. Avoid the temptation to create a “Reservation” in IPAM; that term refers to a different concept entirely and will not accomplish what you intend.

    Also, there is no need to place Fixed Addresses inside a DHCP Range (a “scope” in Microsoft terms); in fact, it’s best practice to avoid doing this. If you don’t want to use dynamic address allocation behavior on your network, you should not create a DHCP Range at all.

IPv4 Autoconfiguration Types

For IPv4, autoconfiguration is synonymous with DHCPv4, so the standard choices are simple; DHCPv4 is either enabled or disabled for any given network.

No Autoconfiguration

DHCPv4
dynamic address allocation?
fixed address allocation?
manual client configuration? ✅ note: manually configured clients may need to explicitly disable autoconfiguration.
Technical Details

Router: no ip helper

IPAM: network disabled

Router: ip helper pointing to campus DHCP servers

IPAM: network enabled, with Fixed Addresses / Hosts (for fixed allocation behavior) and/or Ranges (for dynamic allocation behavior)

Notes:

  • Several best practice recommendations are discussed in DHCP Ranges (Dynamic Pools).
  • One strategy for preserving flexibility on a mixed-behavior net is to create a DHCP Range near the end of the net (i.e. highest-numbered IPs), and allocate Fixed Addresses, DHCP-enabled Hosts, and static IPs for manual configuration (if any) starting from the beginning of the net (lowest-numbered IPs).

IPv6 Autoconfiguration Types

For IPv6, there are multiple standard implementation choices for autoconfiguration, each supporting different behavior(s):

No Autoconfiguration

Stateless Stateful
dynamic address allocation? ✅ preferred ⚠️ less efficient, redundancy is not automatic (see technical details)
fixed address allocation? ✅ yes, but see Limitations
manual client configuration? ✅ note: manually configured clients may need to explicitly disable autoconfiguration. ✅ note: manually configured clients may need to explicitly disable autoconfiguration.
Suggested Use Cases

non-routed nets carrying only link-local traffic

other special cases

typical end-user nets (dynamic)

wherever fixed address allocation behavior is required
What Happens

Client self-configures one or more arbitrary IPv6 addresses, and sends a DHCPv6 Information-Request to obtain option values (including the IPv6 DNS resolver address).

Clients lacking DHCPv6 support can still obtain an address, but will not obtain option values.

Client uses DHCPv6 to obtain both an IPv6 address and option values (including the IPv6 DNS resolver address).

Dynamic vs fixed allocation is determined by IPAM configuration.

Clients lacking DHCPv6 support must be configured manually.

Technical Details

Router: A=0, M=0, O=0, no DHCPv6 relay

IPAM: network disabled

More precisely “SLAAC + stateless DHCPv6”

Router: A=1, M=0, O=1, DHCPv6 relay pointing to campus DHCP servers

IPAM: network enabled, but no Ranges or Fixed Addresses / Hosts

Router: A=0, M=1, O=0, DHCPv6 relay pointing to campus DHCP servers

IPAM: network enabled, with Fixed Addresses / Hosts (for fixed allocation behavior) and/or Ranges (for dynamic allocation behavior)

Notes:

  • Where feasible, choose Stateless over Stateful autoconfiguration for your IPv6 networks.
    • Stateless is simpler than Stateful, and significantly easier on the DHCP servers.
    • If your network includes clients without DHCPv6 support, they will still be able to obtain an IPv6 address using Stateless autoconfiguration. Such clients will not learn the IPv6 DNS resolver address or other option values, but in many cases clients can function successfully without this information (e.g. by using IPv4 for DNS resolution, if available).
    • It is easy to migrate between Stateless and Stateful in the future if your requirements change.
  • Most modern clients do support DHCPv6, as shown in https://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems.

Technical Details

  • A, M, and O refer to the “Autonomous address configuration”, “Managed address configuration”, and “Other configuration” flags in the Router Advertisement, defined in RFC 4861.
  • The “Stateless” option shown above is more precisely described as “SLAAC + stateless DHCPv6” (SLAAC is the common abbreviation for IPv6 Stateless Address Autoconfiguration, as defined in RFC 4862).  Other stateless options are technically possible, but are not listed in the chart because we anticipate that they would rarely offer any practical advantage.
    • In particular, RDNSS (the “Recursive DNS Server” Router Advertisement option defined in RFC 6106) offers another way to provide clients with the IPv6 DNS resolver address, but DHCPv6 provides more general functionality, and most clients which support RDNSS also support DHCPv6.
  • The DHCPv6 Failover Protocol (to automatically provide redundancy for dynamic autoconfiguration using DHCPv6) defined in RFC 8156 is not currently supported by IPAM, so the only way to achieve dynamic allocation redundancy with Stateful autoconfiguration is to manually configure two separate non-overlapping Ranges in IPAM, one served by each DHCP server.

Limitations of DHCPv6 fixed address allocation

The DHCPv4 protocol specification (RFC 2131) includes a “client hardware address” (chaddr) field which in practice contains the MAC address of the requesting client’s network interface.  This makes it easy for a DHCPv4 server to identify clients by MAC, and to assign fixed address allocations based on the client’s MAC.

The DHCPv6 protocol specification (RFC 3315) does not include a client hardware address field; instead, it defines the DHCP Unique Identifier (DUID) which is intended as an opaque, globally unique, and stable identifier for the whole client device (not just for one of its network interfaces).  Because the MAC address is not included in DHCPv6 messages, there is currently no way for a DHCPv6 server to assign fixed address allocations based on the client’s MAC address; instead, you must configure them based on the client’s DUID.

The challenge is that it can be difficult or impossible to learn the client’s DUID ahead of time.  While the MAC address is a property of the physical hardware, the DUID (for most general-purpose computers, at least) is a software property generated and stored on disk by the operating system.  Depending on your operating system, the DUID may not even exist until it is needed for the first time – and it will almost certainly change if you reinstall the operating system, dual-boot to a second operating system, etc.

Recommendations:

  • Where possible, sidestep this issue entirely by using dynamic address allocation instead of fixed.
  • If you do require fixed address allocation, make sure you understand the challenges discussed in this section and that you have a strategy for ascertaining client DUIDs.

RFC 6939 defines a Client Link-Layer Address option (inserted by the router acting as relay agent) which may someday provide an easier alternative, but as of this writing it is not supported by IPAM or by most building routers.

Other Information

DHCP Standards details important guidelines and recommendations for using the DHCP service, as well as the default configuration parameters that will automatically apply to all networks unless you choose to override them.

Email Alerts explains the automated email notifications that may be sent to network administrators by the DHCP service.