Summary

  • RFC 5417 defines separate DHCPv4 and DHCPv6 options that carry ordered lists of CAPWAP access-controller addresses; a configured DHCP server supplies the sequence.
  • The order steers which candidate a WTP should try first. It does not establish reachability, controller identity, authorization or a working CAPWAP session; DTLS authenticates the peers when that session is established.

A packet capture can show a DHCP reply carrying an ordered list of controller addresses and still leave the decisive questions open: what does the WTP try next, and which peer will it trust? RFC 5417 answers only the first part. Its options let DHCP place candidate access controllers (ACs) in a preferred search order before CAPWAP discovery proceeds.

The two options are deliberately separate. DHCPv4 option 138 carries a list of IPv4 addresses, each 32 bits long; its address data must therefore occupy a multiple of four octets. DHCPv6 option 52 carries 128-bit IPv6 addresses, with a length that must be a multiple of sixteen octets. The client acting for a WTP must request the relevant option in its Parameter Request List. The DHCP server returns it only when its policy is configured appropriately and a list of AC addresses is configured.

That server-side condition matters operationally. The sequence is not an independent measurement of which controller is healthy. It is a configured input to bootstrap. RFC 5417 says that addresses are listed in order of preference and that a WTP receiving the option may use the list to locate an AC. The WTP should try the records in the order supplied. Those words give the list real influence over the search path, while stopping short of a service guarantee: the RFC does not make an address reachable, measure controller load, or promise that the first entry will accept the WTP.

The distinction between the two address families also deserves attention. RFC 5417 defines one preference order within the DHCPv4 list and another within the DHCPv6 list. It does not describe a single ranking that merges the two lists. An operator should not assume that the first IPv4 candidate and the first IPv6 candidate express the same preference unless the local DHCP configuration makes that relationship explicit.

The sequence also does not make the chosen AC trustworthy. DHCP can deliver the WTP’s first clue about where to go, but the CAPWAP discovery and session procedures do different work. RFC 5415 describes discovery messages and the subsequent session process. RFC 5417’s security section is direct: an attacker who modifies a DHCP response or inserts a response could steer a WTP toward a rogue AC, which could intercept call requests or deny service. CAPWAP must use Datagram Transport Layer Security (DTLS) to authenticate peers when establishing a session.

That authentication boundary is not a reason to ignore the bootstrap path. RFC 5417 notes that, in most networks, DHCP options arrive before network-access authentication and are not protected for integrity or origin. In security-sensitive environments, the options should not be the only way to determine which AC a WTP contacts. RFC 5415 defines other discovery procedures that a WTP may use. The design is layered: DHCP can nominate and order candidates; a later authenticated exchange must decide whether a candidate is an acceptable peer.

IANA continues to list DHCPv4 option 138 as OPTION_CAPWAP_AC_V4 and DHCPv6 option 52 as OPTION_CAPWAP_AC_V6, both with RFC 5417 as their reference. Those assignments establish that the protocol parameters remain registered. They do not establish how widely current products request or honor the options, how a particular WTP behaves after a failed attempt, or how quickly a site converges on another controller.

For operators, the useful object is therefore not just the option number. It is the full chain: whether each WTP requests the option; what the DHCP server returns for its scope and address family; whether each listed address is routed and listening; what CAPWAP discovery returns; and whether DTLS authenticates the intended peer. A packet capture showing option 138 or 52 proves what the DHCP exchange carried. It does not prove that the WTP reached the intended AC or established a usable control session.

RFC 5417’s contribution is modest and consequential. It lets DHCP policy shape the order in which a wireless endpoint searches for management, without pretending that a configured preference is a live election or a security verdict. Keeping those stages separate makes a controller migration easier to reason about: the address list expresses intent, discovery tests candidates, and DTLS authenticates the peer that proceeds.

Sources