rfc-5416

Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11

P. Calhoun (Editor), M. Montemurro (Editor), D. Stanley (Editor)
date2009-03 streamIETF areaops wgcapwap statusPROPOSED STANDARD pages76 canonicalhttps://www.rfc-editor.org/rfc/rfc5416 doi10.17487/RFC5416 errataview
Wireless LAN product architectures have evolved from single autonomous access points to systems consisting of a centralized Access Controller (AC) and Wireless Termination Points (WTPs). The general goal of centralized control architectures is to move access control, including user authentication and authorization, mobility management, and radio management from the single access point to a centralized controller. This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Binding Specification for use with the IEEE 802.11 Wireless Local Area Network protocol. [STANDARDS-TRACK]

Extracted elements (25)

design-rationale §2.2.1

In Split MAC, the AC handles Distribution Service, Integration Service, 802.11 Association/Disassociation/Reassociation, 802.1X/EAP, RSNA Key Management, and QoS classification, while the WTP handles Beacon generation, Probe Responses, Power Management/Packet Buffering, and real-time scheduling/queuing. This design centralizes policy enforcement and AAA at the AC while keeping time-critical, latency-sensitive functions at the WTP to reduce cost pressure.

security

design-rationale §2.2.1

The CAPWAP protocol does not guarantee in-order delivery of tunneled data packets. For IP-over-802.11 traffic this is not an issue since IP has no in-order delivery requirement, but implementers must consider this characteristic before deploying CAPWAP for protocols that require ordered delivery.

interoperability-note §1

This binding mandates support for both the WiFi Alliance WPA and WMM specifications, which are widely deployed interim pseudo-standards. Implementations must include the WPA and WMM Information Elements in Add WLAN messages. New IEEE 802.11 specifications (802.11n, 802.11r, 802.11v) are explicitly not supported and must be addressed through a separate CAPWAP binding or an update to this document.

security

normative-requirement §6.1 MUST

All IEEE 802.11 management frames MUST be tunneled using 802.11 Tunnel mode. The 802.3 Tunnel mode MUST NOT be selected in conjunction with Split MAC mode. The AC MUST NOT request a MAC mode or Tunnel Mode that was not advertised by the WTP during the discovery process.

normative-requirement §5.1 MUST

An IEEE 802.11 WTP Radio Information message element MUST be present for every radio in the WTP in all Discovery Request, Discovery Response, Primary Discovery Request, Primary Discovery Response, Join Request, and Join Response messages.

normative-requirement §2.4 MUST

During the GTK update process, the AC (for Split MAC) or WTP (for Local MAC) MUST duplicate broadcast packets and transmit them encrypted with both the current and new GTK. When the update is complete, the AC MUST transmit an IEEE 802.11 WLAN Configuration Request including an Update WLAN element with Key Status=4.

security, crypto

normative-requirement §2.6.2 SHOULD

IEEE 802.11 MAC management frames SHOULD use 802.1p precedence value 7, except Probe Requests which SHOULD use value 4. For DSCP, MAC management frames SHOULD use the CS6 per-hop behavior; Probe Requests should use the Low Drop Assured Forwarding per-hop behavior.

qos

normative-requirement §2.2.2 MUST

In Local MAC mode, the WTP MUST forward all IEEE 802.1X, EAP, and RSNA Key Management frames to the AC and forward the corresponding responses to the station, ensuring the AAA client and RSNA Key Management remain on the AC.

security, crypto

normative-requirement §6.1 MUST

The IEEE 802.11 Add WLAN message element MUST be accompanied by IEEE 802.11 Information Element message elements containing: Power Constraint IE, EDCA Parameter Set IE, QoS Capability IE, WPA IE, RSN IE, and WMM IE. Additionally, the SSID field MUST NOT exceed 32 octets.

security, crypto

normative-requirement §2.2 MUST

The WTP and AC MUST support 802.11 encryption/decryption at the WTP for both Split and Local MAC modes. The WTP and AC MAY additionally support 802.11 encryption/decryption at the AC.

security, crypto

normative-requirement §2.2.1 MUST

The WTP SHALL include the IEEE 802.11 MAC header contents in all frames transmitted to the AC. When AC-side encryption is used, the WTP SHALL NOT decrypt uplink frames prior to transmitting them to the AC.

security

normative-requirement §2.2.1 MUST

When 802.11 encryption/decryption is performed at the WTP (Split MAC), the WTP MUST decrypt uplink frames, MUST set the Protected Frame field to 0, and MUST strip IV/EIV, MIC, and ICV fields before forwarding to the AC. For downlink frames, the AC MUST set Protected Frame to 0; the WTP MUST apply required protection policy and set Protected Frame on air transmission.

security, crypto

protocol-element §4

CAPWAP data messages encapsulate the IEEE 802.11 header and payload excluding the FCS checksum. The WTP validates and strips the FCS on uplink frames before forwarding to the AC; on downlink, the WTP computes and appends the FCS. The Optional Wireless Specific Information header carries IEEE 802.11 Frame Info (WTP-to-AC direction) or Destination WLANs (AC-to-WTP direction).

