rfc-5417

Control And Provisioning of Wireless Access Points (CAPWAP) Access Controller DHCP Option

P. Calhoun
date2009-03 streamIETF areaops wgcapwap statusPROPOSED STANDARD pages6 canonicalhttps://www.rfc-editor.org/rfc/rfc5417 doi10.17487/RFC5417
The Control And Provisioning of Wireless Access Points Protocol allows a Wireless Termination Point to use DHCP to discover the Access Controllers to which it is to connect. This document describes the DHCP options to be used by the CAPWAP Protocol. [STANDARDS-TRACK]

Extracted elements (14)

design-rationale §1

DHCP-based AC discovery is provided as a pre-CAPWAP-Discovery method to bootstrap WTP-to-AC connectivity, complementing other discovery mechanisms defined in RFC 5415. The ordering of AC addresses in the option encodes server-configured preference, allowing operators to influence which AC a WTP attempts first.

normative-requirement §2 SHOULD

A CAPWAP WTP acting as a DHCPv4 client receiving the CAPWAP AC DHCPv4 Option SHOULD try the AC records in the order listed in the option received from the DHCPv4 server.

normative-requirement §3 SHOULD

A CAPWAP WTP acting as a DHCPv6 client receiving the CAPWAP AC DHCPv6 Option SHOULD try the AC records in the order listed in the option received from the DHCPv6 server.

normative-requirement §2 MUST

A DHCPv4 client acting on behalf of a CAPWAP WTP MUST request the CAPWAP AC DHCPv4 Option in a Parameter Request List Option, as described in RFC 2131 and RFC 2132.

security

normative-requirement §3 MUST

A DHCPv6 client acting on behalf of a CAPWAP WTP MUST request the CAPWAP AC DHCPv6 Option in a Parameter Request List Option, as described in RFC 3315.

security

normative-requirement §5 MUST

CAPWAP's use of DTLS MUST be used to authenticate the CAPWAP peers in the establishment of the session, mitigating the risk of a WTP being directed to a rogue AC via a manipulated DHCP response.

tls, security

normative-requirement §5 SHOULD NOT

In security-sensitive environments, the DHCP-based AC discovery options defined in this document SHOULD NOT be the only methods used to determine which AC a WTP should connect to, because the DHCP exchange is typically neither integrity-protected nor origin-authenticated.

security

normative-requirement §2 MUST

The DHCPv4 option-length for the CAPWAP AC option MUST be a multiple of four (4), reflecting the 32-bit IPv4 address size.

normative-requirement §3 MUST

The DHCPv6 option-length for the CAPWAP AC option MUST be a multiple of sixteen (16), reflecting the 128-bit IPv6 address size.

protocol-element §2

A CAPWAP WTP MAY use the IP address(es) provided in the CAPWAP AC DHCPv4 or DHCPv6 option to locate an AC prior to the CAPWAP Discovery process. RFC 5415 provides further guidance on the WTP's discovery process.

registry §4

IANA assigned DHCPv4 option code 138 (OPTION_CAPWAP_AC_V4) and DHCPv6 option code 52 (OPTION_CAPWAP_AC_V6) for the CAPWAP AC DHCP options defined in this document.

registry

security-consideration §5

If an adversary modifies or spoofs a DHCP server response, a WTP could be directed to a rogue CAPWAP AC that intercepts call requests or denies service. DTLS peer authentication is mandatory to counter this threat, and DHCP-based discovery alone SHOULD NOT be relied upon in security-sensitive environments.

security, tls

wire-format §2

The DHCPv4 CAPWAP AC option (OPTION_CAPWAP_AC_V4, code 138) carries one or more 32-bit IPv4 addresses of CAPWAP ACs. The option-length field MUST be a multiple of four, with ACs listed in preference order.

tls, security, registry

wire-format §3

The DHCPv6 CAPWAP AC option (OPTION_CAPWAP_AC_V6, code 52) carries one or more 128-bit IPv6 addresses of CAPWAP ACs. The option-code and option-length are each 16-bit fields; option-length MUST be a multiple of sixteen, with ACs listed in preference order.

tls, security, registry