diff options
| author | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
|---|---|---|
| committer | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
| commit | 4bfd864f10b68b71482b35c818559068ef8d5797 (patch) | |
| tree | e3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc5416.txt | |
| parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) | |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc5416.txt')
| -rw-r--r-- | doc/rfc/rfc5416.txt | 4259 |
1 files changed, 4259 insertions, 0 deletions
diff --git a/doc/rfc/rfc5416.txt b/doc/rfc/rfc5416.txt new file mode 100644 index 0000000..4c0829c --- /dev/null +++ b/doc/rfc/rfc5416.txt @@ -0,0 +1,4259 @@ + + + + + + +Network Working Group P. Calhoun, Ed. +Request for Comments: 5416 Cisco Systems, Inc. +Category: Standards Track M. Montemurro, Ed. + Research In Motion + D. Stanley, Ed. + Aruba Networks + March 2009 + + + Control and Provisioning of Wireless Access Points (CAPWAP) Protocol + Binding for IEEE 802.11 + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents in effect on the date of + publication of this document (http://trustee.ietf.org/license-info). + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + + + + + + + + + +Calhoun, et al. Standards Track [Page 1] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + +Abstract + + 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. + +Table of Contents + + 1. Introduction ....................................................4 + 1.1. Goals ......................................................5 + 1.2. Conventions Used in This Document ..........................5 + 1.3. Terminology ................................................5 + 2. IEEE 802.11 Binding .............................................7 + 2.1. CAPWAP Wireless Binding Identifier .........................7 + 2.2. Split MAC and Local MAC Functionality ......................7 + 2.2.1. Split MAC ...........................................7 + 2.2.2. Local MAC ..........................................12 + 2.3. Roaming Behavior ..........................................15 + 2.4. Group Key Refresh .........................................16 + 2.5. BSSID to WLAN ID Mapping ..................................17 + 2.6. CAPWAP Data Channel QoS Behavior ..........................18 + 2.6.1. IEEE 802.11 Data Frames ............................18 + 2.6.1.1. 802.1p Support ............................19 + 2.6.1.2. DSCP Support ..............................19 + 2.6.2. IEEE 802.11 MAC Management Messages ................21 + 2.7. Run State Operation .......................................21 + 3. IEEE 802.11 Specific CAPWAP Control Messages ...................21 + 3.1. IEEE 802.11 WLAN Configuration Request ....................22 + 3.2. IEEE 802.11 WLAN Configuration Response ...................23 + 4. CAPWAP Data Message Bindings ...................................23 + 5. CAPWAP Control Message Bindings ................................25 + 5.1. Discovery Request Message .................................25 + 5.2. Discovery Response Message ................................25 + 5.3. Primary Discovery Request Message .........................25 + 5.4. Primary Discovery Response Message ........................26 + 5.5. Join Request Message ......................................26 + 5.6. Join Response Message .....................................26 + 5.7. Configuration Status Request Message ......................26 + 5.8. Configuration Status Response Message .....................27 + 5.9. Configuration Update Request Message ......................27 + + + +Calhoun, et al. Standards Track [Page 2] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + 5.10. Station Configuration Request ............................28 + 5.11. Change State Event Request ...............................28 + 5.12. WTP Event Request ........................................28 + 6. IEEE 802.11 Message Element Definitions ........................29 + 6.1. IEEE 802.11 Add WLAN ......................................29 + 6.2. IEEE 802.11 Antenna .......................................35 + 6.3. IEEE 802.11 Assigned WTP BSSID ............................36 + 6.4. IEEE 802.11 Delete WLAN ...................................37 + 6.5. IEEE 802.11 Direct Sequence Control .......................37 + 6.6. IEEE 802.11 Information Element ...........................38 + 6.7. IEEE 802.11 MAC Operation .................................39 + 6.8. IEEE 802.11 MIC Countermeasures ...........................41 + 6.9. IEEE 802.11 Multi-Domain Capability .......................42 + 6.10. IEEE 802.11 OFDM Control .................................43 + 6.11. IEEE 802.11 Rate Set .....................................44 + 6.12. IEEE 802.11 RSNA Error Report From Station ...............44 + 6.13. IEEE 802.11 Station ......................................46 + 6.14. IEEE 802.11 Station QoS Profile ..........................47 + 6.15. IEEE 802.11 Station Session Key ..........................48 + 6.16. IEEE 802.11 Statistics ...................................50 + 6.17. IEEE 802.11 Supported Rates ..............................54 + 6.18. IEEE 802.11 Tx Power .....................................54 + 6.19. IEEE 802.11 Tx Power Level ...............................55 + 6.20. IEEE 802.11 Update Station QoS ...........................56 + 6.21. IEEE 802.11 Update WLAN ..................................57 + 6.22. IEEE 802.11 WTP Quality of Service .......................61 + 6.23. IEEE 802.11 WTP Radio Configuration ......................63 + 6.24. IEEE 802.11 WTP Radio Fail Alarm Indication ..............65 + 6.25. IEEE 802.11 WTP Radio Information ........................66 + 7. IEEE 802.11 Binding WTP Saved Variables ........................67 + 7.1. IEEE80211AntennaInfo ......................................67 + 7.2. IEEE80211DSControl ........................................67 + 7.3. IEEE80211MACOperation .....................................67 + 7.4. IEEE80211OFDMControl ......................................67 + 7.5. IEEE80211Rateset ..........................................67 + 7.6. IEEE80211TxPower ..........................................67 + 7.7. IEEE80211QoS ..............................................68 + 7.8. IEEE80211RadioConfig ......................................68 + 8. Technology Specific Message Element Values .....................68 + 8.1. WTP Descriptor Message Element, Encryption + Capabilities Field ........................................68 + 9. Security Considerations ........................................68 + 9.1. IEEE 802.11 Security ......................................68 + 10. IANA Considerations ...........................................70 + 10.1. CAPWAP Wireless Binding Identifier .......................70 + 10.2. CAPWAP IEEE 802.11 Message Types .........................70 + 10.3. CAPWAP Message Element Type ..............................70 + 10.4. IEEE 802.11 Key Status ...................................71 + + + +Calhoun, et al. Standards Track [Page 3] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + 10.5. IEEE 802.11 QoS ..........................................71 + 10.6. IEEE 802.11 Auth Type ....................................71 + 10.7. IEEE 802.11 Antenna Combiner .............................71 + 10.8. IEEE 802.11 Antenna Selection ............................72 + 10.9. IEEE 802.11 Session Key Flags ............................72 + 10.10. IEEE 802.11 Tagging Policy ..............................72 + 10.11. IEEE 802.11 WTP Radio Fail ..............................72 + 10.12. IEEE 802.11 WTP Radio Type ..............................73 + 10.13. WTP Encryption Capabilities .............................73 + 11. Acknowledgments ...............................................73 + 12. References ....................................................73 + 12.1. Normative References .....................................73 + 12.2. Informative References ...................................75 + +1. Introduction + + The CAPWAP protocol [RFC5415] defines an extensible protocol to allow + an Access Controller to manage wireless agnostic Wireless Termination + Points. The CAPWAP protocol itself does not include any specific + wireless technologies; instead, it relies on a binding specification + to extend the technology to a particular wireless technology. + + 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. Use of CAPWAP + control message fields, new control messages, and message elements + are defined. The minimum required definitions for a binding-specific + Statistics message element, Station message element, and WTP Radio + Information message element are included. + + Note that this binding only supports the IEEE 802.11-2007 + specification. Of note, this binding does not support the ad hoc + network mode defined in the IEEE 802.11-2007 standard. This + specification also does not cover the use of data frames with the + four-address format, commonly referred to as Wireless Bridges, whose + use is not specified in the IEEE 802.11-2007 standard. This protocol + specification does not currently officially support IEEE 802.11n. + That said, the protocol does allow a WTP to advertise support for an + IEEE 802.11n radio; however, the protocol does not allow for any of + the protocol's additional features to be configured and/or used. New + IEEE protocol specifications published outside of this document + (e.g., IEEE 802.11v, IEEE 802.11r) are also not supported through + this binding, and in addition to IEEE 802.11n, must be addressed + either through a separate CAPWAP binding, or an update to this + binding. + + + + + + +Calhoun, et al. Standards Track [Page 4] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + In order to address immediate market needs for standards still being + developed by the IEEE 802.11 standards body, the WiFi Alliance + created interim pseudo-standards specifications. Two such + specifications are widely used in the industry, namely the WiFi + Protect Access [WPA] and the WiFi MultiMedia [WMM] specifications. + Given their widespread adoption, this CAPWAP binding requires the use + of these two specifications. + +1.1. Goals + + The goals of this CAPWAP protocol binding are to make the + capabilities of the CAPWAP protocol available for use in conjunction + with IEEE 802.11 wireless networks. The capabilities to be made + available can be summarized as: + + 1. To centralize the authentication and policy enforcement functions + for an IEEE 802.11 wireless network. The AC may also provide + centralized bridging, forwarding, and encryption of user traffic. + Centralization of these functions will enable reduced cost and + higher efficiency by applying the capabilities of network + processing silicon to the wireless network, as in wired LANs. + + 2. To enable shifting of the higher-level protocol processing from + the WTP. This leaves the time-critical applications of wireless + control and access in the WTP, making efficient use of the + computing power available in WTPs that are subject to severe cost + pressure. + + The CAPWAP protocol binding extensions defined herein apply solely to + the interface between the WTP and the AC. Inter-AC and station-to-AC + communication are strictly outside the scope of this document. + +1.2. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +1.3. Terminology + + This section contains definitions for terms used frequently + throughout this document. However, many additional definitions can + be found in [IEEE.802-11.2007]. + + Access Controller (AC): The network entity that provides WTP access + to the network infrastructure in the data plane, control plane, + management plane, or a combination therein. + + + + +Calhoun, et al. Standards Track [Page 5] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + Basic Service Set (BSS): A set of stations controlled by a single + coordination function. + + Distribution: The service that, by using association information, + delivers medium access control (MAC) service data units (MSDUs) + within the distribution system (DS). + + Distribution System Service (DSS): The set of services provided by + the distribution system (DS) that enable the medium access control + (MAC) layer to transport MAC service data units (MSDUs) between + stations that are not in direct communication with each other over a + single instance of the wireless medium (WM). These services include + the transport of MSDUs between the access points (APs) of basic + service sets (BSSs) within an extended service set (ESS), transport + of MSDUs between portals and BSSs within an ESS, and transport of + MSDUs between stations in the same BSS in cases where the MSDU has a + multicast or broadcast destination address, or where the destination + is an individual address but the station sending the MSDU chooses to + involve the DSS. DSSs are provided between pairs of IEEE 802.11 + MACs. + + Integration: The service that enables delivery of medium access + control (MAC) service data units (MSDUs) between the distribution + system (DS) and an existing, non-IEEE 802.11 local area network (via + a portal). + + Station (STA): A device that contains an IEEE 802.11 conformant + medium access control (MAC) and physical layer (PHY) interface to the + wireless medium (WM). + + Portal: The logical point at which medium access control (MAC) + service data units (MSDUs) from a non-IEEE 802.11 local area network + (LAN) enter the distribution system (DS) of an extended service set + (ESS). + + WLAN: In this document, WLAN refers to a logical component + instantiated on a WTP device. A single physical WTP may operate a + number of WLANs. Each Basic Service Set Identifier (BSSID) and its + constituent wireless terminal radios is denoted as a distinct WLAN on + a physical WTP. + + Wireless Termination Point (WTP): The physical or network entity that + contains an IEEE 802.11 RF antenna and wireless PHY to transmit and + receive station traffic for wireless access networks. + + + + + + + +Calhoun, et al. Standards Track [Page 6] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + +2. IEEE 802.11 Binding + + This section describes use of the CAPWAP protocol with the IEEE + 802.11 Wireless Local Area Network protocol, including Local and + Split MAC operation, Group Key Refresh, Basic Service Set + Identification (BSSID) to WLAN Mapping, IEEE 802.11 MAC management + frame Quality of Service (Qos) tagging and Run State operation. + +2.1. CAPWAP Wireless Binding Identifier + + The CAPWAP Header, defined in Section 4.3 of [RFC5415] requires that + all CAPWAP binding specifications have a Wireless Binding Identifier + (WBID) assigned. This document, which defines the IEEE 802.11 + binding, uses the value one (1). + +2.2. Split MAC and Local MAC Functionality + + The CAPWAP protocol, when used with IEEE 802.11 devices, requires + specific behavior from the WTP and the AC to support the required + IEEE 802.11 protocol functions. + + For both the Split and Local MAC approaches, the CAPWAP functions, as + defined in the taxonomy specification [RFC4118], reside in the AC. + + To provide system component interoperability, the WTP and AC MUST + support 802.11 encryption/decryption at the WTP. The WTP and AC MAY + support 802.11 encryption/decryption at the AC. + +2.2.1. Split MAC + + This section shows the division of labor between the WTP and the AC + in a Split MAC architecture. Figure 1 shows the separation of + functionality between CAPWAP components. + + + + + + + + + + + + + + + + + + +Calhoun, et al. Standards Track [Page 7] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + Function Location + Distribution Service AC + Integration Service AC + Beacon Generation WTP + Probe Response Generation WTP + Power Mgmt/Packet Buffering WTP + Fragmentation/Defragmentation WTP/AC + Assoc/Disassoc/Reassoc AC + + IEEE 802.11 QoS + Classifying AC + Scheduling WTP/AC + Queuing WTP + + IEEE 802.11 RSN + IEEE 802.1X/EAP AC + RSNA Key Management AC + IEEE 802.11 Encryption/Decryption WTP/AC + + Figure 1: Mapping of 802.11 Functions for Split MAC Architecture + + In a Split MAC Architecture, the Distribution and Integration + services reside on the AC, and therefore all user data is tunneled + between the WTP and the AC. As noted above, all real-time IEEE + 802.11 services, including the Beacon and Probe Response frames, are + handled on the WTP. + + All remaining IEEE 802.11 MAC management frames are supported on the + AC, including the Association Request frame that allows the AC to be + involved in the access policy enforcement portion of the IEEE 802.11 + protocol. The IEEE 802.1X [IEEE.802-1X.2004], Extensible + Authentication Protocol (EAP) [RFC3748] and IEEE Robust Security + Network Association (RSNA) Key Management [IEEE.802-11.2007] + functions are also located on the AC. This implies that the + Authentication, Authorization, and Accounting (AAA) client also + resides on the AC. + + While the admission control component of IEEE 802.11 resides on the + AC, the real-time scheduling and queuing functions are on the WTP. + Note that this does not prevent the AC from providing additional + policy and scheduling functionality. + + Note that in the following figure, the use of '( - )' indicates that + processing of the frames is done on the WTP. This figure represents + a case where encryption services are provided by the AC. + + + + + + +Calhoun, et al. Standards Track [Page 8] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + Client WTP AC + + Beacon + <----------------------------- + Probe Request + ----------------------------( - )-------------------------> + Probe Response + <----------------------------- + 802.11 AUTH/Association + <---------------------------------------------------------> + Station Configuration Request + [Add Station (Station MAC + Address), IEEE 802.11 Add + Station (WLAN ID), IEEE + 802.11 Session Key(Flag=A)] + <--------------------------> + 802.1X Authentication & 802.11 Key Exchange + <---------------------------------------------------------> + Station Configuration Request + [Add Station(Station MAC + Address), IEEE 802.11 Add + Station (WLAN ID), IEEE 802.11 + Station Session Key(Flag=C)] + <--------------------------> + 802.11 Action Frames + <---------------------------------------------------------> + 802.11 DATA (1) + <---------------------------( - )-------------------------> + + Figure 2: Split MAC Message Flow + + Figure 2 provides an illustration of the division of labor in a Split + MAC architecture. In this example, a WLAN has been created that is + configured for IEEE 802.11, using 802.1X-based end user + authentication and Advanced Encryption Standard-Counter Mode with + CBC-MAC Protocol (AES-CCMP) link layer encryption (CCMP, see + [FIPS.197.2001]). The following process occurs: + + o The WTP generates the IEEE 802.11 Beacon frames, using information + provided to it through the IEEE 802.11 Add WLAN (see Section 6.1) + message element, including the Robust Security Network Information + Element (RSNIE), which indicates support of 802.1X and AES-CCMP. + + o The WTP processes the Probe Request frame and responds with a + corresponding Probe Response frame. The Probe Request frame is + then forwarded to the AC for optional processing. + + + + + +Calhoun, et al. Standards Track [Page 9] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + o The WTP forwards the IEEEE 802.11 Authentication and Association + frames to the AC, which is responsible for responding to the + client. + + o Once the association is complete, the AC transmits a Station + Configuration Request message, which includes an Add Station + message element, to the WTP (see Section 4.6.8 in [RFC5415]). In + the above example, the WLAN was configured for IEEE 802.1X, and + therefore the IEEE 802.11 Station Session Key is included with the + flag field's 'A' bit set. + + o If the WTP is providing encryption/decryption services, once the + client has completed the IEEE 802.11 key exchange, the AC + transmits another Station Configuration Request message, which + includes: + + - An Add Station message element. + + - An IEEE 802.11 Add Station message element, which includes the + WLAN Identifier with which the station has associated. + + - An IEEE 802.11 Station Session Key message element, which + includes the pairwise encryption key. + + - An IEEE 802.11 Information Element message element, which + includes the Robust Security Network Information Element + (RSNIE) to the WTP, stating the security policy to enforce for + the client (in this case AES-CCMP). + + o If the WTP is providing encryption/decryption services, once the + client has completed the IEEE 802.11 key exchange, the AC + transmits another Station Configuration Request message, which + includes: + + - An Add Station message element. + + - An IEEE 802.11 Add Station message element, which includes the + WLAN Identifier with which the station has associated. + + - An IEEE 802.11 Station Session Key message element, which + includes the pairwise encryption key. + + - An IEEE 802.11 Information Element message element, which + includes the Robust Security Network Information Element + (RSNIE) to the WTP, stating the security policy to enforce for + the client (in this case AES-CCMP). + + + + + +Calhoun, et al. Standards Track [Page 10] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + o If the AC is providing encryption/decryption services, once the + client has completed the IEEE 802.11 key exchange, the AC + transmits another Station Configuration Request message, which + includes: + + - An Add Station message element. + + - An IEEE 802.11 Add Station message element, which includes the + WLAN Identifier with which the station has associated. + + - An IEEE 802.11 Station Session Key message element with the + flag field's 'C' bit enabled (indicating that the AC will + provide crypto services). + + o The WTP forwards any IEEE 802.11 Management Action frames received + to the AC. + + o All IEEE 802.11 station data frames are tunneled between the WTP + and the AC. + + Note that during the EAP over LAN (EAPOL)-Key exchange between the + Station and the AC, the Receive Sequence Counter (RSC) field for the + Group Key (GTK) needs to be included in the frame. The value of zero + (0) is used by the AC during this exchange. Additional details are + available in Section 9.1. + + The WTP SHALL include the IEEE 802.11 MAC header contents in all + frames transmitted to the AC. + + When 802.11 encryption/decryption is performed at the WTP, the WTP + MUST decrypt the uplink frames, MUST set the Protected Frame field to + 0, and MUST make the frame format consistent with that of an + unprotected 802.11 frame prior to transmitting the frames to the AC. + The fields added to an 802.11 protected frame (i.e., Initialization + Vector/Extended Initialization Vector (IV/EIV), Message Integrity + Code (MIC), and Integrity Check Value (ICV)) MUST be stripped off + prior to transmission from the WTP to AC. For downlink frames, the + Protected Frame field MUST be set to 0 by the AC as the frame being + sent is unencrypted. The WTP MUST apply the required protection + policy for the WLAN, and set the Protected Frame field on + transmission over the air. The Protected Frame field always needs to + accurately indicate the status of the 802.11 frame that is carrying + it. + + When 802.11 encryption/decryption is performed at the AC, the WTP + SHALL NOT decrypt the uplink frames prior to transmitting the frames + to the AC. The AC and WTP SHALL populate the IEEE 802.11 MAC header + fields as described in Figure 3. + + + +Calhoun, et al. Standards Track [Page 11] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + MAC header field Location + Frame Control: + Version AC + ToDS AC + FromDS AC + Type AC + SubType AC + MoreFrag WTP/AC + Retry WTP + Pwr Mgmt - + MoreData WTP + Protected WTP/AC + Order AC + Duration: WTP + Address 1: AC + Address 2: AC + Address 3: AC + Sequence Ctrl: WTP + Address 4: AC + QoS Control: AC + Frame Body: AC + FCS: WTP + + Figure 3: Population of the IEEE 802.11 MAC Header Fields for + Downlink Frames + + When 802.11 encryption/decryption is performed at the AC, the + MoreFrag bit is populated at the AC. The Pwr Mgmt bit is not + applicable to downlink frames, and is set to 0. Note that the Frame + Check Sequence (FCS) field is not included in 802.11 frames exchanged + between the WTP and the AC. Upon sending data frames to the AC, the + WTP is responsible for validating and stripping the FCS field. Upon + receiving data frames from the AC, the WTP is responsible for adding + the FCS field, and populating the field as described in + [IEEE.802-11.2007]. + + Note that when the WTP tunnels data packets to the AC (and vice + versa), the CAPWAP protocol does not guarantee in-order delivery. + When the protocol being transported over IEEE 802.11 is IP, out-of- + order delivery is not an issue as IP has no such requirements. + However, implementers need to be aware of this protocol + characteristic before deciding to use CAPWAP. + +2.2.2. Local MAC + + This section shows the division of labor between the WTP and the AC + in a Local MAC architecture. Figure 4 shows the separation of + functionality among CAPWAP components. + + + +Calhoun, et al. Standards Track [Page 12] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + Function Location + Distribution Service WTP/AC + Integration Service WTP + Beacon Generation WTP + Probe Response Generation WTP + Power Mgmt/Packet Buffering WTP + Fragmentation/Defragmentation WTP + Assoc/Disassoc/Reassoc WTP/AC + + IEEE 802.11 QoS + Classifying WTP + Scheduling WTP + Queuing WTP + + IEEE 802.11 RSN + IEEE 802.1X/EAP AC + RSNA Key Management AC + IEEE 802.11 Encryption/Decryption WTP + + Figure 4: Mapping of 802.11 Functions for Local AP Architecture + + In the Local MAC mode, the integration service exists on the WTP, + while the distribution service MAY reside on either the WTP or the + AC. When it resides on the AC, station-generated frames are not + forwarded to the AC in their native format, but encapsulated as 802.3 + frames. + + While the MAC is terminated on the WTP, it is necessary for the AC to + be aware of mobility events within the WTPs. Thus, the WTP MUST + forward the IEEE 802.11 Association Request frames to the AC. The AC + MAY reply with a failed Association Response frame if it deems it + necessary, and upon receipt of a failed Association Response frame + from the AC, the WTP MUST send a Disassociation frame to the station. + + The IEEE 802.1X [IEEE.802-1X.2004], EAP, and IEEE RSNA Key Management + [IEEE.802-11.2007] functions reside in the AC. Therefore, 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. This + implies that the AAA client also resides on the AC. + + Note that in the following figure, the use of '( - )' indicates that + processing of the frames is done on the WTP. + + + + + + + + + +Calhoun, et al. Standards Track [Page 13] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + Client WTP AC + + Beacon + <----------------------------- + Probe + <----------------------------> + 802.11 AUTH + <----------------------------- + 802.11 Association + <---------------------------( - )-------------------------> + Station Configuration Request + [Add Station (Station MAC + Address), IEEE 802.11 Add + Station (WLAN ID), IEEE + 802.11 Session Key(Flag=A)] + <--------------------------> + 802.1X Authentication & 802.11 Key Exchange + <---------------------------------------------------------> + Station Configuration Request + [Add Station(Station MAC + Address), IEEE 802.11 Add + Station (WLAN ID), IEEE 802.11 + Station session Key (Key=x), + IEEE 802.11 Information + Element(RSNIE(Pairwise + Cipher=CCMP))] + <--------------------------> + 802.11 Action Frames + <---------------------------------------------------------> + 802.11 DATA + <-----------------------------> + + Figure 5: Local MAC Message Flow + + Figure 5 provides an illustration of the division of labor in a Local + MAC architecture. In this example, a WLAN that is configured for + IEEE 802.11 has been created using AES-CCMP for privacy. The + following process occurs: + + o The WTP generates the IEEE 802.11 Beacon frames, using information + provided to it through the Add WLAN (see Section 6.1) message + element. + + o The WTP processes a Probe Request frame and responds with a + corresponding Probe Response frame. + + o The WTP forwards the IEEE 802.11 Authentication and Association + frames to the AC. + + + +Calhoun, et al. Standards Track [Page 14] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + o Once the association is complete, the AC transmits a Station + Configuration Request message, which includes the Add Station + message element, to the WTP (see Section 4.6.8 in [RFC5415]). In + the above example, the WLAN was configured for IEEE 802.1X, and + therefore the IEEE 802.11 Station Session Key is included with the + flag field's 'A' bit set. + + o The WTP forwards all IEEE 802.1X and IEEE 802.11 key exchange + messages to the AC for processing. + + o The AC transmits another Station Configuration Request message, + which includes: + + - An Add Station message element, which MAY include a Virtual LAN + (VLAN) [IEEE.802-1Q.2005] name, which when present is used by + the WTP to identify the VLAN on which the user's data frames + are to be bridged. + + - An IEEE 802.11 Add Station message element, which includes the + WLAN Identifier with which the station has associated. + + - An IEEE 802.11 Station Session Key message element, which + includes the pairwise encryption key. + + - An IEEE 802.11 Information Element message element, which + includes the RSNIE to the WTP, stating the security policy to + enforce for the client (in this case AES-CCMP). + + o The WTP forwards any IEEE 802.11 Management Action frames received + to the AC. + + o The WTP MAY locally bridge client data frames (and provide the + necessary encryption and decryption services). The WTP MAY also + tunnel client data frames to the AC, using 802.3 frame tunnel mode + or 802.11 frame tunnel mode. + +2.3. Roaming Behavior + + This section expands upon the examples provided in the previous + section, and describes how the CAPWAP control protocol is used to + provide secure roaming. + + Once a client has successfully associated with the network in a + secure fashion, it is likely to attempt to roam to another WTP. + Figure 6 shows an example of a currently associated station moving + from its "Old WTP" to a "New WTP". The figure is valid for multiple + different security policies, including IEEE 802.1X and Wireless + Protected Access (WPA) or Wireless Protected Access 2 (WPA2) [WPA]. + + + +Calhoun, et al. Standards Track [Page 15] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + In the event that key caching was employed, the 802.1X Authentication + step would be eliminated. Note that the example represents one where + crypto services are provided by the WTP, so in a case where the AC + provided this function the last Station Configuration Request would + be different. + + Client Old WTP New WTP AC + + Association Request/Response + <--------------------------------------( - )--------------> + Station Configuration Request + [Add Station (Station MAC + Address), IEEE 802.11 Add + Station (WLAN ID), IEEE + 802.11 Session Key(Flag=A)] + <----------------> + 802.1X Authentication (if no key cache entry exists) + <--------------------------------------( - )--------------> + 802.11 4-way Key Exchange + <--------------------------------------( - )--------------> + Station Configuration Request + [Delete Station] + <----------------------------------> + Station Configuration Request + [Add Station(Station MAC + Address), IEEE 802.11 Add + Station (WLAN ID), IEEE 802.11 + Station session Key (Key=x), + IEEE 802.11 Information + Element(RSNIE(Pairwise + Cipher=CCMP))] + <----------------> + + Figure 6: Client Roaming Example + +2.4. Group Key Refresh + + Periodically, the Group Key (GTK) for the BSS needs to be updated. + The AC uses an EAPOL-Key frame to update the group key for each STA + in the BSS. While the AC is updating the GTK, each Layer 2 (L2) + broadcast frame transmitted to the BSS needs to be duplicated and + transmitted using both the current GTK and the new GTK. Once the GTK + update process has completed, broadcast frames transmitted to the BSS + will be encrypted using the new GTK. + + In the case of Split MAC, the AC needs to duplicate all broadcast + packets and update the key index so that the packet is transmitted + using both the current and new GTK to ensure that all STAs in the BSS + + + +Calhoun, et al. Standards Track [Page 16] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + receive the broadcast frames. In the case of Local MAC, the WTP + needs to duplicate and transmit broadcast frames using the + appropriate index to ensure that all STAs in the BSS continue to + receive broadcast frames. + + The Group Key update procedure is shown in the following figure. The + AC will signal the update to the GTK using an IEEE 802.11 + Configuration Request message, including an IEEE 802.11 Update WLAN + message element with the new GTK, its index, the Transmit Sequence + Counter (TSC) for the Group Key and the Key Status set to 3 (begin + GTK update). The AC will then begin updating the GTK for each STA. + During this time, 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 AC has completed the GTK update to all + STAs in the BSS, the AC MUST transmit an IEEE 802.11 Configuration + Request message including an IEEE 802.11 Update WLAN message element + containing the new GTK, its index, and the Key Status set to 4 (GTK + update complete). + + Client WTP AC + + IEEE 802.11 WLAN Configuration Request [Update + WLAN (GTK, GTK Index, GTK Start, + Group TSC) ] + <-------------------------------------------- + 802.1X EAPoL (GTK Message 1) + <-------------( - )------------------------------------------- + 802.1X EAPoL (GTK Message 2) + -------------( - )-------------------------------------------> + IEEE 802.11 WLAN Configuration Request [ Update + WLAN (GTK Index, GTK Complete) ] + <-------------------------------------------- + + Figure 7: Group Key Update Procedure + +2.5. BSSID to WLAN ID Mapping + + The CAPWAP protocol binding enables the WTP to assign BSSIDs upon + creation of a WLAN (see Section 6.1). While manufacturers are free + to assign BSSIDs using any arbitrary mechanism, it is advised that + where possible the BSSIDs are assigned as a contiguous block. + + When assigned as a block, implementations can still assign any of the + available BSSIDs to any WLAN. One possible method is for the WTP to + assign the address using the following algorithm: base BSSID address + + WLAN ID. + + + + + +Calhoun, et al. Standards Track [Page 17] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + The WTP communicates the maximum number of BSSIDs that it supports + during configuration via the IEEE 802.11 WTP WLAN Radio Configuration + message element (see Section 6.23). + +2.6. CAPWAP Data Channel QoS Behavior + + The CAPWAP IEEE 802.11 binding specification provides procedures to + allow for the WTP to enforce Quality of Service on IEEE 802.11 Data + Frames and MAC Management messages. + +2.6.1. IEEE 802.11 Data Frames + + When the WLAN is created on the WTP, a default Quality of Service + policy is established through the IEEE 802.11 WTP Quality of Service + message element (see Section 6.22). This default policy will cause + the WTP to use the default QoS values for any station associated with + the WLAN in question. The AC MAY also override the policy for a + given station by sending the IEEE 802.11 Update Station QoS message + element (see Section 6.20), known as a station-specific QoS policy. + + Beyond the default, and per station QoS policy, the IEEE 802.11 + protocol also allows a station to request special QoS treatment for a + specific flow through the Traffic Specification (TSPEC) Information + Elements found in the IEEE 802.11-2007's QoS Action Frame. + Alternatively, stations MAY also use the WiFi Alliance's WMM + specification instead to request QoS treatment for a flow (see + [WMM]). This requires the WTP to observe the Status Code in the IEEE + 802.11-2007 and WMM QoS Action Add Traffic System (ADDTS) responses + from the AC, and provide the services requested in the TSPEC + Information Element. Similarly, the WTP MUST observe the Reason Code + Information Element in the IEEE 802.11-2007 and WMM QoS Action DELTS + responses from the AC by removing the policy associated with the + TSPEC. + + The IEEE 802.11 WTP Quality of Service message element's Tagging + Policy field indicates how the packets are to be tagged, known as the + Tagging Policy. There are five bits defined, two of which are used + to indicate the type of QoS to be used by the WTP. The first is the + 'P' bit, which is set to inform the WTP it is to use the 802.1p QoS + mechanism. When set, the 'Q' bit is used to inform the WTP which + 802.1p priority values it is to use. + + The 'D' bit is set to inform the WTP it is to use the Differentiated + Services Code Point (DSCP) QoS mechanism. When set, the 'I' and 'O' + bits are used to inform the WTP which values it is to use in the + inner header, in the station's original packet, or the outer header, + the latter of which is only valid when tunneling is enabled. + + + + +Calhoun, et al. Standards Track [Page 18] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + When an IEEE 802.11 Update Station QoS message element is received, + while the specific 802.1p priority or DSCP values may change for a + given station, known as the station specific policy, the original + Tagging Policy (the use of the five bits) remains the same. + + The use of the DSCP and 802.1p QoS mechanisms are not mutually + exclusive. An AC MAY request that a WTP use none, one, or both types + of QoS mechanisms at the same time. + +2.6.1.1. 802.1p Support + + The IEEE 802.11 WTP Quality of Service and IEEE 802.11 Update Station + QoS message elements include the "802.1p Tag" field, which is the + 802.1p priority value. This value is used by the WTP by adding an + 802.1Q header (see [IEEE.802-1Q.2005]) with the priority field set + according to the policy provided. Note that this tagging is only + valid for interfaces that support 802.1p. The actual treatment does + not change for either Split or Local MAC modes, or when tunneling is + used. The only exception is when tunneling is used, the 802.1Q + header is added to the outer packet (tunneled) header. The IEEE + 802.11 standard does not permit the station's packet to include an + 802.1Q header. Instead, the QoS mechanisms defined in the IEEE + 802.11 standard are used by stations to mark a packet's priority. + When the 'P' bit is set in the Tagging Policy, the 'Q' bit has the + following behavior: + + Q=1: The WTP marks the priority field in the 802.1Q header to + either the default or the station-specific 802.1p policy. + + Q=0: The WTP marks the priority field in the 802.1Q header to the + value found in the User Priority field of the QoS Control + field of the IEEE 802.11 header. If the QoS Control field is + not present in the IEEE 802.11 header, then the behavior + described under 'Q=1' is used. + +2.6.1.2. DSCP Support + + The IEEE 802.11 WTP Quality of Service and IEEE 802.11 Update Station + QoS message elements also provide a "DSCP Tag", which is used by the + WTP when the 'D' bit is set to mark the DSCP field of both the IPv4 + and IPv6 headers (see [RFC2474]). When DSCP is used, the WTP marks + the inner packet (the original packet received by the station) when + the 'I' bit is set. Similarly, the WTP marks the outer packet + (tunnel header's DSCP field) when the 'O' bit is set. + + When the 'D' bit is set, the treatment of the packet differs based on + whether the WTP is tunneling the station's packets to the AC. + Tunneling does not occur in a Local MAC mode when the AC has + + + +Calhoun, et al. Standards Track [Page 19] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + communicated that tunneling is not required, as part of the IEEE + 802.11 Add WLAN message element, see Section 6.1. In the case where + tunneling is not used, the 'I' and 'O' bits have the following + behaviors: + + O=1: This option is invalid when tunneling is not enabled for + station data frames. + + O=0: This option is invalid when tunneling is not enabled for + station data frames. + + I=1: The WTP sets the DSCP field in the station's packet to either + the default policy or the station-specific policy if one + exists. + + I=0: The WTP MUST NOT modify the DSCP field in the station's + packet. + + For Split MAC mode, or Local MAC with tunneling enabled, the WTP + needs to contend with both the inner packet (the station's original + packet) as well as the tunnel header (added by the WTP). In this + mode of operation, the bits are treated as follows: + + O=1: The WTP sets the DSCP field in the tunnel header to either the + default policy or the station specific policy if one exists. + + O=0: The WTP sets the DSCP field in the tunnel header to the value + found in the inner packet's DSCP field. If encryption + services are provided by the AC (see Section 6.15), the packet + is encrypted; therefore, the WTP cannot access the inner DSCP + field, in which case it uses the behavior described when the + 'O' bit is set. This occurs also if the inner packet is not + IPv4 or IPv6, and thus does not have a DSCP field. + + I=1: The WTP sets the DSCP field in the station's packet to either + the default policy or the station-specific policy if one + exists. If encryption services are provided by the AC (see + Section 6.15), the packet is encrypted; therefore, the WTP + cannot access the inner DSCP field, in which case it uses the + behavior described when the 'I' bit is not set. This occurs + also if the inner packet is not IPv4 or IPv6, and thus does + not have a DSCP field. + + I=0: The WTP MUST NOT modify the DSCP field in the station's + packet. + + + + + + +Calhoun, et al. Standards Track [Page 20] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + The CAPWAP protocol supports the Explicit Congestion Notification + (ECN) bits [RFC3168]. Additional details on ECN support can be found + in [RFC5415]. + +2.6.2. IEEE 802.11 MAC Management Messages + + It is recommended that IEEE 802.11 MAC Management frames be sent by + both the AC and the WTP with appropriate Quality of Service values, + listed below, to ensure that congestion in the network minimizes + occurrences of packet loss. Note that the QoS Mechanism specified in + the Tagging Policy is used as specified by the AC in the IEEE 802.11 + WTP Quality of Service message element (see Section 6.22). However, + the station-specific policy is not used for IEEE 802.11 MAC + Management frames. + + 802.1p: The precedence value of 7 (decimal) SHOULD be used for all + IEEE 802.11 MAC management frames, except for Probe + Requests, which SHOULD use 4. + + DSCP: All IEEE 802.11 MAC management frames SHOULD use the CS6 + per- hop behavior (see [RFC2474]), while IEEE 802.11 Probe + Requests should use the Low Drop Assured Forwarding per-hop + behavior (see [RFC3246]). + +2.7. Run State Operation + + The Run state is the normal state of operation for the CAPWAP + protocol in both the WTP and the AC. + + When the WTP receives a WLAN Configuration Request message (see + Section 3.1), it MUST respond with a WLAN Configuration Response + message (see Section 3.2), and it remains in the Run state. + + When the AC sends a WLAN Configuration Request message (see + Section 3.1) or receives the corresponding WLAN Configuration + Response message (see Section 3.2) from the WTP, it remains in the + Run state. + +3. IEEE 802.11 Specific CAPWAP Control Messages + + This section defines CAPWAP Control messages that are specific to the + IEEE 802.11 binding. Two messages are defined: IEEE 802.11 WLAN + Configuration Request and IEEE 802.11 WLAN Configuration Response. + See Section 4.5 in [RFC5415] for CAPWAP Control message definitions + and the derivation of the Message Type value from the IANA Enterprise + number. + + + + + +Calhoun, et al. Standards Track [Page 21] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + The valid message types for IEEE 802.11-specific control messages are + listed below. The IANA Enterprise number used with these messages is + 13277. + + CAPWAP Control Message Message Type + Value + + IEEE 802.11 WLAN Configuration Request 3398913 + IEEE 802.11 WLAN Configuration Response 3398914 + +3.1. IEEE 802.11 WLAN Configuration Request + + The IEEE 802.11 WLAN Configuration Request is sent by the AC to the + WTP in order to change services provided by the WTP. This control + message is used to either create, update, or delete a WLAN on the + WTP. + + The IEEE 802.11 WLAN Configuration Request is sent as a result of + either some manual administrative process (e.g., deleting a WLAN), or + automatically to create a WLAN on a WTP. When sent automatically to + create a WLAN, this control message is sent after the CAPWAP + Configuration Update Response message (see Section 8.5 in [RFC5415]) + has been received by the AC. + + Upon receiving this control message, the WTP will modify the + necessary services and transmit an IEEE 802.11 WLAN Configuration + Response. + + A WTP MAY provide service for more than one WLAN; therefore, every + WLAN is identified through a numerical index. For instance, a WTP + that is capable of supporting up to 16 Service Set Identifiers + (SSIDs), could accept up to 16 IEEE 802.11 WLAN Configuration Request + messages that include the Add WLAN message element. + + Since the index is the primary identifier for a WLAN, an AC MAY + attempt to ensure that the same WLAN is identified through the same + index number on all of its WTPs. An AC that does not follow this + approach MUST find some other means of maintaining a WLAN-Identifier- + to-SSID mapping table. + + The following message elements MAY be included in the IEEE 802.11 + WLAN Configuration Request message. Only one message element MUST be + present. + + o IEEE 802.11 Add WLAN, see Section 6.1 + + o IEEE 802.11 Delete WLAN, see Section 6.4 + + + + +Calhoun, et al. Standards Track [Page 22] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + o IEEE 802.11 Update WLAN, see Section 6.21 + + The following message element MAY be present. + + o IEEE 802.11 Information Element, see Section 6.6 + + o Vendor-Specific Payload, see [RFC5415] + +3.2. IEEE 802.11 WLAN Configuration Response + + The IEEE 802.11 WLAN Configuration Response message is sent by the + WTP to the AC. It is used to acknowledge receipt of an IEEE 802.11 + WLAN Configuration Request message, and to indicate that the + requested configuration was successfully applied or that an error + related to the processing of the IEEE 802.11 WLAN Configuration + Request message occurred on the WTP. + + The following message element MUST be included in the IEEE 802.11 + WLAN Configuration Response message. + + o Result Code, see Section 4.6.34 in [RFC5415] + + The following message element MAY be included in the IEEE 802.11 WLAN + Configuration Response message. + + o IEEE 802.11 Assigned WTP BSSID, see Section 6.3 + + o Vendor-Specific Payload, see [RFC5415] + +4. CAPWAP Data Message Bindings + + This section describes the CAPWAP data message bindings to support + transport of IEEE 802.11 frames. + + Payload encapsulation: The CAPWAP protocol defines the CAPWAP data + message, which is used to encapsulate a wireless payload. For + IEEE 802.11, the IEEE 802.11 header and payload are encapsulated + (excluding the IEEE 802.11 FCS checksum). The IEEE 802.11 FCS + checksum is handled by the WTP. This allows the WTP to validate + an IEEE 802.11 frame prior to sending it to the AC. Similarly, + when an AC wishes to transmit a frame to a station, the WTP + computes and adds the FCS checksum. + + Optional Wireless Specific Information: This optional CAPWAP header + field (see Section 4.3 in [RFC5415]) is only used with CAPWAP data + messages, and it serves two purposes, depending upon the direction + of the message. For messages from the WTP to the AC, the field + uses the format described in the "IEEE 802.11 Frame Info" field + + + +Calhoun, et al. Standards Track [Page 23] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + (see below). However, for messages sent by the AC to the WTP, the + format used is described in the "Destination WLANs" field (also + defined below). + + Note that in both cases, the two optional headers fit in the + "Data" field of the Wireless Specific Information header. + + IEEE 802.11 Frame Info: When an IEEE 802.11 frame is received from a + station over the air, it is encapsulated and this field is used to + include radio and PHY-specific information associated with the + frame. + + The IEEE 802.11 Frame Info field has the following format: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RSSI | SNR | Data Rate | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + RSSI: Received Signal Strength Indication (RSSI) is a signed, + 8-bit value. It is the received signal strength indication, in + dBm. + + SNR: SNR is a signed, 8-bit value. It is the signal-to-noise + ratio of the received IEEE 802.11 frame, in dB. + + Data Rate: The data rate field is a 16-bit unsigned value. The + data rate field is a 16-bit unsigned value expressing the data + rate of the packets received by the WTP in units of 0.1 Mbps. + For instance, a packet received at 5.5 Mbps would be set to 55, + while 11 Mbps would be set to 110. + + Destination WLANs: The Destination WLANs field is used to specify + the target WLANs for a given frame, and is only used with + broadcast and multicast frames. This field allows the AC to + transmit a single broadcast or multicast frame to the WTP and + allows the WTP to perform the necessary frame replication. The + field uses the following format: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | WLAN ID bitmap | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + +Calhoun, et al. Standards Track [Page 24] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + WLAN ID bitmap: This bit field indicates the WLAN ID (see + Section 6.1) on which the WTP will transmit the included frame. + For instance, if a multicast packet is to be transmitted on + WLANs 1 and 3, the bits for WLAN 1 and 3 of this field would be + enabled. WLAN 1 is represented by bit 15 in the figure above, + or the least significant bit, while WLAN 16 would be + represented by bit zero (0), or the most significant bit, in + the figure. This field is to be set to all zeroes for unicast + packets and is unused if the WTP is not providing IEEE 802.11 + encryption. + + Reserved: All implementations complying with this protocol MUST + set to zero any bits that are reserved in the version of the + protocol supported by that implementation. Receivers MUST + ignore all bits not defined for the version of the protocol + they support. + +5. CAPWAP Control Message Bindings + + This section describes the IEEE 802.11-specific message elements + included in CAPWAP Control Messages. + +5.1. Discovery Request Message + + The following IEEE 802.11-specific message element MUST be included + in the CAPWAP Discovery Request Message. + + o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE + 802.11 WTP Radio Information message element MUST be present for + every radio in the WTP. + +5.2. Discovery Response Message + + The following IEEE 802.11-specific message element MUST be included + in the CAPWAP Discovery Response Message. + + o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE + 802.11 WTP Radio Information message element MUST be present for + every radio in the WTP. + +5.3. Primary Discovery Request Message + + The following IEEE 802.11 specific message element MUST be included + in the CAPWAP Primary Discovery Request message. + + o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE + 802.11 WTP Radio Information message element MUST be present for + every radio in the WTP. + + + +Calhoun, et al. Standards Track [Page 25] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + +5.4. Primary Discovery Response Message + + The following IEEE 802.11-specific message element MUST be included + in the CAPWAP Primary Discovery Response message. + + o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE + 802.11 WTP Radio Information message element MUST be present for + every radio in the WTP. + +5.5. Join Request Message + + The following IEEE 802.11-specific message element MUST be included + in the CAPWAP Join Request message. + + o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE + 802.11 WTP Radio Information message element MUST be present for + every radio in the WTP. + +5.6. Join Response Message + + The following IEEE 802.11-specific message element MUST be included + in the CAPWAP Join Response message. + + o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE + 802.11 WTP Radio Information message element MUST be present for + every radio in the WTP. + +5.7. Configuration Status Request Message + + The following IEEE 802.11-specific message elements MAY be included + in the CAPWAP Configuration Status Request message. More than one of + each message element listed MAY be included. + + o IEEE 802.11 Antenna, see Section 6.2 + + o IEEE 802.11 Direct Sequence Control, see Section 6.5 + + o IEEE 802.11 MAC Operation, see Section 6.7 + + o IEEE 802.11 Multi-Domain Capability, see Section 6.9 + + o IEEE 802.11 Orthogonal Frequency Division Multiplexing (OFDM) + Control, see Section 6.10 + + o IEEE 802.11 Supported Rates, see Section 6.17 + + o IEEE 802.11 Tx Power, see Section 6.18 + + + + +Calhoun, et al. Standards Track [Page 26] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + o IEEE 802.11 TX Power Level, see Section 6.19 + + o IEEE 802.11 WTP Radio Configuration, see Section 6.23 + + o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE + 802.11 WTP Radio Information message element MUST be present for + every radio in the WTP. + +5.8. Configuration Status Response Message + + The following IEEE 802.11 specific message elements MAY be included + in the CAPWAP Configuration Status Response Message. More than one + of each message element listed MAY be included. + + o IEEE 802.11 Antenna, see Section 6.2 + + o IEEE 802.11 Direct Sequence Control, see Section 6.5 + + o IEEE 802.11 MAC Operation, see Section 6.7 + + o IEEE 802.11 Multi-Domain Capability, see Section 6.9 + + o IEEE 802.11 OFDM Control, see Section 6.10 + + o IEEE 802.11 Rate Set, see Section 6.11 + + o IEEE 802.11 Supported Rates, see Section 6.17 + + o IEEE 802.11 Tx Power, see Section 6.18 + + o IEEE 802.11 WTP Quality of Service, see Section 6.22 + + o IEEE 802.11 WTP Radio Configuration, see Section 6.23 + +5.9. Configuration Update Request Message + + The following IEEE 802.11-specific message elements MAY be included + in the CAPWAP Configuration Update Request message. More than one of + each message element listed MAY be included. + + o IEEE 802.11 Antenna, see Section 6.2 + + o IEEE 802.11 Direct Sequence Control, see Section 6.5 + + o IEEE 802.11 MAC Operation, see Section 6.7 + + o IEEE 802.11 Multi-Domain Capability, see Section 6.9 + + + + +Calhoun, et al. Standards Track [Page 27] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + o IEEE 802.11 OFDM Control, see Section 6.10 + + o IEEE 802.11 Rate Set, see Section 6.11 + + o IEEE 802.11 RSNA Error Report from Station, see Section 6.12 + + o IEEE 802.11 Tx Power, see Section 6.18 + + o IEEE 802.11 WTP Quality of Service, see Section 6.22 + + o IEEE 802.11 WTP Radio Configuration, see Section 6.23 + +5.10. Station Configuration Request + + The following IEEE 802.11-specific message elements MAY be included + in the CAPWAP Station Configuration Request message. More than one + of each message element listed MAY be included. + + o IEEE 802.11 Station, see Section 6.13 + + o IEEE 802.11 Station Session Key, see Section 6.15 + + o IEEE 802.11 Station QoS Profile, see Section 6.14 + + o IEEE 802.11 Update Station Qos, see Section 6.20 + +5.11. Change State Event Request + + The following IEEE 802.11-specific message element MAY be included in + the CAPWAP Station Configuration Request message. + + o IEEE 802.11 WTP Radio Fail Alarm Indication, see Section 6.24 + +5.12. WTP Event Request + + The following IEEE 802.11-specific message elements MAY be included + in the CAPWAP WTP Event Request message. More than one of each + message element listed MAY be included. + + o IEEE 802.11 MIC Countermeasures, see Section 6.8 + + o IEEE 802.11 RSNA Error Report from Station, see Section 6.12 + + o IEEE 802.11 Statistics, see Section 6.16 + + + + + + + +Calhoun, et al. Standards Track [Page 28] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + +6. IEEE 802.11 Message Element Definitions + + The following IEEE 802.11-specific message elements are defined in + this section. + + IEEE 802.11 Message Element Type Value + + IEEE 802.11 Add WLAN 1024 + IEEE 802.11 Antenna 1025 + IEEE 802.11 Assigned WTP BSSID 1026 + IEEE 802.11 Delete WLAN 1027 + IEEE 802.11 Direct Sequence Control 1028 + IEEE 802.11 Information Element 1029 + IEEE 802.11 MAC Operation 1030 + IEEE 802.11 MIC Countermeasures 1031 + IEEE 802.11 Multi-Domain Capability 1032 + IEEE 802.11 OFDM Control 1033 + IEEE 802.11 Rate Set 1034 + IEEE 802.11 RSNA Error Report From Station 1035 + IEEE 802.11 Station 1036 + IEEE 802.11 Station QoS Profile 1037 + IEEE 802.11 Station Session Key 1038 + IEEE 802.11 Statistics 1039 + IEEE 802.11 Supported Rates 1040 + IEEE 802.11 Tx Power 1041 + IEEE 802.11 Tx Power Level 1042 + IEEE 802.11 Update Station QoS 1043 + IEEE 802.11 Update WLAN 1044 + IEEE 802.11 WTP Quality of Service 1045 + IEEE 802.11 WTP Radio Configuration 1046 + IEEE 802.11 WTP Radio Fail Alarm Indication 1047 + IEEE 802.11 WTP Radio Information 1048 + + Figure 8: IEEE 802.11 Binding Message Elements + +6.1. IEEE 802.11 Add WLAN + + The IEEE 802.11 Add WLAN message element is used by the AC to define + a WLAN on the WTP. The inclusion of this message element MUST also + include IEEE 802.11 Information Element message elements, containing + the following IEEE 802.11 IEs: + + Power Constraint information element + + EDCA Parameter Set information element + + QoS Capability information element + + + + +Calhoun, et al. Standards Track [Page 29] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + WPA information element [WPA] + + RSN information element + + WMM information element [WMM] + + These IEEE 802.11 Information Elements are stored by the WTP and + included in any Probe Responses and Beacons generated, as specified + in the IEEE 802.11 standard [IEEE.802-11.2007]. If present, the RSN + Information Element is sent with the IEEE 802.11 Add WLAN message + element to instruct the WTP on the usage of the Key field. + + If cryptographic services are provided at the WTP, the WTP MUST + observe the algorithm dictated in the Group Cipher Suite field of the + RSN Information Element sent by the AC. The RSN Information Element + is used to communicate any supported algorithm, including WEP, + Temporal Key Integrity Protocol (TKIP) and AES-CCMP. In the case of + static WEP keys, the RSN Information Element is still used to + indicate the cryptographic algorithm even though no key exchange + occurred. + + An AC MAY include additional Information Elements as desired. The + message element uses the following format: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Radio ID | WLAN ID | Capability | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key Index | Key Status | Key Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Group TSC | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Group TSC | QoS | Auth Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MAC Mode | Tunnel Mode | Suppress SSID | SSID ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 1024 for IEEE 802.11 Add WLAN + + Length: >= 20 + + Radio ID: An 8-bit value representing the radio, whose value is + between one (1) and 31. + + + + + +Calhoun, et al. Standards Track [Page 30] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + WLAN ID: An 8-bit value specifying the WLAN Identifier. The value + MUST be between one (1) and 16. + + Capability: A 16-bit value containing the Capability information + field to be advertised by the WTP in the Probe Request and Beacon + frames. Each bit of the Capability field represents a different + WTP capability, which are described in detail in + [IEEE.802-11.2007]. The format of the field is: + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |E|I|C|F|P|S|B|A|M|Q|T|D|V|O|K|L| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + E (ESS): The AC MUST set the Extended Service Set (ESS) subfield + to 1. + + I (IBSS): The AC MUST set the Independent Basic Service Set + (IBSS) subfield to 0. + + C (CF-Pollable): The AC sets the Contention Free Pollable (CF- + Pollable) subfield based on the table found in + [IEEE.802-11.2007]. + + F (CF-Poll Request): The AC sets the CF-Poll Request subfield + based on the table found in [IEEE.802-11.2007]. + + P (Privacy): The AC sets the Privacy subfield based on the + confidentiality requirements of the WLAN, as defined in + [IEEE.802-11.2007]. + + S (Short Preamble): The AC sets the Short Preamble subfield + based on whether the use of short preambles is permitted on the + WLAN, as defined in [IEEE.802-11.2007]. + + B (PBCC): The AC sets the Packet Binary Convolutional Code + (PBCC) modulation option subfield based on whether the use of + PBCC is permitted on the WLAN, as defined in [IEEE.802-11.2007]. + + A (Channel Agility): The AC sets the Channel Agility subfield + based on whether the WTP is capable of supporting the High Rate + Direct Sequence Spread Spectrum (HR/DSSS), as defined in + [IEEE.802-11.2007]. + + + + + + + +Calhoun, et al. Standards Track [Page 31] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + M (Spectrum Management): The AC sets the Spectrum Management + subfield according to the value of the + dot11SpectrumManagementRequired MIB variable, as defined in + [IEEE.802-11.2007]. + + Q (QoS): The AC sets the Quality of Service (QoS) subfield based + on the table found in [IEEE.802-11.2007]. + + T (Short Slot Time): The AC sets the Short Slot Time subfield + according to the value of the WTP's currently used slot time + value, as defined in [IEEE.802-11.2007]. + + D (APSD): The AC sets the Automatic Power Save Delivery (APSD) + subfield according to the value of the + dot11APSDOptionImplemented Management Information Base (MIB) + variable, as defined in [IEEE.802-11.2007]. + + V (Reserved): The AC sets the Reserved subfield to zero, as + defined in [IEEE.802-11.2007]. + + O (DSSS-OFDM): The AC sets the DSSS-OFDM subfield to indicate + the use of Direct Sequence Spread Spectrum with Orthogonal + Frequency Division Multiplexing (DSSS-OFDM), as defined in + [IEEE.802-11.2007]. + + K (Delayed Block ACK): The AC sets the Delayed Block ACK + subfield according to the value of the + dot11DelayedBlockAckOptionImplemented MIB variable, as defined + in [IEEE.802-11.2007]. + + L (Immediate Block ACK): The AC sets the Delayed Block ACK + subfield according to the value of the + dot11ImmediateBlockAckOptionImplemented MIB variable, as defined + in [IEEE.802-11.2007]. + + Key-Index: The Key Index associated with the key. + + Key Status: A 1-byte value that specifies the state and usage of + the key that has been included. Note this field is ignored if the + Key Length field is set to zero (0). The following values + describe the key usage and its status: + + 0 - A value of zero, with the inclusion of the RSN Information + Element means that the WLAN uses per-station encryption keys, + and therefore the key in the 'Key' field is only used for + multicast traffic. + + + + + +Calhoun, et al. Standards Track [Page 32] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + 1 - When set to one, the WLAN employs a shared Wired Equivalent + Privacy (WEP) key, also known as a static WEP key, and uses + the encryption key for both unicast and multicast traffic for + all stations. + + 2 - The value of 2 indicates that the AC will begin rekeying the + GTK with the STA's in the BSS. It is only valid when IEEE + 802.11 is enabled as the security policy for the BSS. + + 3 - The value of 3 indicates that the AC has completed rekeying + the GTK and broadcast packets no longer need to be duplicated + and transmitted with both GTK's. + + Key Length: A 16-bit value representing the length of the Key + field. + + Key: A Session Key, whose length is known via the Key Length field, + used to provide data privacy. For encryption schemes that employ + a separate encryption key for unicast and multicast traffic, the + key included here only applies to multicast frames, and the cipher + suite is specified in an accompanied RSN Information Element. In + these scenarios, the key and cipher information is communicated + via the Add Station message element, see Section 4.6.8 in + [RFC5415] and the IEEE 802.11 Station Session Key message element, + see Section 6.15. When used with WEP, the key field includes the + broadcast key. When used with CCMP, the Key field includes the + 128-bit Group Temporal Key. When used with TKIP, the Key field + includes the 256-bit Group Temporal Key (which consists of a 128- + bit key used as input for TKIP key mixing, and two 64-bit keys + used for Michael). + + Group TSC: A 48-bit value containing the Transmit Sequence Counter + (TSC) for the updated group key. The WTP will set the TSC for + broadcast/multicast frames to this value for the updated group + key. + + QoS: An 8-bit value specifying the default QoS policy for the WTP + to apply to network traffic received for a non-WMM enabled STA. + + The following enumerated values are supported: + + 0 - Best Effort + + 1 - Video + + + + + + + +Calhoun, et al. Standards Track [Page 33] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + 2 - Voice + + 3 - Background + + Auth Type: An 8-bit value specifying the supported authentication + type. + + The following enumerated values are supported: + + 0 - Open System + + 1 - WEP Shared Key + + MAC Mode: This field specifies whether the WTP should support the + WLAN in Local or Split MAC mode. Note that the AC MUST NOT + request a mode of operation that was not advertised by the WTP + during the discovery process (see Section 4.6.43 in [RFC5415]). + The following enumerated values are supported: + + 0 - Local MAC: Service for the WLAN is to be provided in Local + MAC mode. + + 1 - Split MAC: Service for the WLAN is to be provided in Split + MAC mode. + + Tunnel Mode: This field specifies the frame tunneling type to be + used for 802.11 data frames from all stations associated with the + WLAN. The AC MUST NOT request a mode of operation that was not + advertised by the WTP during the discovery process (see Section + 4.6.42 in [RFC5415]). All IEEE 802.11 management frames MUST be + tunneled using 802.11 Tunnel mode. The following enumerated + values are supported: + + 0 - Local Bridging: All user traffic is to be locally bridged. + + 1 - 802.3 Tunnel: All user traffic is to be tunneled to the AC + in 802.3 format (see Section 4.4.2 in [RFC5415]). Note that + this option MUST NOT be selected with Split MAC mode. + + 2 - 802.11 Tunnel: All user traffic is to be tunneled to the AC + in 802.11 format. + + Suppress SSID: A boolean indicating whether the SSID is to be + advertised by the WTP. A value of zero suppresses the SSID in the + 802.11 Beacon and Probe Response frames, while a value of one will + cause the WTP to populate the field. + + + + + +Calhoun, et al. Standards Track [Page 34] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + SSID: The SSID attribute is the service set identifier that will be + advertised by the WTP for this WLAN. The SSID field contains any + ASCII character and MUST NOT exceed 32 octets in length, as + defined in [IEEE.802-11.2007]. + +6.2. IEEE 802.11 Antenna + + The IEEE 802.11 Antenna message element is communicated by the WTP to + the AC to provide information on the antennas available. The AC MAY + use this element to reconfigure the WTP's antennas. The message + element contains the following fields: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Radio ID | Diversity | Combiner | Antenna Cnt | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Antenna Selection... + +-+-+-+-+-+-+-+-+ + + Type: 1025 for IEEE 802.11 Antenna + + Length: >= 5 + + Radio ID: An 8-bit value representing the radio to configure, whose + value is between one (1) and 31. + + Diversity: An 8-bit value specifying whether the antenna is to + provide receiver diversity. The value of this field is the same + as the IEEE 802.11 dot11DiversitySelectionRx MIB element, see + [IEEE.802-11.2007]. The following enumerated values are + supported: + + 0 - Disabled + + 1 - Enabled (may only be true if the antenna can be used as a + receiving antenna) + + Combiner: An 8-bit value specifying the combiner selection. The + following enumerated values are supported: + + 1 - Sectorized (Left) + + 2 - Sectorized (Right) + + + + + + + +Calhoun, et al. Standards Track [Page 35] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + 3 - Omni + + 4 - Multiple Input/Multiple Output (MIMO) + + Antenna Count: An 8-bit value specifying the number of Antenna + Selection fields. This value SHOULD be the same as the one found + in the IEEE 802.11 dot11CurrentTxAntenna MIB element (see + [IEEE.802-11.2007]). + + Antenna Selection: One 8-bit antenna configuration value per + antenna in the WTP, containing up to 255 antennas. The following + enumerated values are supported: + + 1 - Internal Antenna + + 2 - External Antenna + +6.3. IEEE 802.11 Assigned WTP BSSID + + The IEEE 802.11 Assigned WTP BSSID is only included by the WTP when + the IEEE 802.11 WLAN Configuration Request included the IEEE 802.11 + Add WLAN message element. The BSSID value field of this message + element contains the BSSID that has been assigned by the WTP, + enabling the WTP to perform its own BSSID assignment. + + The WTP is free to assign the BSSIDs the way it sees fit, but it is + highly recommended that the WTP assign the BSSID using the following + algorithm: BSSID = {base BSSID} + WLAN ID. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Radio ID | WLAN ID | BSSID + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | BSSID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 1026 for IEEE 802.11 Assigned WTP BSSID + + Length: 8 + + Radio ID: An 8-bit value representing the radio, whose value is + between one (1) and 31. + + WLAN ID: An 8-bit value specifying the WLAN Identifier. The value + MUST be between one (1) and 16. + + + + + +Calhoun, et al. Standards Track [Page 36] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + BSSID: The BSSID assigned by the WTP for the WLAN created as a + result of receiving an IEEE 802.11 Add WLAN. + +6.4. IEEE 802.11 Delete WLAN + + The IEEE 802.11 Delete WLAN message element is used to inform the WTP + that a previously created WLAN is to be deleted, and contains the + following fields: + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Radio ID | WLAN ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 1027 for IEEE 802.11 Delete WLAN + + Length: 2 + + Radio ID: An 8-bit value representing the radio, whose value is + between one (1) and 31. + + WLAN ID: An 8-bit value specifying the WLAN Identifier. The value + MUST be between one (1) and 16. + +6.5. IEEE 802.11 Direct Sequence Control + + The IEEE 802.11 Direct Sequence Control message element is a bi- + directional element. When sent by the WTP, it contains the current + state. When sent by the AC, the WTP MUST adhere to the values + provided. This element is only used for IEEE 802.11b radios. The + message element has the following fields. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Radio ID | Reserved | Current Chan | Current CCA | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Energy Detect Threshold | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 1028 for IEEE 802.11 Direct Sequence Control + + Length: 8 + + + + + + + +Calhoun, et al. Standards Track [Page 37] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + Radio ID: An 8-bit value representing the radio to configure, whose + value is between one (1) and 31. + + Reserved: All implementations complying with this protocol MUST set + to zero any bits that are reserved in the version of the protocol + supported by that implementation. Receivers MUST ignore all bits + not defined for the version of the protocol they support. + + Current Channel: This attribute contains the current operating + frequency channel of the Direct Sequence Spread Spectrum (DSSS) + PHY. This value comes from the IEEE 802.11 dot11CurrentChannel + MIB element (see [IEEE.802-11.2007]). + + Current CCA: The current Clear Channel Assessment (CCA) method in + operation, whose value can be found in the IEEE 802.11 + dot11CCAModeSupported MIB element (see [IEEE.802-11.2007]). Valid + values are: + + 1 - energy detect only (edonly) + + 2 - carrier sense only (csonly) + + 4 - carrier sense and energy detect (edandcs) + + 8 - carrier sense with timer (cswithtimer) + + 16 - high rate carrier sense and energy detect (hrcsanded) + + Energy Detect Threshold: The current Energy Detect Threshold being + used by the DSSS PHY. The value can be found in the IEEE 802.11 + dot11EDThreshold MIB element (see [IEEE.802-11.2007]). + +6.6. IEEE 802.11 Information Element + + The IEEE 802.11 Information Element is used to communicate any IE + defined in the IEEE 802.11 protocol. The data field contains the raw + IE as it would be included within an IEEE 802.11 MAC management + message. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Radio ID | WLAN ID |B|P| Reserved |Info Element... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + +Calhoun, et al. Standards Track [Page 38] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + Type: 1029 for IEEE 802.11 Information Element + + Length: >= 4 + + Radio ID: An 8-bit value representing the radio, whose value is + between one (1) and 31. + + WLAN ID: An 8-bit value specifying the WLAN Identifier. The value + MUST be between one (1) and 16. + + B: When set, the WTP is to include the Information Element in IEEE + 802.11 Beacons associated with the WLAN. + + P: When set, the WTP is to include the Information Element in Probe + Responses associated with the WLAN. + + Reserved: All implementations complying with this protocol MUST set + to zero any bits that are reserved in the version of the protocol + supported by that implementation. Receivers MUST ignore all bits + not defined for the version of the protocol they support. + + Info Element: The IEEE 802.11 Information Element, which includes + the type, length, and value field. + +6.7. IEEE 802.11 MAC Operation + + The IEEE 802.11 MAC Operation message element is sent by the AC to + set the IEEE 802.11 MAC parameters on the WTP, and contains the + following fields. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Radio ID | Reserved | RTS Threshold | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Short Retry | Long Retry | Fragmentation Threshold | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tx MSDU Lifetime | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Rx MSDU Lifetime | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 1030 for IEEE 802.11 MAC Operation + + Length: 16 + + + + + + +Calhoun, et al. Standards Track [Page 39] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + Radio ID: An 8-bit value representing the radio to configure, whose + value is between one (1) and 31. + + Reserved: All implementations complying with this protocol MUST set + to zero any bits that are reserved in the version of the protocol + supported by that implementation. Receivers MUST ignore all bits + not defined for the version of the protocol they support. + + RTS Threshold: This attribute indicates the number of octets in an + MAC Protocol Data Unit (MPDU), below which a Request To Send/Clear + To Send (RTS/CTS) handshake MUST NOT be performed. An RTS/CTS + handshake MUST be performed at the beginning of any frame exchange + sequence where the MPDU is of type Data or Management, the MPDU + has an individual address in the Address1 field, and the length of + the MPDU is greater than this threshold. Setting this attribute + to be larger than the maximum MSDU size MUST have the effect of + turning off the RTS/CTS handshake for frames of Data or Management + type transmitted by this STA. Setting this attribute to zero MUST + have the effect of turning on the RTS/CTS handshake for all frames + of Data or Management type transmitted by this STA. The default + value of this attribute MUST be 2347. The value of this field + comes from the IEEE 802.11 dot11RTSThreshold MIB element, (see + [IEEE.802-11.2007]). + + Short Retry: This attribute indicates the maximum number of + transmission attempts of a frame, the length of which is less than + or equal to RTSThreshold, that MUST be made before a failure + condition is indicated. The default value of this attribute MUST + be 7. The value of this field comes from the IEEE 802.11 + dot11ShortRetryLimit MIB element, (see [IEEE.802-11.2007]). + + Long Retry: This attribute indicates the maximum number of + transmission attempts of a frame, the length of which is greater + than dot11RTSThreshold, that MUST be made before a failure + condition is indicated. The default value of this attribute MUST + be 4. The value of this field comes from the IEEE 802.11 + dot11LongRetryLimit MIB element, (see [IEEE.802-11.2007]). + + Fragmentation Threshold: This attribute specifies the current + maximum size, in octets, of the MPDU that MAY be delivered to the + PHY. A MAC Service Data Unit (MSDU) MUST be broken into fragments + if its size exceeds the value of this attribute after adding MAC + headers and trailers. An MSDU or MAC Management Protocol Data + Unit (MMPDU) MUST be fragmented when the resulting frame has an + individual address in the Address1 field, and the length of the + frame is larger than this threshold. The default value for this + attribute MUST be the lesser of 2346 or the aMPDUMaxLength of the + attached PHY and MUST never exceed the lesser of 2346 or the + + + +Calhoun, et al. Standards Track [Page 40] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + aMPDUMaxLength of the attached PHY. The value of this attribute + MUST never be less than 256. The value of this field comes from + the IEEE 802.11 dot11FragmentationThreshold MIB element, (see + [IEEE.802-11.2007]). + + Tx MSDU Lifetime: This attribute specifies the elapsed time in Time + Units (TUs), after the initial transmission of an MSDU, after + which further attempts to transmit the MSDU MUST be terminated. + The default value of this attribute MUST be 512. The value of + this field comes from the IEEE 802.11 dot11MaxTransmitMSDULifetime + MIB element, (see [IEEE.802-11.2007]). + + Rx MSDU Lifetime: This attribute specifies the elapsed time in TU, + after the initial reception of a fragmented MMPDU or MSDU, after + which further attempts to reassemble the MMPDU or MSDU MUST be + terminated. The default value MUST be 512. The value of this + field comes from the IEEE 802.11 dot11MaxReceiveLifetime MIB + element, (see [IEEE.802-11.2007]). + +6.8. IEEE 802.11 MIC Countermeasures + + The IEEE 802.11 MIC Countermeasures message element is sent by the + WTP to the AC to indicate the occurrence of a MIC failure. For more + information on MIC failure events, see the + dot11RSNATKIPCounterMeasuresInvoked MIB element definition in + [IEEE.802-11.2007]. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Radio ID | WLAN ID | MAC Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MAC Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 1031 for IEEE 802.11 MIC Countermeasures + + Length: 8 + + Radio ID: The Radio Identifier, whose value is between one (1) and + 31, typically refers to some interface index on the WTP. + + WLAN ID: This 8-bit unsigned integer includes the WLAN Identifier, + on which the MIC failure occurred. The value MUST be between one + (1) and 16. + + + + + + +Calhoun, et al. Standards Track [Page 41] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + MAC Address: The MAC Address of the station that caused the MIC + failure. + +6.9. IEEE 802.11 Multi-Domain Capability + + The IEEE 802.11 Multi-Domain Capability message element is used by + the AC to inform the WTP of regulatory limits. The AC will transmit + one message element per frequency band to indicate the regulatory + constraints in that domain. The message element contains the + following fields. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Radio ID | Reserved | First Channel # | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Number of Channels | Max Tx Power Level | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 1032 for IEEE 802.11 Multi-Domain Capability + + Length: 8 + + Radio ID: An 8-bit value representing the radio to configure, whose + value is between one (1) and 31. + + Reserved: All implementations complying with this protocol MUST set + to zero any bits that are reserved in the version of the protocol + supported by that implementation. Receivers MUST ignore all bits + not defined for the version of the protocol they support. + + First Channel #: This attribute indicates the value of the lowest + channel number in the sub-band for the associated domain country + string. The value of this field comes from the IEEE 802.11 + dot11FirstChannelNumber MIB element (see [IEEE.802-11.2007]). + + Number of Channels: This attribute indicates the value of the total + number of channels allowed in the sub-band for the associated + domain country string (see Section 6.23). The value of this field + comes from the IEEE 802.11 dot11NumberofChannels MIB element (see + [IEEE.802-11.2007]). + + Max Tx Power Level: This attribute indicates the maximum transmit + power, in dBm, allowed in the sub-band for the associated domain + country string (see Section 6.23). The value of this field comes + from the IEEE 802.11 dot11MaximumTransmitPowerLevel MIB element + (see [IEEE.802-11.2007]). + + + + +Calhoun, et al. Standards Track [Page 42] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + +6.10. IEEE 802.11 OFDM Control + + The IEEE 802.11 Orthogonal Frequency Division Multiplexing (OFDM) + Control message element is a bi-directional element. When sent by + the WTP, it contains the current state. When sent by the AC, the WTP + MUST adhere to the received values. This message element is only + used for 802.11a radios and contains the following fields: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Radio ID | Reserved | Current Chan | Band Support | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | TI Threshold | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 1033 for IEEE 802.11 OFDM Control + + Length: 8 + + Radio ID: An 8-bit value representing the radio to configure, whose + value is between one (1) and 31. + + Reserved: All implementations complying with this protocol MUST set + to zero any bits that are reserved in the version of the protocol + supported by that implementation. Receivers MUST ignore all bits + not defined for the version of the protocol they support. + + Current Channel: This attribute contains the current operating + frequency channel of the OFDM PHY. The value of this field comes + from the IEEE 802.11 dot11CurrentFrequency MIB element (see + [IEEE.802-11.2007]). + + Band Supported: The capability of the OFDM PHY implementation to + operate in the three Unlicensed National Information + Infrastructure (U-NII) bands. The value of this field comes from + the IEEE 802.11 dot11FrequencyBandsSupported MIB element (see + [IEEE.802-11.2007]), coded as a bit field, whose values are: + + Bit 0 - capable of operating in the 5.15-5.25 GHz band + + Bit 1 - capable of operating in the 5.25-5.35 GHz band + + Bit 2 - capable of operating in the 5.725-5.825 GHz band + + + + + + + +Calhoun, et al. Standards Track [Page 43] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + Bit 3 - capable of operating in the 5.47-5.725 GHz band + + Bit 4 - capable of operating in the lower Japanese 5.25 GHz band + + Bit 5 - capable of operating in the 5.03-5.091 GHz band + + Bit 6 - capable of operating in the 4.94-4.99 GHz band + + For example, for an implementation capable of operating in the + 5.15-5.35 GHz bands, this attribute would take the value 3. + + TI Threshold: The threshold being used to detect a busy medium + (frequency). CCA MUST report a busy medium upon detecting the + RSSI above this threshold. The value of this field comes from the + IEEE 802.11 dot11TIThreshold MIB element (see [IEEE.802-11.2007]). + +6.11. IEEE 802.11 Rate Set + + The rate set message element value is sent by the AC and contains the + supported operational rates. It contains the following fields. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Radio ID | Rate Set... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 1034 for IEEE 802.11 Rate Set + + Length: >= 3 + + Radio ID: An 8-bit value representing the radio to configure, whose + value is between one (1) and 31. + + Rate Set: The AC generates the Rate Set that the WTP is to include + in its Beacon and Probe messages. The length of this field is + between 2 and 8 bytes. The value of this field comes from the + IEEE 802.11 dot11OperationalRateSet MIB element (see + [IEEE.802-11.2007]). + +6.12. IEEE 802.11 RSNA Error Report From Station + + The IEEE 802.11 RSN Error Report From Station message element is used + by a WTP to send RSN error reports to the AC. The WTP does not need + to transmit any reports that do not include any failures. The fields + from this message element come from the IEEE 802.11 + Dot11RSNAStatsEntry table, see [IEEE.802-11.2007]. + + + + +Calhoun, et al. Standards Track [Page 44] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Client MAC Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Client MAC Address | BSSID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | BSSID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Radio ID | WLAN ID | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | TKIP ICV Errors | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | TKIP Local MIC Failures | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | TKIP Remote MIC Failures | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | CCMP Replays | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | CCMP Decrypt Errors | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | TKIP Replays | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Type: 1035 for IEEE 802.11 RSNA Error Report From Station + + Length: 40 + + Client MAC Address: The Client MAC Address of the station. + + BSSID: The BSSID on which the failures are being reported. + + Radio ID: The Radio Identifier, whose value is between one (1) and + 31, typically refers to some interface index on the WTP. + + WLAN ID: The WLAN ID on which the RSNA failures are being reported. + The value MUST be between one (1) and 16. + + Reserved: All implementations complying with this protocol MUST set + to zero any bits that are reserved in the version of the protocol + supported by that implementation. Receivers MUST ignore all bits + not defined for the version of the protocol they support. + + + + + + + + +Calhoun, et al. Standards Track [Page 45] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + TKIP ICV Errors: A 32-bit value representing the number of Temporal + Key Integrity Protocol (TKIP) (as defined in [IEEE.802-11.2007]) + ICV errors encountered when decrypting packets from the station. + The value of this field comes from the IEEE 802.11 + dot11RSNAStatsTKIPICVErrors MIB element (see [IEEE.802-11.2007]). + + TKIP Local MIC Failures: A 32-bit value representing the number of + MIC failures encountered when checking the integrity of packets + received from the station. The value of this field comes from the + IEEE 802.11 dot11RSNAStatsTKIPLocalMICFailures MIB element (see + [IEEE.802-11.2007]). + + TKIP Remote MIC Failures: A 32-bit value representing the number of + MIC failures reported by the station encountered (possibly via the + EAPOL-Key frame). The value of this field comes from the IEEE + 802.11 dot11RSNAStatsTKIPRemoteMICFailures MIB element (see + [IEEE.802-11.2007]). + + CCMP Replays: A 32-bit value representing the number of CCMP MPDUs + discarded by the replay detection mechanism. The value of this + field comes from the IEEE 802.11 dot11RSNACCMPReplays MIB element + (see [IEEE.802-11.2007]). + + CCMP Decrypt Errors: A 32-bit value representing the number of CCMP + MDPUs discarded by the decryption algorithm. The value of this + field comes from the IEEE 802.11 dot11RSNACCMPDecryptErrors MIB + element (see [IEEE.802-11.2007]). + + TKIP Replays: A 32-bit value representing the number of TKIP + Replays detected in frames received from the station. The value + of this field comes from the IEEE 802.11 dot11RSNAStatsTKIPReplays + MIB element (see [IEEE.802-11.2007]). + +6.13. IEEE 802.11 Station + + The IEEE 802.11 Station message element accompanies the Add Station + message element, and is used to deliver IEEE 802.11 station policy + from the AC to the WTP. + + The latest IEEE 802.11 Station message element overrides any + previously received message elements. + + If the QoS field is set, the WTP MUST observe and provide policing of + the 802.11e priority tag to ensure that it does not exceed the value + provided by the AC. + + + + + + +Calhoun, et al. Standards Track [Page 46] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Radio ID | Association ID | Flags | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MAC Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MAC Address | Capabilities | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | WLAN ID |Supported Rates| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 1036 for IEEE 802.11 Station + + Length: >= 14 + + Radio ID: An 8-bit value representing the radio, whose value is + between one (1) and 31. + + Association ID: A 16-bit value specifying the IEEE 802.11 + Association Identifier. + + Flags: All implementations complying with this protocol MUST set to + zero any bits that are reserved in the version of the protocol + supported by that implementation. Receivers MUST ignore all bits + not defined for the version of the protocol they support. + + MAC Address: The station's MAC Address + + Capabilities: A 16-bit field containing the IEEE 802.11 + Capabilities Information Field to use with the station. + + WLAN ID: An 8-bit value specifying the WLAN Identifier. The value + MUST be between one (1) and 16. + + Supported Rates: The variable-length field containing the supported + rates to be used with the station, as found in the IEEE 802.11 + dot11OperationalRateSet MIB element (see [IEEE.802-11.2007]). + This field MUST NOT exceed 126 octets and specifies the set of + data rates at which the station may transmit data, where each + octet represents a data rate. + +6.14. IEEE 802.11 Station QoS Profile + + The IEEE 802.11 Station QoS Profile message element contains the + maximum IEEE 802.11e priority tag that may be used by the station. + Any packet received that exceeds the value encoded in this message + element MUST be tagged using the maximum value permitted by to the + + + +Calhoun, et al. Standards Track [Page 47] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + user. The priority tag MUST be between zero (0) and seven (7). This + message element MUST NOT be present without the IEEE 802.11 Station + (see Section 6.13) message element. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MAC Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MAC Address | Reserved |8021p| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 1037 for IEEE 802.11 Station QoS Profile + + Length: 8 + + MAC Address: The station's MAC Address + + Reserved: All implementations complying with this protocol MUST set + to zero any bits that are reserved in the version of the protocol + supported by that implementation. Receivers MUST ignore all bits + not defined for the version of the protocol they support. + + 8021p: The maximum 802.1p priority value that the WTP will allow in + the Traffic Identifier (TID) field in the extended 802.11e QoS + Data header. + +6.15. IEEE 802.11 Station Session Key + + The IEEE 802.11 Station Session Key message element is sent by the AC + to provision encryption keys, or to configure an access policy, on + the WTP. This message element MUST NOT be present without the IEEE + 802.11 Station (see Section 6.13) message element, and MUST NOT be + sent if the WTP had not specifically advertised support for the + requested encryption scheme, through the WTP Descriptor Message + Element's Encryption Capabilities field (see Section 8.1). + + When the Key field is non-zero in length, the RSN Information Element + MUST be sent along with the IEEE 802.11 Station Session Key in order + to instruct the WTP on the usage of the Key field. The WTP MUST + observe the Authentication and Key Management (AKM) field of the RSN + Information Element in order to identify the authentication protocol + to be enforced with the station. + + If cryptographic services are provided at the WTP, the WTP MUST + observe the algorithm dictated in the Pairwise Cipher Suite field of + the RSN Information Element sent by the AC. The RSN Information + Element included here is the one sent by the AC in the third message + + + +Calhoun, et al. Standards Track [Page 48] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + of the 4-Way Key Handshake, which specifies which cipher is to be + applied to provide encryption and decryption services with the + station. The RSN Information Element is used to communicate any + supported algorithm, including WEP, TKIP, and AES-CCMP. In the case + of static WEP keys, the RSN Information Element is still used to + indicate the cryptographic algorithm even though no key exchange + occurred. + + If the IEEE 802.11 Station Session Key message element's 'AKM-Only' + bit is set, the WTP MUST drop all IEEE 802.11 packets that are not + part of the Authentication and Key Management (AKM), such as EAP. + Note that AKM-Only MAY be set while an encryption key is in force, + requiring that the AKM packets be encrypted. Once the station has + successfully completed authentication via the AKM, the AC MUST send a + new Add Station message element to remove the AKM-Only restriction, + and optionally push the session key down to the WTP. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MAC Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MAC Address |A|C| Flags | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Pairwise TSC | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Pairwise TSC | Pairwise RSC | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Pairwise RSC | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key... + +-+-+-+-+-+-+-+- + + Type: 1038 for IEEE 802.11 Station Session Key + + Length: >= 25 + + MAC Address: The station's MAC Address + + Flags: All implementations complying with this protocol MUST set to + zero any bits that are reserved in the version of the protocol + supported by that implementation. Receivers MUST ignore all bits + not defined for the version of the protocol they support. The + following bits are defined: + + + + + + + +Calhoun, et al. Standards Track [Page 49] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + A: The 1-bit AKM-Only field is set by the AC to inform the WTP + that is MUST NOT accept any 802.11 Data Frames other than AKM + frames. This is the equivalent of the WTP's IEEE 802.1X port + for the station to be in the closed state. When set, the WTP + MUST drop any non-IEEE 802.1X packets it receives from the + station. + + C: The 1-bit field is set by the AC to inform the WTP that + encryption services will be provided by the AC. When set, + the WTP SHOULD police frames received from stations to ensure + that they are properly encrypted as specified in the RSN + Information Element, but does not need to take specific + cryptographic action on the frame. Similarly, for + transmitted frames, the WTP only needs to forward already + encrypted frames. Since packets received by the WTP will be + encrypted, the WTP cannot modify the contents of the packets, + including modifying the DSCP markings of the encapsulated + packet. In this case, this function would be the + responsibility of the AC. + + Pairwise TSC: The 6-byte Transmit Sequence Counter (TSC) field to + use for unicast packets transmitted to the station. + + Pairwise RSC: The 6-byte Receive Sequence Counter (RSC) to use for + unicast packets received from the station. + + Key: The pairwise key the WTP is to use when encrypting traffic to/ + from the station. The format of the keys differs based on the + crypto algorithm used. For unicast WEP keys, the Key field + consists of the actual unicast encryption key (note, this is used + when WEP is used in conjunction with 802.1X, and therefore a + unicast encryption key exists). When used with CCMP, the Key + field includes the 128-bit Temporal Key. When used with TKIP, the + Key field includes the 256-bit Temporal Key (which consists of a + 128-bit key used as input for TKIP key mixing, and two 64-bit keys + used for Michael). + +6.16. IEEE 802.11 Statistics + + The IEEE 802.11 Statistics message element is sent by the WTP to + transmit its current statistics, and it contains the following + fields. All of the fields in this message element are set to zero + upon WTP initialization. The fields will roll over when they reach + their maximum value of 4294967295. Due to the nature of each counter + representing different data points, the rollover event will vary + + + + + + +Calhoun, et al. Standards Track [Page 50] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + greatly across each field. Applications or human operators using + these counters need to be aware of the minimal possible times between + rollover events in order to make sure that no consecutive rollover + events are missed. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Radio ID | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tx Fragment Count | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Multicast Tx Count | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Failed Count | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Retry Count | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Multiple Retry Count | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Frame Duplicate Count | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RTS Success Count | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RTS Failure Count | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ACK Failure Count | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Rx Fragment Count | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Multicast RX Count | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | FCS Error Count | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tx Frame Count | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Decryption Errors | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Discarded QoS Fragment Count | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Associated Station Count | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | QoS CF Polls Received Count | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | QoS CF Polls Unused Count | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | QoS CF Polls Unusable Count | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + +Calhoun, et al. Standards Track [Page 51] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + Type: 1039 for IEEE 802.11 Statistics + + Length: 80 + + Radio ID: An 8-bit value representing the radio, whose value is + between one (1) and 31. + + Reserved: All implementations complying with this protocol MUST set + to zero any bits that are reserved in the version of the protocol + supported by that implementation. Receivers MUST ignore all bits + not defined for the version of the protocol they support. + + Tx Fragment Count: A 32-bit value representing the number of + fragmented frames transmitted. The value of this field comes from + the IEEE 802.11 dot11TransmittedFragmentCount MIB element (see + [IEEE.802-11.2007]). + + Multicast Tx Count: A 32-bit value representing the number of + multicast frames transmitted. The value of this field comes from + the IEEE 802.11 dot11MulticastTransmittedFrameCount MIB element + (see [IEEE.802-11.2007]). + + Failed Count: A 32-bit value representing the transmit excessive + retries. The value of this field comes from the IEEE 802.11 + dot11FailedCount MIB element (see [IEEE.802-11.2007]). + + Retry Count: A 32-bit value representing the number of transmit + retries. The value of this field comes from the IEEE 802.11 + dot11RetryCount MIB element (see [IEEE.802-11.2007]). + + Multiple Retry Count: A 32-bit value representing the number of + transmits that required more than one retry. The value of this + field comes from the IEEE 802.11 dot11MultipleRetryCount MIB + element (see [IEEE.802-11.2007]). + + Frame Duplicate Count: A 32-bit value representing the duplicate + frames received. The value of this field comes from the IEEE + 802.11 dot11FrameDuplicateCount MIB element (see + [IEEE.802-11.2007]). + + RTS Success Count: A 32-bit value representing the number of + successfully transmitted Ready To Send (RTS). The value of this + field comes from the IEEE 802.11 dot11RTSSuccessCount MIB element + (see [IEEE.802-11.2007]). + + + + + + + +Calhoun, et al. Standards Track [Page 52] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + RTS Failure Count: A 32-bit value representing the failed + transmitted RTS. The value of this field comes from the IEEE + 802.11 dot11RTSFailureCount MIB element (see [IEEE.802-11.2007]). + + ACK Failure Count: A 32-bit value representing the number of failed + acknowledgements. The value of this field comes from the IEEE + 802.11 dot11ACKFailureCount MIB element (see [IEEE.802-11.2007]). + + Rx Fragment Count: A 32-bit value representing the number of + fragmented frames received. The value of this field comes from + the IEEE 802.11 dot11ReceivedFragmentCount MIB element (see + [IEEE.802-11.2007]). + + Multicast RX Count: A 32-bit value representing the number of + multicast frames received. The value of this field comes from the + IEEE 802.11 dot11MulticastReceivedFrameCount MIB element (see + [IEEE.802-11.2007]). + + FCS Error Count: A 32-bit value representing the number of FCS + failures. The value of this field comes from the IEEE 802.11 + dot11FCSErrorCount MIB element (see [IEEE.802-11.2007]). + + Decryption Errors: A 32-bit value representing the number of + Decryption errors that occurred on the WTP. Note that this field + is only valid in cases where the WTP provides encryption/ + decryption services. The value of this field comes from the IEEE + 802.11 dot11WEPUndecryptableCount MIB element (see + [IEEE.802-11.2007]). + + Discarded QoS Fragment Count: A 32-bit value representing the + number of discarded QoS fragments received. The value of this + field comes from the IEEE 802.11 dot11QoSDiscardedFragmentCount + MIB element (see [IEEE.802-11.2007]). + + Associated Station Count: A 32-bit value representing the number of + number of associated stations. The value of this field comes from + the IEEE 802.11 dot11AssociatedStationCount MIB element (see + [IEEE.802-11.2007]). + + QoS CF Polls Received Count: A 32-bit value representing the number + of (+)CF-Polls received. The value of this field comes from the + IEEE 802.11 dot11QosCFPollsReceivedCount MIB element (see + [IEEE.802-11.2007]). + + QoS CF Polls Unused Count: A 32-bit value representing the number + of (+)CF-Polls that have been received, but not used. The value + of this field comes from the IEEE 802.11 + dot11QosCFPollsUnusedCount MIB element (see [IEEE.802-11.2007]). + + + +Calhoun, et al. Standards Track [Page 53] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + QoS CF Polls Unusable Count: A 32-bit value representing the number + of (+)CF-Polls that have been received, but could not be used due + to the Transmission Opportunity (TXOP) size being smaller than the + time that is required for one frame exchange sequence. The value + of this field comes from the IEEE 802.11 + dot11QosCFPollsUnusableCount MIB element (see [IEEE.802-11.2007]). + +6.17. IEEE 802.11 Supported Rates + + The IEEE 802.11 Supported Rates message element is sent by the WTP to + indicate the rates that it supports, and contains the following + fields. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Radio ID | Supported Rates... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 1040 for IEEE 802.11 Supported Rates + + Length: >= 3 + + Radio ID: An 8-bit value representing the radio, whose value is + between one (1) and 31. + + Supported Rates: The WTP includes the Supported Rates that its + hardware supports. The format is identical to the Rate Set + message element and is between 2 and 8 bytes in length. + +6.18. IEEE 802.11 Tx Power + + The IEEE 802.11 Tx Power message element value is bi-directional. + When sent by the WTP, it contains the current power level of the + radio in question. When sent by the AC, it contains the power level + to which the WTP MUST adhere. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Radio ID | Reserved | Current Tx Power | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 1041 for IEEE 802.11 Tx Power + + + + + + + +Calhoun, et al. Standards Track [Page 54] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + Length: 4 + + Radio ID: An 8-bit value representing the radio to configure, whose + value is between one (1) and 31. + + Reserved: All implementations complying with this protocol MUST set + to zero any bits that are reserved in the version of the protocol + supported by that implementation. Receivers MUST ignore all bits + not defined for the version of the protocol they support. + + Current Tx Power: This attribute contains the current transmit + output power in mW, as described in the dot11CurrentTxPowerLevel + MIB variable, see [IEEE.802-11.2007]. + +6.19. IEEE 802.11 Tx Power Level + + The IEEE 802.11 Tx Power Level message element is sent by the WTP and + contains the different power levels supported. The values found in + this message element are found in the IEEE 802.11 + Dot11PhyTxPowerEntry MIB table, see [IEEE.802-11.2007]. + + The value field contains the following: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Radio ID | Num Levels | Power Level [n] | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 1042 for IEEE 802.11 Tx Power Level + + Length: >= 4 + + Radio ID: An 8-bit value representing the radio to configure, whose + value is between one (1) and 31. + + Num Levels: The number of power level attributes. The value of + this field comes from the IEEE 802.11 + dot11NumberSupportedPowerLevels MIB element (see + [IEEE.802-11.2007]). + + Power Level: Each power level field contains a supported power + level, in mW. The value of this field comes from the + corresponding IEEE 802.11 dot11TxPowerLevel[n] MIB element, see + [IEEE.802-11.2007]. + + + + + + +Calhoun, et al. Standards Track [Page 55] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + +6.20. IEEE 802.11 Update Station QoS + + The IEEE 802.11 Update Station QoS message element is used to change + the Quality of Service policy on the WTP for a given station. The + QoS tags included in this message element are to be applied to + packets received at the WTP from the station indicated through the + MAC Address field. This message element overrides the default values + provided through the IEEE 802.11 WTP Quality of Service message + element (see Section 6.22). Any tagging performed by the WTP MUST be + directly applied to the packets received from the station, as well as + the CAPWAP tunnel, if the packets are tunneled to the AC. See + Section 2.6 for more information. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Radio ID | MAC Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MAC Address | QoS Sub-Element... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 1043 for IEEE 802.11 Update Station QoS + + Length: 8 + + Radio ID: The Radio Identifier, whose value is between one (1) and + 31, typically refers to some interface index on the WTP. + + MAC Address: The station's MAC Address. + + QoS Sub-Element: The IEEE 802.11 WTP Quality of Service message + element contains four QoS sub-elements, one for every QoS profile. + The order of the QoS profiles are Voice, Video, Best Effort, and + Background. + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved|8021p|RSV| DSCP Tag | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Reserved: All implementations complying with this protocol MUST + set to zero any bits that are reserved in the version of the + protocol supported by that implementation. Receivers MUST + ignore all bits not defined for the version of the protocol + they support. + + + + +Calhoun, et al. Standards Track [Page 56] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + 8021p: The 3-bit 802.1p priority value to use if packets are to + be IEEE 802.1p tagged. This field is used only if the 'P' bit + in the WTP Quality of Service message element was set; + otherwise, its contents MUST be ignored. + + RSV: All implementations complying with this protocol MUST set + to zero any bits that are reserved in the version of the + protocol supported by that implementation. Receivers MUST + ignore all bits not defined for the version of the protocol + they support. + + DSCP Tag: The 6-bit DSCP label to use if packets are eligible to + be DSCP tagged, specifically an IPv4 or IPv6 packet (see + [RFC2474]). This field is used only if the 'D' bit in the WTP + Quality of Service message element was set; otherwise, its + contents MUST be ignored. + +6.21. IEEE 802.11 Update WLAN + + The IEEE 802.11 Update WLAN message element is used by the AC to + define a wireless LAN on the WTP. The inclusion of this message + element MUST also include the IEEE 802.11 Information Element message + element, containing the following 802.11 IEs: + + Power Constraint information element + + WPA information element [WPA] + + RSN information element + + Enhanced Distributed Channel Access (EDCA) Parameter Set information + element + + QoS Capability information element + + WMM information element [WMM] + + These IEEE 802.11 Information Elements are stored by the WTP and + included in any Probe Responses and Beacons generated, as specified + in the IEEE 802.11 standard [IEEE.802-11.2007]. + + If cryptographic services are provided at the WTP, the WTP MUST + observe the algorithm dictated in the Group Cipher Suite field of the + RSN Information Element sent by the AC. The RSN Information Element + is used to communicate any supported algorithm, including WEP, TKIP, + and AES-CCMP. In the case of static WEP keys, the RSN Information + Element is still used to indicate the cryptographic algorithm even + though no key exchange occurred. + + + +Calhoun, et al. Standards Track [Page 57] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + The message element uses the following format: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Radio ID | WLAN ID | Capability | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key Index | Key Status | Key Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 1044 for IEEE 802.11 Update WLAN + + Length: >= 8 + + Radio ID: An 8-bit value representing the radio, whose value is + between one (1) and 31. + + WLAN ID: An 8-bit value specifying the WLAN Identifier. The value + MUST be between one (1) and 16. + + Capability: A 16-bit value containing the Capability information + field to be advertised by the WTP in the Probe Request and Beacon + frames. Each bit of the Capability field represents a different + WTP capability, which are described in detail in + [IEEE.802-11.2007]. The format of the field is: + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |E|I|C|F|P|S|B|A|M|Q|T|D|V|O|K|L| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + E (ESS): The AC MUST set the Extended Service Set (ESS) subfield + to 1. + + I (IBSS): The AC MUST set the Independent Basic Service Set + (IBSS) subfield to 0. + + C (CF-Pollable): The AC sets the Contention Free Pollable (CF- + Pollable) subfield based on the table found in + [IEEE.802-11.2007]. + + F (CF-Poll Request): The AC sets the CF-Poll Request subfield + based on the table found in [IEEE.802-11.2007]. + + + + + +Calhoun, et al. Standards Track [Page 58] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + P (Privacy): The AC sets the Privacy subfield based on the + confidentiality requirements of the WLAN, as defined in + [IEEE.802-11.2007]. + + S (Short Preamble): The AC sets the Short Preamble subfield + based on whether the use of short preambles are permitted on the + WLAN, as defined in [IEEE.802-11.2007]. + + B (PBCC): The AC sets the Packet Binary Convolutional Code + (PBCC) modulation option subfield based on whether the use of + PBCC is permitted on the WLAN, as defined in [IEEE.802-11.2007]. + + A (Channel Agility): The AC sets the Channel Agility subfield + based on whether the WTP is capable of supporting the High Rate + Direct Sequence Spread Spectrum (HR/DSSS), as defined in + [IEEE.802-11.2007]. + + M (Spectrum Management): The AC sets the Spectrum Management + subfield according to the value of the + dot11SpectrumManagementRequired MIB variable, as defined in + [IEEE.802-11.2007]. + + Q (QoS): The AC sets the Quality of Service (QoS) subfield based + on the table found in [IEEE.802-11.2007]. + + T (Short Slot Time): The AC sets the Short Slot Time subfield + according to the value of the WTP's currently used slot time + value, as defined in [IEEE.802-11.2007]. + + D (APSD): The AC sets the APSD subfield according to the value + of the dot11APSDOptionImplemented Management Information Base + (MIB) variable, as defined in [IEEE.802-11.2007]. + + V (Reserved): The AC sets the Reserved subfield to zero, as + defined in [IEEE.802-11.2007]. + + O (DSSS-OFDM): The AC sets the DSSS-OFDM subfield to indicate + the use of Direct Sequence Spread Spectrum with Orthogonal + Frequency Division Multiplexing (DSSS-OFDM), as defined in + [IEEE.802-11.2007]. + + K (Delayed Block ACK): The AC sets the Delayed Block ACK + subfield according to the value of the + dot11DelayedBlockAckOptionImplemented MIB variable, as defined + in [IEEE.802-11.2007]. + + + + + + +Calhoun, et al. Standards Track [Page 59] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + L (Immediate Block ACK): The AC sets the Delayed Block ACK + subfield according to the value of the + dot11ImmediateBlockAckOptionImplemented MIB variable, as defined + in [IEEE.802-11.2007]. + + Key-Index: The Key-Index associated with the key. + + Key Status: A 1-byte value that specifies the state and usage of + the key that has been included. The following values describe the + key usage and its status: + + 0 - A value of zero, with the inclusion of the RSN Information + Element means that the WLAN uses per-station encryption keys, + and therefore the key in the 'Key' field is only used for + multicast traffic. + + 1 - When set to one, the WLAN employs a shared WEP key, also + known as a static WEP key, and uses the encryption key for + both unicast and multicast traffic for all stations. + + 2 - The value of 2 indicates that the AC will begin rekeying the + GTK with the STA's in the BSS. It is only valid when IEEE + 802.11 is enabled as the security policy for the BSS. + + 3 - The value of 3 indicates that the AC has completed rekeying + the GTK and broadcast packets no longer need to be duplicated + and transmitted with both GTK's. + + Key Length: A 16-bit value representing the length of the Key + field. + + Key: A Session Key, whose length is known via the Key Length field, + used to provide data privacy. For static WEP keys, which is true + when the 'Key Status' bit is set to one, this key is used for both + unicast and multicast traffic. For encryption schemes that employ + a separate encryption key for unicast and multicast traffic, the + key included here only applies to multicast data, and the cipher + suite is specified in an accompanied RSN Information Element. In + these scenarios, the key, and cipher information, is communicated + via the Add Station message element, see Section 4.6.8 in + [RFC5415]. When used with WEP, the Key field includes the + broadcast key. When used with CCMP, the Key field includes the + 128-bit Group Temporal Key. When used with TKIP, the Key field + includes the 256-bit Group Temporal Key (which consists of a 128- + bit key used as input for TKIP key mixing, and two 64-bit keys + used for Michael). + + + + + +Calhoun, et al. Standards Track [Page 60] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + +6.22. IEEE 802.11 WTP Quality of Service + + The IEEE 802.11 WTP Quality of Service message element value is sent + by the AC to the WTP to communicate Quality of Service configuration + information. The QoS tags included in this message element are the + default QoS values to be applied to packets received by the WTP from + stations on a particular radio. Any tagging performed by the WTP + MUST be directly applied to the packets received from the station, as + well as the CAPWAP tunnel, if the packets are tunneled to the AC. + See Section 2.6 for more information. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Radio ID |Tagging Policy | QoS Sub-Element ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 1045 for IEEE 802.11 WTP Quality of Service + + Length: 34 + + Radio ID: The Radio Identifier, whose value is between one (1) and + 31, typically refers to some interface index on the WTP. + + Tagging Policy: A bit field indicating how the WTP is to mark + packets for QoS purposes. The required WTP behavior is defined in + Section 2.6.1. The field has the following format: + + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + |Rsvd |P|Q|D|O|I| + +-+-+-+-+-+-+-+-+ + + Rsvd: A set of reserved bits for future use. All implementations + complying with this protocol MUST set to zero any bits that are + reserved in the version of the protocol supported by that + implementation. Receivers MUST ignore all bits not defined for + the version of the protocol they support. + + P: When set, the WTP is to employ the 802.1p QoS mechanism (see + Section 2.6.1.1), and the WTP is to use the 'Q' bit. + + Q: When the 'P' bit is set, the 'Q' bit is used by the AC to + communicate to the WTP how 802.1p QoS is to be enforced. + Details on the behavior of the 'Q' bit are specified in + Section 2.6.1.1. + + + + + +Calhoun, et al. Standards Track [Page 61] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + D: When set, the WTP is to employ the DSCP QoS mechanism (see + Section 2.6.1.2), and the WTP is to use the 'O' and 'I' bits. + + O: When the 'D' bit is set, the 'O' bit is used by the AC to + communicate to the WTP how DSCP QoS is to be enforced on the + outer (tunneled) header. Details on the behavior of the 'O' + bit are specified in Section 2.6.1.2. + + I: When the 'D' bit is set, the 'I' bit is used by the AC to + communicate to the WTP how DSCP QoS is to be enforced on the + station's packet (inner) header. Details on the behavior of + the 'I' bit are specified in Section 2.6.1.2. + + QoS Sub-Element: The IEEE 802.11 WTP Quality of Service message + element contains four QoS sub-elements, one for every QoS profile. + The order of the QoS profiles are Voice, Video, Best Effort, and + Background. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Queue Depth | CWMin | CWMax | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | CWMax | AIFS | Reserved|8021p|RSV| DSCP Tag | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Queue Depth: The number of packets that can be on the specific + QoS transmit queue at any given time. + + CWMin: The Contention Window minimum (CWmin) value for the QoS + transmit queue. The value of this field comes from the IEEE + 802.11 dot11EDCATableCWMin MIB element (see + [IEEE.802-11.2007]). + + CWMax: The Contention Window maximum (CWmax) value for the QoS + transmit queue. The value of this field comes from the IEEE + 802.11 dot11EDCATableCWMax MIB element (see + [IEEE.802-11.2007]). + + AIFS: The Arbitration Inter Frame Spacing (AIFS) to use for the + QoS transmit queue. The value of this field comes from the + IEEE 802.11 dot11EDCATableAIFSN MIB element (see + [IEEE.802-11.2007]). + + + + + + + + +Calhoun, et al. Standards Track [Page 62] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + Reserved: All implementations complying with this protocol MUST + set to zero any bits that are reserved in the version of the + protocol supported by that implementation. Receivers MUST + ignore all bits not defined for the version of the protocol + they support. + + 8021p: The 3-bit 802.1p priority value to use if packets are to + be IEEE 802.1p tagged. This field is used only if the 'P' bit + is set; otherwise, its contents MUST be ignored. + + RSV: All implementations complying with this protocol MUST set + to zero any bits that are reserved in the version of the + protocol supported by that implementation. Receivers MUST + ignore all bits not defined for the version of the protocol + they support. + + DSCP Tag: The 6-bit DSCP label to use if packets are eligible to + be DSCP tagged, specifically an IPv4 or IPv6 packet (see + [RFC2474]). This field is used only if the 'D' bit is set; + otherwise, its contents MUST be ignored. + +6.23. IEEE 802.11 WTP Radio Configuration + + The IEEE 802.11 WTP WLAN Radio Configuration message element is used + by the AC to configure a Radio on the WTP, and by the WTP to deliver + its radio configuration to the AC. The message element value + contains the following fields: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Radio ID |Short Preamble| Num of BSSIDs | DTIM Period | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | BSSID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | BSSID | Beacon Period | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Country String | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 1046 for IEEE 802.11 WTP WLAN Radio Configuration + + Length: 16 + + Radio ID: An 8-bit value representing the radio to configure, whose + value is between one (1) and 31. + + + + + +Calhoun, et al. Standards Track [Page 63] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + Short Preamble: An 8-bit value indicating whether short preamble is + supported. The following enumerated values are currently + supported: + + 0 - Short preamble not supported. + + 1 - Short preamble is supported. + + BSSID: The WLAN Radio's base MAC Address. + + Number of BSSIDs: This attribute contains the maximum number of + BSSIDs supported by the WTP. This value restricts the number of + logical networks supported by the WTP, and is between 1 and 16. + + DTIM Period: This attribute specifies the number of Beacon + intervals that elapse between transmission of Beacons frames + containing a Traffic Indication Map (TIM) element whose Delivery + Traffic Indication Message (DTIM) Count field is 0. This value is + transmitted in the DTIM Period field of Beacon frames. The value + of this field comes from the IEEE 802.11 dot11DTIMPeriod MIB + element (see [IEEE.802-11.2007]). + + Beacon Period: This attribute specifies the number of Time Unit + (TU) that a station uses for scheduling Beacon transmissions. + This value is transmitted in Beacon and Probe Response frames. + The value of this field comes from the IEEE 802.11 + dot11BeaconPeriod MIB element (see [IEEE.802-11.2007]). + + Country String: This attribute identifies the country in which the + station is operating. The value of this field comes from the IEEE + 802.11 dot11CountryString MIB element (see [IEEE.802-11.2007]). + Some regulatory domains do not allow WTPs to have user + configurable country string, and require that it be a fixed value + during the manufacturing process. Therefore, WTP vendors that + wish to allow for the configuration of this field will need to + validate this behavior during its radio certification process. + Other WTP vendors may simply wish to treat this WTP configuration + parameter as read-only. The country strings can be found in + [ISO.3166-1]. + + The WTP and AC MAY ignore the value of this field, depending upon + regulatory requirements, for example to avoid classification as a + Software-Defined Radio. When this field is used, the first two + octets of this string is the two-character country string as + described in [ISO.3166-1], and the third octet MUST either be a + space, 'O', 'I', or X' as defined below. When the value of the + + + + + +Calhoun, et al. Standards Track [Page 64] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + third octet is 255 (HEX 0xff), the country string field is not + used, and MUST be ignored. The following are the possible values + for the third octet: + + 1. an ASCII space character, if the regulations under which the + station is operating encompass all environments in the + country, + + 2. an ASCII 'O' character, if the regulations under which the + station is operating are for an outdoor environment only, or + + 3. an ASCII 'I' character, if the regulations under which the + station is operating are for an indoor environment only, + + 4. an ASCII 'X' character, if the station is operating under a + non-country entity. The first two octets of the non-country + entity shall be two ASCII 'XX' characters, + + 5. a HEX 0xff character means that the country string field is + not used and MUST be ignored. + + Note that the last byte of the Country String MUST be set to NULL. + +6.24. IEEE 802.11 WTP Radio Fail Alarm Indication + + The IEEE 802.11 WTP Radio Fail Alarm Indication message element is + sent by the WTP to the AC when it detects a radio failure. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Radio ID | Type | Status | Pad | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 1047 for IEEE 802.11 WTP Radio Fail Alarm Indication + + Length: 4 + + Radio ID: The Radio Identifier, whose value is between one (1) and + 31, typically refers to some interface index on the WTP. + + Type: The type of radio failure detected. The following enumerated + values are supported: + + 1 - Receiver + + 2 - Transmitter + + + + +Calhoun, et al. Standards Track [Page 65] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + Status: An 8-bit boolean indicating whether the radio failure is + being reported or cleared. A value of zero is used to clear the + event, while a value of one is used to report the event. + + Pad: All implementations complying with version zero of this + protocol MUST set these bits to zero. Receivers MUST ignore all + bits not defined for the version of the protocol they support. + +6.25. IEEE 802.11 WTP Radio Information + + The IEEE 802.11 WTP Radio Information message element is used to + communicate the radio information for each IEEE 802.11 radio in the + WTP. The Discovery Request message, Primary Discovery Request + message, and Join Request message MUST include one such message + element per radio in the WTP. The Radio-Type field is used by the AC + in order to determine which IEEE 802.11 technology specific binding + is to be used with the WTP. + + The message element contains two fields, as shown below. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Radio ID | Radio Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Radio Type | + +-+-+-+-+-+-+-+-+ + + Type: 1048 for IEEE 802.11 WTP Radio Information + + Length: 5 + + Radio ID: The Radio Identifier, whose value is between one (1) and + 31, which typically refers to an interface index on the WTP. + + Radio Type: The type of radio present. Note this is a bit field + that is used to specify support for more than a single type of + PHY/MAC. The field has the following format: + + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + |Reservd|N|G|A|B| + +-+-+-+-+-+-+-+-+ + + + + + + + + +Calhoun, et al. Standards Track [Page 66] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + Reservd: A set of reserved bits for future use. All + implementations complying with this protocol MUST set to zero + any bits that are reserved in the version of the protocol + supported by that implementation. Receivers MUST ignore all + bits not defined for the version of the protocol they support. + + N: An IEEE 802.11n radio. + + G: An IEEE 802.11g radio. + + A: An IEEE 802.11a radio. + + B: An IEEE 802.11b radio. + +7. IEEE 802.11 Binding WTP Saved Variables + + This section contains the IEEE 802.11 binding specific variables that + SHOULD be saved in non-volatile memory on the WTP. + +7.1. IEEE80211AntennaInfo + + The WTP-per-radio antenna configuration, defined in Section 6.2. + +7.2. IEEE80211DSControl + + The WTP-per-radio Direct Sequence Control configuration, defined in + Section 6.5. + +7.3. IEEE80211MACOperation + + The WTP-per-radio MAC Operation configuration, defined in + Section 6.7. + +7.4. IEEE80211OFDMControl + + The WTP-per-radio OFDM MAC Operation configuration, defined in + Section 6.10. + +7.5. IEEE80211Rateset + + The WTP-per-radio Basic Rate Set configuration, defined in + Section 6.11. + +7.6. IEEE80211TxPower + + The WTP-per-radio Transmit Power configuration, defined in + Section 6.18. + + + + +Calhoun, et al. Standards Track [Page 67] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + +7.7. IEEE80211QoS + + The WTP-per-radio Quality of Service configuration, defined in + Section 6.22. + +7.8. IEEE80211RadioConfig + + The WTP-per-radio Radio Configuration, defined in Section 6.23. + +8. Technology Specific Message Element Values + + This section lists IEEE 802.11-specific values for the generic CAPWAP + message elements that include fields whose values are technology + specific. + +8.1. WTP Descriptor Message Element, Encryption Capabilities Field + + This specification defines two new bits for the WTP Descriptor's + Encryption Capabilities field, as defined in [RFC5415]. Note that + only the bits defined in this specification are described below. WEP + is not explicitly advertised as a WTP capability since all WTPs are + expected to support the encryption cipher. The format of the + Encryption Capabilities field is: + + 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | |A|T| | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + A: WTP supports AES-CCMP, as defined in [IEEE.802-11.2007]. + + T: WTP supports TKIP and Michael, as defined in [IEEE.802-11.2007] + and [WPA], respectively. + +9. Security Considerations + + This section describes security considerations for using IEEE 802.11 + with the CAPWAP protocol. A complete threat analysis of the CAPWAP + protocol can also be found in [RFC5418]. + +9.1. IEEE 802.11 Security + + When used with an IEEE 802.11 infrastructure with WEP encryption, the + CAPWAP protocol does not add any new vulnerabilities. Derived + Session Keys between the STA and WTP can be compromised, resulting in + + + + + +Calhoun, et al. Standards Track [Page 68] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + many well-documented attacks. Implementers SHOULD discourage the use + of WEP and encourage the use of technically-sound cryptographic + solutions such as those in an IEEE 802.11 RSN. + + STA authentication is performed using IEEE 802.lX, and consequently + EAP. Implementers SHOULD use EAP methods meeting the requirements + specified [RFC4017]. + + When used with IEEE 802.11 RSN security, the CAPWAP protocol may + introduce new vulnerabilities, depending on whether the link security + (packet encryption and integrity verification) is provided by the WTP + or the AC. When the link security function is provided by the AC, no + new security concerns are introduced. + + However, when the WTP provides link security, a new vulnerability + will exist when the following conditions are true: + + o The client is not the first to associate to the WTP/ESSID (i.e., + other clients are associated), a GTK already exists, and + + o traffic has been broadcast under the existing GTK. + + Under these circumstances, the receive sequence counter (KeyRSC) + associated with the GTK is non-zero, but because the AC anchors the + 4-way handshake with the client, the exact value of the KeyRSC is not + known when the AC constructs the message containing the GTK. The + client will update its Key RSC value to the current valid KeyRSC upon + receipt of a valid multicast/broadcast message, but prior to this, + previous multicast/broadcast traffic that was secured with the + existing GTK may be replayed, and the client will accept this traffic + as valid. + + Typically, busy networks will produce numerous multicast or broadcast + frames per second, so the window of opportunity with respect to such + replay is expected to be very small. In most conditions, it is + expected that replayed frames could be detected (and logged) by the + WTP. + + The only way to completely close this window is to provide the exact + KeyRSC value in message 3 of the 4-way handshake; any other approach + simply narrows the window to varying degrees. Given the low relative + threat level this presents, the additional complexity introduced by + providing the exact KeyRSC value is not warranted. That is, this + specification provides for a calculated risk in this regard. + + + + + + + +Calhoun, et al. Standards Track [Page 69] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + The AC SHOULD use an RSC of 0 when computing message-3 of the 4-way + 802.11i handshake, unless the AC has knowledge of a more optimal RSC + value to use. Mechanisms for determining a more optimal RSC value + are outside the scope of this specification. + +10. IANA Considerations + + This section details the actions IANA has taken per this + specification. There are numerous registries that have been be + created, and the contents, document action (see [RFC5226], and + registry format are all included below. Note that in cases where bit + fields are referred to, the bit numbering is left to right, where the + leftmost bit is labeled as bit zero (0). + +10.1. CAPWAP Wireless Binding Identifier + + This specification requires a value assigned from the Wireless + Binding Identifier namespace, defined in [RFC5415]. (1) has been + assigned (see Section 2.1, as it is used in implementations. + +10.2. CAPWAP IEEE 802.11 Message Types + + IANA created a new sub-registry in the existing CAPWAP Message Type + registry, which is defined in [RFC5415]. + + IANA created and maintains the CAPWAP IEEE 802.11 Message Types + sub-registry for all message types whose Enterprise Number is set to + 13277. The namespace is 8 bits (3398912-3399167), where the value + 3398912 is reserved and must not be assigned. The values 3398913 and + 3398914 are allocated in this specification, and can be found in + Section 3. Any new assignments of a CAPWAP IEEE 802.11 Message Type + (whose Enterprise Number is set to 13277) require an Expert Review. + The format of the registry maintained by IANA is as follows: + + CAPWAP IEEE 802.11 Message Type Reference + Control Message Value + +10.3. CAPWAP Message Element Type + + This specification defines new values to be registered to the + existing CAPWAP Message Element Type registry, defined in [RFC5415]. + The values used in this document, 1024 through 1048, as listed in + Figure 8 are recommended as implementations already exist that make + use of these values. + + + + + + + +Calhoun, et al. Standards Track [Page 70] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + +10.4. IEEE 802.11 Key Status + + The Key Status field in the IEEE 802.11 Add WLAN message element (see + Section 6.1) and IEEE 802.11 Update WLAN message element (see + Section 6.21) is used to provide information about the status of the + keying exchange. This document defines four values, zero (0) through + three (3), and the remaining values (4-255) are controlled and + maintained by IANA and requires an Expert Review. + +10.5. IEEE 802.11 QoS + + The QoS field in the IEEE 802.11 Add WLAN message element (see + Section 6.1) is used to configure a QoS policy for the WLAN. The + namespace is 8 bits (0-255), where the values zero (0) through three + (3) are allocated in this specification, and can be found in + Section 6.1. This namespace is managed by IANA and assignments + require an Expert Review. IANA created the IEEE 802.11 QoS registry, + whose format is: + + IEEE 802.11 QoS Type Value Reference + +10.6. IEEE 802.11 Auth Type + + The Auth Type field in the IEEE 802.11 Add WLAN message element (see + Section 6.1) is 8 bits and is used to configure the IEEE 802.11 + authentication policy for the WLAN. The namespace is 8 bits (0-255), + where the values zero (0) and one (1) are allocated in this + specification, and can be found in Section 6.1. This namespace is + managed by IANA and assignments require an Expert Review. IANA + created the IEEE 802.11 Auth Type registry, whose format is: + + IEEE 802.11 Auth Type Type Value Reference + +10.7. IEEE 802.11 Antenna Combiner + + The Combiner field in the IEEE 802.11 Antenna message element (see + Section 6.2) is used to provide information about the WTP's antennas. + The namespace is 8 bits (0-255), where the values one (1) through + four (4) are allocated in this specification, and can be found in + Section 6.2. This namespace is managed by IANA and assignments + require an Expert Review. IANA created the IEEE 802.11 Antenna + Combiner registry, whose format is: + + IEEE 802.11 Antenna Combiner Type Value Reference + + + + + + + +Calhoun, et al. Standards Track [Page 71] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + +10.8. IEEE 802.11 Antenna Selection + + The Antenna Selection field in the IEEE 802.11 Antenna message + element (see Section 6.2) is used to provide information about the + WTP's antennas. The namespace is 8 bits (0-255), where the values + zero (0) is reserved and used and the values one (1) through two (2) + are allocated in this specification, and can be found in Section 6.2. + This namespace is managed by IANA and assignments require an Expert + Review. IANA created the IEEE 802.11 Antenna Selection registry, + whose format is: + + IEEE 802.11 Antenna Selection Type Value Reference + +10.9. IEEE 802.11 Session Key Flags + + The flags field in the IEEE 802.11 Station Session Key message + element (see Section 6.15) is 16 bits and is used to configure the + session key association with the mobile device. This specification + defines bits zero (0) and one (1), while bits two (2) through fifteen + are reserved. The reserved bits are managed by IANA and assignment + requires an Expert Review. IANA created the IEEE 802.11 Session Key + Flags registry, whose format is: + + IEEE 802.11 Station Session Key Bit Position Reference + +10.10. IEEE 802.11 Tagging Policy + + The Tagging Policy field in the IEEE 802.11 WTP Quality of Service + message element (see Section 6.22) is 8 bits and is used to specify + how the CAPWAP Data Channel packets are to be tagged. This + specification defines bits three (3) through seven (7). The + remaining bits are managed by IANA and assignment requires an Expert + Review. IANA created the IEEE 802.11 Tagging Policy registry, whose + format is: + + IEEE 802.11 Tagging Policy Bit Position Reference + +10.11. IEEE 802.11 WTP Radio Fail + + The Type field in the IEEE 802.11 WTP Radio Fail Alarm Indication + message element (see Section 6.24) is used to provide information on + why a WTP's radio has failed. The namespace is 8 bits (0-255), where + the value zero (0) is reserved and unused, while the values one (1) + and two (2) are allocated in this specification, and can be found in + Section 6.24. This namespace is managed by IANA and assignments + require an Expert Review. IANA created the IEEE 802.11 WTP Radio + Fail registry, whose format is: + + + + +Calhoun, et al. Standards Track [Page 72] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + IEEE 802.11 WTP Radio Fail Type Value Reference + +10.12. IEEE 802.11 WTP Radio Type + + The Radio Type field in the IEEE 802.11 WTP Radio Information message + element (see Section 6.25) is 8 bits and is used to provide + information about the WTP's radio type. This specification defines + bits four (4) through seven (7). The remaining bits are managed by + IANA and assignment requires an Expert Review. IANA created the IEEE + 802.11 WTP Radio Type registry, whose format is: + + IEEE 802.11 WTP Radio Type Bit Position Reference + +10.13. WTP Encryption Capabilities + + The WTP Encryption Capabilities field in the WTP Descriptor message + element (see Section 8.1) is 16 bits and is used by the WTP to + indicate its IEEE 802.11 encryption capabilities. This specification + defines bits 12 and 13. The reserved bits are managed by IANA and + assignment requires an Expert Review. IANA created the IEEE 802.11 + Encryption Capabilities registry, whose format is: + + IEEE 802.11 Encryption Capabilities Bit Position Reference + +11. Acknowledgments + + The following individuals are acknowledged for their contributions to + this binding specification: Puneet Agarwal, Charles Clancy, Pasi + Eronen, Saravanan Govindan, Scott Kelly, Peter Nilsson, Bob O'Hara, + David Perkins, Margaret Wasserman, and Yong Zhang. + +12. References + +12.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to + Indicate Requirement Levels", BCP 14, RFC 2119, + March 1997. + + [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, + "Definition of the Differentiated Services Field + (DS Field) in the IPv4 and IPv6 Headers", + RFC 2474, December 1998. + + [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le + Boudec, J., Courtney, W., Davari, S., Firoiu, V., + and D. Stiliadis, "An Expedited Forwarding PHB + (Per-Hop Behavior)", RFC 3246, March 2002. + + + +Calhoun, et al. Standards Track [Page 73] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The + Addition of Explicit Congestion Notification + (ECN) to IP", RFC 3168, September 2001. + + [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, + J., and H. Levkowetz, "Extensible Authentication + Protocol (EAP)", RFC 3748, June 2004. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for + Writing an IANA Considerations Section in RFCs", + BCP 26, RFC 5226, May 2008. + + [FIPS.197.2001] National Institute of Standards and Technology, + "Advanced Encryption Standard (AES)", FIPS PUB + 197, November 2001, <http://csrc.nist.gov/ + publications/fips/fips197/fips-197.pdf>. + + [ISO.3166-1] ISO Standard, "International Organization for + Standardization, Codes for the representation of + names of countries and their subdivisions - Part + 1: Country codes", ISO Standard 3166-1:1997, + 1997. + + [IEEE.802-11.2007] "Information technology - Telecommunications and + information exchange between systems - Local and + metropolitan area networks - Specific + requirements - Part 11: Wireless LAN Medium + Access Control (MAC) and Physical Layer (PHY) + specifications", IEEE Standard 802.11, 2007, + <http://standards.ieee.org/getieee802/download/ + 802.11-2007.pdf>. + + [RFC5415] Montemurro, M., Stanley, D., and P. Calhoun, + "CAPWAP Protocol Specification", RFC 5415, March + 2009. + + [IEEE.802-1X.2004] "Information technology - Telecommunications and + information exchange between systems - Local and + metropolitan area networks - Specific + requirements - Port-Based Network Access + Control", IEEE Standard 802.1X, 2004, <http:// + standards.ieee.org/getieee802/download/ + 802.1X-2004.pdf>. + + + + + + + + +Calhoun, et al. Standards Track [Page 74] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + + [IEEE.802-1Q.2005] "Information technology - Telecommunications and + information exchange between systems - Local and + metropolitan area networks - Specific + requirements - Virtual Bridged Local Area + Networks", IEEE Standard 802.1Q, 2005, <http:// + standards.ieee.org/getieee802/download/ + 802.1Q-2005.pdf>. + +12.2. Informative References + + [RFC4017] Stanley, D., Walker, J., and B. Aboba, + "Extensible Authentication Protocol (EAP) Method + Requirements for Wireless LANs", RFC 4017, + March 2005. + + [RFC4118] Yang, L., Zerfos, P., and E. Sadot, "Architecture + Taxonomy for Control and Provisioning of Wireless + Access Points (CAPWAP)", RFC 4118, June 2005. + + [RFC5418] Kelly, S. and C. Clancy, "Control And + Provisioning for Wireless Access Points (CAPWAP) + Threat Analysis for IEEE 802.11 Deployments", + RFC 5418, March 2009. + + [WPA] "Deploying Wi-Fi Protected Access (WPA) and WPA2 + in the Enterprise", March 2005, <www.wi-fi.org>. + + [WMM] "Support for Multimedia Applications with Quality + of Service in WiFi Networks)", September 2004, + <www.wi-fi.org>. + + + + + + + + + + + + + + + + + + + + + +Calhoun, et al. Standards Track [Page 75] + +RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009 + + +Editors' Addresses + + Pat R. Calhoun (editor) + Cisco Systems, Inc. + 170 West Tasman Drive + San Jose, CA 95134 + + Phone: +1 408-902-3240 + EMail: pcalhoun@cisco.com + + + Michael P. Montemurro (editor) + Research In Motion + 5090 Commerce Blvd + Mississauga, ON L4W 5M4 + Canada + + Phone: +1 905-629-4746 x4999 + EMail: mmontemurro@rim.com + + + Dorothy Stanley (editor) + Aruba Networks + 1322 Crossman Ave + Sunnyvale, CA 94089 + + Phone: +1 630-363-1389 + EMail: dstanley@arubanetworks.com + + + + + + + + + + + + + + + + + + + + + + + +Calhoun, et al. Standards Track [Page 76] + |