protocol-element §2.3

Client roaming is handled via CAPWAP Station Configuration Request messages: after a station re-associates with a New WTP, the AC sends a Delete Station to the Old WTP and an Add Station with updated session keys to the New WTP. The 802.1X re-authentication step is skipped if key caching was employed.

security, mobility

protocol-element §2.4

GTK refresh is initiated by the AC via an IEEE 802.11 WLAN Configuration Request containing an Update WLAN element with the new GTK, GTK index, Group TSC, and Key Status=3 (begin GTK update). When all STAs have been rekeyed, the AC sends a second Configuration Request with Key Status=4 (GTK update complete). During the update window, broadcast frames must be duplicated and sent with both the current and new GTK.

security, crypto

protocol-element §2.6.1

The CAPWAP IEEE 802.11 QoS Tagging Policy is configured via five bits in the WTP Quality of Service element: 'P' enables 802.1p tagging; 'Q' selects between the default/station-specific 802.1p value and the 802.11 QoS Control field value; 'D' enables DSCP marking; 'I' marks the inner (station) packet DSCP; 'O' marks the outer (tunnel header) DSCP. DSCP and 802.1p mechanisms are not mutually exclusive.

qos

protocol-element §6.1

The IEEE 802.11 Add WLAN message element (type 1024) defines a WLAN on the WTP and carries: Radio ID, WLAN ID (1–16), 16-bit Capability field, Key Index, Key Status (0=per-station RSN, 1=static WEP, 2=begin GTK rekey, 3=GTK rekey complete), Key Length, Group Key (WEP broadcast key, or 128-bit CCMP GTK, or 256-bit TKIP GTK), 48-bit Group TSC, QoS, Auth Type, MAC Mode (Local/Split), Tunnel Mode (Local Bridge/802.3/802.11), Suppress SSID, and SSID.

security, crypto

protocol-element §2.1

The IEEE 802.11 CAPWAP binding uses Wireless Binding Identifier (WBID) value 1 in the CAPWAP header, as required by RFC 5415 Section 4.3. All IEEE 802.11 CAPWAP data and control messages must carry this WBID.

registry

protocol-element §6.15

The IEEE 802.11 Station Session Key message element (type 1038) delivers pairwise encryption keys from the AC to the WTP. The Flag field's 'A' bit signals initial key delivery prior to key exchange (no pairwise key yet); the 'C' bit signals that the AC will provide all crypto services and the WTP should not apply its own encryption to unicast frames.

security, crypto

protocol-element §3.1

The IEEE 802.11 WLAN Configuration Request (type 3398913) is sent by the AC to create, update, or delete a WLAN on the WTP; exactly one of Add WLAN, Delete WLAN, or Update WLAN MUST be present. The WTP MUST respond with an IEEE 802.11 WLAN Configuration Response (type 3398914) containing a Result Code and an optional Assigned WTP BSSID element, remaining in the Run state throughout.

registry §10

RFC 5416 creates or updates thirteen IANA registries: CAPWAP Wireless Binding Identifier (IEEE 802.11 = 1); CAPWAP IEEE 802.11 Message Types (WLAN Configuration Request = 3398913, Response = 3398914); CAPWAP Message Element Types for 25 IEEE 802.11 elements (types 1024–1048); and new enumeration registries for IEEE 802.11 Key Status, QoS, Auth Type, Antenna Combiner, Antenna Selection, Session Key Flags, Tagging Policy, WTP Radio Fail, WTP Radio Type, and WTP Encryption Capabilities.

registry

security-consideration §9.1

During the EAPOL-Key exchange between a station and the AC for GTK delivery, the Receive Sequence Counter (RSC) field for the Group Key must be present in the EAPOL-Key frame; the AC uses the value zero (0) during this initial exchange. Implementations should be aware that using RSC=0 means the WTP must accept frames with any sequence counter until normal sequence counter enforcement begins.

security, crypto

wire-format §2.2.1

For downlink frames with AC-side encryption (Figure 3), MAC header field responsibilities are: AC populates Frame Control (Version, ToDS, FromDS, Type, SubType, Order), Address 1–4, QoS Control, and Frame Body; WTP populates Duration, Sequence Control, and FCS. The FCS field is not transmitted between WTP and AC; the WTP strips it on uplink and computes it on downlink.

security

wire-format §4

The Destination WLANs field (AC-to-WTP, 32 bits) contains a 16-bit WLAN ID bitmap (bit 15 = WLAN 1, bit 0 = WLAN 16) identifying target WLANs for broadcast/multicast frame replication, followed by 16 reserved bits. Must be set to zero for unicast frames and is unused when the WTP does not provide 802.11 encryption.

wire-format §4

The IEEE 802.11 Frame Info field (WTP-to-AC, 32 bits) encodes per-frame radio metadata: RSSI (signed 8-bit, dBm), SNR (signed 8-bit, dB), and Data Rate (unsigned 16-bit, units of 0.1 Mbps; e.g., 55 = 5.5 Mbps).