RFC 5416
Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11
RFC 5416: CAPWAP Protocol Binding for IEEE 802.11 🦋
Okay bestie, this one is a Standards Track doc from March 2009 💅 Its full title is "Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11" and it's part of the Network Working Group series.
The authors are P. Calhoun (Ed.) from Cisco Systems, Inc., M. Montemurro (Ed.) from Research In Motion, and D. Stanley (Ed.) from Aruba Networks 🫶 (the "Ed." just means they edited it). Also, the header doesn't list any obsoletes or updates, so this RFC isn't replacing or patching anything 🌸
Status of This Memo ✨
This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements. For the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). 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, as they're in effect on the date this document was published (http://trustee.ietf.org/license-info). Read these carefully, because they spell out your rights and restrictions for this document. 📜
This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people controlling the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So, unless you get an adequate license from those copyright holders, 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. The exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌈
Abstract 🌸
Wireless LAN product architectures have leveled up from single autonomous access points to systems made of a centralized Access Controller (AC) and Wireless Termination Points (WTPs) 🔥 The big idea behind centralized control is to move access control, including user authentication and authorization, mobility management, and radio management, off the single access point and onto 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
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
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 ...................................751. Introduction 🦋
The CAPWAP protocol [RFC5415] defines an extensible protocol that lets an Access Controller manage wireless agnostic Wireless Termination Points. Here's the fun part: CAPWAP itself doesn't include any specific wireless technologies 🤯 Instead, it relies on a binding specification to extend it 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. It defines how CAPWAP control message fields, new control messages, and message elements are used. It also includes the minimum required definitions for a binding-specific Statistics message element, Station message element, and WTP Radio Information message element 💖
Quick reality check, though 🙈 This binding only supports the IEEE 802.11-2007 specification. It also does not support the ad hoc network mode defined in IEEE 802.11-2007. This spec also doesn't cover data frames with the four-address format, which people commonly call Wireless Bridges, since their use isn't specified in IEEE 802.11-2007. Right now, this protocol specification does not officially support IEEE 802.11n. That said, the protocol does let a WTP advertise support for an IEEE 802.11n radio. The catch is that it does not allow any of the protocol's additional features to be configured or used. New IEEE protocol specs published outside this document (e.g., IEEE 802.11v, IEEE 802.11r) aren't supported through this binding either. Along with IEEE 802.11n, those must be addressed through a separate CAPWAP binding or an update to this binding 🌸
Bestie, IEEE 802.11n, 802.11v, and 802.11r are all still on the to-do list ✨
Now for the backstory 📜 Standards for IEEE 802.11 were still being developed by the IEEE 802.11 standards body, and the market needed things right away. So the WiFi Alliance made interim pseudo-standards specifications. Two of them are widely used across the industry: the WiFi Protect Access [WPA] specification and the WiFi MultiMedia [WMM] specification. Because they've been adopted so widely, this CAPWAP binding requires the use of both of these specifications 👑
1.1. Goals ✨
Okay so the goals of this CAPWAP protocol binding are basically to bring CAPWAP's superpowers to IEEE 802.11 wireless networks 🦋 Here's the lineup, bestie:
- Centralize the auth and policy enforcement for an IEEE 802.11 wireless network. The AC may also handle centralized bridging, forwarding, and encryption of user traffic. This is giving reduced cost and higher efficiency, because you get to use network processing silicon on wireless the same way wired LANs already do 🔥
- Shift the higher-level protocol processing off the WTP. The time-critical stuff, meaning wireless control and access, stays on the WTP, so those cost-pressured WTPs can use their computing power really efficiently 💅
The CAPWAP protocol binding extensions defined here 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]. Read those capitalised ones very carefully, they're the important vibes 💜
1.3. Terminology
This section has definitions for terms that show up a lot in this doc. Plenty more definitions live in [IEEE.802-11.2007], so go check there too 🧚
- Access Controller (AC): the network entity that gives WTPs access to the network infrastructure in the data plane, the control plane, the management plane, or some combo of those 🎀
- Basic Service Set (BSS): a set of stations controlled by a single coordination function 🌸
- Distribution: the service that uses association information to deliver medium access control (MAC) service data units (MSDUs) within the distribution system (DS) 🦋
- Distribution System Service (DSS): the set of services the distribution system (DS) provides so the medium access control (MAC) layer can carry MSDUs between stations that aren't in direct communication with each other over a single instance of the wireless medium (WM). These include carrying MSDUs between the access points (APs) of basic service sets (BSSs) within an extended service set (ESS), carrying MSDUs between portals and BSSs within an ESS, and carrying MSDUs between stations in the same BSS when the MSDU has a multicast or broadcast destination address, or when the destination is an individual address but the sending station chooses to involve the DSS. DSSs are provided between pairs of IEEE 802.11 MACs. It's a whole thing, fr fr 💅
- 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 where 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 means a logical component instantiated on a WTP device. One physical WTP can 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 📡
2. IEEE 802.11 Binding 🌸
Okay this section is where it all comes together, bestie 🫶 It describes how CAPWAP works with the IEEE 802.11 Wireless Local Area Network protocol. That covers Local and Split MAC operation, Group Key Refresh, mapping Basic Service Set Identification (BSSID) to WLANs, Quality of Service (QoS) tagging for IEEE 802.11 MAC management frames, and Run State operation. So much to unpack, I'm obsessed 😭
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 defines the IEEE 802.11 binding, and it uses the value one (1) for its WBID 🎀
2.2. Split MAC and Local MAC Functionality
Here's the tea: when CAPWAP is used with IEEE 802.11 devices, it needs specific behavior from the WTP and the AC so the required IEEE 802.11 protocol functions actually work ✨
For both the Split and Local MAC approaches, the CAPWAP functions, as defined in the taxonomy specification [RFC4118], live 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 ✨
okay bestie, this part is all about how the work gets split between the WTP and the AC in a Split MAC setup 💅 Figure 1 shows who does what 🦋
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/ACFigure 1: Mapping of 802.11 Functions for Split MAC Architecture
In a Split MAC Architecture, the Distribution and Integration services live on the AC, so all user data gets tunneled between the WTP and the AC 🫶 As we said above, all the real-time IEEE 802.11 services, including the Beacon and Probe Response frames, are handled on the WTP 🧚
All the remaining IEEE 802.11 MAC management frames are supported on the AC, including the Association Request frame, which lets the AC get involved in the access policy enforcement part 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 also live on the AC 👑 which implies that the Authentication, Authorization, and Accounting (AAA) client also resides on the AC.
While the admission control component of IEEE 802.11 lives on the AC, the real-time scheduling and queuing functions are on the WTP. Note that this does not stop 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 shows a case where encryption services are provided by the AC.
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 gives a picture of the division of labor in a Split MAC architecture 🌈 In this example, a WLAN has been set up 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]). Here's what happens:
- 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.
- 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.
- The WTP forwards the IEEEE 802.11 Authentication and Association frames to the AC, which is responsible for responding to the client.
- 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. - 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).
- 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).
- 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).
- The WTP forwards any IEEE 802.11 Management Action frames received to the AC.
- 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 before 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 the AC. For downlink frames, the Protected Frame field MUST be set to 0 by the AC, since 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 💅
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: WTPFigure 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 🍓
⚠️ bestie, read that last bit twice: CAPWAP doesn't promise in-order delivery, so know that before you commit to it! 💜
2.2.2. Local MAC ✨
okay so this part is about how the work gets split up in a Local MAC setup 💅 the WTP and the AC each have their own jobs, and Figure 4 is basically the group chat seating chart for who does what 🎀
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 WTPFigure 4: Mapping of 802.11 Functions for Local AP Architecture 🌸
so in Local MAC mode the integration service lives on the WTP 🧚 the distribution service MAY sit on either the WTP or the AC 💖 and when it's on the AC, station-generated frames aren't sent over in their native format. they get wrapped up as 802.3 frames instead 🎁
bestie, this part is lowkey important 🫶 the MAC layer ends on the WTP, which means the AC has to know about mobility events happening on the WTPs. so 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 thinks that's needed, and if the WTP gets a failed Association Response 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] stuff all lives in the AC 👑 so the WTP MUST forward all IEEE 802.1X, EAP, and RSNA Key Management frames to the AC and then pass the matching responses back to the station 🔥 which also means the AAA client has to live on the AC too, iykyk 🙈
quick heads up: in the next figure, ( - ) means the frames are processed on the WTP 👀
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 walks through the Local MAC split. the example is a WLAN set up for IEEE 802.11 using AES-CCMP for privacy 🔐 here's how it goes:
- the WTP generates the IEEE 802.11 Beacon frames, using the info it gets through the Add WLAN (see Section 6.1) message element 📡
- the WTP handles a Probe Request frame and sends back the matching Probe Response frame 🌈
- the WTP forwards the IEEE 802.11 Authentication and Association frames to the AC 💌
- once the association is done, the AC sends a Station Configuration Request message with the Add Station message element to the WTP (see Section 4.6.8 in [RFC5415]) ✨ this WLAN was set up for IEEE 802.1X, so the IEEE 802.11 Station Session Key is included with the flag field's 'A' bit set 🎀
- the WTP forwards all IEEE 802.1X and IEEE 802.11 key exchange messages to the AC for processing 🔁
- the AC sends another Station Configuration Request message, which includes:
- an Add Station message element, which MAY include a Virtual LAN (VLAN) [IEEE.802-1Q.2005] name. when it's there, the WTP uses it to figure out which VLAN the user's data frames get bridged onto 🌸
- an IEEE 802.11 Add Station message element, which has the WLAN Identifier the station associated with 🧚
- an IEEE 802.11 Station Session Key message element, which has the pairwise encryption key 🔑
- an IEEE 802.11 Information Element message element, which carries the RSNIE to the WTP, saying which security policy to enforce for the client (in this case AES-CCMP) 🛡️
- the WTP forwards any IEEE 802.11 Management Action frames it receives to the AC 🫶
- the WTP MAY locally bridge client data frames (and handle the encryption and decryption too). the WTP MAY also tunnel client data frames to the AC, using either 802.3 frame tunnel mode or 802.11 frame tunnel mode 🚇
2.3. Roaming Behavior
this section builds on the examples from the last bit and explains how the CAPWAP control protocol keeps roaming secure 🦋
once a client has associated with the network securely, it's super likely to try roaming over to another WTP 🏃♀️ Figure 6 shows a station moving from its "Old WTP" to a "New WTP". this figure works for lots of different security policies, including IEEE 802.1X and Wireless Protected Access (WPA) or Wireless Protected Access 2 (WPA2) [WPA] 💜
if key caching was being used, the 802.1X Authentication step gets skipped entirely ⚡ also, this example has the WTP providing the crypto services. if the AC handled that instead, the last Station Configuration Request would look 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
every so often, the Group Key (GTK) for the BSS needs an update 🔄 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, every Layer 2 (L2) broadcast frame sent to the BSS has to be duplicated and sent using both the current GTK and the new GTK 👯♀️ once the GTK update is done, broadcast frames to the BSS get encrypted with the new GTK ✨
with Split MAC, the AC has to duplicate all broadcast packets and update the key index, so each packet goes out using both the current and new GTK. that way every STA in the BSS still gets the broadcast frames 📣 with Local MAC, the WTP needs to duplicate and send the broadcast frames using the right index, so all the STAs in the BSS keep receiving them 🫶
here's the Group Key update procedure in Figure 7 🎀 the AC signals the GTK update with an IEEE 802.11 Configuration Request message. it includes an IEEE 802.11 Update WLAN message element carrying the new GTK, its index, the Transmit Sequence Counter (TSC) for the Group Key, and the Key Status set to 3 (begin GTK update). then the AC starts updating the GTK for each STA. during that time, the AC (for Split MAC) or WTP (for Local MAC) MUST duplicate broadcast packets and send them encrypted with both the current and new GTK 🔁 when the AC has finished updating the GTK for all STAs in the BSS, the AC MUST transmit an IEEE 802.11 Configuration Request message with an IEEE 802.11 Update WLAN message element that has 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
okay so the CAPWAP binding lets the WTP assign BSSIDs when a WLAN gets created 🫶 (see Section 6.1). manufacturers can pick any method they want 💅, but it's advised that BSSIDs come as a contiguous block whenever possible 🧚
even with a block, implementations can still hand any of the available BSSIDs to any WLAN, so it's not locked to one order ✨ one possible method is for the WTP to compute the address as base BSSID address + WLAN ID 🍓
the WTP tells the AC the max number of BSSIDs it supports during configuration, using 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 has procedures so the WTP can enforce Quality of Service on IEEE 802.11 Data Frames and MAC Management messages 💖
2.6.1. IEEE 802.11 Data Frames
when a WLAN gets created on the WTP, a default QoS policy is set up through the IEEE 802.11 WTP Quality of Service message element (see Section 6.22) 🌸 this default makes the WTP use the default QoS values for any station associated with that WLAN ✨ 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), which is called a station-specific QoS policy 🦋
so beyond the default and the per-station policy, IEEE 802.11 also lets a station ask for special QoS treatment for a specific flow through the Traffic Specification (TSPEC) Information Elements in the IEEE 802.11-2007's QoS Action Frame 👑 stations MAY also use the WiFi Alliance's WMM specification to ask for QoS treatment for a flow instead (see [WMM]) 🌈 this means the WTP has to watch the Status Code in the IEEE 802.11-2007 and WMM QoS Action Add Traffic System (ADDTS) responses from the AC, and actually provide the services asked for in the TSPEC Information Element 😭 same deal for removal: the WTP MUST observe the Reason Code Information Element in the IEEE 802.11-2007 and WMM QoS Action DELTS responses from the AC and remove the policy tied to the TSPEC 💅
the IEEE 802.11 WTP Quality of Service message element has a Tagging Policy field that says how packets get tagged, called the Tagging Policy 🎀 there are five bits defined, and two of them pick the type of QoS the WTP uses 💜 the first is the 'P' bit, which is set to tell the WTP to use the 802.1p QoS mechanism 🦋 when that's set, the 'Q' bit tells the WTP which 802.1p priority values to use ✨
the 'D' bit is set to tell the WTP to use the Differentiated Services Code Point (DSCP) QoS mechanism 🌸 when it's set, the 'I' and 'O' bits tell the WTP which values to use in the inner header (the station's original packet) or the outer header 🫶 the outer one only counts when tunneling is enabled 💀
when an IEEE 802.11 Update Station QoS message element comes in, the 802.1p priority or DSCP values for that station can change, and that's the station specific policy 🔥 but the original Tagging Policy (the use of those five bits) stays exactly the same 🎀
the DSCP and 802.1p mechanisms are not mutually exclusive 🌈 an AC MAY ask a WTP to 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 an "802.1p Tag" field, which is the 802.1p priority value 🧚 the WTP uses it by adding an 802.1Q header (see [IEEE.802-1Q.2005]) with the priority field set to match the policy 💖 this tagging is only valid for interfaces that support 802.1p ⚠️ the actual treatment doesn't change for Split or Local MAC modes, or when tunneling is used 🌸 the one exception is when tunneling is used: then the 802.1Q header goes on the outer packet (tunneled) header 🦋
the IEEE 802.11 standard does not permit the station's packet to include an 802.1Q header 💅 instead, stations mark a packet's priority with the QoS mechanisms defined in IEEE 802.11 🫶 when the 'P' bit is set in the Tagging Policy, the 'Q' bit behaves like this:
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 have a "DSCP Tag" 🎀 the WTP uses it when the 'D' bit is set to mark the DSCP field of both the IPv4 and IPv6 headers (see [RFC2474]) 💜 with DSCP, the WTP marks the inner packet (the one the station originally sent) when the 'I' bit is set 🦋 and it marks the outer packet (the tunnel header's DSCP field) when the 'O' bit is set 👑
when the 'D' bit is set, what happens depends on whether the WTP is tunneling the station's packets to the AC 🙈 tunneling doesn't happen in Local MAC mode when the AC has said tunneling isn't required, through the IEEE 802.11 Add WLAN message element (see Section 6.1) 🍓 if tunneling isn't used, the 'I' and 'O' bits work like this:
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 has to deal with both the inner packet (the station's original packet) and the tunnel header (which the WTP adds) 🧚 in this mode the bits work like this:
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. 🫶
the CAPWAP protocol supports the Explicit Congestion Notification (ECN) bits [RFC3168] 🦋 more ECN details live 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 the right Quality of Service values (listed below), so congestion in the network keeps packet loss to a minimum 🌈 the QoS Mechanism in the Tagging Policy is used as the AC specified in the IEEE 802.11 WTP Quality of Service message element (see Section 6.22) 💅 but the station-specific policy is NOT used for IEEE 802.11 MAC Management frames, so don't go looking for it there 🙈
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 CAPWAP 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 stays in the Run state 🫶
when the AC sends a WLAN Configuration Request message (see Section 3.1) or receives the matching WLAN Configuration Response message (see Section 3.2) from the WTP, it stays in the Run state too 🌸
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 the CAPWAP Control message definitions and how the Message Type value gets derived from the IANA Enterprise number 📚
here are the valid message types for IEEE 802.11-specific control messages 🎀 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 33989143.1. IEEE 802.11 WLAN Configuration Request 🎀
Okay bestie, so the AC sends this IEEE 802.11 WLAN Configuration Request to the WTP to change what services the WTP offers 💅. It's how you create, update, or delete a WLAN on the WTP. Full glow-up or full glow-down, your call 💖.
It gets sent because someone clicked something manually (like deleting a WLAN 😭), or automatically to make a WLAN on a WTP. For the automatic version, the AC only sends it after it has received the CAPWAP Configuration Update Response message (see Section 8.5 in [RFC5415]) ✨.
When the WTP gets this message, it updates the services it needs to update and then sends back an IEEE 802.11 WLAN Configuration Response 🦋.
A WTP MAY provide service for more than one WLAN, so every WLAN gets its own numerical index 🔢. Like, a WTP that can handle up to 16 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 main identifier for a WLAN, an AC MAY try to keep the same WLAN on the same index number across all of its WTPs 🧚. An AC that doesn't follow that approach MUST find some other means of keeping 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.
IEEE 802.11 Add WLAN, see Section 6.1IEEE 802.11 Delete WLAN, see Section 6.4IEEE 802.11 Update WLAN, see Section 6.21
The following message element MAY be present.
IEEE 802.11 Information Element, see Section 6.6Vendor-Specific Payload, see [RFC5415]
3.2. IEEE 802.11 WLAN Configuration Response 💌
The WTP sends this one back to the AC, and it's the "got it!" reply to an IEEE 802.11 WLAN Configuration Request 🫶. It confirms receipt, and it says either that the requested config was applied successfully or that something went wrong while the WTP was processing that request 😬.
The following message element MUST be included in the IEEE 802.11 WLAN Configuration Response message.
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.
IEEE 802.11 Assigned WTP BSSID, see Section 6.3Vendor-Specific Payload, see [RFC5415]
4. CAPWAP Data Message Bindings ✨
This section is all about how CAPWAP data messages carry IEEE 802.11 frames 📦.
Payload encapsulation: CAPWAP defines the CAPWAP data message, which wraps up a wireless payload 🎁. For IEEE 802.11, the IEEE 802.11 header and payload get encapsulated, but the IEEE 802.11 FCS checksum is left out of that. The WTP handles the FCS checksum, which means it can check an IEEE 802.11 frame before sending it to the AC 🕵️. Going the other way, when the AC wants to send 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]) only shows up with CAPWAP data messages, and it has two jobs depending on which direction the message is going 🧭. For messages from the WTP to the AC, the field uses the "IEEE 802.11 Frame Info" format (see below). For messages from the AC to the WTP, it uses the "Destination WLANs" format (also defined below). 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 comes in from a station over the air, it gets encapsulated, and this field carries the radio and PHY-specific info associated with that 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's the received signal strength indication, in dBm 📶.
SNR: SNR is a signed, 8-bit value. It's 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 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 specifies the target WLANs for a given frame, and it's only used with broadcast and multicast frames 🪞. This lets the AC send a single broadcast or multicast frame to the WTP, and lets the WTP do 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+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 it's 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.
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.
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.
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.4. Primary Discovery Response Message 🏆
The following IEEE 802.11-specific message element MUST be included in the CAPWAP Primary Discovery Response message.
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.
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.
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.
IEEE 802.11 Antenna, see Section 6.2IEEE 802.11 Direct Sequence Control, see Section 6.5IEEE 802.11 MAC Operation, see Section 6.7IEEE 802.11 Multi-Domain Capability, see Section 6.9IEEE 802.11 Orthogonal Frequency Division Multiplexing (OFDM) Control, see Section 6.10IEEE 802.11 Supported Rates, see Section 6.17IEEE 802.11 Tx Power, see Section 6.18IEEE 802.11 TX Power Level, see Section 6.19IEEE 802.11 WTP Radio Configuration, see Section 6.23IEEE 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.
IEEE 802.11 Antenna, see Section 6.2IEEE 802.11 Direct Sequence Control, see Section 6.5IEEE 802.11 MAC Operation, see Section 6.7IEEE 802.11 Multi-Domain Capability, see Section 6.9IEEE 802.11 OFDM Control, see Section 6.10IEEE 802.11 Rate Set, see Section 6.11IEEE 802.11 Supported Rates, see Section 6.17IEEE 802.11 Tx Power, see Section 6.18IEEE 802.11 WTP Quality of Service, see Section 6.22IEEE 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.
IEEE 802.11 Antenna, see Section 6.2IEEE 802.11 Direct Sequence Control, see Section 6.5IEEE 802.11 MAC Operation, see Section 6.7IEEE 802.11 Multi-Domain Capability, see Section 6.9IEEE 802.11 OFDM Control, see Section 6.10IEEE 802.11 Rate Set, see Section 6.11IEEE 802.11 RSNA Error Report from Station, see Section 6.12IEEE 802.11 Tx Power, see Section 6.18IEEE 802.11 WTP Quality of Service, see Section 6.22IEEE 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.
IEEE 802.11 Station, see Section 6.13IEEE 802.11 Station Session Key, see Section 6.15IEEE 802.11 Station QoS Profile, see Section 6.14IEEE 802.11 Update Station Qos, see Section 6.20
5.11. Change State Event Request 🦋
okay so this one's a quick one bestie 💅 The following IEEE 802.11-specific message element MAY be included in the CAPWAP Station Configuration Request message. It's the only one listed here, so it's giving simple, but it's still important!
- IEEE 802.11 WTP Radio Fail Alarm Indication, see Section 6.24 🚨
5.12. WTP Event Request 🌸
the WTP Event Request is where the IEEE 802.11 extras show up, and it's giving main character energy 👑 Three message elements are listed here, and they MAY be included in the CAPWAP WTP Event Request message. Also, more than one of each element listed MAY be included, so you can stack them if you need to ✨
- IEEE 802.11 MIC Countermeasures, see Section 6.8 🛡️
- IEEE 802.11 RSNA Error Report from Station, see Section 6.12 💜
- IEEE 802.11 Statistics, see Section 6.16 📊
6. IEEE 802.11 Message Element Definitions 🧚
this is the big list bestie 😭 The following IEEE 802.11-specific message elements are defined in this section. Each one gets a type value, so here's the whole lineup in one place 🍓
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 Elements6.1. IEEE 802.11 Add WLAN ✨
okay so the IEEE 802.11 Add WLAN message element is how the AC defines a WLAN on the WTP 🧚 and it's giving main character energy. If you include it, you MUST also include IEEE 802.11 Information Element message elements holding these IEs:
- Power Constraint information element
- EDCA Parameter Set information element
- QoS Capability information element
- WPA information element [WPA]
- RSN information element
- WMM information element [WMM]
The WTP stores these IEs and includes them in any Probe Responses and Beacons it generates, as the IEEE 802.11 standard [IEEE.802-11.2007] describes 🌸. If the RSN Information Element is there, it comes along with the IEEE 802.11 Add WLAN message element to tell the WTP how to use the Key field 🔑.
If the WTP is providing cryptographic services, it MUST observe the algorithm named in the Group Cipher Suite field of the RSN Information Element the AC sent 💅. That RSN IE can carry any supported algorithm, including WEP, Temporal Key Integrity Protocol (TKIP) and AES-CCMP 🦋. With static WEP keys, the RSN IE still gets used to name the cipher even though no key exchange happened, which is kind of wild but also very on brand 😭.
An AC MAY include additional Information Elements as desired 🎀. Here's the layout of the 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 for the radio, between one (1) and 31 📻
WLAN ID: an 8-bit WLAN Identifier 🪪. It MUST be between one (1) and 16, no exceptions bestie 🙅♀️
Capability: a 16-bit value holding the Capability information field that the WTP advertises in Probe Request and Beacon frames ✨. Each bit stands for a different WTP capability, and [IEEE.802-11.2007] explains them in detail. The field looks like this:
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's how each bit gets set 💜:
- 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 in [IEEE.802-11.2007] 📋
- F (CF-Poll Request): the AC sets the CF-Poll Request subfield based on the table in [IEEE.802-11.2007] 📋
- P (Privacy): the AC sets the Privacy subfield based on the WLAN's confidentiality requirements, as defined in [IEEE.802-11.2007] 🔐
- S (Short Preamble): the AC sets the Short Preamble subfield based on whether short preambles are allowed 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 PBCC is allowed 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 can support 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 to match 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 in [IEEE.802-11.2007] 💅
- T (Short Slot Time): the AC sets the Short Slot Time subfield to match 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 to match 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] 0️⃣
- 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 to match the dot11DelayedBlockAckOptionImplemented MIB variable, as defined in [IEEE.802-11.2007] 🧩
- L (Immediate Block ACK): the AC sets the Delayed Block ACK subfield to match the dot11ImmediateBlockAckOptionImplemented MIB variable, as defined in [IEEE.802-11.2007]. Yes, the description says "Delayed Block ACK" here too 🙈
Key-Index: the Key Index tied to the key 🗝️
Key Status: a 1-byte value describing the state and usage of the included key 💫. This field gets ignored if the Key Length field is zero (0), so don't stress about it then 😌. These values describe the key usage and status:
0- A value of zero, when the RSN Information Element is included, means the WLAN uses per-station encryption keys, so the key in theKeyfield only covers multicast traffic 👯1- When set to one, the WLAN uses a shared Wired Equivalent Privacy (WEP) key, also called a static WEP key, and that same encryption key covers both unicast and multicast traffic for all stations 🔁2- The AC will begin rekeying the GTK with the STAs in the BSS 🔄. This is only valid when IEEE 802.11 is the security policy for the BSS3- The AC has finished rekeying the GTK, so broadcast packets no longer need to be duplicated and sent with both GTKs 🎉
Key Length: a 16-bit value for the length of the Key field 📏
Key: a Session Key, whose length comes from the Key Length field, used to provide data privacy 🔒. For encryption schemes that use a separate key for unicast and multicast traffic, the key here only applies to multicast frames, and the cipher suite is named in an accompanying RSN Information Element 🧠. In those cases, the key and cipher info get communicated through 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). With WEP, the Key field holds the broadcast key 🌟. With CCMP, it holds the 128-bit Group Temporal Key 💜. With TKIP, it holds the 256-bit Group Temporal Key, which is a 128-bit key used as input for TKIP key mixing plus two 64-bit keys used for Michael 🦋.
Group TSC: a 48-bit value holding the Transmit Sequence Counter (TSC) for the updated group key 🔢. The WTP sets the TSC for broadcast/multicast frames to this value for the updated group key 📨.
QoS: an 8-bit value setting the default QoS policy the WTP applies to network traffic received from a non-WMM enabled STA 🎀. These enumerated values are supported:
0- Best Effort1- Video2- Voice3- Background
Auth Type: an 8-bit value naming the supported authentication type 🪄. These enumerated values are supported:
0- Open System1- WEP Shared Key
MAC Mode: this field says whether the WTP should support the WLAN in Local or Split MAC mode 🧩. The AC MUST NOT request a mode the WTP didn't advertise during discovery (see Section 4.6.43 in [RFC5415]) 🚫. These enumerated values are supported:
0- Local MAC: service for the WLAN is provided in Local MAC mode 🏠1- Split MAC: service for the WLAN is provided in Split MAC mode ✂️
Tunnel Mode: this field sets the frame tunneling type for 802.11 data frames from all stations associated with the WLAN 🚇. The AC MUST NOT request a mode the WTP didn't advertise during discovery (see Section 4.6.42 in [RFC5415]) 🙅♀️. All IEEE 802.11 management frames MUST be tunneled using 802.11 Tunnel mode 📬. These enumerated values are supported:
0- Local Bridging: all user traffic is locally bridged 🌉1- 802.3 Tunnel: all user traffic is tunneled to the AC in 802.3 format (see Section 4.4.2 in [RFC5415]). This option MUST NOT be selected with Split MAC mode 🚫2- 802.11 Tunnel: all user traffic is tunneled to the AC in 802.11 format 📦
Suppress SSID: a boolean for whether the WTP advertises the SSID 🫣. A value of zero suppresses the SSID in the 802.11 Beacon and Probe Response frames, while a value of one makes the WTP populate the field 📣.
SSID: the service set identifier the WTP advertises for this WLAN 🏷️. The SSID field can hold any ASCII character and MUST NOT exceed 32 octets in length, as defined in [IEEE.802-11.2007] 💖.
6.2. IEEE 802.11 Antenna ✨
okay so this is the element the WTP uses to tell the AC what antennas it's rocking 🦋 The AC MAY use it to reconfigure the WTP's antennas too 💅 Here's the layout:
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:
1025for IEEE 802.11 Antenna 🎀 - Length:
>= 5 - Radio ID: an 8-bit value for the radio you're configuring, between one (1) and 31 🌸
- Diversity: an 8-bit value saying whether the antenna provides receiver diversity. It uses the same value as the IEEE 802.11 dot11DiversitySelectionRx MIB element, see [IEEE.802-11.2007]. The supported values are:
0- Disabled1- Enabled (may only be true if the antenna can be used as a receiving antenna)
- Combiner: an 8-bit value for the combiner selection. The supported values are:
1- Sectorized (Left)2- Sectorized (Right)3- Omni4- Multiple Input/Multiple Output (MIMO)
- Antenna Count: an 8-bit value for how many Antenna Selection fields there are. This value SHOULD be the same as the one 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, so up to 255 antennas. The supported values are:
1- Internal Antenna2- External Antenna
6.3. IEEE 802.11 Assigned WTP BSSID 🧚
this one only shows up from the WTP when the IEEE 802.11 WLAN Configuration Request included the IEEE 802.11 Add WLAN message element. Its BSSID value field carries the BSSID the WTP assigned itself, so the WTP gets to do its own BSSID assignment 💜
the WTP is free to assign BSSIDs however it sees fit, but it is highly recommended that it use this 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:
1026for IEEE 802.11 Assigned WTP BSSID - Length:
8 - Radio ID: an 8-bit value for the radio, between one (1) and 31
- WLAN ID: an 8-bit value for the WLAN Identifier. The value MUST be between one (1) and 16 🍓
- BSSID: the BSSID the WTP assigned for the WLAN that got created when it received an IEEE 802.11 Add WLAN
6.4. IEEE 802.11 Delete WLAN 🙈
this is the message element that tells the WTP a WLAN it made earlier should be deleted. It has these fields:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | WLAN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type:
1027for IEEE 802.11 Delete WLAN - Length:
2 - Radio ID: an 8-bit value for the radio, between one (1) and 31
- WLAN ID: an 8-bit value for the WLAN Identifier. The value MUST be between one (1) and 16 🦋
6.5. IEEE 802.11 Direct Sequence Control 💅
this one is bi-directional, which is so iconic 👑 When the WTP sends it, it carries the current state. When the AC sends it, the WTP MUST adhere to the values provided. This element is only used for IEEE 802.11b radios. The fields look like this:
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:
1028for IEEE 802.11 Direct Sequence Control - Length:
8 - Radio ID: an 8-bit value for the radio you're configuring, 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 they support. Receivers MUST ignore all bits not defined for the version of the protocol they support 🧚
- Current Channel: this is the current operating frequency channel of the Direct Sequence Spread Spectrum (DSSS) PHY. The value comes from the IEEE 802.11 dot11CurrentChannel MIB element (see [IEEE.802-11.2007]) 🌸
- Current CCA: the Clear Channel Assessment (CCA) method currently in operation. Its value can be found in the IEEE 802.11 dot11CCAModeSupported MIB element (see [IEEE.802-11.2007]). The 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 Energy Detect Threshold the DSSS PHY is currently using. 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 🌈
this is how you pass along any IE defined in the IEEE 802.11 protocol. The data field holds the raw IE, exactly as it would show up inside 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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type:
1029for IEEE 802.11 Information Element - Length:
>= 4 - Radio ID: an 8-bit value for the radio, between one (1) and 31
- WLAN ID: an 8-bit value for 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 they support. 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 🎀
okay so the IEEE 802.11 MAC Operation message element is how the AC sets the IEEE 802.11 MAC parameters on the WTP 💅 it's the AC being the boss, basically. here's the layout:
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 is the code for IEEE 802.11 MAC Operation 🍓
Length: 16 ✨
Radio ID: an 8-bit value picking which radio to configure. It has to be between 1 and 31 📻
Reserved: every implementation that follows this protocol MUST set any bits that are reserved in its protocol version to zero 🧊 receivers MUST ignore all the bits they don't define for the version they support. no peeking at the unknown stuff, bestie 🙈
RTS Threshold: this is the number of octets in an MAC Protocol Data Unit (MPDU) where an RTS/CTS handshake MUST NOT happen if the MPDU is smaller than that. otherwise an RTS/CTS handshake MUST be done at the start of any frame exchange where the MPDU is Data or Management, has an individual address in the Address1 field, and is longer than this threshold 🚦 if you set it bigger than the max MSDU size, the handshake MUST be turned off for Data or Management frames sent by this STA. set it to zero and it MUST be turned on for all of them 💜 the default MUST be 2347. this value comes from the IEEE 802.11 dot11RTSThreshold MIB element (see [IEEE.802-11.2007]).
Short Retry: the max number of transmission attempts for a frame whose length is less than or equal to RTSThreshold. these MUST be made before the frame is called a failure 🔁 the default MUST be 7. it comes from the IEEE 802.11 dot11ShortRetryLimit MIB element (see [IEEE.802-11.2007]) 🌸
Long Retry: the max number of attempts for a frame longer than dot11RTSThreshold, which MUST be made before it counts as a failure 🔁 the default MUST be 4. it comes from the IEEE 802.11 dot11LongRetryLimit MIB element (see [IEEE.802-11.2007]) 🌈
Fragmentation Threshold: this is the current max size, in octets, of an MPDU that MAY be handed to the PHY 🧩 an MAC Service Data Unit (MSDU) MUST be broken into fragments if it's bigger than this after you add the MAC headers and trailers. an MSDU or MAC Management Protocol Data Unit (MMPDU) MUST be fragmented when the frame has an individual address in the Address1 field and is larger than this threshold. the default MUST be the lesser of 2346 or the aMPDUMaxLength of the attached PHY, and it MUST never go above that same lesser value. it MUST never be less than 256 ✂️ this value comes from the IEEE 802.11 dot11FragmentationThreshold MIB element (see [IEEE.802-11.2007]).
Tx MSDU Lifetime: the elapsed time in Time Units (TUs) after the first transmission of an MSDU. after that, any further transmit attempts MUST be terminated ⏳ the default MUST be 512. it comes from the IEEE 802.11 dot11MaxTransmitMSDULifetime MIB element (see [IEEE.802-11.2007]) 🕰️
Rx MSDU Lifetime: the elapsed time in TU after the first reception of a fragmented MMPDU or MSDU. after that, further attempts to reassemble it MUST be terminated 🧵 the default MUST be 512. this value 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 how the WTP tells the AC that a MIC failure happened 😭 if you want the full scoop on MIC failure events, check out 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 is the code for IEEE 802.11 MIC Countermeasures 🏷️
Length: 8 📏
Radio ID: the Radio Identifier, between 1 and 31. it usually points to some interface index on the WTP 🔌
WLAN ID: an 8-bit unsigned integer with the WLAN Identifier where the MIC failure happened 🛜 it MUST be between 1 and 16 💅
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 how the AC tells the WTP about regulatory limits 📜 the AC sends one message element per frequency band to show the regulatory constraints for that domain. here are the 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 is the code for IEEE 802.11 Multi-Domain Capability 🏷️
Length: 8 📏
Radio ID: an 8-bit value picking the radio to configure. it has to be between 1 and 31 📻
Reserved: every implementation that follows this protocol MUST set any reserved bits in its protocol version to zero 🧊 receivers MUST ignore all the bits they don't define for their version. 🙈
First Channel #: the lowest channel number in the sub-band for the associated domain country string. this value comes from the IEEE 802.11 dot11FirstChannelNumber MIB element (see [IEEE.802-11.2007]) 🌊
Number of Channels: the total number of channels allowed in the sub-band for the associated domain country string (see Section 6.23). this value comes from the IEEE 802.11 dot11NumberofChannels MIB element (see [IEEE.802-11.2007]) 🔢
Max Tx Power Level: the maximum transmit power, in dBm, allowed in the sub-band for the associated domain country string (see Section 6.23). this value comes from the IEEE 802.11 dot11MaximumTransmitPowerLevel MIB element (see [IEEE.802-11.2007]) ⚡
6.10. IEEE 802.11 OFDM Control 🌈
the IEEE 802.11 Orthogonal Frequency Division Multiplexing (OFDM) Control message element goes both ways 🔁 when the WTP sends it, it carries the current state. when the AC sends it, the WTP MUST adhere to the values it got. this message element is only used for 802.11a radios and has these 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 is the code for IEEE 802.11 OFDM Control 🏷️
Length: 8 📏
Radio ID: an 8-bit value picking the radio to configure, between 1 and 31 📻
Reserved: every implementation that follows this protocol MUST set any reserved bits in its protocol version to zero 🧊 receivers MUST ignore all the bits they don't define for their version. 🙈
Current Channel: the current operating frequency channel of the OFDM PHY. this value comes from the IEEE 802.11 dot11CurrentFrequency MIB element (see [IEEE.802-11.2007]) 📡
Band Supported: this shows the OFDM PHY implementation's ability to operate in the three Unlicensed National Information Infrastructure (U-NII) bands 🎶 the value comes from the IEEE 802.11 dot11FrequencyBandsSupported MIB element (see [IEEE.802-11.2007]), coded as a bit field, with these values:
- 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
- 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
so for an implementation that can run in the 5.15-5.35 GHz bands, this attribute would be 3 🧮
TI Threshold: the threshold used to detect a busy medium (frequency). CCA MUST report a busy medium when it detects RSSI above this threshold 📶 this value comes from the IEEE 802.11 dot11TIThreshold MIB element (see [IEEE.802-11.2007]) 🫶
6.11. IEEE 802.11 Rate Set 🎀
okay bestie, so this one is the rate set message element and the AC is the one sending it ✨ it's basically the menu of supported operational rates, aka the speeds the radio is allowed to use. here's the layout:
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:
1034for IEEE 802.11 Rate Set 💖 - Length:
>= 3🌸 - Radio ID: an 8-bit value for the radio being configured, 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, and the value comes from the IEEE 802.11 dot11OperationalRateSet MIB element (see [IEEE.802-11.2007]) 💅
6.12. IEEE 802.11 RSNA Error Report From Station 🔥
so this message element is how a WTP tells the AC about RSN errors 🫶 the WTP doesn't need to send any reports that don't include any failures. the fields come from the IEEE 802.11 Dot11RSNAStatsEntry table (see [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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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:
1035for 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 🙈
- 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 💜
this one rides along with the Add Station message element 🧚 and it's how the AC delivers IEEE 802.11 station policy to the WTP. the latest IEEE 802.11 Station message element overrides any previously received message elements, so newest wins, periodt 💅
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. this is not optional, bestie 🚨
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:
1036for 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 Station QoS Profile message element holds the maximum IEEE 802.11e priority tag that the station is allowed to use 💅 any packet that goes over the value in this element MUST be tagged with the maximum value permitted by to the user. the priority tag MUST be between zero (0) and seven (7) 🌈. and yes, this message element MUST NOT be present without the IEEE 802.11 Station (see Section 6.13) message element, so it always has a buddy 🫶
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:
1037for 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 🔑✨
okay bestie, this one is all about the keys 🗝️💖 The AC uses the IEEE 802.11 Station Session Key message element to provision encryption keys, or to set up an access policy, on the WTP. This element MUST NOT be present without the IEEE 802.11 Station (see Section 6.13) message element, and it 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 so the WTP knows how to use the Key field 🧠 The WTP MUST observe the Authentication and Key Management (AKM) field of the RSN Information Element to figure out which authentication protocol to enforce with the station. it's giving organized 📋
If cryptographic services are provided at the WTP, the WTP MUST observe the algorithm in the Pairwise Cipher Suite field of the RSN Information Element sent by the AC. this is the RSN Information Element from the AC's third message of the 4-Way Key Handshake, and it says which cipher to use for encrypting and decrypting traffic with the station 🔐 The RSN Information Element can communicate any supported algorithm, including WEP, TKIP, and AES-CCMP 🌈 Even with static WEP keys, where no key exchange happened, the RSN Information Element still gets used to name the cryptographic algorithm ✨
Now the AKM-Only bit. 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, which means the AKM packets have to be encrypted 🔒 Once the station has successfully authenticated 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. main character glow-up moment 👑
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: 🚩
- A: The 1-bit AKM-Only field is set by the AC to inform the WTP that it 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 being 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 make sure they are properly encrypted as specified in the RSN Information Element, but it doesn't need to take specific cryptographic action on the frame. Same deal for transmitted frames: the WTP only needs to forward frames that are already encrypted. Since packets the WTP receives will be encrypted, it can't modify their contents, including the DSCP markings of the encapsulated packet 💅 In this case, that job belongs to 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 depends on the crypto algorithm being used. For unicast WEP keys, the Key field holds the actual unicast encryption key (note, this is used when WEP is used together with 802.1X, which means 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 is made of a 128-bit key used as input for TKIP key mixing, plus two 64-bit keys used for Michael 🌸
6.16. IEEE 802.11 Statistics ✨
okay so the WTP sends this one to spill its current stats tea 📊 and there are a LOT of fields 😭. everything starts at zero when the WTP initializes 🌱. each counter rolls over when it hits its max of 4294967295 🔄, and each field rolls over at a totally different speed, so whoever is reading these needs to know the minimum possible time between rollovers so they don't miss any back-to-back ones 👀 it's giving detective energy fr 🕵️♀️
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type: 1039 for IEEE 802.11 Statistics 🏷️
Length: 80 📏
Radio ID: an 8-bit value for the radio, between one (1) and 31 📻
Reserved: every implementation that follows this protocol MUST set to zero any bits that are reserved in the version it supports. Receivers MUST ignore all bits not defined for the version they support. bits that aren't defined yet? ignore them, bestie 🙈
Tx Fragment Count: a 32-bit value for how many fragmented frames got transmitted. it comes from the IEEE 802.11 dot11TransmittedFragmentCount MIB element (see [IEEE.802-11.2007]) 📦
Multicast Tx Count: a 32-bit value for how many multicast frames got transmitted. it comes from the IEEE 802.11 dot11MulticastTransmittedFrameCount MIB element (see [IEEE.802-11.2007]) 📣
Failed Count: a 32-bit value for transmit excessive retries 💀. it comes from the IEEE 802.11 dot11FailedCount MIB element (see [IEEE.802-11.2007])
Retry Count: a 32-bit value for the number of transmit retries 🔁. it comes from the IEEE 802.11 dot11RetryCount MIB element (see [IEEE.802-11.2007])
Multiple Retry Count: a 32-bit value for the number of transmits that needed more than one retry 🫠. it comes from the IEEE 802.11 dot11MultipleRetryCount MIB element (see [IEEE.802-11.2007])
Frame Duplicate Count: a 32-bit value for duplicate frames received 👯. it comes from the IEEE 802.11 dot11FrameDuplicateCount MIB element (see [IEEE.802-11.2007])
RTS Success Count: a 32-bit value for how many Ready To Send (RTS) frames went through successfully ✅. it comes from the IEEE 802.11 dot11RTSSuccessCount MIB element (see [IEEE.802-11.2007])
RTS Failure Count: a 32-bit value for failed transmitted RTS ❌. it comes from the IEEE 802.11 dot11RTSFailureCount MIB element (see [IEEE.802-11.2007])
ACK Failure Count: a 32-bit value for failed acknowledgements 🙃. it comes from the IEEE 802.11 dot11ACKFailureCount MIB element (see [IEEE.802-11.2007])
Rx Fragment Count: a 32-bit value for fragmented frames received 📥. it comes from the IEEE 802.11 dot11ReceivedFragmentCount MIB element (see [IEEE.802-11.2007])
Multicast RX Count: a 32-bit value for multicast frames received 📻. it comes from the IEEE 802.11 dot11MulticastReceivedFrameCount MIB element (see [IEEE.802-11.2007])
FCS Error Count: a 32-bit value for FCS failures 🚫. it comes from the IEEE 802.11 dot11FCSErrorCount MIB element (see [IEEE.802-11.2007])
Decryption Errors: a 32-bit value for decryption errors that happened on the WTP 🔐. heads up, this one is only valid when the WTP is actually doing the encryption/decryption stuff 🧐. it comes from the IEEE 802.11 dot11WEPUndecryptableCount MIB element (see [IEEE.802-11.2007])
Discarded QoS Fragment Count: a 32-bit value for discarded QoS fragments received 🗑️. it comes from the IEEE 802.11 dot11QoSDiscardedFragmentCount MIB element (see [IEEE.802-11.2007])
Associated Station Count: a 32-bit value for the number of number of associated stations 🧑🤝🧑 (yes, the text really says "number of number of", we're keeping it 😭). it comes from the IEEE 802.11 dot11AssociatedStationCount MIB element (see [IEEE.802-11.2007])
QoS CF Polls Received Count: a 32-bit value for the number of (+)CF-Polls received 📨. it comes from the IEEE 802.11 dot11QosCFPollsReceivedCount MIB element (see [IEEE.802-11.2007])
QoS CF Polls Unused Count: a 32-bit value for (+)CF-Polls that got received but never used 🛌. it comes from the IEEE 802.11 dot11QosCFPollsUnusedCount MIB element (see [IEEE.802-11.2007])
QoS CF Polls Unusable Count: a 32-bit value for (+)CF-Polls that got received but couldn't be used, because the Transmission Opportunity (TXOP) size was smaller than the time needed for one frame exchange sequence 🥲. it comes from the IEEE 802.11 dot11QosCFPollsUnusableCount MIB element (see [IEEE.802-11.2007])
6.17. IEEE 802.11 Supported Rates 🎶
the WTP sends this to show off the rates its hardware can handle 💪. here's the layout:
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 for the radio, between one (1) and 31 📻
Supported Rates: the WTP includes the Supported Rates its hardware supports 🙌. the format matches the Rate Set message element, and it's between 2 and 8 bytes long 📐
6.18. IEEE 802.11 Tx Power ⚡
this one is bi-directional, which is so iconic 🦋. when the WTP sends it, it's giving "here's my current power level" 🔋. when the AC sends it, it's giving "this is the power level you MUST adhere to" 👑. here's the layout:
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
Length: 4 📏
Radio ID: an 8-bit value for the radio you're configuring, between one (1) and 31 🎛️
Reserved: every implementation that follows this protocol MUST set to zero any bits that are reserved in the version it supports. Receivers MUST ignore all bits not defined for the version they support. same energy as before, bestie 🫶
Current Tx Power: this attribute holds 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 📡
Okay so the WTP sends this one, and it's basically the menu of every transmit power level it supports 💖 The values come straight from the IEEE 802.11 Dot11PhyTxPowerEntry MIB table, so if you want the source of truth, go check [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 | Num Levels | Power Level [n] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type: 1042 for IEEE 802.11 Tx Power Level 🎀
Length: >= 4 🌈
- Radio ID: an 8-bit value for the radio you're configuring, and it has to be between one (1) and 31 🦋
- Num Levels: this is how many power level attributes are in the list 🍓 The value comes from the IEEE 802.11
dot11NumberSupportedPowerLevelsMIB element (see [IEEE.802-11.2007]). - Power Level: each power level field holds one supported level, in mW 🔥 The value comes from the matching IEEE 802.11
dot11TxPowerLevel[n]MIB element, see [IEEE.802-11.2007].
6.20. IEEE 802.11 Update Station QoS 💅
The Update Station QoS message element is how you change the Quality of Service policy on the WTP for one specific station, and it's giving main character energy 👑 The QoS tags in here get applied to packets the WTP receives from the station named in the MAC Address field. This message element overrides the defaults set by the IEEE 802.11 WTP Quality of Service message element (see Section 6.22). Any tagging the WTP does MUST be applied directly to the packets received from the station, and also to the CAPWAP tunnel if those packets get tunneled to the AC. See Section 2.6 for more info 🫶
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, between one (1) and 31. It typically points 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 has four QoS sub-elements, one for each QoS profile 💖 The order goes Voice, Video, Best Effort, then 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: every implementation that follows this protocol MUST set any reserved bits to zero, for the version it supports. Receivers MUST ignore all bits that aren't defined for their version of the protocol 🫧
- 8021p: the 3-bit 802.1p priority value, used if the packets are going to be IEEE 802.1p tagged 🍓 This field only counts if the 'P' bit in the WTP Quality of Service message element was set. Otherwise, its contents MUST be ignored 🙅♀️
- RSV: same deal as Reserved. Every implementation MUST set reserved bits to zero, and receivers MUST ignore any bits not defined for their protocol version 💅
- DSCP Tag: the 6-bit DSCP label for packets that are eligible to be DSCP tagged, which means IPv4 or IPv6 packets (see [RFC2474]) 🦋 This field only applies 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 Update WLAN message element is how the AC defines a wireless LAN on the WTP 🎀 Including this message element MUST also include the IEEE 802.11 Information Element message element, and that one carries these 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]
The WTP stores these IEEE 802.11 Information Elements and puts them in any Probe Responses and Beacons it generates, as laid out in the IEEE 802.11 standard [IEEE.802-11.2007] 🌸
If cryptographic services are provided at the WTP, the WTP MUST observe the algorithm named in the Group Cipher Suite field of the RSN Information Element that the AC sent 🔥 The RSN Information Element can communicate any supported algorithm, including WEP, TKIP, and AES-CCMP. Even with static WEP keys, where no key exchange happened, the RSN Information Element still gets used to indicate the cryptographic algorithm 🙈
The message element looks like this:
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 for the radio, between one (1) and 31 🦋
- WLAN ID: an 8-bit value for the WLAN Identifier. The value MUST be between one (1) and 16 👑
- Capability: a 16-bit value holding the Capability information field the WTP advertises in Probe Request and Beacon frames 🧚 Each bit stands for a different WTP capability, and they're all described in detail in [IEEE.802-11.2007]. The field looks like this:
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 this based on the table in [IEEE.802-11.2007] 🌸
- F (CF-Poll Request): the AC sets this based on the table in [IEEE.802-11.2007] 🫶
- P (Privacy): the AC sets this based on the WLAN's confidentiality requirements, as defined in [IEEE.802-11.2007] 🔥
- S (Short Preamble): the AC sets this depending on whether 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 PBCC is permitted on the WLAN, as defined in [IEEE.802-11.2007] 🌈
- A (Channel Agility): the AC sets this based on whether the WTP can support the High Rate Direct Sequence Spread Spectrum (HR/DSSS), as defined in [IEEE.802-11.2007] 🍓
- M (Spectrum Management): the AC sets this according to the
dot11SpectrumManagementRequiredMIB variable, as defined in [IEEE.802-11.2007] 🧚 - Q (QoS): the AC sets the Quality of Service (QoS) subfield based on the table in [IEEE.802-11.2007] 💜
- T (Short Slot Time): the AC sets this according to the WTP's currently used slot time value, as defined in [IEEE.802-11.2007] 🙈
- D (APSD): the AC sets this according to the
dot11APSDOptionImplementedManagement 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 this 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 this according to the
dot11DelayedBlockAckOptionImplementedMIB variable, as defined in [IEEE.802-11.2007] ✨ - L (Immediate Block ACK): the AC sets the Delayed Block ACK subfield according to the
dot11ImmediateBlockAckOptionImplementedMIB variable, as defined in [IEEE.802-11.2007] 👑
- Key-Index: the Key-Index tied to the key 🌈
- Key Status: a 1-byte value that tells you the state and usage of the key that got included 💅 Here's what each value means:
- 0 - A value of zero, with the RSN Information Element included, means the WLAN uses per-station encryption keys. So the key in the 'Key' field is only for multicast traffic 🦋
- 1 - When this is set to one, the WLAN uses a shared WEP key (aka a static WEP key), and that key encrypts both unicast and multicast traffic for every station 🔥
- 2 - A value of 2 means the AC is about to start rekeying the GTK with the STAs in the BSS. This is only valid when IEEE 802.11 is the security policy for the BSS 💖
- 3 - A value of 3 means the AC finished rekeying the GTK, so broadcast packets don't need to be duplicated and sent with both GTKs anymore 🎀
- Key Length: a 16-bit value for the length of the Key field 🧚
- Key: a Session Key, whose length is known from the Key Length field, used for data privacy 🌸 For static WEP keys (that's when the 'Key Status' is set to one), this key covers both unicast and multicast traffic. For encryption schemes that use a separate key for unicast and multicast, the key here only applies to multicast data, and the cipher suite is specified in an accompanying RSN Information Element. In those cases, the key and cipher info get communicated through the Add Station message element, see Section 4.6.8 in [RFC5415] 🫶 When it's used with WEP, the Key field holds the broadcast key. With CCMP, it holds the 128-bit Group Temporal Key. With TKIP, it holds the 256-bit Group Temporal Key, which is a 128-bit key used as input for TKIP key mixing plus two 64-bit keys used for Michael 🔐✨
6.22. IEEE 802.11 WTP Quality of Service ✨
Okay bestie, this one is all about QoS vibes 💅 The AC sends this IEEE 802.11 WTP Quality of Service message element to the WTP to hand over its Quality of Service config 🎀 The QoS tags in here are the default QoS values for packets the WTP gets from stations on a particular radio 🦋 Any tagging the WTP does MUST be applied directly to the packets from the station, plus the CAPWAP tunnel if those packets get tunneled to the AC. See Section 2.6 for more info 🫶
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. It typically refers to some interface index on the WTP.
Tagging Policy: this is a bit field that tells the WTP how to mark packets for QoS purposes. The required WTP behavior is defined in Section 2.6.1, and the field looks like this:
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 how the AC tells the WTP how 802.1p QoS is to be enforced. The details on the behavior of the 'Q' bit are in Section 2.6.1.1 ✨
- 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 how the AC tells the WTP to enforce DSCP QoS on the outer (tunneled) header. The details are in Section 2.6.1.2 🌈
- I: when the 'D' bit is set, the 'I' bit is how the AC tells the WTP to enforce DSCP QoS on the station's packet (inner) header. The details are in Section 2.6.1.2 💅
QoS Sub-Element: this message element holds four QoS sub-elements, one for every QoS profile, in this order: Voice, Video, Best Effort, and Background. Each one looks like this 👑
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. This value 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. This value 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. This value comes from the IEEE 802.11 dot11EDCATableAIFSN MIB element (see [IEEE.802-11.2007]) ⭐
- 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 only used 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 only used 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 how the AC configures a Radio on the WTP, and how the WTP sends its radio configuration back to the AC 🔁 The message element value has these 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 for the radio being configured, whose value is between one (1) and 31 🆔
Short Preamble: an 8-bit value saying whether short preamble is supported. These enumerated values are supported right now:
- 0 - Short preamble not supported.
- 1 - Short preamble is supported.
BSSID: the WLAN Radio's base MAC Address 🪪
Number of BSSIDs: this attribute holds the maximum number of BSSIDs the WTP supports. It limits how many logical networks the WTP can run, and the value is between 1 and 16 🌐
DTIM Period: this attribute is the number of Beacon intervals that pass between Beacon frames carrying a Traffic Indication Map (TIM) element whose Delivery Traffic Indication Message (DTIM) Count field is 0. This value goes in the DTIM Period field of Beacon frames. It comes from the IEEE 802.11 dot11DTIMPeriod MIB element (see [IEEE.802-11.2007]) ⏰
Beacon Period: this attribute is the number of Time Units (TU) a station uses for scheduling Beacon transmissions. This value goes in Beacon and Probe Response frames. It comes from the IEEE 802.11 dot11BeaconPeriod MIB element (see [IEEE.802-11.2007]) 🕰️
Country String: this attribute identifies the country the station is operating in. It comes from the IEEE 802.11 dot11CountryString MIB element (see [IEEE.802-11.2007]). Some regulatory domains don't let WTPs have a user configurable country string, and they need it to be a fixed value set during manufacturing. So WTP vendors who want this field to be configurable will need to validate that behavior during their radio certification process. Other WTP vendors might just treat this config 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 on regulatory requirements, for example to avoid being classified as a Software-Defined Radio 📡 When this field is used, the first two octets of the string are the two-character country string 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 third octet is 255 (HEX 0xff), the country string field is not used, and MUST be ignored. The possible values for the third octet are:
- an ASCII space character, if the regulations under which the station is operating cover all environments in the country,
- an ASCII 'O' character, if the regulations under which the station is operating are for an outdoor environment only, or
- an ASCII 'I' character, if the regulations under which the station is operating are for an indoor environment only,
- 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,
- 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. It typically refers to some interface index on the WTP.
Type: the type of radio failure detected. These enumerated values are supported:
- 1 - Receiver
- 2 - Transmitter
Status: an 8-bit boolean saying whether the radio failure is being reported or cleared. A value of zero clears the event, and a value of one reports it 🔔
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 📡
okay so this message element is how the WTP tells the AC what each of its IEEE 802.11 radios can do 📡✨ it's giving "here's my whole radio lineup, bestie." The Discovery Request message, Primary Discovery Request message, and Join Request message MUST include one such message element per radio in the WTP 💖 The AC uses the Radio Type field to figure out which IEEE 802.11 technology specific binding to use with that WTP 🧚
The message element has two fields, 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 🌸 its value is between one (1) and 31, and it typically refers to an interface index on the WTP 🦋
Radio Type: the type of radio present 💜 ngl this one is a bit field, which means it can flag support for more than one type of PHY/MAC at the same time (main character energy 👑). It has the following format:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Reservd|N|G|A|B|
+-+-+-+-+-+-+-+-+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. (no cap, this is the "don't touch what isn't yours" rule 💀)
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 💾
okay this section is the list of IEEE 802.11 binding specific variables that SHOULD be saved in non-volatile memory on the WTP 💖 so basically the stuff you want to still be there after a reboot, iykyk ✨
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 ✨
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 the IEEE 802.11-specific values for the generic CAPWAP message elements that have fields whose values depend on the technology 🦋 lowkey the main event of the whole vibe 💅
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] 🌸 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 (it's just assumed, bestie, like breathing 🙈). 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 🚨
⚠️ okay this part is SERIOUS, so read it with your whole chest 😭 nothing here is a vibe check, it's about protecting real networks, periodt
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 🙈 BUT derived Session Keys between the STA and WTP can be compromised, resulting in 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 (phew, bestie 🫠).
however, when the WTP provides link security, a new vulnerability will exist when the following conditions are true:
- The client is not the first to associate to the WTP/ESSID (i.e., other clients are associated), a GTK already exists, and
- 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 💅
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 Value10.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 🌈
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 require 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 Reference10.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 Reference10.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 Reference10.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 value 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 Reference10.9. IEEE 802.11 Session Key Flags 🗝️
okay so the flags field in the IEEE 802.11 Station Session Key message element (see Section 6.15) is 16 bits 💖 and it's what configures the session key association with the mobile device. this spec only defines bits zero (0) and one (1) ✨, and bits two (2) through fifteen are reserved 🙈. those reserved bits are managed by IANA, and getting one assigned needs an Expert Review. IANA made the IEEE 802.11 Session Key Flags registry, and it looks like this:
IEEE 802.11 Station Session Key Bit Position Reference10.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 it's used to specify how the CAPWAP Data Channel packets are to be tagged. this spec defines bits three (3) through seven (7) 🦋. the remaining bits are managed by IANA, and assignment needs an Expert Review. IANA made the IEEE 802.11 Tagging Policy registry, format below:
IEEE 802.11 Tagging Policy Bit Position Reference10.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 how we find out why a WTP's radio has failed 😭. the namespace is 8 bits (0-255), where value zero (0) is reserved and unused 💀, while values one (1) and two (2) are allocated in this spec and you can find them in Section 6.24 🌸. this namespace is managed by IANA, and assignments need an Expert Review. IANA made the IEEE 802.11 WTP Radio Fail registry:
IEEE 802.11 WTP Radio Fail Type Value Reference10.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 it's used to give info about the WTP's radio type 🧚. this spec 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, which is formatted like this:
IEEE 802.11 WTP Radio Type Bit Position Reference10.13. WTP Encryption Capabilities 🔐
the WTP Encryption Capabilities field in the WTP Descriptor message element (see Section 8.1) is 16 bits 🍓, and the WTP uses it to say what its IEEE 802.11 encryption capabilities are. this spec defines bits 12 and 13 ✨. the reserved bits are managed by IANA, and assignment needs an Expert Review. IANA made the IEEE 802.11 Encryption Capabilities registry, and it goes like this:
IEEE 802.11 Encryption Capabilities Bit Position Reference11. Acknowledgments 🫶
huge thank you to these babes for their contributions to this binding spec: 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.[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>.[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>.
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📦 where this page comes from
- ietf: rfc5416 2009-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms