idnits 2.17.1 draft-ietf-capwap-protocol-specification-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 6076. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 6053. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 6060. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 6066. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 47 instances of too long lines in the document, the longest one being 21 characters in excess of 72. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 5, 2006) is 6538 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'ChangeCipherSpec' on line 1165 -- Looks like a reference, but probably isn't: 'DTLS' on line 1134 == Unused Reference: '2' is defined on line 5923, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 5927, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 5930, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 5952, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 5955, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 5965, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 5981, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 5984, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 5993, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 5996, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 5999, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 6002, but no explicit reference was found in the text == Unused Reference: '25' is defined on line 6007, but no explicit reference was found in the text == Unused Reference: '27' is defined on line 6012, but no explicit reference was found in the text == Unused Reference: '28' is defined on line 6014, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Downref: Normative reference to an Informational RFC: RFC 3610 (ref. '3') ** Obsolete normative reference: RFC 1750 (ref. '4') (Obsoleted by RFC 4086) ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '5') -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Downref: Normative reference to an Unknown state RFC: RFC 815 (ref. '8') ** Downref: Normative reference to an Informational RFC: RFC 3394 (ref. '9') ** Obsolete normative reference: RFC 1305 (ref. '10') (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 3280 (ref. '11') (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 4346 (ref. '14') (Obsoleted by RFC 5246) -- Possible downref: Non-RFC (?) normative reference: ref. '15' -- Possible downref: Non-RFC (?) normative reference: ref. '16' -- Possible downref: Non-RFC (?) normative reference: ref. '17' -- Possible downref: Non-RFC (?) normative reference: ref. '18' -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. '21') (Obsoleted by RFC 4301) Summary: 12 errors (**), 0 flaws (~~), 19 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Calhoun, Editor 3 Internet-Draft Cisco Systems, Inc. 4 Expires: November 6, 2006 M. Montemurro, Editor 5 Chantry Networks 6 D. Stanley, Editor 7 Aruba Networks 8 May 5, 2006 10 CAPWAP Protocol Specification 11 draft-ietf-capwap-protocol-specification-01 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on November 6, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 Wireless LAN product architectures have evolved from single 45 autonomous access points to systems consisting of a centralized 46 controller and Wireless Termination Points (WTPs). The general goal 47 of centralized control architectures is to move access control, 48 including user authentication and authorization, mobility management 49 and radio management from the single access point to a centralized 50 controller. 52 This specification defines the Control And Provisioning of Wireless 53 Access Points (CAPWAP) Protocol. The CAPWAP protocol meets the IETF 54 CAPWAP working group protocol requirements. The CAPWAP protocol is 55 designed to be flexible, allowing it to be used for a variety of 56 wireless technologies. This document describes the base CAPWAP 57 protocol, including an extension which supports the IEEE 802.11 58 wireless LAN protocol. Future extensions will enable support of 59 additional wireless technologies. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 64 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 1.2. Conventions used in this document . . . . . . . . . . . 8 66 1.3. Contributing Authors . . . . . . . . . . . . . . . . . . 8 67 1.4. Acknowledgements . . . . . . . . . . . . . . . . . . . . 10 68 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 11 69 2.1. Wireless Binding Definition . . . . . . . . . . . . . . 12 70 2.2. CAPWAP Session Establishment Overview . . . . . . . . . 12 71 2.3. CAPWAP State Machine Definition . . . . . . . . . . . . 14 72 2.3.1. CAPWAP Protocol State Transitions . . . . . . . . . 15 73 2.3.2. CAPWAP to DTLS Commands . . . . . . . . . . . . . . 22 74 2.3.3. DTLS to CAPWAP Notifications . . . . . . . . . . . 23 75 2.3.4. DTLS State Transitions . . . . . . . . . . . . . . 23 76 2.4. Use of DTLS in the CAPWAP Protocol . . . . . . . . . . . 26 77 2.4.1. DTLS Handshake Processing . . . . . . . . . . . . . 27 78 2.4.2. DTLS Error Handling . . . . . . . . . . . . . . . . 28 79 2.4.3. DTLS Rehandshake Behavior . . . . . . . . . . . . . 29 80 2.4.4. DTLS EndPoint Authentication . . . . . . . . . . . 32 81 3. CAPWAP Transport . . . . . . . . . . . . . . . . . . . . . . 35 82 3.1. UDP Transport . . . . . . . . . . . . . . . . . . . . . 35 83 3.2. AC Discovery . . . . . . . . . . . . . . . . . . . . . . 35 84 3.3. Fragmentation/Reassembly . . . . . . . . . . . . . . . . 36 85 4. CAPWAP Packet Formats . . . . . . . . . . . . . . . . . . . . 37 86 4.1. CAPWAP Transport Header . . . . . . . . . . . . . . . . 38 87 4.2. CAPWAP Data Messages . . . . . . . . . . . . . . . . . . 40 88 4.3. CAPWAP Control Messages . . . . . . . . . . . . . . . . 41 89 4.3.1. Control Message Format . . . . . . . . . . . . . . 41 90 4.3.2. Control Message Quality of Service . . . . . . . . 44 91 4.4. CAPWAP Protocol Message Elements . . . . . . . . . . . . 44 92 4.4.1. AC Descriptor . . . . . . . . . . . . . . . . . . . 45 93 4.4.2. AC IPv4 List . . . . . . . . . . . . . . . . . . . 46 94 4.4.3. AC IPv6 List . . . . . . . . . . . . . . . . . . . 46 95 4.4.4. AC Name . . . . . . . . . . . . . . . . . . . . . . 47 96 4.4.5. AC Name with Index . . . . . . . . . . . . . . . . 47 97 4.4.6. AC Timestamp . . . . . . . . . . . . . . . . . . . 48 98 4.4.7. Add MAC ACL Entry . . . . . . . . . . . . . . . . . 48 99 4.4.8. Add Mobile Station . . . . . . . . . . . . . . . . 49 100 4.4.9. Add Static MAC ACL Entry . . . . . . . . . . . . . 49 101 4.4.10. CAPWAP Timers . . . . . . . . . . . . . . . . . . . 50 102 4.4.11. Change State Event . . . . . . . . . . . . . . . . 50 103 4.4.12. Data Transfer Data . . . . . . . . . . . . . . . . 51 104 4.4.13. Data Transfer Mode . . . . . . . . . . . . . . . . 52 105 4.4.14. Decryption Error Report . . . . . . . . . . . . . . 52 106 4.4.15. Decryption Error Report Period . . . . . . . . . . 53 107 4.4.16. Delete MAC ACL Entry . . . . . . . . . . . . . . . 53 108 4.4.17. Delete Mobile Station . . . . . . . . . . . . . . . 54 109 4.4.18. Delete Static MAC ACL Entry . . . . . . . . . . . . 54 110 4.4.19. Discovery Type . . . . . . . . . . . . . . . . . . 55 111 4.4.20. Duplicate IPv4 Address . . . . . . . . . . . . . . 55 112 4.4.21. Duplicate IPv6 Address . . . . . . . . . . . . . . 56 113 4.4.22. Idle Timeout . . . . . . . . . . . . . . . . . . . 56 114 4.4.23. Image Data . . . . . . . . . . . . . . . . . . . . 57 115 4.4.24. Image Filename . . . . . . . . . . . . . . . . . . 57 116 4.4.25. Initiate Download . . . . . . . . . . . . . . . . . 58 117 4.4.26. Location Data . . . . . . . . . . . . . . . . . . . 58 118 4.4.27. MTU Discovery Padding . . . . . . . . . . . . . . . 59 119 4.4.28. Radio Administrative State . . . . . . . . . . . . 59 120 4.4.29. Result Code . . . . . . . . . . . . . . . . . . . . 60 121 4.4.30. Session ID . . . . . . . . . . . . . . . . . . . . 60 122 4.4.31. Statistics Timer . . . . . . . . . . . . . . . . . 61 123 4.4.32. Vendor Specific Payload . . . . . . . . . . . . . . 61 124 4.4.33. WTP Board Data . . . . . . . . . . . . . . . . . . 62 125 4.4.34. WTP Descriptor . . . . . . . . . . . . . . . . . . 63 126 4.4.35. WTP Fallback . . . . . . . . . . . . . . . . . . . 64 127 4.4.36. WTP Frame Encapsulation Type . . . . . . . . . . . 65 128 4.4.37. WTP IPv4 IP Address . . . . . . . . . . . . . . . . 66 129 4.4.38. WTP MAC Type . . . . . . . . . . . . . . . . . . . 66 130 4.4.39. WTP Radio Information . . . . . . . . . . . . . . . 67 131 4.4.40. WTP Manager Control IPv4 Address . . . . . . . . . 67 132 4.4.41. WTP Manager Control IPv6 Address . . . . . . . . . 68 133 4.4.42. WTP Name . . . . . . . . . . . . . . . . . . . . . 69 134 4.4.43. WTP Reboot Statistics . . . . . . . . . . . . . . . 69 135 4.4.44. WTP Static IP Address Information . . . . . . . . . 70 136 4.5. CAPWAP Protocol Timers . . . . . . . . . . . . . . . . . 71 137 4.5.1. DiscoveryInterval . . . . . . . . . . . . . . . . . 71 138 4.5.2. DTLSRehandshake . . . . . . . . . . . . . . . . . . 71 139 4.5.3. DTLSSessionDelete . . . . . . . . . . . . . . . . . 71 140 4.5.4. EchoInterval . . . . . . . . . . . . . . . . . . . 71 141 4.5.5. KeyLifetime . . . . . . . . . . . . . . . . . . . . 71 142 4.5.6. MaxDiscoveryInterval . . . . . . . . . . . . . . . 72 143 4.5.7. NeighborDeadInterval . . . . . . . . . . . . . . . 72 144 4.5.8. ResponseTimeout . . . . . . . . . . . . . . . . . . 72 145 4.5.9. RetransmitInterval . . . . . . . . . . . . . . . . 72 146 4.5.10. SilentInterval . . . . . . . . . . . . . . . . . . 72 147 4.5.11. WaitJoin . . . . . . . . . . . . . . . . . . . . . 72 148 4.6. CAPWAP Protocol Variables . . . . . . . . . . . . . . . 73 149 4.6.1. DiscoveryCount . . . . . . . . . . . . . . . . . . 73 150 4.6.2. MaxDiscoveries . . . . . . . . . . . . . . . . . . 73 151 4.6.3. MaxRetransmit . . . . . . . . . . . . . . . . . . . 73 152 4.6.4. RetransmitCount . . . . . . . . . . . . . . . . . . 73 153 5. CAPWAP Discovery Operations . . . . . . . . . . . . . . . . . 74 154 5.1. Discovery Request Message . . . . . . . . . . . . . . . 74 155 5.2. Discovery Response Message . . . . . . . . . . . . . . . 75 156 5.3. Primary Discovery Request Message . . . . . . . . . . . 75 157 5.4. Primary Discovery Response . . . . . . . . . . . . . . . 76 158 6. CAPWAP Join Operations . . . . . . . . . . . . . . . . . . . 77 159 6.1. Join Request . . . . . . . . . . . . . . . . . . . . . . 77 160 6.2. Join Response . . . . . . . . . . . . . . . . . . . . . 78 161 7. Control Channel Management . . . . . . . . . . . . . . . . . 79 162 7.1. Echo Request . . . . . . . . . . . . . . . . . . . . . . 79 163 7.2. Echo Response . . . . . . . . . . . . . . . . . . . . . 79 164 8. WTP Configuration Management . . . . . . . . . . . . . . . . 80 165 8.1. Configuration Consistency . . . . . . . . . . . . . . . 80 166 8.1.1. Configuration Flexibility . . . . . . . . . . . . . 81 167 8.2. Configuration Status . . . . . . . . . . . . . . . . . . 81 168 8.3. Configuration Status Response . . . . . . . . . . . . . 82 169 8.4. Configuration Update Request . . . . . . . . . . . . . . 82 170 8.5. Configuration Update Response . . . . . . . . . . . . . 83 171 8.6. Change State Event Request . . . . . . . . . . . . . . . 84 172 8.7. Change State Event Response . . . . . . . . . . . . . . 84 173 8.8. Clear Config Indication . . . . . . . . . . . . . . . . 85 174 9. Device Management Operations . . . . . . . . . . . . . . . . 86 175 9.1. Image Data Request . . . . . . . . . . . . . . . . . . . 86 176 9.2. Image Data Response . . . . . . . . . . . . . . . . . . 87 177 9.3. Reset Request . . . . . . . . . . . . . . . . . . . . . 87 178 9.4. Reset Response . . . . . . . . . . . . . . . . . . . . . 87 179 9.5. WTP Event Request . . . . . . . . . . . . . . . . . . . 87 180 9.6. WTP Event Response . . . . . . . . . . . . . . . . . . . 88 181 9.7. Data Transfer Request . . . . . . . . . . . . . . . . . 88 182 9.8. Data Transfer Response . . . . . . . . . . . . . . . . . 88 183 10. Mobile Session Management . . . . . . . . . . . . . . . . . . 90 184 10.1. Mobile Config Request . . . . . . . . . . . . . . . . . 90 185 10.2. Mobile Config Response . . . . . . . . . . . . . . . . . 90 186 11. IEEE 802.11 Binding . . . . . . . . . . . . . . . . . . . . . 91 187 11.1. Split MAC and Local MAC Functionality . . . . . . . . . 91 188 11.1.1. Split MAC . . . . . . . . . . . . . . . . . . . . . 91 189 11.1.2. Local MAC . . . . . . . . . . . . . . . . . . . . . 93 190 11.2. Roaming Behavior . . . . . . . . . . . . . . . . . . . . 96 191 11.3. Group Key Refresh . . . . . . . . . . . . . . . . . . . 97 192 11.4. Transport specific bindings . . . . . . . . . . . . . . 97 193 11.5. BSSID to WLAN ID Mapping . . . . . . . . . . . . . . . . 99 194 11.6. Quality of Service for Control Messages . . . . . . . . 99 195 11.7. IEEE 802.11 Specific CAPWAP Control Messages . . . . . . 100 196 11.7.1. IEEE 802.11 WLAN Config Request . . . . . . . . . . 100 197 11.7.2. IEEE 802.11 WLAN Config Response . . . . . . . . . 101 198 11.8. Data Message bindings . . . . . . . . . . . . . . . . . 101 199 11.9. Control Message bindings . . . . . . . . . . . . . . . . 101 200 11.9.1. Mobile Config Request . . . . . . . . . . . . . . . 101 201 11.9.2. WTP Event Request . . . . . . . . . . . . . . . . . 101 202 11.9.3. Configuration Messages . . . . . . . . . . . . . . 102 203 11.10. IEEE 802.11 Message Element Definitions . . . . . . . . 102 204 11.10.1. IEEE 802.11 Add WLAN . . . . . . . . . . . . . . . 102 205 11.10.2. IEEE 802.11 Antenna . . . . . . . . . . . . . . . . 106 206 11.10.3. IEEE 802.11 Assigned WTP BSSID . . . . . . . . . . 107 207 11.10.4. IEEE 802.11 Broadcast Probe Mode . . . . . . . . . 108 208 11.10.5. IEEE 802.11 Delete WLAN . . . . . . . . . . . . . . 108 209 11.10.6. IEEE 802.11 Direct Sequence Control . . . . . . . . 109 210 11.10.7. IEEE 802.11 Information Element . . . . . . . . . . 110 211 11.10.8. IEEE 802.11 MAC Operation . . . . . . . . . . . . . 110 212 11.10.9. IEEE 802.11 MIC Countermeasures . . . . . . . . . . 112 213 11.10.10. IEEE 802.11 MIC Error Report From Mobile . . . . . 112 214 11.10.11. IEEE 802.11 Mobile . . . . . . . . . . . . . . . . 113 215 11.10.12. IEEE 802.11 Mobile Session Key . . . . . . . . . . 114 216 11.10.13. IEEE 802.11 Multi-domain Capability . . . . . . . . 116 217 11.10.14. IEEE 802.11 OFDM Control . . . . . . . . . . . . . 117 218 11.10.15. IEEE 802.11 Rate Set . . . . . . . . . . . . . . . 118 219 11.10.16. IEEE 802.11 Statistics . . . . . . . . . . . . . . 118 220 11.10.17. IEEE 802.11 Supported Rates . . . . . . . . . . . . 120 221 11.10.18. IEEE 802.11 Tx Power . . . . . . . . . . . . . . . 121 222 11.10.19. IEEE 802.11 Tx Power Level . . . . . . . . . . . . 121 223 11.10.20. IEEE 802.11 Update Mobile QoS . . . . . . . . . . . 122 224 11.10.21. IEEE 802.11 Update WLAN . . . . . . . . . . . . . . 122 225 11.10.22. IEEE 802.11 WTP Quality of Service . . . . . . . . 125 226 11.10.23. IEEE 802.11 WTP Radio Fail Alarm Indication . . . . 126 227 11.10.24. IEEE 802.11 WTP Radio Configuration . . . . . . . . 127 228 11.10.25. Station QoS Profile . . . . . . . . . . . . . . . . 128 229 11.11. Technology Specific Message Element Values . . . . . . . 129 230 12. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 130 231 13. Security Considerations . . . . . . . . . . . . . . . . . . . 132 232 13.1. CAPWAP Security . . . . . . . . . . . . . . . . . . . . 132 233 13.1.1. Converting Protected Data into Unprotected Data . . 133 234 13.1.2. Converting Unprotected Data into Protected Data 235 (Insertion) . . . . . . . . . . . . . . . . . . . . 133 236 13.1.3. Deletion of Protected Records . . . . . . . . . . . 133 237 13.1.4. Insertion of Unprotected Records . . . . . . . . . 133 238 13.2. Use of Preshared Keys in CAPWAP . . . . . . . . . . . . 133 239 13.3. Use of Certificates in CAPWAP . . . . . . . . . . . . . 134 240 13.4. AAA Security . . . . . . . . . . . . . . . . . . . . . . 134 241 13.5. IEEE 802.11 Security . . . . . . . . . . . . . . . . . . 135 242 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 136 243 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 137 244 15.1. Normative References . . . . . . . . . . . . . . . . . . 137 245 15.2. Informational References . . . . . . . . . . . . . . . . 138 246 Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 140 247 Intellectual Property and Copyright Statements . . . . . . . . . 141 249 1. Introduction 251 The emergence of centralized architectures, in which simple IEEE 252 802.11 WTPs are managed by an Access Controller (AC) suggests that a 253 standards based, interoperable protocol could radically simplify the 254 deployment and management of wireless networks. WTPs require a set 255 of dynamic management and control functions related to their primary 256 task of connecting the wireless and wired mediums. Traditional 257 protocols for managing WTPs are either manual static configuration 258 via HTTP, proprietary Layer 2 specific or non-existent (if the WTPs 259 are self-contained). This document describes the CAPWAP Protocol, a 260 standard, interoperable protocol which enables an AC to manage a 261 collection of WTPs. While the protocol is defined to be independent 262 of layer 2 technology, an IEEE 802.11 binding is provided to support 263 IEEE 802.11 wireless LAN networks. 265 CAPWAP assumes a network configuration consisting of multiple WTPs 266 communicating via the Internet Protocol (IP) to an AC. WTPs are 267 viewed as remote RF interfaces controlled by the AC. The AC forwards 268 all L2 frames to be transmitted by a WTP to that WTP via the CAPWAP 269 protocol. L2 frames from mobile nodes (STAs) are forwarded by the 270 WTP to the AC using the CAPWAP protocol. Both Split-MAC and Local 271 MAC arhcitectures are supported. Figure 1 illustrates this 272 arrangement as applied to an IEEE 802.11 binding. 274 +-+ 802.11 frames +-+ 275 | |--------------------------------| | 276 | | +-+ | | 277 | |--------------| |---------------| | 278 | | 802.11 PHY/ | | CAPWAP | | 279 | | MAC sublayer | | | | 280 +-+ +-+ +-+ 281 STA WTP AC 283 Figure 1: Representative CAPWAP Architecture for Split MAC 285 Provisioning WTPs with security credentials, and managing which WTPs 286 are authorized to provide service are traditionally handled by 287 proprietary solutions. Allowing these functions to be performed from 288 a centralized AC in an interoperable fashion increases manageability 289 and allows network operators to more tightly control their wireless 290 network infrastructure. 292 1.1. Goals 294 The goals for the CAPWAP protocol are listed below: 296 1. To centralize the bridging, forwarding, authentication and policy 297 enforcement functions for a wireless network. Optionally, the AC 298 may also provide centralized encryption of user traffic. 299 Centralization of these functions will enable reduced cost and 300 higher efficiency by applying the capabilities of network 301 processing silicon to the wireless network, as in wired LANs. 303 2. To enable shifting of the higher level protocol processing from 304 the WTP. This leaves the time critical applications of wireless 305 control and access in the WTP, making efficient use of the 306 computing power available in WTPs which are the subject to severe 307 cost pressure. 309 3. To provide a generic encapsulation and transport mechanism, 310 enabling the CAPWAP protocol to be applied to other access point 311 types in the future, via a specific wireless binding. 313 The CAPWAP protocol concerns itself solely with the interface between 314 the WTP and the AC. Inter-AC, or mobile node (STA) to AC 315 communication is strictly outside the scope of this document. 317 1.2. Conventions used in this document 319 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 320 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 321 document are to be interpreted as described in RFC 2119 [1]. 323 1.3. Contributing Authors 325 This section lists and acknowledges the authors of significant text 326 and concepts included in this specification. [Note: This section 327 needs work to accurately reflect the contribution of each author and 328 this work will be done in revision 01 of this document.] 330 The CAPWAP Working Group selected the Lightweight Access Point 331 Protocol (LWAPP) [add reference, when available]to be used as the 332 basis of the CAPWAP protocol specification. The following people are 333 authors of the LWAPP document: 335 Bob O'Hara, Cisco Systems, Inc.,170 West Tasman Drive, San Jose, CA 95134 336 Phone: +1 408-853-5513, Email: bob.ohara@cisco.com 338 Pat Calhoun, Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134 339 Phone: +1 408-853-5269, Email: pcalhoun@cisco.com 341 Rohit Suri, Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134 342 Phone: +1 408-853-5548, Email: rsuri@cisco.com 344 Nancy Cam Winget, Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134 345 Phone: +1 408-853-0532, Email: ncamwing@cisco.com 347 Scott Kelly, Aruba Networks, 1322 Crossman Ave, Sunnyvale, CA 94089 348 Phone: +1 408-754-8408, Email: skelly@arubanetworks.com 350 Michael Glenn Williams, Nokia, Inc., 313 Fairchild Drive, Mountain View, CA 94043 351 Phone: +1 650-714-7758, Email: Michael.G.Williams@Nokia.com 353 Sue Hares, Nexthop Technologies, Inc., 825 Victors Way, Suite 100, Ann Arbor, MI 48108 354 Phone: +1 734 222 1610, Email: shares@nexthop.com 356 DTLS is used as the security solution for the CAPWAP protocol. The 357 following people are authors of significant DTLS-related text 358 included in this document: 360 Scott Kelly, Aruba Networks, 1322 Crossman Ave, Sunnyvale, CA 94089 361 Phone: +1 408-754-8408, Email: skelly@arubanetworks.com 363 Eric Rescorla, Network Resonance, 2483 El Camino Real, #212,Palo Alto CA, 94303 364 Email: ekr@networkresonance.com 366 The concept of using DTLS to secure the CAPWAP protocol was part of 367 the Secure Light Access Point Protocol (SLAPP) proposal [add 368 reference when available]. The following people are authors of the 369 SLAPP proposal: 371 Partha Narasimhan, Aruba Networks, 1322 Crossman Ave, Sunnyvale, CA 94089 372 Phone: +1 408-480-4716, Email: partha@arubanetworks.com 374 Dan Harkins, Tropos Networks, 555 Del Rey Avenue, Sunnyvale, CA, 95085 375 Phone: +1 408 470 7372, Email: dharkins@tropos.com 377 Subbu Ponnuswamy, Aruba Networks, 1322 Crossman Ave, Sunnyvale, CA 94089 378 Phone: +1 408-754-1213, Email: subbu@arubanetworks.com 380 1.4. Acknowledgements 382 The authors thank Michael Vakulenko for contributing text that 383 describes how CAPWAP can be used over a layer 3 (IP/UDP) network. 385 The authors thank Russ Housley and Charles Clancy for their 386 assistance in provide a security review of the LWAPP specification. 387 Charles' review can be found at [16]. 389 2. Protocol Overview 391 The CAPWAP protocol is a generic protocol defining AC and WTP control 392 and data plane communication via a CAPWAP protocol transport 393 mechanism. CAPWAP control messages, and optionally CAPWAP data 394 messages, are secured using Datagram Transport Layer Security (DTLS) 395 [14]. DTLS is a standards-track IETF protocol based upon TLS. The 396 underlying security-related protocol mechanisms of TLS have been 397 successfully deployed for many years. 399 The CAPWAP protocol Transport layer carries two types of payload, 400 CAPWAP Data messages and CAPWAP Control messages. CAPWAP Data 401 messages are forwarded wireless frames. CAPWAP protocol Control 402 messages are management messages exchanged between a WTP and an AC. 403 The CAPWAP Data and Control packets are sent over separate UDP ports. 404 Since both data and control frames can exceed the PMTU, the payload 405 of a CAPWAP data or control message can be fragmented. The 406 fragmentation behavior is defined in Section 3. 408 The CAPWAP Protocol begins with a discovery phase. The WTPs send a 409 Discovery Request message, causing any Access Controller (AC) 410 receiving the message to respond with a Discovery Response message. 411 From the Discovery Response messages received, a WTP will select an 412 AC with which to establish a secure DTLS session. CAPWAP protocol 413 messages will be fragmented to the maximum length discovered to be 414 supported by the network. 416 Once the WTP and the AC have completed DTLS session establishment, a 417 configuration exchange occurs in which both devices to agree on 418 version information. During this exchange the WTP may receive 419 provisioning settings. For the IEEE 802.11 binding, this information 420 typically includes a name (IEEE 802.11 Service Set Identifier, SSID) 421 security parameters, the data rates to be advertised and the 422 associated radio channel(s) to be used. The WTP is then enabled for 423 operation. 425 When the WTP and AC have completed the version and provision exchange 426 and the WTP is enabled, the CAPWAP protocol is used to encapsulate 427 the wireless data frames sent between the WTP and AC. The CAPWAP 428 protocol will fragment the L2 frames if the size of the encapsulated 429 wireless user data (Data) or protocol control (Management) frames 430 causes the resulting CAPWAP protocol packet to exceed the MTU 431 supported between the WTP and AC. Fragmented CAPWAP packets are 432 reassembled to reconstitute the original encapsulated payload. 434 The CAPWAP protocol provides for the delivery of commands from the AC 435 to the WTP for the management of mobile units (STAs) that are 436 communicating with the WTP. This may include the creation of local 437 data structures in the WTP for the mobile units and the collection of 438 statistical information about the communication between the WTP and 439 the mobile units. The CAPWAP protocol provides a mechanism for the 440 AC to obtain statistical information collected by the WTP. 442 The CAPWAP protocol provides for a keep alive feature that preserves 443 the communication channel between the WTP and AC. If the AC fails to 444 appear alive, the WTP will try to discover a new AC. 446 This Document uses terminology defined in [5]. 448 2.1. Wireless Binding Definition 450 The CAPWAP protocol is independent of a specific WTP radio 451 technology. Elements of the CAPWAP protocol are designed to 452 accommodate the specific needs of each wireless technology in a 453 standard way. Implementation of the CAPWAP protocol for a particular 454 wireless technology must follow the binding requirements defined for 455 that technology. This specification includes a binding for the IEEE 456 802.11 standard(see Section 11). 458 When defining a binding for other wireless technologies, the authors 459 MUST include any necessary definitions for technology-specific 460 messages and all technology-specific message elements for those 461 messages. At a minimum, a binding MUST provide the definition for a 462 binding-specific Statistics message element, carried in the WTP Event 463 Request message, and a Mobile message element, carried in the Mobile 464 Configure Request. If technology specific message elements are 465 required for any of the existing CAPWAP messages defined in this 466 specification, they MUST also be defined in the technology binding 467 document. 469 The naming of binding-specific message elements MUST begin with the 470 name of the technology type, e.g., the binding for IEEE 802.11, 471 provided in this specification, begins with "IEEE 802.11"." 473 2.2. CAPWAP Session Establishment Overview 475 This section describes the session establishment process message 476 exchanges in the ideal case. The annotated ladder diagram shows the 477 AC on the right, the WTP on the left, and assumes the use of 478 certificates for DTLS authentication. The CAPWAP Protocol State 479 Machine is described in detail in Section 2.3. 481 ============ ============ 482 WTP AC 483 ============ ============ 484 [----------- begin optional discovery ------------] 485 Discover Request ------> 486 <------ Discover Response 488 [----------- end optional discovery ------------] 490 (--- begin dtls handshake ---) 492 ClientHello ------> 493 <------ HelloVerifyRequest 494 (with cookie) 496 ClientHello ------> 497 (with cookie) 498 <------ ServerHello 499 <------ Certificate 500 <------ ServerHelloDone 502 (WTP callout for AC authorization) 504 Certificate* 505 ClientKeyExchange 506 CertificateVerify* 507 [ChangeCipherSpec] 508 Finished ------> 510 (AC callout for WTP 511 authorization) 513 [ChangeCipherSpec] 514 <------ Finished 516 (--- DTLS session is established now ---) 518 Join Request ------> 519 <------ Join Response 521 ( ---assume image is up to date ---) 523 Configure Request -------> 524 <------ Configure Response 526 (--- enter RUN state ---) 528 : 529 : 531 Echo Request -------> 532 <------ Echo Response 533 : 534 : 536 EventRequest -------> 537 <------ Event Response 539 : 540 : 542 At the end of the illustrated CAPWAP message exchange, the AC and WTP 543 are securely exchanging CAPWAP control messages. This is an 544 idealized illustration, provided to clarify protocol operation. 545 Section 2.3 provides a detailed description of the corresponding 546 state machine. 548 2.3. CAPWAP State Machine Definition 550 The following state diagram represents the lifecycle of a WTP-AC 551 session. Use of DTLS by the CAPWAP protocol results in the 552 juxtaposition of two nominally separate yet tightly bound state 553 machines. The DTLS and CAPWAP state machines are coupled through an 554 API consisting of commands (from CAPWAP to DTLS) and notifications 555 (from (DTLS to CAPWAP). Certain transitions in the DTLS state 556 machine are triggered by commands from the CAPWAP state machine, 557 while certain transitions in the CAPWAP state machine are triggered 558 by notifications from the DTLS state machine. 560 This section defines the CAPWAP Integrated State Machine. In the 561 figure below, single lines (denoted with '-' and '|') are used to 562 illustrate state transitions. Double lines (denoted with '=' and 563 '"') are used to illustrate commands and notifications between DTLS 564 and CAPWAP. A line composed of '~' characters is used to delineate 565 the boundary between nominal CAPWAP and DTLS state machine 566 components. 568 /-------------<----------------+--------------------\ 569 v |d | 570 +------+ b+-----------+ +----------+ | 571 | Idle |-->| Discovery |--->| Sulking | | 572 +------+ a +-----------+ c +----------+ | 573 ^ |aa ^ |e /----------------------\ | 574 | V f| v k| | | 575 h +--------------+ +------------+ i +------------+j | | 576 /--| Join |->| Configure |-->| Image Data | | | 577 | +--------------+ g+------------+ +------------+ | | 578 | "c1, ^ ^ ^ m| ^ |l | | 579 | "c4 " " " | /-------/ | /----/ | 580 | " " " " V |s v V | 581 | " " " " +------------+ o+------------+ | 582 | " " " " | Run |->| Reset |-------/ 583 | " " " " n+------------+ +------------+ p 584 | " " " " "c2 ^ ^ c3" ^ 585 \---"-----"--"---"--------"----"-------/ " " CAPWAP 586 ~~~~~~~"~~~~~"~~"~~~"~~~~~~~~"~~~~"~~~~~~~~~~~~"~~~"~~~~~~~~~~~~ 587 " " " " " " " " DTLS 588 v " "n2 \"""""\ " " v "n6,n7 589 /-->+------+ " W+------+ " " " +------------+ 590 | /-| Idle | " C| Auth |--"~-"----"----->| Shutdown |-------\P 591 | | +------+ " +------+V " " " /--->| |<----\ | 592 | |X Z| " ^ U| " " n4 " | +------------+ | | 593 | | | " | | " " n5," | ^ | | 594 | | v "n1 |Y | n3" v n8" |R |Q | | 595 | | +--------+ | +------------+ S+------------+ | | 596 | | | Init | \->| Run |<--| Rekey | | | 597 | | +--------+ | |-->| | | | 598 | | +------------+T +------------+ | | 599 | \---------------------------------------------------------/ | 600 \-------------------------------------------------------------/ 602 Figure 2: CAPWAP Integrated State Machine 604 The CAPWAP protocol state machine, depicted above, is used by both 605 the AC and the WTP. In cases where states are not shared (i.e. not 606 implemented in one or the other of the AC or WTP), this is explicitly 607 called out in the transition descriptions below. For every state 608 defined, only certain messages are permitted to be sent and received. 609 The CAPWAP control messages definitions specify the state(s) in which 610 each message is valid. 612 2.3.1. CAPWAP Protocol State Transitions 614 The following text discusses the various state transitions, and the 615 events that cause them. This section does not discuss interactions 616 between DTLS- and CAPWAP-specific states. Those interactions, as 617 well as DTLS-specific states and transitions, are discussed in 618 subsequent sections. 620 Idle to Discovery (a): This transition occurs once device 621 initialization is complete. 623 WTP: The WTP enters the Discovery state prior to transmitting the 624 first Discovery Request message (see Section 5.1). Upon 625 entering this state, the WTP sets the DiscoveryInterval timer 626 (see Section 4.5). The WTP resets the DiscoveryCount counter 627 to zero (0) (see Section 4.6). The WTP also clears all 628 information from ACs it may have received during a previous 629 Discovery phase. 631 AC: The AC does not maintain state information for the WTP upon 632 reception of the Discovery Request message, but it SHOULD 633 respond with a Discovery Response message (see Section 5.2). 634 This transition is a no-op for the AC. 636 Idle to Join (aa): This transition occurs when the WTP presents a 637 DTLS ClientHello message containing a valid cookie to the AC. 639 WTP: This transition is a no-op for the WTP. 641 AC: The AC does not maintain state information until the WTP 642 presents a DTLS ClientHello message containing a valid cookie. 643 Upon receipt of a DTLS ClientHello message containing a valid 644 cookie, the AC creates session state and transitions to the 645 Join state. 647 Discovery to Discovery (b): In the Discovery state, the WTP 648 determines which AC to connect to. 650 WTP: This transition occurs when the DiscoveryInterval timer 651 expires. If the WTP is configured with a list of ACs, it 652 transmits a Discovery Request message to every AC from which it 653 has not received a Discovery Response message. For every 654 transition to this event, the WTP increments the DiscoveryCount 655 counter. See Section 5.1 for more information on how the WTP 656 knows the ACs to which it should transmit the Discovery Request 657 messages. The WTP restarts the DiscoveryInterval timer 658 whenever it transmits Discovery Request messages. 660 AC: This is a no-op. 662 Discovery to Sulking (c): This transition occurs on a WTP when 663 Discovery or connectivity to the AC fails. 665 WTP: The WTP enters this state when the DiscoveryInterval timer 666 expires and the DiscoveryCount variable is equal to the 667 MaxDiscoveries variable (see Section 4.6). Upon entering this 668 state, the WTP shall start the SilentInterval timer. While in 669 the Sulking state, all received CAPWAP protocol messages 670 received shall be ignored. 672 AC: This is a no-op. 674 Sulking to Idle (d): This transition occurs on a WTP when it must 675 restart the discovery phase. 677 WTP: The WTP enters this state when the SilentInterval timer (see 678 Section 4.5) expires. 680 AC: This is a no-op. 682 Discovery to Join (e): This transition occurs when the WTP sends a 683 ClientHello message to the AC, confirming that it wishes to be 684 provided services by the AC. 686 WTP: The WTP selects the best AC based either on information it 687 gathered during the Discovery Phase or on its configuration. 688 It then sends a JoinRequest message to its preferred AC, sets 689 the WaitJoin timer, and awaits the Join Response Message. 691 AC: This is a no-op for the AC. 693 Join to Discovery (f): This state transition is used to return the 694 WTP to the Discovery state when an unresponsive AC is encountered. 696 WTP: The WTP re-enters the Discovery state when the WaitJoin timer 697 expires. 699 AC: This is a no-op. 701 Join to Configure (g): This state transition is used by the WTP and 702 the AC to exchange configuration information. 704 WTP: The WTP enters the Configure state when it successfully 705 completes the Join operation. If it determines that its 706 version number and the version number advertised by the AC are 707 the same, the WTP transmits the Configuration Status message 708 (see Section 8.2) to the AC with a snapshot of its current 709 configuration. The WTP also starts the ResponseTimeout timer 710 (see ). (Section 4.5) If the version numbers are not the same, 711 the WTP will immediately transition to Image Data state (see 712 transition (i)). 714 AC: This state transition occurs immediately after the AC 715 transmits the Join Response message to the WTP. If the AC 716 receives the Configuration Status message from the WTP, the AC 717 must transmit a Configuration Status Response message(see 718 Section 8.3) to the WTP, and may include specific message 719 elements to override the WTP's configuration. If the AC 720 instead receives the Image Data Request from the WTP, it 721 immediately transitions to the Image Data state (see transition 722 (i)). 724 Join to Reset (h): This state transition occurs when the WaitJoin 725 Timer expires. 727 WTP: The state transition occurs when the WTP WaitJoin timer 728 expires, or upon DTLS negotiation failure. 730 AC: Thise state transition occurs when the AC WaitJoin timer 731 expires, or or upon DTLS negotiation failure. 733 Configure to Image Data (i): This state transition is used by the WTP 734 and the AC to download executable firmware. 736 WTP: The WTP enters the Image Data state when it successfully 737 comletes DTLS session establishment, and determines that its 738 version number and the version number advertised by the AC are 739 different. The WTP transmits the Image Data Request (see 740 Section 9.1) message requesting that a download of the AC's 741 latest firmware be initiated. 743 AC: This state transition occurs when the AC receives the Image 744 Data Request message from the WTP. The AC must transmit an 745 Image Data Response message (see Section 9.2) to the WTP, which 746 includes a portion of the firmware. 748 Image Data to Image Data (j): The Image Data state is used by WTP and 749 the AC during the firmware download phase. 751 WTP: The WTP enters the Image Data state when it receives an Image 752 Data Response message indicating that the AC has more data to 753 send. 755 AC: This state transition occurs when the AC receives the Image 756 Data Request message from the WTP while already in the Image 757 Data state, and it detects that the firmware download has not 758 completed. 760 Configure to Reset (k): This state transition is used to reset the 761 connection to the AC prior to restarting the WTP with a new 762 configuration. 764 WTP: The WTP enters the Reset state when it determines that a 765 reset of the WTP is required, due to the characteristics of a 766 new configuration. 768 AC: The AC transitions to the Reset state when it receives the 769 DTLSPeerDisconnect (n7) notification. 771 Image Data to Reset (l): This state transition is used to reset the 772 DTLS connection prior to restarting the WTP after an image 773 download. 775 WTP: When an image download completes, the WTP enters the Reset 776 state, and terminates the DTLS connection, sending a 777 DTLSShutdown command to the DTLS state machine. 779 AC: The AC enters the Reset state upon receipt of a DTLSIdle (n6) 780 notification. 782 Configure to Run (m): This state transition occurs when the WTP and 783 AC enter their normal state of operation. 785 WTP: The WTP enters this state when it receives a successful 786 Configuration Status Response message from the AC. The WTP 787 initializes the HeartBeat timer (see Section 4.5), and 788 transmits the Change State Event Request message (see 789 Section 8.6). 791 AC: This state transition occurs when the AC receives the Change 792 State Event Request message (see Section 8.6) from the WTP. 793 The AC responds with a Change State Event Response (see 794 Section 8.7) message. The AC must start the 795 NeighborDeadInterval timer (see Section 4.5). 797 Run to Run (n): This is the normal state of operation. 799 WTP: This is the WTP's normal state of operation. There are many 800 events that result this state transition: 802 Configuration Update: The WTP receives a Configuration Update 803 Request message(see Section 8.4). The WTP MUST respond with 804 a Configuration Update Response message (see Section 8.5). 806 Change State Event: The WTP receives a Change State Event 807 Response message, or determines that it must initiate a 808 Change State Event Request message, as a result of a failure 809 or change in the state of a radio. 811 Echo Request: The WTP receives an Echo Request message (see 812 Section 7.1), to which it MUST respond with an Echo Response 813 message(see Section 7.2). 815 Clear Config Indication: The WTP receives a Clear Config 816 Indication message (see Section 8.8). The WTP MUST reset 817 its configuration back to manufacturer defaults. 819 WTP Event: The WTP generates a WTP Event Request message to 820 send information to the AC (see Section 9.5). The WTP 821 receives a WTP Event Response message from the AC (see 822 Section 9.6). 824 Data Transfer: The WTP generates a Data Transfer Request 825 message to the AC (see Section 9.7). The WTP receives a 826 Data Transfer Response message from the AC (see 827 Section 9.8). 829 WLAN Config Request: The WTP receives a WLAN Config Request 830 message (see Section 11.7.1), to which it MUST respond with 831 a WLAN Config Response message (see Section 11.7.2). 833 Mobile Config Request: The WTP receives a Mobile Config Request 834 message (see Section 10.1), to which it MUST respond with a 835 Mobile Config Response message (see Section 10.2). 837 AC: This is the AC's normal state of operation: 839 Configuration Update: The AC sends a Configuration Update 840 Request message (see Section 8.4) to the WTP to update its 841 configuration. The AC receives a Configuration Update 842 Response message (see Section 8.5) from the WTP. 844 Change State Event: The AC receives a Change State Event 845 Request message (see Section 8.6), to which it MUST respond 846 with the Change State Event Response message (see 847 Section 8.7). 849 Echo: The AC sends an Echo Request message Section 7.1 or 850 receives the corresponding Echo Response message, see 851 Section 7.2 from the WTP. 853 Clear Config Indication: The AC sends a Clear Config Indication 854 message (see Section 8.8). 856 WLAN Config: The AC sends a WLAN Config Request message (see 857 Section 11.7.1) or receives the corresponding WLAN Config 858 Response message (see Section 11.7.2) from the WTP. 860 Mobile Config: The AC sends a Mobile Config Request message 861 (see Section 10.1) or receives the corresponding Mobile 862 Config Response message (see Section 10.2) from the WTP. 864 Data Transfer: The AC receives a Data Transfer Request message 865 from the AC (see Section 9.7) and MUST generate a 866 corresponding Data Transfer Response message (see 867 Section 9.8). 869 WTP Event: The AC receives a WTP Event Request message from the 870 AC (see Section 9.5) and MUST generate a corresponding WTP 871 Event Response message (see Section 9.6). 873 Run to Reset(o): This state transition is used when the AC or WTP 874 wish to tear down the connection. This may occur as part of 875 normal operation, or due to error conditions. 877 WTP: The WTP enters the Reset state when it initiates orderly 878 termination of the DTLS connection, or when the underlying 879 reliable transport is unable to transmit a message within the 880 RetransmitInterval timer, see Section 4.5 The WTP also enters 881 the Reset state upon receiving a DTLS session termination 882 message (DTLS alert) from the AC. The WTP sends a DTLSReset 883 command to the DTLS state machine. 885 AC: The AC enters the Idle state when it initiates orderly 886 termination of the DTLS connection, or when the underlying 887 reliable transport is unable to transmit a message within the 888 RetransmitInterval timer (see Section 4.5), and the maximum 889 number of RetransmitCount counter has reached the MaxRetransmit 890 variable (see Section 4.6). The AC also enters the Reset state 891 upon receiving a DTLS session termination message from the WTP. 893 Reset to Idle (p): This state transition occurs when the state 894 machine is restarted following a system restart, an unrecoverable 895 error on the AC-WTP connection, or orderly session teardown. 897 WTP: The WTP clears any state associated with any AC and enters 898 the Idle state. 900 AC: The AC clears any state associated with the WTP and enters the 901 idle state. 903 Run to Image Data (s): This state transition occurs when the AC 904 transmits an Image Data Request to the WTP, with the Initiate 905 Download message element. The means by which the AC decides to 906 download firmware is undefined, but could occur through an 907 administrative action. 909 WTP: The WTP enters this state when it receives an an Image Data 910 Request to the WTP, with the Initiate Download message element. 911 The WTP responds by transmitting an Image Data Request with the 912 Image Filename message element included.. 914 AC: This state transition occurs when the AC decides that an WTP 915 is to update its firmware by sending an Image Data Request to 916 the WTP, with the Initiate Download message element. 918 2.3.2. CAPWAP to DTLS Commands 920 Four commands are defined for the CAPWAP to DTLS API. These 921 "commands" are conceptual, and may be implemented as one or more 922 function calls. This API definition is provided to clarify 923 interactions between the DTLS and CAPWAP components of the integrated 924 CAPWAP state machine. 926 Below is a list of the minimal command API: 928 o c1: DTLSStart is sent to the DTLS module to cause a DTLS session 929 to be established. 931 o c2: DTLSRehandshake is sent to the DTLS module to cause initiation 932 of a rehandshake (DTLS rekey). 934 o c3: DTLSShutdown is sent to the DTLS module to cause session 935 teardown. 937 o c4: DTLSAbort is sent to the DTLS module to cause session teardown 938 when the WaitJoin timer expires. 940 2.3.3. DTLS to CAPWAP Notifications 942 Eight notifications are defined for the DTLS to CAPWAP API. These 943 "notifications" are conceptual, and may be implemented in numerous 944 ways (e.g. as function return values). This API definition is 945 provided to clarify interactions between the DTLS and CAPWAP 946 components of the integrated CAPWAP state machine. 948 Below is a list of the API notifications: 950 o n1: DTLSInitFailure is sent to the CAPWAP module to indicate an 951 initialization failure, which may be due to out of memory or other 952 internal error condition. 954 o n2: DTLSAuthenticateFail or DTLSAuthorizeFail is sent to the 955 CAPWAP module to indicate peer authentication or authorization 956 failures, respectively. 958 o n3: DTLSEstablished is sent to the CAPWAP module to indicate that 959 that a secure channel now exists. 961 o n4: DTLSEncapFailure may be sent to CAPWAP to indicate an 962 encapsulation failure. DTLSDecapFailure may be sent to CAPWAP to 963 indicate an encryption/authentication failure 965 o n5: DTLSRehandshake is sent to the CAPWAP module to indicate DTLS 966 rehandshake initiation by peer. 968 o n6: DTLSIdle is sent to the CAPWAP module to indicate that session 969 abort (as requested by CAPWAP) is complete; this occurs when the 970 WaitJoin timer expires, or when CAPWAP is executing an orderly 971 session shutdown. 973 o n7: DTLSPeerDisconnect is sent to the CAPWAP module to indicate 974 DTLS session teardown by peer. Note that the n7 notification, can 975 be received while in the Join, Configure, Image Data, Run and 976 Reset states, and always causes a transition to the Reset state. 978 o n8: DTLSReassemblyFailure may be sent to the CAPWAP module to 979 indicate DTLS fragment reassembly failure. 981 2.3.4. DTLS State Transitions 983 This section describes the transitions in the DTLS-specific portion 984 of the state machine. 986 Idle to Init (Z): This transition indicates the begining of a DTLS 987 session. 989 WTP: The state ransition is triggered by receipt of the DTLSStart 990 command from the CAPWAP state machine, and causes the WTP to 991 send a DTLS ClientHello to the AC. 993 AC: The state transition is triggered by receipt of the DTLSStart 994 command from the CAPWAP state machine. The AC starts the 995 WaitJoin timer and awaits reception of a DTLS ClientHello 996 message 998 Init to Authenticate/Authorize (Y) This transition indicates that the 999 DTLS handshake is in progress. 1001 WTP: The WTP executes this state transition upon receipt of a 1002 valid ServerHello. 1004 AC: The AC executes this transition upon receipt of a certificate 1005 payload (if configured for public key authentication) or upon 1006 receipt of the ClientKeyExchange payload if configured for 1007 preshared keys. 1009 Init to Idle(X) This state transition occurs upon timeout of the 1010 WaitJoin Timer. 1012 WTP: Upon receiving a DTLSAbort command from the CAPWAP state 1013 machine, the WTP DTLS state machine transitions to Idle state. 1015 AC: Upon receiving a DTLSAbort command from the CAPWAP state 1016 machine, the AC DTLS state machine transitions to Idle state. 1018 Authenticate/Authorize to Authenticate/Authorize (W) This state 1019 transition is a Loopback state, representing execution of the TLS 1020 handshake protocol, including authorization callbacks to the 1021 CAPWAP architecture. 1023 WTP: Upon receiving AC credential, attempt to execute associated 1024 validation, authentication, and authorization callbacks. Note 1025 that credentials may span protocol messages, in which case the 1026 WTP will remain in this state pending receipt of all credential 1027 payloads. 1029 AC: Upon receipt of the WTP credential, attempt to execute 1030 associated validation, authentication, and authorization 1031 callbacks. Note that credentials may span protocol messages, 1032 in which case the AC will remain in this state pending receipt 1033 of all credential payloads. 1035 Authenticate/Authorize to Shutdown (V) This state transition 1036 indicates a failure of the DTLS handshake. 1038 WTP: Send a DTLSAuthenticateFail or DTLSAuthorizeFail to the 1039 CAPWAP state machine, depending on the exact cause of the 1040 error. May send a DTLS notification to the AC to indicate 1041 failure. 1043 AC: Send a DTLSAuthenticateFail or DTLSAuthorizeFail to the CAPWAP 1044 state machine, depending on the exact cause of the error. May 1045 send a DTLS Notification to the AC to indicate failure. 1047 Authenticate/Authorize to Run (U) This state transition occurs upon 1048 successful completion of the DTLS handshake. 1050 WTP: Send a DTLSEstablished notification to the CAPWAP state 1051 machine. 1053 AC: Send a DTLSEstablished notification to the CAPWAP state 1054 machine. 1056 Run to Rekey (T) This state transition occurs when a DTLS rehandshake 1057 is in progress; this is initiated when either (a) the DTLS state 1058 machine receives the DTLSRehandshake command from CAPWAP, or (b) a 1059 DTLS rehandshake message is received from the peer.. 1061 WTP: If CAPWAP issued a DTLSRehandshake command, initiate 1062 rehandshake with the peer; note that control traffic may 1063 continue to flow using existing secure association. If the 1064 rehandshake is initiated by the peer, send a DTLSRehandshake 1065 notification to CAPWAP. 1067 AC: If CAPWAP issued a DTLSRehandshake command, initiate 1068 rehandshake with the peer; note that control traffic may 1069 continue to flow using existing secure association. If the 1070 rehandshake is initiated by the peer, send a DTLSRehandshake 1071 notification to CAPWAP. 1073 Run to Shutdown (S) This state transition indicates a shutdown of the 1074 DTLS channel. 1076 WTP: This state transition occurs when the CAPWAP state machine 1077 sends a DTLSShutdown command, or when the the AC terminates the 1078 DTLS session. 1080 AC: This state transition occurs when CAPWAP state machine sends a 1081 DTLSShutdown command, or when the WTP terminates the DTLS 1082 session. 1084 Rekey to Run (R) This state transition indicates the successful 1085 completion of a DTLS rehandshake. 1087 WTP: This state transition occurs when the WTP receives the DTLS 1088 Finished message from the AC, completing the DTLS re-handshake. 1090 AC: This state transition occurs when the AC sends a DTLS Finished 1091 message to the WTP, completing the DTLS re-handshake. 1093 Rekey to Shutdown (Q) This state transition indicates the failure of 1094 the DTLS rekey operation. 1096 WTP: This state transition occurs when there is a failure in the 1097 rehandshake negotiation with the AC. 1099 AC: This state transition occurs when there is a failure in the 1100 rehandshake negotiation with the WTP. 1102 Shutdown to Idle (P) This state transition occurs upon transmission 1103 of a DTLS Session termination message, or upon receipt of a DTLS 1104 session termination message. 1106 WTP: This state transition occurs after the WTP transmits the DTLS 1107 session termination message. If the WTP receives a DTLS 1108 session termination message, it sends the DTLSPeerDisconnect 1109 notification to CAPWAP and moves to the Idle state. 1111 AC: This state transition occurs after the AC transmits the DTLS 1112 session termination message. If the AC receives a DTLS session 1113 termination message, it sends the DTLSPeerDisconnect 1114 notification to CAPWAP and moves to the Idle state. 1116 2.4. Use of DTLS in the CAPWAP Protocol 1118 DTLS is used as a tightly-integrated, secure wrapper for the CAPWAP 1119 protocol. In this document DTLS and CAPWAP are discussed as 1120 nominally distinct entitites; however they are very closely coupled, 1121 and may even be implemented inseparably. Since there are DTLS 1122 library implementations currently available, and since security 1123 protocols (e.g. IPsec, TLS) are often implemented in widely 1124 available acceleration hardware, it is both convenient and forward- 1125 looking to maintain a modular distinction in this document. 1127 This section describes a detailed walk-through of the interactions 1128 between the DTLS module and the CAPWAP module, via 'commands' (CAPWAP 1129 to DTLS) and 'notifications' (DTLS to CAPWAP) as they would be 1130 encountered during the normal course of operation. 1132 2.4.1. DTLS Handshake Processing 1134 Details of the DTLS handshake process are specified in [DTLS]. This 1135 section describes the interactions between the DTLS session 1136 establishment process and the CAPWAP protocol. In the normal case, 1137 the DTLS handshake will proceed as follows (NOTE: this example uses 1138 certificates, but preshared keys are also supported): 1140 ============ ============ 1141 WTP AC 1142 ============ ============ 1144 ClientHello ------> 1145 <------ HelloVerifyRequest 1146 (with cookie) 1148 ClientHello ------> 1149 (with cookie) 1150 <------ ServerHello 1151 <------ Certificate 1152 <------ ServerHelloDone 1154 (WTP callout for AC authorization) 1156 Certificate* 1157 ClientKeyExchange 1158 CertificateVerify* 1159 [ChangeCipherSpec] 1160 Finished ------> 1162 (AC callout for WTP 1163 authorization) 1165 [ChangeCipherSpec] 1166 <------ Finished 1168 DTLS, as specified, provides its own retransmit timers with an 1169 exponential back-off. However, it will never terminate the handshake 1170 due to non-responsiveness; rather, it will continue to increase its 1171 back-off timer period. Hence, timing out incomplete DTLS handshakes 1172 is entirely the responsiblity of the CAPWAP protocol. 1174 2.4.1.1. Join Operations 1176 The WTP, either through the Discovery process, or through pre- 1177 configuration, determines the AC to connect to. The WTP uses DTLS to 1178 establish a secure connection to the selected AC. Prior to 1179 initiation of the DTLS handshake, the WTP sets the WaitJoin timer. 1180 Upon receipt of a ClientHello message containing a valid cookie, the 1181 AC sets the WaitJoin timer. If the Join operation has not completed 1182 prior to timer expiration, the Join process is aborted, the WTP 1183 transitions back to Discovery state, and the AC transitions back to 1184 Idle state. Upon successful completion of the Join process the 1185 WaitJoin timer is deactivated. 1187 2.4.2. DTLS Error Handling 1189 If the AC does not respond to any DTLS messages sent by the WTP, the 1190 DTLS specification calls for the WTP to retransmit these messages. 1191 If the WaitJoin timer expires, CAPWAP will issue the DTLSAbort 1192 command, causing DTLS to terminate the handshake and remove any 1193 allocated session context. Note that DTLS MAY send a single TLS 1194 Alert message to the AC to indicate session termination. 1196 If the WTP does not respond to any DTLS messages sent by the AC, the 1197 CAPWAP protocol allows for three possiblities, listed below. Note 1198 that DTLS MAY send a single TLS Alert message to the AC to indicate 1199 session termination. 1201 o The message was lost in transit; in this case, the WTP will re- 1202 transmit its last outstanding message, since it did not receive 1203 the reply. 1205 o The WTP sent a DTLS Alert, which was lost in transit; in this 1206 case, the AC's WaitJoin timer will expire, and the session will be 1207 terminated. 1209 o Communication with the WTP has completely failed; in this case, 1210 the AC's WaitJoin timer will expire, and the session will be 1211 terminated. 1213 The DTLS specification provides for retransmission of unacknowledged 1214 requests. If retransmissions remain unacknowledged, the WaitJoin 1215 timer will eventually expire, at which time the CAPWAP module will 1216 terminate the session. 1218 If a cookie fails to validate, this could represent a WTP error, or 1219 it could represent a DoS attack. Hence, AC resource utilization 1220 SHOULD be minimized. The AC MAY log a message indicating the 1221 failure, but SHOULD NOT attempt to reply to the WTP. 1223 Since DTLS handshake messages are potentially larger than the maximum 1224 record size, DTLS supports fragmenting of handshake messages across 1225 multiple records. There are several potential causes of re-assembly 1226 errors, including overlapping and/or lost fragments. The DTLS module 1227 MUST send a DTLSReassemblyFailure notification to CAPWAP. Whether 1228 precise information is given along with notification is an 1229 implementation issue, and hence is beyond the scope of this document. 1230 Upon receipt of such an error, the CAPWAP protocol implementation 1231 SHOULD log an appropriate error message. Whether processing 1232 continues or the DTLS session is terminated is implementation 1233 dependent. 1235 DTLS decapsulation errors consist of three types: decryption errors, 1236 and authentication errors, and malformed DTLS record headers. Since 1237 DTLS authenticates the data prior to encapsulation, if decryption 1238 fails, it is difficult to detect this without first attempting to 1239 authenticate the packet. If authentication fails, a decryption error 1240 is also likely, but not guaranteed. Rather than attempt to derive 1241 (and require the implementation of) algorithms for detecting 1242 decryption failures, these are reported as authentication failures. 1243 The DTLS module MUST provide a DTLSDecapFailure notification to 1244 CAPWAP when such errors occur. If a malformed DTLS record header is 1245 detected, the packets SHOULD be silently discarded, and the receiver 1246 MAY log an error message. 1248 There is currently only one encapsulation error defined: MTU 1249 exceeeded. As part of DTLS session establishment, CAPWAP informs 1250 DTLS of the MTU size. This may be dynamically modified at any time 1251 when CAPWAP sends the DTLSMtuUpdate command to DTLS. DTLS returns 1252 this notification to CAPWAP whenever a transmission request will 1253 result in a packet which exceeds the MTU. 1255 2.4.3. DTLS Rehandshake Behavior 1257 DTLS rekeying (known in DTLS as "rehandshake") requires special 1258 attention, as the DTLS specification provides no rehandshake 1259 triggering mechanism. Rather, the application (in this case, CAPWAP) 1260 is expected to manage this for itself. This section addressed 1261 various aspects of rehandshake behavior. 1263 One simple way to think of a DTLS session is as a pair of 1264 unidirectional channels which are tightly bound together. A useful 1265 analogy is the twisted pair used for phone wiring, with one line per 1266 pair. Then, the rehandshake process can be thought of using the call 1267 over the existing pair to establish a call over a new pair - that is, 1268 an entirely new session is negotiated under the protection of the 1269 existing session. 1271 This sounds simple enough, yet there is operational complexity in 1272 changing over to the new session. In particular, how does each end 1273 know when it is safe to delete the "old" session, and switch over to 1274 the new one? If DTLS were not a datagram protocol, this would be 1275 simpler, but the fact that message delivery is unreliable 1276 significantly complicates things: when the AC (the "server") 1277 transmits its Finished message, it cannot be sure that the WTP 1278 received it until the WTP transmits data on the new channel. 1280 This fact constrains the way in which we transition to the new 1281 session, and delete the old one. The WTP, upon receipt of the AC's 1282 Finished message for the new session, immediately makes the new 1283 session active, and transmits no further data (e.g. echo requests, 1284 statistics, etc) on the old channel, and sends a TLS "user_cancelled" 1285 alert message on the old channel, after which the old session is 1286 immediately deleted. 1288 The AC, sets a DTLSSessionDelete timer, (see Section 4.5) and 1289 immediately makes the new session active, and transmits no further 1290 data (e.g. echo requests, statistics, etc) on the old channel. 1292 If a TLS "user_cancelled" alert message is received on the old 1293 channel, the session delete timer is deactivated, and the session is 1294 deleted. 1296 if the dtls-session-delete timer expires, a TLS "user_cancelled" 1297 alert message is transmitted on the old channel, and the session is 1298 deleted. 1300 Note that there is a slight possibility that some packets may be in 1301 flight when the session is deleted. However, since CAPWAP provides 1302 reliable delivery, these packets will be retransmitted over the new 1303 channel. 1305 2.4.3.1. Peer Initiated Rehandshake Triggers 1307 Since key lifetimes are not negotiable in DTLS, it is possible that a 1308 rehandshake from a peer may occur at any time, and implementations 1309 must be prepared for this eventuality. Presumably, communicating 1310 devices will be within the same domain of control. This being the 1311 case, overly-aggressive rekeying may be detected by simply monitoring 1312 logs, assuming such activity is indeed logged. Hence, 1313 implementations MUST log rekey attempts as they occur, reporting the 1314 time and identifying information for the peer. 1316 CAPWAP implementations MUST provide an administrative interface which 1317 permits specification of key lifetimes in seconds. Also, 1318 implementations which wait until this interval has expired to begin 1319 the rehandshake process are liable to encounter temporary service 1320 lapses on heavily loaded networks, so implementations SHOULD begin 1321 the rehandshake before the actual lifetime has elapsed. 1323 Given the relatively low bandwidth we might reasonably expect over a 1324 CAPWAP control channel and the strength of modern cryptographic 1325 algorithms (e.g. AES-128, 3DES, etc), it is reasonable to assume 1326 that lifetimes will typically be more than 8 hours. Given this 1327 assumption, a good rule of thumb for deciding when to rekey is this: 1328 deduct a random number of seconds from the lifetime (say, between 1% 1329 and 5% of the lifetime), and begin the rehandshake process at that 1330 point. Using a random value helps avert collisions, when both sides 1331 initiate a rehandshake at the same time (discussed further below). 1333 2.4.3.2. Time Based Rehandshake Triggers 1335 CAPWAP implementations MUST provide an administrative interface which 1336 permits specification of key lifetimes in seconds. Also, 1337 implementations which wait until this interval has expired to begin 1338 the rehandshake process are liable to encounter temporary service 1339 lapses on heavily loaded networks, so implementations SHOULD begin 1340 the rehandshake before the actual lifetime has elapsed. 1342 Given the relatively low bandwidth we might reasonably expect over a 1343 CAPWAP control channel and the strength of modern cryptographic 1344 algorithms (e.g. AES-128, 3DES, etc), it is reasonable to assume 1345 that key lifetimes will typically be more than 8 hours. Given this 1346 assumption, a good rule of thumb for deciding when to rekey is this: 1347 deduct a random number of seconds from the lifetime (say, between 1% 1348 and 5% of the lifetime), and begin the rehandshake process at that 1349 point. Using a random value helps avert collisions, when both sides 1350 initiate a rehandshake at the same time. 1352 2.4.3.3. Volume Based Rehandshake Triggers 1354 CAPWAP implementations MUST provide an administrative interface which 1355 permits specification of key lifetimes in packet count. Like time- 1356 based, lifetimes, implementations which wait until this interval has 1357 expired to begin the rehandshake process may encounter temporary 1358 service lapses on heavily loaded networks, so implementations SHOULD 1359 begin the rehandshake before the actual lifetime has elapsed. 1361 Volume-based lifetime estimation for purposes of rehandshake 1362 initiation is considerably more complex than time-based lifetime. In 1363 addition to avoiding collisions, the maximum burst rate must be 1364 known, and an extimate made, assuming rehandshake packets are lost, 1365 etc. Hence, we do not specify a one-size-fits-all approach here, and 1366 the specific algorithm used is implementation dependent. 1368 2.4.3.4. Rehandshake Collisions 1370 A collision occurs when both sides initiate a rehandshake 1371 simultaneously. No matter how much care is taken, rehandshake 1372 collisions are a distinct possibility. Hence, a contention 1373 resolution strategy is specified. 1375 A rehandshake collision is detected when a system receives a 1376 rehandshake initiation when it has one outstanding with the same 1377 peer. 1379 When this occurs, each side will compare its own address with that of 1380 its peer (in network byte order). 1382 The one with the lower of the two addresses will ignore the peer's 1383 rehandshake message, and continue with its own rehandshake process. 1385 The one with the higher message will immediately abort its current 1386 rehandshake, and set the DTLSRehandshake timer (see Section 4.5); if 1387 the peer with the lower address does not complete the rehandshake 1388 before the timer expires, the peer with the higher address will re- 1389 initiate. 1391 2.4.4. DTLS EndPoint Authentication 1393 DTLS supports endpoint authentication with certificates or preshared 1394 keys. The TLS algorithm suites for each endpoint authentication 1395 method are described below. 1397 2.4.4.1. Authenticating with Certificates 1399 Note that only block ciphers are currently recommended for use with 1400 DTLS. To understand the reasoning behind this, see [26]. 1401 However,support for AES counter mode encryption is currently 1402 progressing in the TLS working group, and once protocol identifiers 1403 are available, they will be added below. At present, the following 1404 algorithms MUST be supported when using certificates for CAPWAP 1405 authentication: 1407 o TLS_RSA_WITH_AES_128_CBC_SHA 1409 o TLS_RSA_WITH_3DES_EDE_CBC_SHA 1411 The following algorithms SHOULD be supported when using certificates: 1413 o TLS_DH_RSA_WITH_AES_128_CBC_SHA 1414 o TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA 1416 The following algorithms MAY be supported when using certificates: 1418 o TLS_RSA_WITH_AES_256_CBC_SHA 1420 o TLS_DH_RSA_WITH_AES_256_CBC_SHA 1422 2.4.4.2. Authenticating with Preshared Keys 1424 Pre-shared keys present significant challenges from a security 1425 perspective, and for that reason, their use is strongly discouraged. 1426 However, [13] defines 3 different methods for authenticating with 1427 preshared keys: 1429 o PSK key exchange algorithm - simplest method, ciphersuites use 1430 only symmetric key algorithms 1432 o DHE_PSK key exchange algorithm - use a PSK to authenticate a 1433 Diffie-Hellman exchange. These ciphersuites give some additional 1434 protection against dictionary attacks and also provide Perfect 1435 Forward Secrecy (PFS). 1437 o RSA_PSK key exchange algorithm - use RSA and certificates to 1438 authenticate the server, in addition to using a PSK. This is not 1439 susceptible to passive attacks. 1441 The first approach (plain PSK) is susceptible to passive dictionary 1442 attacks; hence, while this alorithm MAY be supported, special care 1443 should be taken when choosing that method. In particular, user- 1444 readable passphrases SHOULD NOT be used, and use of short PSKs should 1445 be strongly discouraged. Additionally, DHE_PSK MUST be supported, 1446 and RSA_PSK MAY be supported. 1448 The following cryptographic algorithms MUST be supported when using 1449 preshared keys: 1451 o TLS_DHE_PSK_WITH_AES_128_CBC_SHA 1453 o TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA 1455 The following algorithms SHOULD be supported when using preshared 1456 keys: 1458 o TLS_DHE_PSK_WITH_AES_256_CBC_SHA 1460 The following algorithms MAY be supported when using preshared keys: 1462 o TLS_PSK_WITH_AES_128_CBC_SHA 1464 o TLS_PSK_WITH_AES_256_CBC_SHA 1466 o TLS_PSK_WITH_3DES_EDE_CBC_SHA 1468 o TLS_RSA_PSK_WITH_AES_128_CBC_SHA 1470 o TLS_RSA_PSK_WITH_AES_256_CBC_SHA 1472 o TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA 1474 2.4.4.3. Certificate Usage 1476 Validation of the certificates by the AC and WTP is required so that 1477 only an AC may perform the functions of an AC and that only a WTP may 1478 perform the functions of a WTP. This restriction of functions to the 1479 AC or WTP requires that the certificates used by the AC MUST be 1480 distinguishable from the certificate used by the WTP. To accomplish 1481 this differentiation, the x.509v3 certificates MUST include the 1482 Extensions field [11] and MUST include the NetscapeComment [15] 1483 extension. 1485 For an AC, the value of the NetscapeComment extension MUST be the 1486 string "CAPWAP AC Device Certificate". For a WTP, the value of the 1487 NetscapeComment extension MUST be the string "CAPWAP WTP Device 1488 Certificate". 1490 Part of the CAPWAP certificate validation process includes ensuring 1491 that the proper string is included in the NetscapeComment extension, 1492 and only allowing the CAPWAP session to be established if the 1493 extension does not represent the same role as the device validating 1494 the certificate. For instance, a WTP MUST NOT accept a certificate 1495 whose NetscapeComment field is set to "CAPWAP WTP Device 1496 Certificate". 1498 3. CAPWAP Transport 1500 The CAPWAP protocol uses UDP as a transport, and can be used with 1501 IPv4 or IPv6. This section details the specifics of how the CAPWAP 1502 protocol works in conjunction with IP. 1504 3.1. UDP Transport 1506 Communication between a WTP and an AC is established according to the 1507 standard UDP client/server model. One of the CAPWAP requirements is 1508 to allow a WTP to reside behind a firewall and/or Network Address 1509 Translation (NAT) device. Since the connection is initiated by the 1510 WTP (client) to the well-known UDP port of the AC (server), the use 1511 of UDP is a logical choice. 1513 CAPWAP protocol control packets sent between the WTP and the AC use 1514 well known UDP port [to be IANA assigned]. CAPWAP protocol data 1515 packets sent between the WTP and the AC use UDP port [to be IANA 1516 assigned]. 1518 3.2. AC Discovery 1520 A WTP and an AC will frequently not reside in the same IP subnet 1521 (broadcast domain). When this occurs, the WTP must be capable of 1522 discovering the AC, without requiring that multicast services are 1523 enabled in the network. This section describes how AC discovery is 1524 performed by WTPs. 1526 As the WTP attempts to establish communication with an AC, it sends 1527 the Discovery Request message and receives the corresponding response 1528 message from the AC(s). The WTP must send the Discovery Request 1529 message to either the limited broadcast IP address (255.255.255.255), 1530 a well known multicast address or to the unicast IP address of the 1531 AC. Upon receipt of the Discovery Request message, the AC issues a 1532 Discovery Response message to the unicast IP address of the WTP, 1533 regardless of whether the Discovery Request message was sent as a 1534 broadcast, multicast or unicast message. 1536 WTP use of a limited IP broadcast, multicast or unicast IP address is 1537 implementation dependent. 1539 When a WTP transmits a Discovery Request message to a unicast 1540 address, the WTP must first obtain the IP address of the AC. Any 1541 static configuration of an AC's IP address on the WTP non-volatile 1542 storage is implementation dependent. However, additional dynamic 1543 schemes are possible, for example: 1545 DHCP: A comma delimited ASCII encoded list of AC IP addresses is 1546 embedded in the DHCP vendor specific option 43 extension. An 1547 example of the actual format of the vendor specific payload for 1548 IPv4 is of the form "10.1.1.1, 10.1.1.2". 1550 DNS: The DNS name "CAPWAP-AC-Address" MAY be resolvable to one or 1551 more AC addresses. 1553 3.3. Fragmentation/Reassembly 1555 While fragmentation and reassembly services are provided by IP, the 1556 CAPWAP protocol also provides such services. Environments where the 1557 CAPWAP protocol is used involve firewall, Network Address Translation 1558 (NAT) and "middle box" devices, which tend to drop IP fragments in 1559 order to minimize possible Denial of Service attacks. By providing 1560 fragmentation and reassembly at the application layer, any 1561 fragmentation required due to the tunneling component of the CAPWAP 1562 protocol becomes transparent to these intermediate devices. 1563 Consequently, the CAPWAP protocol is not impacted by any network 1564 configurations. 1566 4. CAPWAP Packet Formats 1568 This section contains the CAPWAP protocol packet formats. A CAPWAP 1569 protocol packet consists of a CAPWAP Transport Layer packet header 1570 followed by a CAPWAP message. The CAPWAP message can be either of 1571 type Control or Data, where Control packets carry signaling, and Data 1572 packets carry user payloads. The CAPWAP frame formats for CAPWAP 1573 Data packets, and for DTLS encapsulated CAPWAP Data and Control 1574 packets. are as shown below: 1576 CAPWAP Data Packet : 1577 +--------------------------------+ 1578 | IP |UDP | CAPWAP | Wireless | 1579 | Hdr |Hdr | Header | Payload | 1580 +--------------------------------+ 1582 CAPWAP + Optional DTLS Data Packet Security: 1583 +------------------------------------------------+ 1584 | IP |UDP | DTLS | CAPWAP | Wireless | DTLS | 1585 | Hdr |Hdr | Hdr | Hdr | Payload | Trailer| 1586 +------------------------------------------------+ 1587 \--authenticated-----------/ 1588 \--- encrypted-----------/ 1590 CAPWAP Control Packet (DTLS Security Required): 1591 +-----------------------------------------------------------+ 1592 | IP |UDP | DTLS | CAPWAP | Control | Message | DTLS | 1593 | Hdr |Hdr | Hdr | Header | Header | Element(s) | Trailer | 1594 +-----------------------------------------------------------+ 1595 \-------authenticated-----------------/ 1596 \------------encrypted-------------------/ 1598 UDP: All CAPWAP packets are encapsulated within UDP. Section 1599 Section 3.1 defines the specific UDP usage. 1601 CAPWAP Header: All CAPWAP protocol packets use a common header that 1602 immediately follows the UDP header. This header, is defined in 1603 Section 4.1. 1605 Wireless Payload: A CAPWAP protocol packet that contains a wireless 1606 payload is known as a data frame. The CAPWAP protocol does not 1607 dictate the format of the wireless payload, which is defined by 1608 the appropriate wireless standard. Additional information is in 1609 Section 4.2. 1611 Control Header: The CAPWAP protocol includes a signalling component, 1612 known as the CAPWAP control protocol. All CAPWAP control packets 1613 include a Control Header, which is defined in Section 4.3.1. 1615 Message Elements: A CAPWAP Control packet includes one or more 1616 message elements, which are found immediately following the 1617 control header. These message elements are in a Type/Length/value 1618 style header, defined in Section 4.4. 1620 4.1. CAPWAP Transport Header 1622 All CAPWAP protocol messages are encapsulated using a common header 1623 format, regardless of the CAPWAP control or CAPWAP Data transport 1624 used to carry the messages. However, certain flags are not 1625 applicable for a given transport. Refer to the specific transport 1626 section in order to determine which flags are valid. 1628 0 1 2 3 1629 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 1630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1631 |Version| RID | HLEN |F|L|W|M| Flags | 1632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1633 | Fragment ID | Frag Offset |Rsv-2| 1634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1635 | (optional) Radio MAC Address | 1636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1637 | (optional) Wireless Specific Information | 1638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1639 | Payload .... | 1640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1642 Version: A 4 bit field which contains the version of CAPWAP used in 1643 this packet. The value for this draft is 0. 1645 RID: A 5 bit field which contains the Radio ID number for this 1646 packet. WTPs with multiple radios but a single MAC Address range 1647 use this field to indicate which radio is associated with the 1648 packet. 1650 HLEN: Length of CAPWAP tunnel header in 4 byte words. (Similar to IP 1651 header length). This length includes the optional headers. 1653 F: The Fragment 'F' bit indicates whether this packet is a fragment. 1654 When this bit is one (1), the packet is a fragment and MUST be 1655 combined with the other corresponding fragments to reassemble the 1656 complete information exchanged between the WTP and AC. 1658 L: The Not Last 'L' bit is valid only if the 'F' bit is set and 1659 indicates whether the packet contains the last fragment of a 1660 fragmented exchange between WTP and AC. When this bit is 1, the 1661 packet is not the last fragment. When this bit is 0, the packet 1662 is the last fragment. 1664 W: The Wireless 'W' bit is used to specify whether the optional 1665 wireless specific information field is present in the header. A 1666 value of one (1) is used to represent the fact that the optional 1667 header is present. 1669 M: The M bit is used to indicate that the Radio MAC Address optional 1670 header is present. This is used to communicate the MAC address of 1671 the receiving radio when the native wireless packet. This field 1672 MUST NOT be set to one in packets sent by the AC to the WTP. 1674 Flags: A set of reserved bits for future flags in the CAPWAP header. 1675 All implementations complying with version zero of this protocol 1676 MUST set these bits to zero. 1678 Fragment ID: An 16 bit field whose value is assigned to each group of 1679 fragments making up a complete set. The fragment ID space is 1680 managed individually for every WTP/AC pair. The value of Fragment 1681 ID is incremented with each new set of fragments. The Fragment ID 1682 wraps to zero after the maximum value has been used to identify a 1683 set of fragments. 1685 Fragment Offset: A 13 bit field that indicates where in the payload 1686 will this fragment belong during re-assembly. This field is valid 1687 when the 'F' bit is set to 1. The fragment offset is measured in 1688 units of 8 octets (64 bits). The first fragment has offset zero. 1690 Reserved: The 3-bit Reserved-2 field is reserved and set to 0 in this 1691 version of the CAPWAP protocol. 1693 Radio MAC Address: This optional field contains the MAC address of 1694 the radio receiving the packet. This is useful in packets sent 1695 from the WTP to the AC, when the native wireless frame format is 1696 converted to 802.3 by the WTP. This field is only present if the 1697 'M' bit is set. 1699 The field contains the basic format: 1701 0 1 2 3 1702 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 1703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1704 | Length | MAC Address 1705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1707 Length: The number of bytes in the MAC Address field. The length 1708 field is present since new IEEE technologies are using 48 byte 1709 MAC addresses. 1711 MAC Address: The MAC Address of the receiving radio. 1713 Wireless Specific Information: This optional field contains 1714 technology specific information that may be used to carry per 1715 packet wireless information. This field is only present if the 1716 'W' bit is set. 1718 The field contains the basic format: 1720 0 1 2 3 1721 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 1722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1723 | Wireless ID | Length | Data 1724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1726 Wireless ID: The wireless binding identifier. The following 1727 values are defined: 1729 1 - : IEEE 802.11 1731 Length: The length of the data field 1733 Data: Wireless specific information, whose details are defined in 1734 the technology specific binding section. 1736 Payload: This field contains the header for a CAPWAP Data Message or 1737 CAPWAP Control Message, followed by the data associated with that 1738 message. 1740 4.2. CAPWAP Data Messages 1742 A CAPWAP protocol data message is a forwarded wireless frame. The 1743 CAPWAP protocol defines two different modes of encapsulations; IEEE 1744 802.3 and native wireless. IEEE 802.3 encapsulation requires that 1745 the bridging function be performed in the WTP. An IEEE 802.3 1746 encapsulated user payload frame has the following format: 1748 +------------------------------------------------------+ 1749 | IP Header | UDP Header | CAPWAP Header | 802.3 Frame | 1750 +------------------------------------------------------+ 1752 The CAPWAP protocol also defines the native wireless encapsulation 1753 mode. The actual format of the encapsulated CAPWAP data frame is 1754 subject to the rules defined under the specific wireless technology 1755 binding. As a consequence, each wireless technology binding MUST 1756 define a section entitled "Payload encapsulation", which defines the 1757 format of the wireless payload that is encapsulated within the CAPWAP 1758 Data messages. 1760 In the event that the encapsulated frame would exceed the transport 1761 layer's MTU, the sender is responsible for the fragmentation of the 1762 frame, as specified in Section 3.3. 1764 4.3. CAPWAP Control Messages 1766 The CAPWAP Control protocol provides a control channel between the 1767 WTP and the AC. Control messages are divided into the following 1768 distinct message types: 1770 Discovery: CAPWAP Discovery messages are used to identify potential 1771 ACs, their load and capabilities. 1773 WTP Configuration: The WTP Configuration messages are used by the AC 1774 to push a specific configuration to the WTP it has a control 1775 channel with. Messages that deal with the retrieval of statistics 1776 from the WTP also fall in this category. 1778 Mobile Session Management: Mobile session management messages are 1779 used by the AC to push specific mobile station policies to the 1780 WTP. 1782 Firmware Management: Messages in this category are used by the AC to 1783 push a new firmware image to the WTP. 1785 Discovery, WTP Configuration and Mobile Session Management messages 1786 MUST be implemented. Firmware Management MAY be implemented. 1788 In addition, technology specific bindings may introduce new control 1789 channel commands. 1791 4.3.1. Control Message Format 1793 All CAPWAP control messages are sent encapsulated within the CAPWAP 1794 header (see Section 4.1). Immediately following the CAPWAP header, 1795 is the control header, which has the following format: 1797 0 1 2 3 1798 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 1799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1800 | Message Type | 1801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1802 | Seq Num | Msg Element Length | Flags | 1803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1804 | Time Stamp | 1805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1806 | Msg Element [0..N] ... 1807 +-+-+-+-+-+-+-+-+-+-+-+-+ 1809 4.3.1.1. Message Type 1811 The Message Type field identifies the function of the CAPWAP control 1812 message. The Message Type field is comprised of an IANA Enterprise 1813 Number and a message type value field. The first two byte contain 1814 the IANA Enterprise Number (for example, the IEEE 802.11 IANA 1815 Enterprise number is 13277), and the second two bytes contain the 1816 Message Type value. The message type field can be expressed as: 1818 Message Type = IANA Enterprise Number * 256 + Message Type Value 1820 The valid values for base CAPWAP Message Types are given in the table 1821 below: 1823 CAPWAP Control Message Message Type 1824 Value 1825 Discovery Request 1 1826 Discovery Response 2 1827 Join Request 3 1828 Join Response 4 1829 Configuration Status 5 1830 Configuration Status Response 6 1831 Configuration Update Request 7 1832 Configuration Update Response 8 1833 WTP Event Request 9 1834 WTP Event Response 10 1835 Change State Event Request 11 1836 Change State Event Response 12 1837 Echo Request 13 1838 Echo Response 14 1839 Image Data Request 15 1840 Image Data Response 16 1841 Reset Request 17 1842 Reset Response 18 1843 Primary Discovery Request 19 1844 Primary Discovery Response 20 1845 Data Transfer Request 21 1846 Data Transfer Response 22 1847 Clear Config Indication 23 1848 Mobile Config Request 24 1849 Mobile Config Response 25 1851 4.3.1.2. Sequence Number 1853 The Sequence Number Field is an identifier value to match request and 1854 response packet exchanges. When a CAPWAP packet with a request 1855 message type is received, the value of the sequence number field is 1856 copied into the corresponding response packet. 1858 When a CAPWAP control message is sent, its internal sequence number 1859 counter is monotonically incremented, ensuring that no two requests 1860 pending have the same sequence number. This field will wrap back to 1861 zero. 1863 4.3.1.3. Message Element Length 1865 The Length field indicates the number of bytes following the Sequence 1866 Num field. 1868 4.3.1.4. Flags 1870 The Flags field MUST be set to zero. 1872 4.3.1.5. Time Stamp 1874 The Timestamp contains the timestamp. PRC-TODO: Details need to be 1875 added here, and I am waiting for info from Dave Perkins. 1877 4.3.1.6. Message Element[0..N] 1879 The message element(s) carry the information pertinent to each of the 1880 control message types. Every control message in this specification 1881 specifies which message elements are permitted. 1883 4.3.2. Control Message Quality of Service 1885 It is recommended that CAPWAP control messages be sent by both the AC 1886 and the WTP with an appropriate Quality of Service precedence value, 1887 ensuring that congestion in the network minimizes occurrences of 1888 CAPWAP control channel disconnects. Therefore, a Quality of Service 1889 enabled CAPWAP device should use the following values: 1891 802.1P: The precedence value of 7 SHOULD be used. 1893 DSCP: The DSCP tag value of 46 SHOULD be used. 1895 4.4. CAPWAP Protocol Message Elements 1897 This section defines the CAPWAP Protocol message elements which are 1898 included in CAPWAP protocol control messages. 1900 Message elements are used to carry information needed in control 1901 messages. Every message element is identified by the Type field, 1902 whose numbering space is managed via IANA (see Section 14). The 1903 total length of the message elements is indicated in the Message 1904 Element Length field. 1906 All of the message element definitions in this document use a diagram 1907 similar to the one below in order to depict its format. Note that in 1908 order to simplify this specification, these diagrams do not include 1909 the header fields (Type and Length). The header field values are 1910 defined in the Message element descriptions. 1912 Additional message elements may be defined in separate IETF 1913 documents. 1915 The format of a message element uses the TLV format shown here: 1917 0 1 2 3 1918 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 1919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1920 | Type | Length | 1921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1922 | Value ... | 1923 +-+-+-+-+-+-+-+-+ 1925 Where Type (16 bit) identifies the character of the information 1926 carried in the Value field and Length (16 bits) indicates the number 1927 of bytes in the Value field. 1929 4.4.1. AC Descriptor 1931 The AC payload message element is used by the AC to communicate it's 1932 current state. The value contains the following fields. 1934 0 1 2 3 1935 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 1936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1937 | Reserved | Hardware Version ... | 1938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1939 | HW Ver | Software Version ... | 1940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1941 | SW Ver | Stations | Limit | 1942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1943 | Limit | Active WTPs | Max WTPs | 1944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1945 | Max WTPs | Security | 1946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1948 Type: 1 for AC Descriptor 1950 Length: 18 1952 Reserved: MUST be set to zero 1954 Hardware Version: The AC's hardware version number 1956 Software Version: The AC's Firmware version number 1958 Stations: The number of mobile stations currently associated with 1959 the AC 1961 Limit: The maximum number of stations supported by the AC 1962 Active WTPs: The number of WTPs currently attached to the AC 1964 Max WTPs: The maximum number of WTPs supported by the AC 1966 Security: A 8 bit bit mask specifying the authentication credential 1967 type supported by the AC. The following values are supported (see 1968 Section 2.4.4): 1970 1 - X.509 Certificate Based 1972 2 - Pre-Shared Secret 1974 4.4.2. AC IPv4 List 1976 The AC List message element is used to configure a WTP with the 1977 latest list of ACs in a cluster. 1979 0 1 2 3 1980 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 1981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1982 | AC IP Address[] | 1983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1985 Type: 2 for AC List 1987 Length: 4 1989 The AC IP Address: An array of 32-bit integers containing an AC's 1990 IPv4 Address. 1992 4.4.3. AC IPv6 List 1994 The AC List message element is used to configure a WTP with the 1995 latest list of ACs in a cluster. 1997 0 1 2 3 1998 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 1999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2000 | AC IP Address[] | 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2002 | AC IP Address[] | 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2004 | AC IP Address[] | 2005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2006 | AC IP Address[] | 2007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2009 Type: 3 for AC IPV6 List 2011 Length: 16 2013 The AC IP Address: An array of 32-bit integers containing an AC's 2014 IPv6 Address. 2016 4.4.4. AC Name 2018 The AC name message element contains an ASCII representation of the 2019 AC's identity. The value is a variable length byte string. The 2020 string is NOT zero terminated. 2022 0 2023 0 1 2 3 4 5 6 7 2024 +-+-+-+-+-+-+-+-+ 2025 | Name ... 2026 +-+-+-+-+-+-+-+-+ 2028 Type: 4 for AC Name 2030 Length: > 0 2032 Name: A variable length ASCII string containing the AC's name 2034 4.4.5. AC Name with Index 2036 The AC Name with Index message element is sent by the AC to the WTP 2037 to configure preferred ACs. The number of instances where this 2038 message element would be present is equal to the number of ACs 2039 configured on the WTP. 2041 0 1 2042 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2044 | Index | AC Name... 2045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2047 Type: 5 for AC Name with Index 2049 Length: > 2 2051 Index: The index of the preferred server (e.g., 1=primary, 2052 2=secondary). 2054 AC Name: A variable length ASCII string containing the AC's name. 2056 4.4.6. AC Timestamp 2058 The AC Timestamp message element is sent by the AC to synchronize the 2059 WTP's clock. 2061 0 1 2 3 2062 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 2063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2064 | Timestamp | 2065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2067 Type: 6 for AC Timestamp 2069 Length: 4 2071 Timestamp: The AC's current time, allowing all of the WTPs to be 2072 time synchronized in the format defined by Network Time Protocol 2073 (NTP) in RFC 1305 [10]. 2075 4.4.7. Add MAC ACL Entry 2077 The Add MAC Access Control List (ACL) Entry message element is used 2078 by an AC to add a MAC ACL list entry on a WTP, ensuring that the WTP 2079 no longer provides any service to the MAC addresses provided in the 2080 message. The MAC Addresses provided in this message element are not 2081 expected to be saved in non-volatile memory on the WTP. 2083 0 1 2 3 2084 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 2085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2086 | Num of Entries| MAC Address[] | 2087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2088 | MAC Address[] | 2089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2091 Type: 7 for Add MAC ACL Entry 2093 Length: >= 7 2095 Num of Entries: The number of MAC Addresses in the array. 2097 MAC Address: An array of MAC Addresses to add to the ACL. 2099 4.4.8. Add Mobile Station 2101 The Add Mobile Station message element is used by the AC to inform a 2102 WTP that it should forward traffic for a particular mobile station. 2103 The Add Mobile Station message element will be accompanied by 2104 technology specific binding information element which may include 2105 security parameters. Consequently, the security parameters must be 2106 applied by the WTP for the particular mobile. 2108 Once a mobile station's policy has been pushed to the WTP through 2109 this message element, an AC may change any policies by simply sending 2110 a modified Add Mobile Station message element. When a WTP receives 2111 an Add Mobile Station message element for an existing mobile station, 2112 it must override any existing state it may have for the mobile 2113 station in question. The latest Add Mobile Station message element 2114 data overrides any previously received messages. 2116 0 1 2 3 2117 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 2118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2119 | Radio ID | MAC Address | 2120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2121 | MAC Address | VLAN Name... 2122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2124 Type: 8 for Add Mobile 2126 Length: >= 7 2128 Radio ID: An 8-bit value representing the radio 2130 MAC Address: The mobile station's MAC Address 2132 VLAN Name: An optional variable string containing the VLAN Name on 2133 which the WTP is to locally bridge user data. Note this field is 2134 only valid with WTPs configured in Local MAC mode. 2136 4.4.9. Add Static MAC ACL Entry 2138 The Add Static MAC ACL Entry message element is used by an AC to add 2139 a permanent ACL entry on a WTP, ensuring that the WTP no longer 2140 provides any service to the MAC addresses provided in the message. 2141 The MAC Addresses provided in this message element are expected to be 2142 saved in non-volative memory on the WTP. 2144 0 1 2 3 2145 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 2146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2147 | Num of Entries| MAC Address[] | 2148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2149 | MAC Address[] | 2150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2152 Type: 9 for Add Static MAC ACL Entry 2154 Length: >= 7 2156 Num of Entries: The number of MAC Addresses in the array. 2158 MAC Address: An array of MAC Addresses to add to the permanent ACL. 2160 4.4.10. CAPWAP Timers 2162 The CAPWAP Timers message element is used by an AC to configure 2163 CAPWAP timers on a WTP. 2165 0 1 2166 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2168 | Discovery | Echo Request | 2169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2171 Type: 10 for CAPWAP Timers 2173 Length: 2 2175 Discovery: The number of seconds between CAPWAP Discovery packets, 2176 when the WTP is in the discovery mode. 2178 Echo Request: The number of seconds between WTP Echo Request CAPWAP 2179 messages. 2181 4.4.11. Change State Event 2183 The Change State message element is used to communicate a change in 2184 the operational state of a radio. The value contains two fields, as 2185 shown. 2187 0 1 2 2188 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2190 | Radio ID | State | Cause | 2191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2193 Type: 11 for Change State Event 2195 Length: 3 2197 Radio ID: The Radio Identifier, typically refers to some interface 2198 index on the WTP. 2200 State: An 8-bit boolean value representing the state of the radio. 2201 A value of one disables the radio, while a value of two enables 2202 it. 2204 Cause: In the event of a radio being inoperable, the cause field 2205 would contain the reason the radio is out of service. The 2206 following values are supported: 2208 0 - Normal 2210 1 - Radio Failure 2212 2 - Software Failure 2214 4.4.12. Data Transfer Data 2216 The Data Transfer Data message element is used by the WTP to provide 2217 information to the AC for debugging purposes. 2219 0 1 2 2220 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2222 | Data Type | Data Length | Data .... 2223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2225 Type: 12 for Data Transfer Data 2227 Length: >= 3 2229 Data Type: An 8-bit value the type of information being sent. The 2230 following values are supported: 2232 1 - WTP Crash Data 2234 2 - WTP Memory Dump 2236 Data Length: Length of data field. 2238 Data: Debug information. 2240 4.4.13. Data Transfer Mode 2242 The Data Transfer Mode message element is used by the AC to request 2243 information from the WTP for debugging purposes. 2245 0 2246 0 1 2 3 4 5 6 7 2247 +-+-+-+-+-+-+-+-+ 2248 | Data Type | 2249 +-+-+-+-+-+-+-+-+ 2251 Type: 13 for Data Transfer Mode 2253 Length: 1 2255 Data Type: An 8-bit value the type of information being requested. 2256 The following values are supported: 2258 1 - WTP Crash Data 2260 2 - WTP Memory Dump 2262 4.4.14. Decryption Error Report 2264 The Decryption Error Report message element value is used by the WTP 2265 to inform the AC of decryption errors that have occurred since the 2266 last report. Note that this error reporting mechanism is not used if 2267 encryption and decryption services are provided via the AC. 2269 0 1 2 2270 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2272 | Radio ID |Num Of Entries | Mobile MAC Address | 2273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2274 | Mobile MAC Address[] | 2275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2277 Type: 14 for Decryption Error Report 2279 Length: >= 8 2281 Radio ID: The Radio Identifier, which typically refers to an 2282 interface index on the WTP 2284 Num Of Entries: An 8-bit unsigned integer indicating the number of 2285 mobile MAC addresses. 2287 Mobile MAC Address: An array of mobile station MAC addresses that 2288 have caused decryption errors. 2290 4.4.15. Decryption Error Report Period 2292 The Decryption Error Report Period message element value is used by 2293 the AC to inform the WTP how frequently it should send decryption 2294 error report messages. 2296 0 1 2 2297 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2299 | Radio ID | Report Interval | 2300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2302 Type: 15 for Decryption Error Report Period 2304 Length: 3 2306 Radio ID: The Radio Identifier, typically refers to some interface 2307 index on the WTP 2309 Report Interval: A 16-bit unsigned integer indicating the time, in 2310 seconds 2312 4.4.16. Delete MAC ACL Entry 2314 The Delete MAC ACL Entry message element is used by an AC to delete a 2315 MAC ACL entry on a WTP, ensuring that the WTP provides service to the 2316 MAC addresses provided in the message. 2318 0 1 2 3 2319 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 2320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2321 | Num of Entries| MAC Address[] | 2322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2323 | MAC Address[] | 2324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2326 Type: 16 for Delete MAC ACL Entry 2328 Length: >= 7 2329 Num of Entries: The number of MAC Addresses in the array. 2331 MAC Address: An array of MAC Addresses to delete from the ACL. 2333 4.4.17. Delete Mobile Station 2335 The Delete Mobile station message element is used by the AC to inform 2336 an WTP that it should no longer provide service to a particular 2337 mobile station. The WTP must terminate service immediately upon 2338 receiving this message element. 2340 The transmission of a Delete Mobile Station message element could 2341 occur for various reasons, including for administrative reasons, as a 2342 result of the fact that the mobile has roamed to another WTP, etc. 2344 Once access has been terminated for a given station, any future 2345 packets received from the mobile station must result in a 2346 deauthenticate message, as specified in [6]. 2348 0 1 2 3 2349 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 2350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2351 | Radio ID | MAC Address | 2352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2353 | MAC Address | 2354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2356 Type: 17 for Delete Mobile Station 2358 Length: 7 2360 Radio ID: An 8-bit value representing the radio 2362 MAC Address: The mobile station's MAC Address 2364 4.4.18. Delete Static MAC ACL Entry 2366 The Delete Static MAC ACL Entry message element is used by an AC to 2367 delete a previously added static MAC ACL entry on a WTP, ensuring 2368 that the WTP provides service to the MAC addresses provided in the 2369 message. 2371 0 1 2 3 2372 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 2373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2374 | Num of Entries| MAC Address[] | 2375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2376 | MAC Address[] | 2377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2379 Type: 18 for Delete Static MAC ACL Entry 2381 Length: >= 7 2383 Num of Entries: The number of MAC Addresses in the array. 2385 MAC Address: An array of MAC Addresses to delete from the static MAC 2386 ACL entry. 2388 4.4.19. Discovery Type 2390 The Discovery message element is used to configure a WTP to operate 2391 in a specific mode. 2393 0 2394 0 1 2 3 4 5 6 7 2395 +-+-+-+-+-+-+-+-+ 2396 | Discovery Type| 2397 +-+-+-+-+-+-+-+-+ 2399 Type: 19 for Discovery Type 2401 Length: 1 2403 Discovery Type: An 8-bit value indicating how the AC was discovered. 2404 The following values are supported: 2406 0 - Broadcast 2408 1 - Configured 2410 4.4.20. Duplicate IPv4 Address 2412 The Duplicate IPv4 Address message element is used by a WTP to inform 2413 an AC that it has detected another IP device using the same IP 2414 address it is currently using. 2416 0 1 2 3 2417 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 2418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2419 | IP Address | 2420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2421 | MAC Address | 2422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2423 | MAC Address | 2424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2426 Type: 20 for Duplicate IPv4 Address 2428 Length: 10 2430 IP Address: The IP Address currently used by the WTP. 2432 MAC Address: The MAC Address of the offending device. 2434 4.4.21. Duplicate IPv6 Address 2436 The Duplicate IPv6 Address message element is used by a WTP to inform 2437 an AC that it has detected another host using the same IP address it 2438 is currently using. 2440 0 1 2 3 2441 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 2442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2443 | IP Address | 2444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2445 | IP Address | 2446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2447 | IP Address | 2448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2449 | IP Address | 2450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2451 | MAC Address | 2452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2453 | MAC Address | 2454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2456 Type: 21 for Duplicate IPv6 Address 2458 Length: 22 2460 IP Address: The IP Address currently used by the WTP. 2462 MAC Address: The MAC Address of the offending device. 2464 4.4.22. Idle Timeout 2466 The Idle Timeout message element is sent by the AC to the WTP to 2467 provide it with the idle timeout that it should enforce on its active 2468 mobile station entries. 2470 0 1 2 3 2471 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 2472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2473 | Timeout | 2474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2476 Type: 22 for Idle Timeout 2478 Length: 4 2480 Timeout: The current idle timeout to be enforced by the WTP. 2482 4.4.23. Image Data 2484 The image data message element is present in the Image Data Request 2485 message sent by the AC and contains the following fields. 2487 0 1 2 3 2488 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 2489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2490 | Opcode | Checksum | Image Data | 2491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2492 | Image Data ... | 2493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2495 Type: 23 for Image Data 2497 Length: >= 4 (allows 0 length element if last data unit is 1024 2498 bytes) 2500 Opcode: An 8-bit value representing the transfer opcode. The 2501 following values are supported: 2503 3 - Image data is included 2505 5 - An error occurred. Transfer is aborted 2507 Checksum: A 16-bit value containing a checksum of the image data 2508 that follows 2510 Image Data: The Image Data field contains 1024 characters, unless 2511 the payload being sent is the last one (end of file). If the last 2512 block was 1024 in length, an Image Data with a zero length payload 2513 is sent. 2515 4.4.24. Image Filename 2517 The image filename message element is sent by the WTP to the AC and 2518 is used to initiate the firmware download process. This message 2519 element contains the image filename, which the AC subsequently 2520 transfers to the WTP via the Image Data message element. The value 2521 is a variable length byte string, which is NOT zero terminated. 2523 0 1 2 3 2524 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 2525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2526 | Filename ... | 2527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2529 Type: 24 for Image Filename 2531 Length: >= 1 2533 Filename: A variable length string containing the filename to 2534 download. 2536 4.4.25. Initiate Download 2538 The Initiate Download message element is used by the AC to inform the 2539 WTP that it should initiate a firmware upgrade. This is performed by 2540 having the WTP initiate its own Image Data Request, with the Image 2541 Download message element. This message element does not contain any 2542 data. 2544 Type: 25 for Initiate Download 2546 Length: 0 2548 4.4.26. Location Data 2550 The Location Data message elementis a variable length byte string 2551 containing user defined location information (e.g. "Next to 2552 Fridge"). This information is configurable by the network 2553 administrator, and allows for the WTP location to be determined 2554 through this field. The string is not zero terminated. 2556 0 2557 0 1 2 3 4 5 6 7 2558 +-+-+-+-+-+-+-+-+- 2559 | Location ... 2560 +-+-+-+-+-+-+-+-+- 2562 Type: 26 for Location Data 2564 Length: > 0 2566 Timeout: A non-zero terminated string containing the WTP location. 2568 4.4.27. MTU Discovery Padding 2570 The MTU Discovery Padding message element is used as padding to 2571 perform MTU discovery, and MUST contain octets of value 0xFF, of any 2572 length 2574 0 2575 0 1 2 3 4 5 6 7 2576 +-+-+-+-+-+-+-+-+ 2577 | Padding... 2578 +-+-+-+-+-+-+-+- 2580 Type: 27 for MTU Discovery Padding 2582 Length: variable 2584 Timeout: A variable length pad. 2586 4.4.28. Radio Administrative State 2588 The administrative event message element is used to communicate the 2589 state of a particular radio. The value contains the following 2590 fields. 2592 0 1 2593 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2595 | Radio ID | Admin State | 2596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2598 Type: 28 for Administrative State 2600 Length: 2 2602 Radio ID: An 8-bit value representing the radio to configure. The 2603 Radio ID field may also include the value of 0xff, which is used 2604 to identify the WTP itself. Therefore, if an AC wishes to change 2605 the administrative state of a WTP, it would include 0xff in the 2606 Radio ID field. 2608 Admin State: An 8-bit value representing the administrative state of 2609 the radio. The following values are supported: 2611 1 - Enabled 2612 2 - Disabled 2614 4.4.29. Result Code 2616 The Result Code message element value is a 32-bit integer value, 2617 indicating the result of the request operation corresponding to the 2618 sequence number in the message. 2620 0 1 2 3 2621 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 2622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2623 | Result Code | 2624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2626 Type: 29 for Result Code 2628 Length: 4 2630 Result Code: The following values are defined: 2632 0 Success 2634 1 Failure (AC List message element MUST be present) 2636 2 Success (NAT detected) 2638 3 Failure (unspecified) 2640 4 Failure (Join Failure, Resource Depletion) 2642 5 Failure (Join Failure, Unknown Source) 2644 6 Failure (Join Failure, Incorrect Data) 2646 7 Failure (Join Failure, Session ID already in use) 2648 4.4.30. Session ID 2650 The session ID message element value contains a randomly generated 2651 unsigned 32-bit integer. 2653 0 1 2 3 2654 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 2655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2656 | Session ID | 2657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2659 Type: 30 for Session ID 2661 Length: 4 2663 Session ID: A 32-bit random session identifier 2665 4.4.31. Statistics Timer 2667 The statistics timer message element value is used by the AC to 2668 inform the WTP of the frequency which it expects to receive updated 2669 statistics. 2671 0 1 2672 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2674 | Statistics Timer | 2675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2677 Type: 31 for Statistics Timer 2679 Length: 2 2681 Statistics Timer: A 16-bit unsigned integer indicating the time, in 2682 seconds 2684 4.4.32. Vendor Specific Payload 2686 The Vendor Specific Payload is used to communicate vendor specific 2687 information between the WTP and the AC. The value contains the 2688 following format: 2690 0 1 2 3 2691 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 2692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2693 | Vendor Identifier | 2694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2695 | Element ID | Value... | 2696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2698 Type: 32 for Vendor Specific 2700 Length: >= 7 2702 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 2703 Network Management Private Enterprise Codes" [19] 2705 Element ID: A 16-bit Element Identifier which is managed by the 2706 vendor. 2708 Value: The value associated with the vendor specific element. 2710 4.4.33. WTP Board Data 2712 The WTP Board Data message element is sent by the WTP to the AC and 2713 contains information about the hardware present. 2715 0 1 2 3 2716 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 2717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2718 | Vendor Identifier | 2719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2720 | Type=0 | Length | 2721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2722 | Value... 2723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2724 | Type=1 | Length | 2725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2726 | Value... 2727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2728 | Optional additional vendor specific WTP board data TLVs 2730 Type: 33 for WTP Board Data 2732 Length: >=14 2734 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 2735 Network Management Private Enterprise Codes" 2737 Type: The following values are supported: 2739 0 - WTP Model Number: The WTP Model Number MUST be included in 2740 the WTP Board Data message element. 2742 1 - WTP Serial Number: The WTP Serial Number MUST be included in 2743 the WTP Board Data message element. 2745 2 - Board ID: A hardware identifier, which MAY be included in the 2746 WTP Board Data mesage element. 2748 3 - Board Revision A revision number of the board, which MAY be 2749 included in the WTP Board Data message element. 2751 4.4.34. WTP Descriptor 2753 The WTP descriptor message element is used by a WTP to communicate 2754 it's current hardware/firmware configuration. The value contains the 2755 following fields. 2757 0 1 2 3 2758 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 2759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2760 | Max Radios | Radios in use | Encryption Capabilities | 2761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2762 | Vendor Identifier | 2763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2764 | Type=0 | Length | 2765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2766 | Value... 2767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2768 | Vendor Identifier | 2769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2770 | Type=1 | Length | 2771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2772 | Value... 2773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2774 | Vendor Identifier | 2775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2776 | Type=0 | Length | 2777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2778 | Value... 2779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2781 Type: 34 for WTP Descriptor 2783 Length: >= 31 2785 Max Radios: An 8-bit value representing the number of radios (where 2786 each radio is identified via the RID field) supported by the WTP 2788 Radios in use: An 8-bit value representing the number of radios 2789 present in the WTP 2791 Encryption Capabilities: This 16-bit field is used by the WTP to 2792 communicate it's capabilities to the AC. Since most WTP's support 2793 link layer encryption, the AC may make use of these services. 2794 There are binding dependent encryption capabilities. A WTP that 2795 does not have any encryption capabilities would set this field to 2796 zero (0). Refer to the specific binding for further specification 2797 of the Encryption Capabilities field. 2799 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 2800 Network Management Private Enterprise Codes" 2802 Type: The following values are supported. The Hardware Version, 2803 Software Version, and Boot Version values MUST be included. 2805 0 - WTP Model Number: The WTP Model Number MUST be included in 2806 the WTP Board Data message element. 2808 1 - WTP Serial Number: The WTP Serial Number MUST be included in 2809 the WTP Board Data message element. 2811 2 - Board ID: A hardware identifier, which MAY be included in the 2812 WTP Board Data mesage element. 2814 3 - Board Revision A revision number of the board, which MAY be 2815 included in the WTP Board Data message element. 2817 4 - Hardware Version: A 32-bit integer representing the WTP's 2818 hardware version number 2820 5 - Software Version: A 32-bit integer representing the WTP's 2821 Firmware version number 2823 6 - Boot Version: A 32-bit integer representing the WTP's boot 2824 loader's version number 2826 4.4.35. WTP Fallback 2828 The WTP Fallback message element is sent by the AC to the WTP to 2829 enable or disable automatic CAPWAP fallback in the event that a WTP 2830 detects its preferred AC, and is not currently connected to it. 2832 0 2833 0 1 2 3 4 5 6 7 2834 +-+-+-+-+-+-+-+-+ 2835 | Mode | 2836 +-+-+-+-+-+-+-+-+ 2838 Type: 35 for WTP Fallback 2839 Length: 1 2841 Mode: The 8-bit value indicates the status of automatic CAPWAP 2842 fallback on the WTP. A value of zero disables fallback, while a 2843 value of one enables it. When enabled, if the WTP detects that 2844 its primary AC is available, and it is not connected to it, it 2845 SHOULD automatically disconnect from its current AC and reconnect 2846 to its primary. If disabled, the WTP will only reconnect to its 2847 primary through manual intervention (e.g., through the Reset 2848 Request command). 2850 4.4.36. WTP Frame Encapsulation Type 2852 The WTP Frame EncapsultationType message element allows the WTP to 2853 communicate the encapsulation type, or tunneling modes of operation 2854 which it supports to the AC. A WTP that advertises support for all 2855 types allows the AC to select which type will be used, based on its 2856 local policy. 2858 0 2859 0 1 2 3 4 5 6 7 2860 +-+-+-+-+-+-+-+-+ 2861 |Frame Enc Type | 2862 +-+-+-+-+-+-+-+-+ 2864 Type: 36 for WTP Frame Encapsulation Type 2866 Length: 1 2868 Frame Encapsulation Type: The Frame type specifies the encapsulation 2869 modes supported by the WTP. The following values are supported: 2871 1 - Local Bridging: Local Bridging allows the WTP to perform the 2872 bridging function. This value MUST NOT be used when the WTP 2873 MAC Type is set to Split-MAC. 2875 2 - 802.3 Bridging: 802.3 Bridging requires the WTP and AC to 2876 encapsulate all user payload as native IEEE 802.3 frames (see 2877 Section 4.2). This value MUST NOT be used when the WTP MAC 2878 Type is set to Split-MAC. 2880 4 - Native Bridging: Native Bridging requires the WTP and AC to 2881 encapsulate all user payloads as native wireless frames, as 2882 defined by the wireless binding (see Section 4.2). 2884 7 - All: The WTP is capable of supporting all frame encapsulation 2885 types. 2887 4.4.37. WTP IPv4 IP Address 2889 The WTP IPv4 address is used to perform NAT detection. 2891 0 1 2 3 2892 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 2893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2894 | WTP IPv4 IP Address | 2895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2897 Type: 37 for WTP IPv4 IP Address 2899 Length: 4 2901 WTP IPv4 IP Address: The IPv4 address from which the WTP is sending 2902 packets. This field is used for NAT detection. 2904 4.4.38. WTP MAC Type 2906 The WTP MAC-Type message element allows the WTP to communicate its 2907 mode of operation to the AC. A WTP that advertises support for both 2908 modes allows the AC to select the mode to use, based on local policy. 2910 0 2911 0 1 2 3 4 5 6 7 2912 +-+-+-+-+-+-+-+-+ 2913 | MAC Type | 2914 +-+-+-+-+-+-+-+-+ 2916 Type: 38 for WTP MAC Type 2918 Length: 1 2920 MAC Type: The MAC mode of operation supported by the WTP. The 2921 following values are supported 2923 0 - Local-MAC: Local-MAC is the default mode that MUST be 2924 supported by all WTPs. 2926 1 - Split-MAC: Split-MAC support is optional, and allows the AC 2927 to receive and process native wireless frames. 2929 2 - Both: WTP is capable of supporting both Local-MAC and Split- 2930 MAC. 2932 4.4.39. WTP Radio Information 2934 The WTP radios information message element is used to communicate the 2935 radio information in a specific slot. The Discovery Request MUST 2936 include one such message element per radio in the WTP. The Radio- 2937 Type field is used by the AC in order to determine which technology 2938 specific binding is to be used with the WTP. 2940 The value contains two fields, as shown. 2942 0 1 2 3 2943 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 2944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2945 | Radio ID | Radio Type | 2946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2947 | Radio Type | 2948 +-+-+-+-+-+-+-+-+ 2950 Type: 39 for WTP Radio Information 2952 Length: 5 2954 Radio ID: The Radio Identifier, which typically refers to an 2955 interface index on the WTP 2957 Radio Type: The type of radio present. Note this bitfield can be 2958 used to specify support for more than a single type of PHY/MAC. 2959 The following values are supported: 2961 1 - 802.11b: An IEEE 802.11b radio. 2963 2 - 802.11a: An IEEE 802.11a radio. 2965 4 - 802.11g: An IEEE 802.11g radio. 2967 8 - 802.11n: An IEEE 802.11n radio. 2969 0xOF - 802.11b, 802.11a, 802.11g and 802.11n: The 4 radio types 2970 indicated are supported in the WTP. 2972 4.4.40. WTP Manager Control IPv4 Address 2974 The WTP Manager Control IPv4 Address message element is sent by the 2975 AC to the WTP during the discovery process and is used by the AC to 2976 provide the interfaces available on the AC, and the current number of 2977 WTPs connected. In the event that multiple WTP Manager Control IPV4 2978 Address message elements are returned, the WTP is expected to perform 2979 load balancing across the multiple interfaces. 2981 0 1 2 3 2982 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 2983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2984 | IP Address | 2985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2986 | WTP Count | 2987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2989 Type: 40 for WTP Manager Control IPv4 Address 2991 Length: 6 2993 IP Address: The IP Address of an interface. 2995 WTP Count: The number of WTPs currently connected to the interface. 2997 4.4.41. WTP Manager Control IPv6 Address 2999 The WTP Manager Control IPv6 Address message element is sent by the 3000 AC to the WTP during the discovery process and is used by the AC to 3001 provide the interfaces available on the AC, and the current number of 3002 WTPs connected. This message element is useful for the WTP to 3003 perform load balancing across multiple interfaces. 3005 0 1 2 3 3006 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 3007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3008 | IP Address | 3009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3010 | IP Address | 3011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3012 | IP Address | 3013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3014 | IP Address | 3015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3016 | WTP Count | 3017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3019 Type: 41 for WTP Manager Control IPv6 Address 3021 Length: 18 3022 IP Address: The IP Address of an interface. 3024 WTP Count: The number of WTPs currently connected to the interface. 3026 4.4.42. WTP Name 3028 The WTP Name message element is a variable length bye string. The 3029 string is not zero terminated. 3031 0 3032 0 1 2 3 4 5 6 7 3033 +-+-+-+-+-+-+-+-+- 3034 | WTP Name ... 3035 +-+-+-+-+-+-+-+-+- 3037 Type: 42 for WTP Name 3039 Length: variable 3041 WTP Name: A non-zero terminated string containing the WTP name. 3043 4.4.43. WTP Reboot Statistics 3045 The WTP Reboot Statistics message element is sent by the WTP to the 3046 AC to communicate reasons why reboots have occurred. 3048 0 1 2 3 3049 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 3050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3051 | Crash Count | CAPWAP Initiated Count | 3052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3053 | Link Failure Count | Failure Type | 3054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3056 Type: 43 for WTP Reboot Statistics 3058 Length: 7 3060 Crash Count: The number of reboots that have occurred due to a WTP 3061 crash. A value of 65535 implies that this information is not 3062 available on the WTP. 3064 CAPWAP Initiated Count: The number of reboots that have occurred at 3065 the request of a CAPWAP protocol message, such as a change in 3066 configuration that required a reboot or an explicit CAPWAP reset 3067 request. A value of 65535 implies that this information is not 3068 available on the WTP. 3070 Link Failure Count: The number of times that a CAPWAP protocol 3071 connection with an AC has failed. 3073 Failure Type: The last WTP failure. The following values are 3074 supported: 3076 0 - Link Failure 3078 1 - CAPWAP Initiated (see Section 9.3) 3080 2 - WTP Crash 3082 255 - Unknown (e.g., WTP doesn't keep track of info) 3084 4.4.44. WTP Static IP Address Information 3086 The WTP Static IP Address Information message element is used by an 3087 AC to configure or clear a previously configured static IP address on 3088 a WTP. 3090 0 1 2 3 3091 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 3092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3093 | IP Address | 3094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3095 | Netmask | 3096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3097 | Gateway | 3098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3099 | Static | 3100 +-+-+-+-+-+-+-+-+ 3102 Type: 44 for WTP Static IP Address Information 3104 Length: 13 3106 IP Address: The IP Address to assign to the WTP. This field is only 3107 valid if the static field is set to one. 3109 Netmask: The IP Netmask. This field is only valid if the static 3110 field is set to one. 3112 Gateway: The IP address of the gateway. This field is only valid if 3113 the static field is set to one. 3115 Netmask: The IP Netmask. This field is only valid if the static 3116 field is set to one. 3118 Static: An 8-bit boolean stating whether the WTP should use a static 3119 IP address or not. A value of zero disables the static IP 3120 address, while a value of one enables it. 3122 4.5. CAPWAP Protocol Timers 3124 A WTP or AC that implements CAPWAP discovery MUST implement the 3125 following timers. 3127 4.5.1. DiscoveryInterval 3129 The minimum time, in seconds, that a WTP MUST wait after receiving a 3130 Discovery Response, before initiating a DTLS handshake. 3132 Default: 5 3134 4.5.2. DTLSRehandshake 3136 The minimum time, in seconds, a WTP MUST wait for DTLS rehandshake to 3137 complete. 3139 Default: 10 3141 4.5.3. DTLSSessionDelete 3143 The minimum time, in seconds, a WTP MUST wait for DTLS session 3144 deletion. 3146 Default: 5 3148 4.5.4. EchoInterval 3150 The minimum time, in seconds, between sending echo requests to the AC 3151 with which the WTP has joined. 3153 Default: 30 3155 4.5.5. KeyLifetime 3157 The maximum time, in seconds, which a CAPWAP DTLS session key is 3158 valid. 3160 Default: 28800 3162 4.5.6. MaxDiscoveryInterval 3164 The maximum time allowed between sending discovery requests from the 3165 interface, in seconds. Must be no less than 2 seconds and no greater 3166 than 180 seconds. 3168 Default: 20 seconds. 3170 4.5.7. NeighborDeadInterval 3172 The minimum time, in seconds, a WTP MUST wait without having received 3173 Echo Responses to its Echo Requests, before the destination for the 3174 Echo Request may be considered dead. Must be no less than 3175 2*EchoInterval seconds and no greater than 240 seconds. 3177 Default: 60 3179 4.5.8. ResponseTimeout 3181 The minimum time, in seconds, which the WTP or AC must respond to a 3182 CAPWAP Request message. 3184 Default: 1 3186 4.5.9. RetransmitInterval 3188 The minimum time, in seconds, which a non-acknowledged CAPWAP packet 3189 will be retransmitted. 3191 Default: 3 3193 4.5.10. SilentInterval 3195 The minimum time, in seconds, a WTP MUST wait after failing to 3196 receive any responses to its discovery requests, before it MAY again 3197 send discovery requests. 3199 Default: 30 3201 4.5.11. WaitJoin 3203 The maximum time, in seconds, a WTP MUST wait without having received 3204 a DTLS Handshake message from an AC. This timer must be greater than 3205 30 seconds. 3207 Default: 60 3209 4.6. CAPWAP Protocol Variables 3211 A WTP or AC that implements CAPWAP discovery MUST allow for the 3212 following variables to be configured by system management; default 3213 values are specified so as to make it unnecessary to configure any of 3214 these variables in many cases. 3216 4.6.1. DiscoveryCount 3218 The number of discoveries transmitted by a WTP to a single AC. This 3219 is a monotonically increasing counter. 3221 4.6.2. MaxDiscoveries 3223 The maximum number of discovery requests that will be sent after a 3224 WTP boots. 3226 Default: 10 3228 4.6.3. MaxRetransmit 3230 The maximum number of retransmissions for a given CAPWAP packet 3231 before the link layer considers the peer dead. 3233 Default: 5 3235 4.6.4. RetransmitCount 3237 The number of retransmissions for a given CAPWAP packet. This is a 3238 monotonically increasing counter. 3240 5. CAPWAP Discovery Operations 3242 The Discovery messages are used by a WTP to determine which ACs are 3243 available to provide service, and the capabilities and load of the 3244 ACs. 3246 5.1. Discovery Request Message 3248 The Discovery Request message is used by the WTP to automatically 3249 discover potential ACs available in the network. The Discovery 3250 Request message provides ACs with the primary capabilities of the 3251 WTP. A WTP must exchange this information to ensure subsequent 3252 exchanges with the ACs are consistent with the WTP's functional 3253 characteristics. A WTP must transmit this command even if it has a 3254 statically configured AC. 3256 Discovery Request messages MUST be sent by a WTP in the Discover 3257 state after waiting for a random delay less than 3258 MaxDiscoveryInterval, after a WTP first comes up or is 3259 (re)initialized. A WTP MUST send no more than the maximum of 3260 MaxDiscoveries Discovery Request messages, waiting for a random delay 3261 less than MaxDiscoveryInterval between each successive message. 3263 This is to prevent an explosion of WTP Discovery Request messages. 3264 An example of this occurring is when many WTPs are powered on at the 3265 same time. 3267 Discovery Request messages MUST be sent by a WTP when no Echo 3268 Response messages are received for NeighborDeadInterval and the WTP 3269 returns to the Idle state. Discovery Request messages are sent after 3270 NeighborDeadInterval. They MUST be sent after waiting for a random 3271 delay less than MaxDiscoveryInterval. A WTP MAY send up to a maximum 3272 of MaxDiscoveries Discovery Request messages, waiting for a random 3273 delay less than MaxDiscoveryInterval between each successive message. 3275 If a Discovery Response message is not received after sending the 3276 maximum number of Discovery Request messages, the WTP enters the 3277 Sulking state and MUST wait for an interval equal to SilentInterval 3278 before sending further Discovery Request messages. 3280 The Discovery Request message may be sent as a unicast, broadcast or 3281 multicast message. 3283 Upon receiving a Discovery Request message, the AC will respond with 3284 a Discovery Response message sent to the address in the source 3285 address of the received discovery request message. 3287 The following message elements MUST be included in the Discovery 3288 Request message: 3290 o Discovery Type, see Section 4.4.19 3292 o WTP Descriptor, see Section 4.4.34 3294 o WTP Frame Type, see Section 4.4.36 3296 o WTP MAC Type, see Section 4.4.38 3298 o WTP Radio Information, see Section 4.4.39 3300 5.2. Discovery Response Message 3302 The Discovery Response message provides a mechanism for an AC to 3303 advertise its services to requesting WTPs. 3305 The Discovery Response message is sent by an AC after receiving a 3306 Discovery Request message from a WTP. 3308 When a WTP receives a Discovery Response message, it MUST wait for an 3309 interval not less than DiscoveryInterval for receipt of additional 3310 Discovery Response messages. After the DiscoveryInterval elapses, 3311 the WTP enters the DTLS-Init state and selects one of the ACs that 3312 sent a Discovery Response message and send a DTLS Handshake to that 3313 AC. 3315 The following message elements MUST be included in the Discovery 3316 Response Message: 3318 o AC Descriptor, see Section 4.4.1 3320 o AC Name, see Section 4.4.4 3322 o WTP Manager Control IPv4 Address, see Section 4.4.40 3324 o WTP Manager Control IPv6 Address, see Section 4.4.41 3326 5.3. Primary Discovery Request Message 3328 The Primary Discovery Request message is sent by the WTP to determine 3329 whether its preferred (or primary) AC is available. 3331 A Primary Discovery Request message is sent by a WTP when it has a 3332 primary AC configured, and is connected to another AC. This 3333 generally occurs as a result of a failover, and is used by the WTP as 3334 a means to discover when its primary AC becomes available. As a 3335 consequence, this message is only sent by a WTP when it is in the Run 3336 state. 3338 The frequency of the Primary Discovery Request messages should be no 3339 more often than the sending of the Echo Request message. 3341 Upon receipt of a Discovery Request message, the AC responds with a 3342 Primary Discovery Response message sent to the address in the source 3343 address of the received Primary Discovery Request message. 3345 The following message elements MUST be included in the Primary 3346 Discovery Request message. 3348 o Discovery Type, see Section 4.4.19 3350 o WTP Descriptor, see Section 4.4.34 3352 o WTP Frame Type, see Section 4.4.36 3354 o WTP MAC Type, see Section 4.4.38 3356 o WTP Radio Information, see Section 4.4.39 A WTP Radio Information 3357 message element MUST be present for every radio in the WTP. 3359 5.4. Primary Discovery Response 3361 The Primary Discovery Response message enables an AC to advertise its 3362 availability and services to requesting WTPs that are configured to 3363 have the AC as its primary AC. 3365 The Primary Discovery Response message is sent by an AC after 3366 receiving a Primary Discovery Request message. 3368 When a WTP receives a Primary Discovery Response message, it may 3369 establish a CAPWAP protocol connection to its primary AC, based on 3370 the configuration of the WTP Fallback Status message element on the 3371 WTP. 3373 The following message elements MUST be included in the Primary 3374 Discovery Response message. 3376 o AC Descriptor, see Section 4.4.1 3378 o AC Name, see Section 4.4.4 3380 o WTP Manager Control IPv4 Address, see Section 4.4.40 3382 o WTP Manager Control IPv6 Address, see Section 4.4.41 3384 6. CAPWAP Join Operations 3386 The Join Request message is used by a WTP to request service from an 3387 AC after a DTLS connection is established to that AC. The Join 3388 Response message is used by the the AC to indicate that it will or 3389 will not provide service. 3391 6.1. Join Request 3393 The Join Request message is used by a WTP to inform an AC that it 3394 wishes to provide services through the AC. A Join Request message is 3395 sent by a WTP after receiving one or more Discovery Responses, and 3396 completion of DTLS session establishment. When an AC receives a Join 3397 Request message it responds with a Join Response message. 3399 Upon completion of the DTLS handshake (synonymous with DTLS "session 3400 establishment"), the WTP sends the Join Request message to the AC. 3401 Upon receipt of the Join Request Message, the AC generates a Join 3402 Response message and sends it to the WTP, indicating success or 3403 failure. 3405 Upon transmission of the Join Request message, the WTP sets the 3406 WaitJoin timer. If the Join Response message has not been received 3407 prior to expiration, the WTP aborts the Join process and transitions 3408 back to the Discovery state, see Section 2.3.1). Upon receipt of the 3409 Join Response message, the WaitJoin timer is deactivated. 3411 If the AC rejects the Join Request, it sends a Join Response with a 3412 failure indication then enters the CAPWAP reset state, resulting in 3413 shutdown of the DTLS session. 3415 Upon determining which AC to join, the WTP creates session state 3416 containing the AC address and session ID, creates the Join Request 3417 message, sets the WaitJoin timer for the session and sends the Join 3418 Request message to the AC. 3420 If an invalid (i.e. malformed) Join Request message is received, the 3421 message MUST be silently discarded by the AC. No response is sent to 3422 the WTP. The AC SHOULD log this event. 3424 The following message elements MUST be included in the Join Request 3425 message. 3427 o Location Data, see Section 4.4.26 3429 o Session ID, see Section 4.4.30 3430 o WTP Descriptor, see Section 4.4.34 3432 o WTP IPv4 IP Address, see Section 4.4.37 3434 o WTP Name, see Section 4.4.42 3436 o WTP Radio Information, see Section 4.4.39 A WTP Radio Information 3437 message element MUST be present for every radio in the WTP. 3439 6.2. Join Response 3441 The Join Response message is sent by the AC to indicate to a WTP that 3442 it is capable and willing to provide service to it. 3444 After determining that a WTP should join the AC, the AC creates 3445 session state containing the WTP address, port and session ID, sets 3446 the WaitJoin timer for the session, sends the Join Response message 3447 to the WTP. 3449 The WTP, receiving a Join Response message checks for success or 3450 failure. If the message indicates success, the WTP clears the 3451 WaitJoin timer for the session and proceeds to the Configure or Image 3452 Data state. Otherwise, the WTP enters the CAPWAP reset state, 3453 resulting in shutdown of the DTLS session. 3455 If the WaitJoin Timer expires prior to reception of the Join Response 3456 message, the WTP MUST terminate the handshake, deallocate associated 3457 session state and transition to the Discover state. 3459 If an invalid (malformed) Join Response message is received, the WTP 3460 SHOULD log an informative message detailing the error. This error 3461 MUST be treated in the same manner as AC non-responsiveness. In this 3462 way, the WaitJoin timer will eventually expire, in which case the WTP 3463 may (if it is so configured) attempt to join with an alternative AC. 3465 The following message elements MAY be included in the Join Response 3466 message. 3468 o Result Code, see Section 4.4.29 3470 o AC IPv4 List, see Section 4.4.2 3472 o AC IPv6 List, see Section 4.4.3 3474 o Session ID, see Section 4.4.30 3476 7. Control Channel Management 3478 The Control Channel Management messages are used by the WTP and AC to 3479 maintain a control communication channel. 3481 7.1. Echo Request 3483 The Echo Request message is a keep alive mechanism for CAPWAP control 3484 messages. 3486 Echo Request messages are sent periodically by a WTP in the Run state 3487 (see Section 2.3) to determine the state of the connection between 3488 the WTP and the AC. The Echo Request message is sent by the WTP when 3489 the Heartbeat timer expires. The WTP MUST start its 3490 NeighborDeadInterval timer when the Heartbeat timer expires. 3492 The Echo Request message carries no message elements. 3494 When an AC receives an Echo Request message it responds with an Echo 3495 Response message. 3497 7.2. Echo Response 3499 The Echo Response message acknowledges the Echo Request message, and 3500 is only processed while in the Run state (see Section 2.3). 3502 An Echo Response message is sent by an AC after receiving an Echo 3503 Request message. After transmitting the Echo Response message, the 3504 AC SHOULD reset its Heartbeat timer to expire in the value configured 3505 for EchoInterval. If another Echo Request message or other control 3506 message is not received by the AC when the timer expires, the AC 3507 SHOULD consider the WTP to be no longer be reachable. 3509 The Echo Response message carries no message elements. 3511 When a WTP receives an Echo Response message it stops the 3512 NeighborDeadInterval timer, and initializes the Heartbeat timer to 3513 the EchoInterval. 3515 If the NeighborDeadInterval timer expires prior to receiving an Echo 3516 Response message, or other control message, the WTP enters the Idle 3517 state. 3519 8. WTP Configuration Management 3521 Wireless Termination Point Configuration messages are used to 3522 exchange configuration information between the AC and the WTP. 3524 8.1. Configuration Consistency 3526 The CAPWAP protocol provides flexibility in how WTP configuration is 3527 managed. A WTP has two options: 3529 1. The WTP retains no configuration and accepts the configuration 3530 provided by the AC. 3532 2. The WTP retains the configuration of parameters provided by the AC 3533 that are non-default values. 3535 If the WTP opts to save configuration locally, the CAPWAP protocol 3536 state machine defines the Configure state, which allows for 3537 configuration exchange. In the Configure state, the WTP sends its 3538 current configuration overrides to the AC via the Configuration 3539 Status message. A configuration override is a parameter that is non- 3540 default. One example is that in the CAPWAP protocol, the default 3541 antenna configuration is internal omni antenna. A WTP that either 3542 has no internal antennas, or has been explicitly configured by the AC 3543 to use external antennas, sends its antenna configuration during the 3544 configure phase, allowing the AC to become aware of the WTP's current 3545 configuration. 3547 Once the WTP has provided its configuration to the AC, the AC sends 3548 its own configuration. This allows the WTP to inherit the 3549 configuration and policies from the AC. 3551 An AC maintains a copy of each active WTP's configuration. There is 3552 no need for versioning or other means to identify configuration 3553 changes. If a WTP becomes inactive, the AC MAY delete the 3554 configuration associated with it. If a WTP fails, and connects to a 3555 new AC, it provides its overridden configuration parameters, allowing 3556 the new AC to be aware of the WTP's configuration. 3558 This model allows for resiliency in case of an AC failure, that 3559 another AC can provide service to the WTP. In this scenario, the new 3560 AC would be automatically updated with WTP configuration changes, 3561 eliminating the need for inter-AC communication or the need for all 3562 ACs to be aware of the configuration of all WTPs in the network. 3564 Once the CAPWAP protocol enters the Run state, the WTPs begin to 3565 provide service. It is quite common for administrators to require 3566 that configuration changes be made while the network is operational. 3568 Therefore, the Configuration Update Request is sent by the AC to the 3569 WTP to make these changes at run-time. 3571 8.1.1. Configuration Flexibility 3573 The CAPWAP protocol provides the flexibility to configure and manage 3574 WTPs of varying design and functional characteristics. When a WTP 3575 first discovers an AC, it provides primary functional information 3576 relating to its type of MAC and to the nature of frames to be 3577 exchanged. The AC configures the WTP appropriately. The AC also 3578 establishes corresponding internal operations to deal with the WTP 3579 according to its functionalities. 3581 8.2. Configuration Status 3583 The Configuration Status message is sent by a WTP to deliver its 3584 current configuration to its AC. 3586 Configuration Status messages are sent by a WTP while in the 3587 Configure state. 3589 The Configuration Status message carries binding specific message 3590 elements. Refer to the appropriate binding for the definition of 3591 this structure. 3593 When an AC receives a Configuration Status message it will act upon 3594 the content of the packet and respond to the WTP with a Configuration 3595 Status Response message. 3597 The Configuration Status message includes multiple Administrative 3598 State message Elements. There is one such message element for the 3599 WTP, and one message element per radio in the WTP. 3601 The following message elements MUST be included in the Configuration 3602 Status message. 3604 o AC Name, see Section 4.4.4 3606 o AC Name with Index, see Section 4.4.5 3608 o Radio Administrative State, see Section 4.4.28 3610 o Statistics Timer, see Section 4.4.31 3612 o WTP Board Data, see Section 4.4.33 3614 o WTP Static IP Address Information, see Section 4.4.44 3615 o WTP Reboot Statistics, see Section 4.4.43 3617 8.3. Configuration Status Response 3619 The Configuration Status Response message is sent by an AC and 3620 provides a mechanism for the AC to override a WTP's requested 3621 configuration. 3623 Configuration Status Response messages are sent by an AC after 3624 receiving a Configure Request message. 3626 The Configuration Status Response message carries binding specific 3627 message elements. Refer to the appropriate binding for the 3628 definition of this structure. 3630 When a WTP receives a Configuration Status Response message it acts 3631 upon the content of the message, as appropriate. If the 3632 Configuration Status Response message includes a Change State Event 3633 message element that causes a change in the operational state of one 3634 of the Radio, the WTP will transmit a Change State Event to the AC, 3635 as an acknowledgement of the change in state. 3637 The following message elements MUST be included in the Configuration 3638 Status Response message. 3640 o AC IPv4 List, see Section 4.4.2 3642 o AC IPv6 List, see Section 4.4.3 3644 o CAPWAP Timers, see Section 4.4.10 3646 o Change State Event, see Section 4.4.11 3648 o Decryption Error Report Period, see Section 4.4.15 3650 o Idle Timeout, see Section 4.4.22 3652 o WTP Fallback, see Section 4.4.35 3654 8.4. Configuration Update Request 3656 Configure Update Request messages are sent by the AC to provision the 3657 WTP while in the Run state. This is used to modify the configuration 3658 of the WTP while it is operational. 3660 When an AC receives a Configuration Update Request message it will 3661 respond with a Configuration Update Response message, with the 3662 appropriate Result Code. 3664 One or more of the following message elements MAY be included in the 3665 Configuration Update message. 3667 o AC IPv4 List, see Section 4.4.2 3669 o AC IPv6 List, see Section 4.4.3 3671 o AC Name with Index, see Section 4.4.5 3673 o AC Timestamp, see Section 4.4.6 3675 o Add MAC ACL Entry, see Section 4.4.7 3677 o Add Static MAC ACL Entry, see Section 4.4.9 3679 o CAPWAP Timers, see Section 4.4.10 3681 o Change State Event, see Section 4.4.11 3683 o Decryption Error Report Period, see Section 4.4.15 3685 o Delete MAC ACL Entry, see Section 4.4.16 3687 o Delete Static MAC ACL Entry, see Section 4.4.18 3689 o Idle Timeout, see Section 4.4.22 3691 o Location Data, see Section 4.4.26 3693 o Radio Administrative State, see Section 4.4.28 3695 o Statistics Timer, see Section 4.4.31 3697 o WTP Fallback, see Section 4.4.35 3699 o WTP Name, see Section 4.4.42 3701 8.5. Configuration Update Response 3703 The Configuration Update Response message is the acknowledgement 3704 message for the Configuration Update Request message. 3706 The Configuration Update Response message is sent by a WTP after 3707 receiving a Configuration Update Request message. 3709 When an AC receives a Configure Update Response message the result 3710 code indicates if the WTP successfully accepted the configuration. 3712 The following message element MUST be present in the Configuration 3713 Update message. 3715 Result Code, see Section 4.4.29 3717 The following message elements MAY be present in the Configuration 3718 Update message. 3720 o AC IPv4 List, see Section 4.4.2 3722 o AC IPv6 List, see Section 4.4.3 3724 8.6. Change State Event Request 3726 The Change State Event Request message is used by the WTP to inform 3727 the AC of a change in the operational state. 3729 The Change State Event Request message is sent by the WTP when it 3730 receives a Configuration Response message that includes a Change 3731 State Event message element. It is also sent when the WTP detects an 3732 operational failure with a radio. The Change State Event Request 3733 message may be sent in either the Configure or Run state (see 3734 Section 2.3. 3736 When an AC receives a Change State Event message it will respond with 3737 a Change State Event Response message and make any necessary 3738 modifications to internal WTP data structures. 3740 The following message elements MUST be present in the Change State 3741 Event Request message. 3743 o Change State Event message element, see Section 4.4.11 3745 8.7. Change State Event Response 3747 The Change State Event Response message acknowledges the Change State 3748 Event Request message. 3750 A Change State Event Response message is by a WTP after receiving a 3751 Change State Event Request message. 3753 The Change State Event Response message carries no message elements. 3754 Its purpose is to acknowledge the receipt of the Change State Event 3755 Request message. 3757 The WTP does not need to perform any special processing of the Change 3758 State Event Response message. 3760 8.8. Clear Config Indication 3762 The Clear Config Indication message is used to reset a WTP's 3763 configuration. 3765 The Clear Config Indication message is sent by an AC to request that 3766 a WTP reset its configuration to the manufacturing default 3767 configuration. The Clear Config Indication message is sent while in 3768 the Run CAPWAP state. 3770 The Clear Config Indication message carries no message elements. 3772 When a WTP receives a Clear Config Indication message it resets its 3773 configuration to the manufacturing default configuration. 3775 9. Device Management Operations 3777 This section defines CAPWAP operations responsible for debugging, 3778 gathering statistics, logging, and firmware management. 3780 9.1. Image Data Request 3782 The Image Data Request message is used to update firmware on the WTP. 3783 This message and its companion response message are used by the AC to 3784 ensure that the image being run on each WTP is appropriate. 3786 Image Data Request messages are exchanged between the WTP and the AC 3787 to download a new firmware image to the WTP. When a WTP or AC 3788 receives an Image Data Request message it will respond with an Image 3789 Data Response message. The message elements contained within the 3790 Image Data Request is required in order to determine the intent of 3791 the request. Note that only one message element may be present in 3792 any given Image Data Request message. 3794 The decision that new firmware is to downloaded to the WTP can occur 3795 in one of two methods: 3797 When the WTP joins the AC, and each exchange their software 3798 revision, the WTP may opt to initiate a firmware download by 3799 sending an Image Data Request, which contains an Image Filename 3800 message element. 3802 Once the WTP is in the CAPWAP state, it is possible for the AC to 3803 cause the WTP to initiate a firmware download by initiating an 3804 Image Data Request, with the Initiate Download message element. 3805 The WTP would then transmit the Image Filename message element to 3806 start the download process. 3808 Regardless of how the download was initiated, once the AC receives an 3809 Image Data Request with the Image Filename message element, it begins 3810 the transfer process by transmitting its own request with the Image 3811 Data message element. This continues until the whole firmware image 3812 has been transfered. 3814 The following message elements MAY be included in the Image Data 3815 Request Message. 3817 o Image Data, see Section 4.4.23 3819 o Image Filename, see Section 4.4.24 3821 o Initiate Download, see Section 4.4.25 3823 9.2. Image Data Response 3825 The Image Data Response message acknowledges the Image Data Request 3826 message. 3828 An Image Data Response message is sent in response to a received 3829 Image Data Request message. Its purpose is to acknowledge the 3830 receipt of the Image Data Request message. 3832 The Image Data Response message carries no message elements. 3834 No action is necessary on receipt. 3836 9.3. Reset Request 3838 The Reset Request message is used to cause a WTP to reboot. 3840 A Reset Request message is sent by an AC to cause a WTP to 3841 reinitialize its operation. 3843 The Reset Request carries no message elements. 3845 When a WTP receives a Reset Request it will respond with a Reset 3846 Response and then reinitialize itself. 3848 9.4. Reset Response 3850 The Reset Response message acknowledges the Reset Request message. 3852 A Reset Response message is sent by the WTP after receiving a Reset 3853 Request message. 3855 The Reset Response message carries no message elements. Its purpose 3856 is to acknowledge the receipt of the Reset Request message. 3858 When an AC receives a Reset Response message, it is notified that the 3859 WTP will reinitialize its operation. 3861 9.5. WTP Event Request 3863 WTP Event Request message is used by a WTP to send information to its 3864 AC. The WTP Event Request message may be sent periodically, or sent 3865 in response to an asynchronous event on the WTP. For example, a WTP 3866 MAY collect statistics and use the WTP Event Request message to 3867 transmit the statistics to the AC. 3869 When an AC receives a WTP Event Request message it will respond with 3870 a WTP Event Response message. 3872 The WTP Event Request message MUST contain one of the message 3873 elements listed below, or a message element that is defined for a 3874 specific wireless technology. 3876 o Decryption Error Report, see Section 4.4.14 3878 o Duplicate IPv4 Address, see Section 4.4.20 3880 o Duplicate IPv6 Address, see Section 4.4.21 3882 9.6. WTP Event Response 3884 The WTP Event Response message acknowledges receipt of the WTP Event 3885 Request message. 3887 A WTP Event Response message issent by an AC after receiving a WTP 3888 Event Request message. 3890 The WTP Event Response message carries no message elements. 3892 9.7. Data Transfer Request 3894 The Data Transfer Request message is used to deliver debug 3895 information from the WTP to the AC. 3897 Data Transfer Request messages are sent by the WTP to the AC when the 3898 WTP determines that it has important information to send to the AC. 3899 For instance, if the WTP detects that its previous reboot was caused 3900 by a system crash, it can send the crash file to the AC. The remote 3901 debugger function in the WTP also uses the Data Transfer Request 3902 message to send console output to the AC for debugging purposes. 3904 When the AC receives a Data Transfer Request message it responds to 3905 the WTP ith a Data Transfer Response message. The AC MAY log the 3906 information received. 3908 The Data Transfer Request message MUST contain one of the message 3909 elements listed below. 3911 o Data Transfer Mode, see Section 4.4.13 3913 o Data Transfer Data, see Section 4.4.12 3915 9.8. Data Transfer Response 3917 The Data Transfer Response message acknowledges the Data Transfer 3918 Request message. 3920 A Data Transfer Response message is sent in response to a received 3921 Data Transfer Request message. Its purpose is to acknowledge receipt 3922 of the Data Transfer Request message. 3924 The Data Transfer Response message carries no message elements. 3926 Upon receipt of a Data Transfer Response message, the WTP transmits 3927 more information, if more information is available. 3929 10. Mobile Session Management 3931 Messages in this section are used by the AC to create, modify or 3932 delete mobile station session state on the WTPs. 3934 10.1. Mobile Config Request 3936 The Mobile Config Request message is used to create, modify or delete 3937 mobile session state on a WTP. The message is sent by the AC to the 3938 WTP, and may contain one or more message elements. The message 3939 elements for this CAPWAP control message include information that is 3940 generally highly technology specific. Refer to the appropriate 3941 binding section or document for the definitions of the messages 3942 elements that may be used in this control message. 3944 The following CAPWAP Control message elements MAY be included in the 3945 Mobile Config Request message. 3947 o Add Mobile Station, see Section 4.4.8 3949 o Delete Mobile Station, see Section 4.4.17 3951 10.2. Mobile Config Response 3953 The Mobile Configuration Response message is used to acknowledge a 3954 previously received Mobile Configuration Request message, and MUST 3955 include a Result Code message element, see Section 4.4.29 which 3956 indicates whether an error occurred on the WTP. 3958 This message requires no special processing, and is only used to 3959 acknowledge receipt of the Mobile Configuration Request message. 3961 11. IEEE 802.11 Binding 3963 This section defines the extensions required for the CAPWAP protocol 3964 to be used with the IEEE 802.11 protocol. 3966 11.1. Split MAC and Local MAC Functionality 3968 The CAPWAP protocol, when used with IEEE 802.11 devices, requires a 3969 specific behavior from the WTP and the AC, to support the required 3970 IEEE 802.11 protocol functions. 3972 For both the Split and Local MAC approaches, the CAPWAP functions, as 3973 defined in the taxonomy specification [Add reference], reside in the 3974 AC. 3976 11.1.1. Split MAC 3978 This section shows the division of labor between the WTP and the AC 3979 in a Split MAC architecture. Figure 3 shows the clear separation of 3980 functionality among CAPWAP components. 3982 Function Location 3983 Distribution Service AC 3984 Integration Service AC 3985 Beacon Generation WTP 3986 Probe Response Generation WTP 3987 Power Mgmt/Packet Buffering WTP 3988 Fragmentation/Defragmentation WTP/AC 3989 Assoc/Disassoc/Reassoc AC 3991 802.11e 3992 Classifying AC 3993 Scheduling WTP/AC 3994 Queuing WTP 3996 802.11i 3997 802.1X/EAP AC 3998 RSNA Key Management AC 3999 802.11 Encryption/Decryption WTP/AC 4001 Figure 3: Mapping of 802.11 Functions for Split MAC Architecture 4003 The Distribution and Integration services reside on the AC, and 4004 therefore all user data is tunneled between the WTP and the AC. As 4005 noted above, all real-time IEEE 802.11 services, including the beacon 4006 and probe response frames, are handled on the WTP. 4008 All remaining IEEE 802.11 MAC management frames are supported on the 4009 AC, including the Association Request which allows the AC to be 4010 involved in the access policy enforcement portion of the IEEE 802.11 4011 protocol. The IEEE 802.1X and IEEE 802.11i key management function 4012 are also located on the AC. 4014 While the admission control component of IEEE 802.11e resides on the 4015 AC, the real time scheduling and queuing functions are on the WTP. 4016 Note this does not exclude the AC from providing additional policing 4017 and scheduling functionality. 4019 Note that in the following figure, the use of '( - )' indicates that 4020 processing of the frames is done on the WTP. 4022 Client WTP AC 4024 Beacon 4025 <----------------------------- 4026 Probe Request 4027 ----------------------------( - )-------------------------> 4028 Probe Response 4029 <----------------------------- 4030 802.11 AUTH/Association 4031 <---------------------------------------------------------> 4032 Mobile Config Request[Add Mobile (Clear Text, 802.1X)] 4033 <-------------------------> 4034 802.1X Authentication & 802.11i Key Exchange 4035 <---------------------------------------------------------> 4036 Mobile Config Request[Add Mobile (AES-CCMP, PTK=x)] 4037 <-------------------------> 4038 802.11 Action Frames 4039 <---------------------------------------------------------> 4040 802.11 DATA (1) 4041 <---------------------------( - )-------------------------> 4043 Figure 4: Split MAC Message Flow 4045 Figure 4 provides an illustration of the division of labor in a Split 4046 MAC architecture. In this example, a WLAN has been created that is 4047 configured for IEEE 802.11i, using AES-CCMP for privacy. The 4048 following process occurs: 4050 o The WTP generates the IEEE 802.11 beacon frames, using information 4051 provided to it through the Add WLAN (see Section Section 11.10.1) 4052 message element. 4054 o The WTP processes the probe request and responds with a 4055 corresponding probe response. The probe request is then forwarded 4056 to the AC for optional processing. 4058 o The WTP forwards the IEEEE 802.11 Authentication and Association 4059 frames to the AC, which is responsible for responding to the 4060 client. 4062 o Once the association is complete, the AC transmits an CAPWAP Add 4063 Mobile Station request to the WTP (see Section Section 4.4.8. In 4064 the above example, the WLAN is configured for IEEE 802.1X, and 4065 therefore the '802.1X only' policy bit is enabled. 4067 o If the WTP is providing encryption/decryption services, once the 4068 client has completed the IEEE 802.11i key exchange, the AC 4069 transmits another Add Mobile request to the WTP, stating the 4070 security policy to enforce for the client (in this case AES-CCMP), 4071 as well as the encryption key to use. If encryption/decryption is 4072 handled in the AC, the Add Mobile Station request would have the 4073 encryption policy set to "Clear Text". 4075 o The WTP forwards any 802.11 Action frames received to the AC. 4077 o All client data frames are tunneled between the WTP and the AC. 4078 Note that the WTP is responsible for encrypting and decrypting 4079 frames, if it was indicated in the Add Mobile request. 4081 11.1.2. Local MAC 4083 This section shows the division of labor between the WTP and the AC 4084 in a Local MAC architecture. Figure 5 shows the clear separation of 4085 functionality among CAPWAP components. 4087 Function Location 4088 Distribution Service WTP 4089 Integration Service WTP 4090 Beacon Generation WTP 4091 Probe Response WTP 4092 Power Mgmt/Packet Buffering WTP 4093 Fragmentation/Defragmentation WTP 4094 Assoc/Disassoc/Reassoc WTP 4096 802.11e 4097 Classifying WTP 4098 Scheduling WTP 4099 Queuing WTP 4101 802.11i 4102 802.1X/EAP AC 4103 RSNA Key Management AC 4104 802.11 Encryption/Decryption WTP 4106 Figure 5: Mapping of 802.11 Functions for Local AP Architecture 4108 Given the Distribution and Integration Services exist on the WTP, 4109 client data frames are not forwarded to the AC, with the exception 4110 listed in the following paragraphs. 4112 While the MAC is terminated on the WTP, it is necessary for the AC to 4113 be aware of mobility events within the WTPs. As a consequence, the 4114 WTP MUST forward the IEEE 802.11 Association Requests to the AC, and 4115 the AC MAY reply with a failed Association Response if it deems it 4116 necessary. 4118 The IEEE 802.1X and RSNA Key Management function resides in the AC. 4119 Therefore, the WTP MUST forward all IEEE 802.1X/RSNA Key Management 4120 frames to the AC and forward the associated responses to the station. 4122 Note that in the following figure, the use of '( - )' indicates that 4123 processing of the frames is done on the WTP. 4125 Client WTP AC 4127 Beacon 4128 <----------------------------- 4129 Probe 4130 <----------------------------> 4131 802.11 AUTH 4132 <----------------------------- 4133 802.11 Association 4134 <---------------------------( - )-------------------------> 4135 Mobile Config Request[Add Mobile (Clear Text, 802.1X)] 4136 <-------------------------> 4137 802.1X Authentication & 802.11i Key Exchange 4138 <---------------------------------------------------------> 4139 802.11 Action Frames 4140 <---------------------------------------------------------> 4141 Mobile Config Request[Add Mobile (AES-CCMP, PTK=x)] 4142 <-------------------------> 4143 802.11 DATA 4144 <-----------------------------> 4146 Figure 6: Local MAC Message Flow 4148 Figure 6 provides an illustration of the division of labor in a Local 4149 MAC architecture. In this example, a WLAN has been created that is 4150 configured for IEEE 802.11i, using AES-CCMP for privacy. The 4151 following process occurs: 4153 o The WTP generates the IEEE 802.11 beacon frames, using information 4154 provided to it through the Add WLAN (see Section 11.10.1) message 4155 element. 4157 o The WTP processes the probe request and responds with a 4158 corresponding probe response. 4160 o The WTP forwards the IEEE 802.11 Authentication and Association 4161 frames to the AC, which is responsible for responding to the 4162 client. 4164 o Once the association is complete, the AC transmits an CAPWAP Add 4165 Mobile Station message element to the WTP (see Section 4166 Section 4.4.8. In the above example, the WLAN is configured for 4167 IEEE 802.1X, and therefore the '802.1X only' policy bit is 4168 enabled. 4170 o The WTP forwards all IEEE 802.1X and IEEE 802.11i key exchange 4171 messages to the AC for processing. 4173 o The AC transmits another Add Mobile Station message element to the 4174 WTP, stating the security policy to enforce for the client (in 4175 this case AES-CCMP), as well as the encryption key to use. The 4176 Add Mobile Station message element MAY include a VLAN name, which 4177 when present is used by the WTP to identify the VLAN on which the 4178 user's data frames are to be bridged. 4180 o The WTP forwards any IEEE 802.11 Action frames received to the AC. 4182 11.2. Roaming Behavior 4184 It is important that CAPWAP implementations react properly to mobile 4185 devices associating to the networks in how they generate Add Mobile 4186 and Delete Mobile messages. This section expands upon the examples 4187 provided in the previous section, and describes how the CAPWAP 4188 control protocol is used in order to provide secure roaming. 4190 Once a client has successfully associated with the network in a 4191 secure fashion, it is likely to attempt to roam to another WTP. 4192 Figure 7 shows an example of a currently associated station moving 4193 from its "Old WTP" to a "new WTP". The figure is useful for multiple 4194 different security policies, including IEEE 802.1X and dynamic WEP 4195 keys, WPA or even WPA2 both with key caching (where the IEEE 802.1x 4196 exchange would be bypassed) and without. 4198 Client Old WTP WTP AC 4200 Association Request/Response 4201 <--------------------------------------( - )--------------> 4202 Mobile Config Request[Add Mobile (Clear Text, 802.1X)] 4203 <----------------> 4204 802.1X Authentication (if no key cache entry exists) 4205 <--------------------------------------( - )--------------> 4206 802.11i 4-way Key Exchange 4207 <--------------------------------------( - )--------------> 4208 Mobile Config Request[Delete Mobile] 4209 <----------------------------------> 4210 Mobile Config Request[Add Mobile (AES-CCMP, PTK=x)] 4211 <----------------> 4213 Figure 7: Client Roaming Example 4215 11.3. Group Key Refresh 4217 Periodically, the Group Key (GTK)for the BSS needs to be updated. 4218 The AC uses an EAPoL frame to update the group key for each STA in 4219 the BSS. While the AC is updating the GTK, each L2 broadcast frame 4220 transmitted to the BSS needs to be duplicated and transmitted using 4221 both the current GTK and the new GTK. Once the GTK update process 4222 has completed, broadcast frames transmitted to the BSS will be 4223 encrypted using the new GYT 4225 In the case of Split MAC, the AC needs to duplicate all broadcast 4226 packets and update the key index so that the packet is transmitted 4227 using both the current and new GTK to ensure that all STA's in the 4228 BSS receive the broadcast frames. In the case of local MAC, the WTP 4229 needs to duplicate and transmit broadcast frames using the 4230 appropriate index to ensure that all STA's in the BSS continue to 4231 receive broadcast frames. 4233 The Group Key update procedure is given in the following figure. The 4234 AC will signal the update to the GTK using an 802.11 Configuration 4235 Request frame with the new GTK, its index, and the Key Status set to 4236 3 (begin GTK update). The AC will then begin updating the GTK for 4237 each STA. During this time, the AC (for Split MAC) or WTP (for Local 4238 MAC) must duplicate broadcast packets and transmit them encrypted 4239 with both the current and new GTK. When the AC has completed the GTK 4240 update to all STA's in the BSS, the AC must transmit an 802.11 4241 Configuration Request frame containing the new GTK, its index, and 4242 the Key Status set to 4 (GTK update complete). 4244 Client WTP AC 4246 802.11 Config Request ( Update WLAN (GTK, GTK Index, GTK Start) 4247 <---------------------------------------------- 4248 802.1X EAPoL (GTK Message 1) 4249 <-------------( - )------------------------------------------- 4250 802.1X EAPoL (GTK Message 2) 4251 -------------( - )-------------------------------------------> 4252 802.11 Config Request ( Update WLAN (GTK, GTK Index, GTK Complete) 4253 <--------------------------------------------- 4255 Figure 8: Group Key Update Procedure 4257 11.4. Transport specific bindings 4259 All CAPWAP transports have the following IEEE 802.11 specific 4260 bindings: 4262 Payload encapsulation The CAPWAP protocol defines the CAPWAP data 4263 frame, which is used to encapsulate a wireless payload. For IEEE 4264 802.11, the IEEE 802.11 header and payload are encapsulated 4265 (excluding the IEEE 802.11 FCS checksum). The IEEE 802.11 FCS 4266 checksum is handled by the WTP. This allows the WTP to validate a 4267 frame prior to sending it to the AC. Similarly, when an AC wishes 4268 to transmit a frame towards a station, the WTP computes and adds 4269 the FCS checksum. 4271 CAPWAP Header Reserved field The reserved CAPWAP header field (see 4272 figure Section 4.1) is only used with CAPWAP data frames, and it 4273 serves two purposes, depending upon the direction of the frame. 4274 For packets from the WTP to the AC, the field uses the format 4275 described in the IEEE 802.11 Frame Info" field. However, for 4276 frames sent by the AC to the WTP, the format used is described in 4277 described in the Destination WLANs field. 4279 IEEE 802.11 Frame Info When an CAPWAP data frame is received from a 4280 station over the air, it is encapsulated and this field is used to 4281 include radio and PHY specific information associated with the 4282 frame. 4284 When used with the IEEE 802.11 binding, the field follows the 4285 following format: 4287 0 1 2 3 4288 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 4289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4290 | RSSI | SNR | Data Rate | 4291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4293 RSSI: RSSI is a signed, 8-bit value. It is the received signal 4294 strength indication, in dBm. 4296 SNR: SNR is a signed, 8-bit value. It is the signal to noise 4297 ratio of the received IEEE 802.11 frame, in dB. 4299 Data Rate: The data rate field is a 16 bit unsigned value. The 4300 contents of the field is set to 1/10th of the data rate of the 4301 packet received by the WTP. For instance, a packet received at 4302 5.5Mbps would be set to 55, while 11Mbps would be set to 110. 4304 Destination WLANs The Destination WLAN field is used to specify the 4305 target WLANs for a given frame, and is only used with broadcast 4306 and multicast frames. This field allows the AC to transmit a 4307 single broadcast or multicast frame to the WTP, and allows the WTP 4308 to perform the necessary frame replication services. The field 4309 uses the following format: 4311 0 1 2 3 4312 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 4313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4314 | WLAN | Reserved | 4315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4317 WLAN: This bit field indicates the WLAN ID (see section 4318 Section 11.10.1) which the WTP will transmit the associated 4319 frame on. For instance, if a multicast packet is to be 4320 transmitted on WLANs 1 and 3, bits 1 and 3 of this field would 4321 be enabled. Note this field is to be set to zero for unicast 4322 packets and is unused if the WTP is not providing encryption 4323 services. 4325 Reserved: This field MUST be set to zero. 4327 11.5. BSSID to WLAN ID Mapping 4329 The CAPWAP protocol allows the WTP to assign BSSIDs upon creation of 4330 a WLAN (see Section Section 11.10.1). While manufacturers are free 4331 to assign BSSIDs using any arbitrary mechanism, it is advised that 4332 where possible the BSSIDs are assigned as a contiguous block. 4334 When assigned as a block, implementations can still assign any of the 4335 available BSSIDs to any WLAN. One possible method is for the WTP to 4336 assign the address using the following algorithm: base BSSID address 4337 + WLAN ID. 4339 The WTP communicates the maximum number of BSSIDs that it supports 4340 during the Config Request within the IEEE 802.11 WTP WLAN Radio 4341 Configuration message element (see Section 11.10.24). 4343 11.6. Quality of Service for Control Messages 4345 It is recommended that IEEE 802.11 MAC management frames be sent by 4346 both the AC and the WTP with appropriate Quality of Service values, 4347 ensuring that congestion in the network minimizes occurrences of 4348 packet loss. Therefore, a Quality of Service enabled CAPWAP device 4349 should use: 4351 802.1P: The precedence value of 6 SHOULD be used for all IEEE 802.11 4352 MAC management frames, except for Probe Requests which SHOULD use 4353 4. 4355 DSCP: The DSCP tag value of 46 SHOULD be used for all IEEE 802.11 4356 MAC management frames, except for Probe Requests which SHOULD use 4357 34. 4359 11.7. IEEE 802.11 Specific CAPWAP Control Messages 4361 This section defines CAPWAP Control Messages that are specific to the 4362 IEEE 802.11 binding. The two messages are defined as IEEE 802.11 4363 WLAN Config Request and IEEE 802.11 WLAN Config Response. See 4364 Section 4.3.1.1 4366 The valid message types for IEEE 802.11 specific control messages are 4367 listed below. The IANA Enterprise number used with these messages is 4368 13277 4370 CAPWAP Control Message Message Type 4371 Value 4373 IEEE 802.11 WLAN Config Request 3398912 4374 IEEE 802.11 WLAN Config Response 3398913 4376 11.7.1. IEEE 802.11 WLAN Config Request 4378 The IEEE 802.11 WLAN Configuration Request is sent by the AC to the 4379 WTP in order to change services provided by the WTP. This control 4380 message is used to either create, update or delete a WLAN on the WTP. 4382 The IEEE 802.11 WLAN Configuration Request is sent as a result of 4383 either some manual admistrative process (e.g., deleting a WLAN), or 4384 automatically to create a WLAN on a WTP. When sent automatically to 4385 create a WLAN, this control message is sent after the CAPWAP 4386 Configure Update Request message has been received by the WTP. 4388 Upon receiving this control message, the WTP will modify the 4389 necessary services, and transmit an IEEE 802.11 WLAN Configuration 4390 Response. 4392 A WTP MAY provide service for more than one WLAN, therefore every 4393 WLAN is identified through a numerical index. For instance, a WTP 4394 that is capable of supporting up to 16 SSIDs, could accept up to 16 4395 IEEE 802.11 WLAN Configuration Request messages that include the Add 4396 WLAN message element. 4398 Since the index is the primary identifier for a WLAN, an AC MAY 4399 attempt to ensure that the same WLAN is identified through the same 4400 index number on all of its WTPs. An AC that does not follow this 4401 approach MUST find some other means of maintaining a WLAN Identifier 4402 to SSID mapping table. 4404 The following message elements may be included in the IEEE 802.11 4405 WLAN Config Request message. Only one message element MUST be 4406 present. 4408 o IEEE 802.11 Add WLAN, see Section 11.10.1 4410 o IEEE 802.11 Delete WLAN, see Section 11.10.5 4412 o IEEE 802.11 Update WLAN, see Section 11.10.21 4414 o IEEE 802.11 Information Element, see Section 11.10.7 4416 11.7.2. IEEE 802.11 WLAN Config Response 4418 The IEEE 802.11 WLAN Configuration Response is sent by the AC to the 4419 WTP as an acknowledgement of the receipt of an IEEE 802.11 WLAN 4420 Configuration Request. 4422 The following message elements may be included in the IEEE 802.11 4423 WLAN Config Request message. Only one message element MUST be 4424 present. 4426 o IEEE 802.11 Assigned WTP BSSID, see Section 11.10.3 4428 11.8. Data Message bindings 4430 There are no CAPWAP Data Message bindings for IEEE 802.11. 4432 11.9. Control Message bindings 4434 This section describes he IEEE 802.11 specific message elements 4435 included in CAPWAP Control Messages. 4437 11.9.1. Mobile Config Request 4439 The following IEEE 802.11 specific message elements MAY used with the 4440 CAPWAP Mobile Config Request message. 4442 o IEEE 802.11 Mobile, see Section 11.10.11 4444 o IEEE 802.11 Mobile Session Key, see Section 11.10.12 4446 o Station QOS Profile, see Section 11.10.25 4448 11.9.2. WTP Event Request 4450 The following IEEE 802.11 specific message elements may be included 4451 in the CAPWAP WTP Event Request message. 4453 o IEEE 802.11 MIC Countermeasures, see Section 11.10.9 4454 o IEEE 802.11 Statistics, see Section 11.10.16 4456 o IEEE 802.11 WTP Radio Fail Alarm Indication, see Section 11.10.23 4458 11.9.3. Configuration Messages 4460 This section defines the IEEE 802.11 Message Elements which MAY be 4461 included in the Configuration Status, Configuration Status Response, 4462 Configuration Update Request and Mobile Config Request CAPWAP control 4463 meessages. The binding of message elements to CAPWAP control 4464 messages is shown below: 4466 Conf Conf Conf Mobile 4467 Message Element Stat Stat Upd Config Req 4468 Msg Resp Msg Msg 4470 IEEE 802.11 Antenna X X X 4471 IEEE 802.11 Broadcast Probe Mode X X 4472 IEEE 802.11 Direct Sequence Control X X X 4473 IEEE 802.11 MAC Operation X X X 4474 IEEE 802.11 MIC Error Report From Mobile X 4475 IEEE 802.11 Mobile Session Key X 4476 IEEE 802.11 Multi-domain Capability X X X 4477 IEEE 802.11 OFDM Control X X X 4478 IEEE 802.11 Rate Set X X 4479 IEEE 802.11 Supported Rates X X 4480 IEEE 802.11 Tx Power X X X 4481 IEEE 802.11 Tx Power Level X 4482 IEEE 802.11 Update Mobile QoS X 4483 IEEE 802.11 WTP Mode and Type X? X 4484 IEEE 802.11 WTP Quality of Service X X 4485 IEEE 802.11 WTP Radio Configuration X X X 4487 11.10. IEEE 802.11 Message Element Definitions 4489 11.10.1. IEEE 802.11 Add WLAN 4491 The Add WLAN message element is used by the AC to define a wireless 4492 LAN on the WTP. The inclusion of this message element MUST also 4493 include IEEE 802.11 Information Element message elements, containing 4494 the following 802.11 IEs: 4496 Power Capability information element 4497 WPA information element 4499 RSN information element 4501 EDCA Parameter Set information element 4503 QoS Capability information element 4505 WMM information element 4507 The message element uses the following format: 4509 0 1 2 3 4510 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 4511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4512 | Radio ID | WLAN ID | Reserved | 4513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4514 | Encryption Policy | 4515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4516 | Key | 4517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4518 | Key | 4519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4520 | Key | 4521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4522 | Key | 4523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4524 | Key | 4525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4526 | Key | 4527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4528 | Key | 4529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4530 | Key | 4531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4532 | Key Index | Key Status | QoS | Auth Type | 4533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4534 | MAC Mode | Tunnel Mode | Suppress SSID | SSID ... 4535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4537 Type: 1024 for IEEE 802.11 Add WLAN 4539 Length: >= 49 4541 Radio ID: An 8-bit value representing the radio. 4543 WLAN ID: An 8-bit value specifying the WLAN Identifier. 4545 Reserved: A 16-bit value that MUST be set to zero. 4547 Encryption Policy: A 32-bit value specifying the encryption scheme 4548 to apply to traffic to and from the mobile station. The 4549 applicability of the encryption policy depends upon the security 4550 policy. For static WEP keys, which is true when the 'Shared Key' 4551 bit is set, this encryption policy is relevant for both unicast 4552 and multicast traffic. For encryption schemes that employ a 4553 separate encryption key for unicast and multicast traffic, the 4554 encryption policy defined here only applies to multicast data. In 4555 these scenarios, the unicast encryption policy is communicated via 4556 the Add Mobile Station (Section 4.4.8). 4558 0 - Encrypt WEP 104: All packets to/from the mobile station must 4559 be encrypted using standard 104 bit WEP. 4561 1 - Clear Text: All packets to/from the mobile station do not 4562 require any additional crypto processing by the WTP. 4564 2 - Encrypt WEP 40: All packets to/from the mobile station must be 4565 encrypted using standard 40 bit WEP. 4567 3 - Encrypt WEP 128: All packets to/from the mobile station must 4568 be encrypted using standard 128 bit WEP. 4570 4 - Encrypt AES-CCMP 128: All packets to/from the mobile station 4571 must be encrypted using 128 bit AES CCMP [7] 4573 5 - Encrypt TKIP-MIC: All packets to/from the mobile station must 4574 be encrypted using TKIP and authenticated using Michael [24] 4576 Key: A 32 byte Session Key to use with the encryption policy. 4578 Key-Index: The Key Index associated with the key. 4580 Key Status: A 1 byte value that specifies the state and usage of the 4581 key that has been included. The following values describe the key 4582 usage and its status: 4584 0 - A value of zero, with the 'Encryption Policy' field set to any 4585 value other than 'Clear Text' means that the WLAN uses per-station 4586 encryption keys, and therefore the key in the 'Key' field is only 4587 used for multicast traffic. 4589 1 - When set to one, the WLAN employs a shared WEP key, also known as 4590 a static WEP key, and uses the encryption key for both unicast and 4591 multicast traffic for all stations. 4593 2 - The value of 2 indicates that the AC will begin rekeying the GTK 4594 with the STA's in the BSS. It is only valid when IEEE 802.11i is 4595 enabled as the security policy for the BSS. 4597 3 - The value of 3 indicates that the AC has completed rekeying the 4598 GTK and broadcast packets no longer need to be duplicated and 4599 transmitted with both GTK's. 4601 QOS: An 8-bit value specifying the QoS policy to enforce for the 4602 station. 4604 The following values are supported: 4606 0 - Best Effort 4608 1 - Video 4610 2 - Voice 4612 3 - Background 4614 Auth Type: An 8-bit value specifying the supported authentication 4615 type. 4617 The following values are supported: 4619 0 - Open System 4621 1 - WEP Shared Key 4623 2 - WPA/WPA2 802.1X 4625 3 - WPA/WPA2 PSK 4627 MAC Mode: This field specifies whether the WTP should support the 4628 WLAN in Local or Split MAC modes. Note that the AC MUST NOT 4629 request a mode of operation that was not advertised by the WTP 4630 during the discovery process (see section Section 4.4.38). The 4631 following values are supported: 4633 0 - Local-MAC: Service for the WLAN is to be provided in Local 4634 MAC mode. 4636 1 - Split-MAC: Service for the WLAN is to be provided in Split 4637 MAC mode. 4639 Tunnel Mode: This field specifies the tunneling type to be used for 4640 all stations associated with the WLAN. Note that the AC MUST NOT 4641 request a mode of operation that was not advertised by the WTP 4642 during the discovery process (see section Section 4.4.36). The 4643 following values are supported: 4645 0 - Local Bridging: All user traffic is to be locally bridged. 4647 1 - 802.3 Tunnel: All user traffic is to be tunneled to the AC in 4648 802.3 format (see section Section 4.2). 4650 2 - 802.11 Bridging: All user traffic is to be tunneled to the AC 4651 in 802.11 format. 4653 Supress SSID: A boolean indicating whether the SSID is to be 4654 advertised by the WTP. A value of zero supresses the SSID in the 4655 802.11 Beacon and Probe Response frames, while a value of one will 4656 cause the WTP to populate the field. 4658 SSID: The SSID attribute is the service set identifier that will be 4659 advertised by the WTP for this WLAN. 4661 11.10.2. IEEE 802.11 Antenna 4663 The antenna message element is communicated by the WTP to the AC to 4664 provide information on the antennas available. The AC MAY use this 4665 element to reconfigure the WTP's antennas. The value contains the 4666 following fields: 4668 0 1 2 3 4669 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 4670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4671 | Radio ID | Diversity | Combiner | Antenna Cnt | 4672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4673 | Antenna Selection [0..N] | 4674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4676 Type: 1025 for IEEE 802.11 Antenna 4678 Length: >= 5 4680 Radio ID: An 8-bit value representing the radio to configure. 4682 Diversity: An 8-bit value specifying whether the antenna is to 4683 provide receive diversity. The following values are supported: 4685 0 - Disabled 4687 1 - Enabled (may only be true if the antenna can be used as a 4688 receive antenna) 4690 Combiner: An 8-bit value specifying the combiner selection. The 4691 following values are supported: 4693 1 - Sectorized (Left) 4695 2 - Sectorized (Right) 4697 3 - Omni 4699 4 - MIMO 4701 Antenna Count: An 8-bit value specifying the number of Antenna 4702 Selection fields. 4704 Antenna Selection: One 8-bit antenna configuration value per antenna 4705 in the WTP. The following values are supported: 4707 1 - Internal Antenna 4709 2 - External Antenna 4711 11.10.3. IEEE 802.11 Assigned WTP BSSID 4713 The IEEE 802.11 Assigned WTP BSSID is only included by the WTP when 4714 the IEEE 802.11 WLAN Config Request included the IEEE 802.11 Add WLAN 4715 message element. The value field of this message element contains 4716 the BSSID that has been assigned by the WTP, which allows the WTP to 4717 perform its own BSSID assignment. 4719 The WTP is free to assign the BSSIDs the way it sees fit, but it is 4720 highly recommended that the WTP assign the BSSID using the following 4721 algorithm: BSSID = {base BSSID} + WLAN ID. 4723 0 1 2 3 4724 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 4725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4726 | BSSID | 4727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4728 | BSSID | 4729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4731 Type: 1026 for IEEE 802.11 Assigned WTP BSSID 4733 Length: 6 4735 BSSID: The BSSID assigned by the WTP for the WLAN created as a 4736 result of receiving an IEEE 802.11 Add WLAN. 4738 11.10.4. IEEE 802.11 Broadcast Probe Mode 4740 The Broadcast Probe Mode message element indicates whether a WTP will 4741 respond to NULL SSID probe requests. Since broadcast NULL probes are 4742 not sent to a specific BSSID, the WTP cannot know which SSID the 4743 sending station is querying. Therefore, this behavior must be global 4744 to the WTP. 4746 0 4747 0 1 2 3 4 5 6 7 4748 +-+-+-+-+-+-+-+-+ 4749 | Status | 4750 +-+-+-+-+-+-+-+-+ 4752 Type: 1027 for IEEE 802.11 Broadcast Probe Mode 4754 Length: 1 4756 Status: An 8-bit boolean indicating the status of whether a WTP 4757 shall response to a NULL SSID probe request. A value of zero 4758 disables NULL SSID probe response, while a value of one enables 4759 it. 4761 11.10.5. IEEE 802.11 Delete WLAN 4763 The delete WLAN message element is used to inform the WTP that a 4764 previously created WLAN is to be deleted. The value contains the 4765 following fields: 4767 0 1 2 4768 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4770 | Radio ID | WLAN ID | 4771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4773 Type: 1028 for IEEE 802.11 Delete WLAN 4775 Length: 3 4776 Radio ID: An 8-bit value representing the radio 4778 WLAN ID: A 16-bit value specifying the WLAN Identifier 4780 11.10.6. IEEE 802.11 Direct Sequence Control 4782 The direct sequence control message element is a bi-directional 4783 element. When sent by the WTP, it contains the current state. When 4784 sent by the AC, the WTP MUST adhere to the values. This element is 4785 only used for 802.11b radios. The value has the following fields. 4787 0 1 2 3 4788 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 4789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4790 | Radio ID | Reserved | Current Chan | Current CCA | 4791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4792 | Energy Detect Threshold | 4793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4795 Type: 1029 for IEEE 802.11 Direct Sequence Control 4797 Length: 8 4799 Radio ID: An 8-bit value representing the radio to configure. 4801 Reserved: MUST be set to zero 4803 Current Channel: This attribute contains the current operating 4804 frequency channel of the DSSS PHY. 4806 Current CCA: The current CCA method in operation. Valid values are: 4808 1 - energy detect only (edonly) 4810 2 - carrier sense only (csonly) 4812 4 - carrier sense and energy detect (edandcs) 4814 8 - carrier sense with timer (cswithtimer) 4816 16 - high rate carrier sense and energy detect (hrcsanded) 4818 Energy Detect Threshold: The current Energy Detect Threshold being 4819 used by the DSSS PHY. 4821 11.10.7. IEEE 802.11 Information Element 4823 The IEEE 802.11 Information Element is used to communicate any IE 4824 defined in the IEEE 802.11 protocol. The data field contains the raw 4825 IE as it would be included within an IEEE 802.11 MAC management 4826 message. 4828 0 1 4829 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 4830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 4831 |B|P| Flags | Info Element 4832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 4834 Type: 1030 for IEEE 802.11 Information Element 4836 Length: >= 2 4838 B: When set, the WTP is to include the information element in 4839 beacons associated with the WLAN. 4841 P: When set, the WTP is to include the information element in probe 4842 responses associated with the WLAN. 4844 Flags: Reserved field and MUST be set to zero. 4846 Info Element: The IEEE 802.11 Information Element, which includes 4847 the type, length and value field. 4849 11.10.8. IEEE 802.11 MAC Operation 4851 The MAC operation message element is sent by the AC to set the 802.11 4852 MAC parameters on the WTP. The value contains the following fields. 4854 0 1 2 3 4855 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 4856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4857 | Radio ID | Reserved | RTS Threshold | 4858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4859 | Short Retry | Long Retry | Fragmentation Threshold | 4860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4861 | Tx MSDU Lifetime | 4862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4863 | Rx MSDU Lifetime | 4864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4866 Type: 1031 for IEEE 802.11 MAC Operation 4868 Length: 16 4870 Radio ID: An 8-bit value representing the radio to configure. 4872 Reserved: MUST be set to zero 4874 RTS Threshold: This attribute indicates the number of octets in an 4875 MPDU, below which an RTS/CTS handshake MUST NOT be performed. An 4876 RTS/CTS handshake MUST be performed at the beginning of any frame 4877 exchange sequence where the MPDU is of type Data or Management, 4878 the MPDU has an individual address in the Address1 field, and the 4879 length of the MPDU is greater than this threshold. Setting this 4880 attribute to be larger than the maximum MSDU size MUST have the 4881 effect of turning off the RTS/CTS handshake for frames of Data or 4882 Management type transmitted by this STA. Setting this attribute 4883 to zero MUST have the effect of turning on the RTS/CTS handshake 4884 for all frames of Data or Management type transmitted by this STA. 4885 The default value of this attribute MUST be 2347. 4887 Short Retry: This attribute indicates the maximum number of 4888 transmission attempts of a frame, the length of which is less than 4889 or equal to RTSThreshold, that MUST be made before a failure 4890 condition is indicated. The default value of this attribute MUST 4891 be 7. 4893 Long Retry: This attribute indicates the maximum number of 4894 transmission attempts of a frame, the length of which is greater 4895 than dot11RTSThreshold, that MUST be made before a failure 4896 condition is indicated. The default value of this attribute MUST 4897 be 4. 4899 Fragmentation Threshold: This attribute specifies the current 4900 maximum size, in octets, of the MPDU that MAY be delivered to the 4901 PHY. An MSDU MUST be broken into fragments if its size exceeds 4902 the value of this attribute after adding MAC headers and trailers. 4903 An MSDU or MMPDU MUST be fragmented when the resulting frame has 4904 an individual address in the Address1 field, and the length of the 4905 frame is larger than this threshold. The default value for this 4906 attribute MUST be the lesser of 2346 or the aMPDUMaxLength of the 4907 attached PHY and MUST never exceed the lesser of 2346 or the 4908 aMPDUMaxLength of the attached PHY. The value of this attribute 4909 MUST never be less than 256. 4911 Tx MSDU Lifetime: This attribute speficies the elapsed time in TU, 4912 after the initial transmission of an MSDU, after which further 4913 attempts to transmit the MSDU MUST be terminated. The default 4914 value of this attribute MUST be 512. 4916 Rx MSDU Lifetime: This attribute specifies the elapsed time in TU, 4917 after the initial reception of a fragmented MMPDU or MSDU, after 4918 which further attempts to reassemble the MMPDU or MSDU MUST be 4919 terminated. The default value MUST be 512. 4921 11.10.9. IEEE 802.11 MIC Countermeasures 4923 The MIC Countermeasures message element is sent by the WTP to the AC 4924 to indicate the occurrence of a MIC failure. 4926 0 1 2 3 4927 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 4928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4929 | Radio ID | WLAN ID | MAC Address | 4930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4931 | MAC Address | 4932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4934 Type: 1032 for IEEE 802.11 MIC Countermeasures 4936 Length: 8 4938 Radio ID: The Radio Identifier, typically refers to some interface 4939 index on the WTP. 4941 WLAN ID: This 8-bit unsigned integer includes the WLAN Identifier, 4942 on which the MIC failure occurred. 4944 MAC Address: The MAC Address of the mobile station that caused the 4945 MIC failure. 4947 11.10.10. IEEE 802.11 MIC Error Report From Mobile 4949 The MIC Error Report From Mobile message element is sent by an AC to 4950 an WTP when it receives a MIC failure notification, via the Error bit 4951 in the EAPOL-Key frame. 4953 0 1 2 3 4954 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 4955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4956 | Client MAC Address | 4957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4958 | Client MAC Address | BSSID | 4959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4960 | BSSID | 4961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4962 | Radio ID | WLAN ID | 4963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4965 Type: 1033 for IEEE 802.11 MIC Error Report From Mobile 4967 Length: 14 4969 Client MAC Address: The Client MAC Address of the station reporting 4970 the MIC failure. 4972 BSSID: The BSSID on which the MIC failure is being reported. 4974 Radio ID: The Radio Identifier, typically refers to some interface 4975 index on the WTP 4977 WLAN ID: The WLAN ID on which the MIC failure is being reported. 4979 11.10.11. IEEE 802.11 Mobile 4981 The IEEE 802.11 Mobile message element accompanies the Add Mobile 4982 message element, and is used to deliver IEEE 802.11 station policy 4983 from the AC to the WTP. 4985 The latest IEEE 802.11 Mobile message element overrides any 4986 previously received message elements. 4988 If the QoS field is set, the WTP MUST observe and provide policing of 4989 the 802.11e priority tag to ensure that it does not exceed the value 4990 provided by the AC. 4992 0 1 2 3 4993 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 4994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4995 | Radio ID | Association ID | Flags | 4996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4997 | Capabilities | WLAN ID |Supported Rates 4998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5000 Type: 1034 for Add IEEE 802.11 Mobile 5002 Length: >= 8 5004 Radio ID: An 8-bit value representing the radio 5006 Association ID: A 16-bit value specifying the IEEE 802.11 5007 Association Identifier 5009 Flags: The Flags field MUST be set to zero 5011 Capabilities: A 16-bit field containing the IEEE 802.11 capabilities 5012 to use with the mobile. 5014 WLAN ID: An 8-bit value specifying the WLAN Identifier 5016 Supported Rates: The variable length field containing the supported 5017 rates to be used with the mobile station. 5019 11.10.12. IEEE 802.11 Mobile Session Key 5021 The Mobile Session Key Payload message element is sent when the AC 5022 determines that encryption of a mobile station must be performed in 5023 the WTP. This message element MUST NOT be present without the IEEE 5024 802.11 Mobile (see Section 11.10.11) message element, and MUST NOT be 5025 sent if the WTP had not specifically advertised support for the 5026 requested encryption scheme. 5028 If the IEEE 802.11 Mobile Session Key message element's EAP-Only bit 5029 is set, the WTP MUST drop all IEEE 802.11 packets that do not contain 5030 EAP packets. Note that when EAP-Only is set, the Encryption Policy 5031 field MAY be set, and therefore it is possible to inform a WTP to 5032 only accept encrypted EAP packets. Once the mobile station has 5033 successfully completed EAP authentication, the AC must send a new Add 5034 Mobile message element to remove the EAP Only restriction, and 5035 optionally push the session key down to the WTP. 5037 0 1 2 3 5038 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 5039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5040 | MAC Address | 5041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5042 | MAC Address |E|C| Flags | 5043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5044 | Encryption Policy | 5045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5046 | Pairwise TSC | 5047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5048 | Pairwise TSC | Pairwise RSC | 5049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5050 | Pairwise RSC | 5051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5052 | Session Key... 5053 +-+-+-+-+-+-+-+- 5055 Type: 1035 for IEEE 802.11 Mobile Session Key 5057 Length: >= 25 5059 MAC Address: The mobile station's MAC Address 5061 Flags: A 16 bit field, whose unused bits MUST be set to zero. The 5062 following bits are defined: 5064 E: The one bit EAP-Only field is set by the AC to inform the WTP 5065 that is MUST NOT accept any 802.11 data frames, other than IEEE 5066 802.1X frames. This is the equivalent of the WTP's IEEE 802.1X 5067 port for the mobile station to be in the closed state. When 5068 set, the WTP MUST drop any non-IEEE 802.1X packets it receives 5069 from the mobile station. 5071 C: The one bit field is set by the AC to inform the WTP that 5072 encryption services will be provided by the AC. When set, the 5073 WTP SHOULD police frames received from stations to ensure that 5074 they comply to the stated encryption policy, but does not need 5075 to take specific cryptographic action on the frame. Similarly, 5076 for transmitted frames, the WTP only needs to forward already 5077 encrypted frames. 5079 Encryption Policy: The policy field informs the WTP how to handle 5080 packets from/to the mobile station. The following values are 5081 supported: 5083 0 - Encrypt WEP 104: All packets to/from the mobile station must 5084 be encrypted using standard 104 bit WEP. 5086 1 - Clear Text: All packets to/from the mobile station do not 5087 require any additional crypto processing by the WTP. 5089 2 - Encrypt WEP 40: All packets to/from the mobile station must be 5090 encrypted using standard 40 bit WEP. 5092 3 - Encrypt WEP 128: All packets to/from the mobile station must 5093 be encrypted using standard 128 bit WEP. 5095 4 - Encrypt AES-CCMP 128: All packets to/from the mobile station 5096 must be encrypted using 128 bit AES CCMP [7] 5098 5 - Encrypt TKIP-MIC: All packets to/from the mobile station must 5099 be encrypted using TKIP and authenticated using Michael [24] 5101 Pairwise TSC: The 6 byte Transmit Sequence Counter (TSC) field to 5102 use for unicast packets transmitted to the mobile. 5104 Pairwise RSC: The 6 byte Receive Sequence Counter (RSC) to use for 5105 unicast packets received from the mobile. 5107 Session Key: The session key the WTP is to use when encrypting 5108 traffic to/from the mobile station. For dynamically created keys, 5109 this is commonly known as a Pairwise Transient Key (PTK). 5111 11.10.13. IEEE 802.11 Multi-domain Capability 5113 The multi-domain capability message element is used by the AC to 5114 inform the WTP of regulatory limits. The value contains the 5115 following fields. 5117 0 1 2 3 5118 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 5119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5120 | Radio ID | Reserved | First Channel # | 5121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5122 | Number of Channels | Max Tx Power Level | 5123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5125 Type: 1036 for IEEE 802.11 Multi-Domain Capability 5127 Length: 8 5128 Radio ID: An 8-bit value representing the radio to configure. 5130 Reserved: MUST be set to zero 5132 First Channnel #: This attribute indicates the value of the lowest 5133 channel number in the subband for the associated domain country 5134 string. 5136 Number of Channels: This attribute indicates the value of the total 5137 number of channels allowed in the subband for the associated 5138 domain country string. 5140 Max Tx Power Level: This attribute indicates the maximum transmit 5141 power, in dBm, allowed in the subband for the associated domain 5142 country string. 5144 11.10.14. IEEE 802.11 OFDM Control 5146 The OFDM control message element is a bi-directional element. When 5147 sent by the WTP, it contains the current state. When sent by the AC, 5148 the WTP MUST adhere to the values. This element is only used for 5149 802.11a radios. The value contains the following fields: 5151 0 1 2 3 5152 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 5153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5154 | Radio ID | Reserved | Current Chan | Band Support | 5155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5156 | TI Threshold | 5157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5159 Type: 1037 for IEEE 802.11 OFDM Control 5161 Length: 8 5163 Radio ID: An 8-bit value representing the radio to configure. 5165 Reserved: MUST be set to zero 5167 Current Channel: This attribute contains the current operating 5168 frequency channel of the OFDM PHY. 5170 Band Supported: The capability of the OFDM PHY implementation to 5171 operate in the three U-NII bands. Coded as an integer value of a 5172 three bit field as follows: 5174 capable of operating in the lower (5.15-5.25 GHz) U-NII band 5175 capable of operating in the middle (5.25-5.35 GHz) U-NII band 5177 capable of operating in the upper (5.725-5.825 GHz) U-NII band 5179 For example, for an implementation capable of operating in the 5180 lower and mid bands this attribute would take the value 5182 TI Threshold: The Threshold being used to detect a busy medium 5183 (frequency). CCA MUST report a busy medium upon detecting the 5184 RSSI above this threshold. 5186 11.10.15. IEEE 802.11 Rate Set 5188 The rate set message element value is sent by the AC and contains the 5189 supported operational rates. It contains the following fields. 5191 0 1 2 3 5192 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 5193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5194 | Radio ID | Rate Set... 5195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5197 Type: 1038 for IEEE 802.11 Rate Set 5199 Length: >= 3 5201 Radio ID: An 8-bit value representing the radio to configure. 5203 Rate Set: The AC generates the Rate Set that the WTP is to include 5204 in it's Beacon and Probe messages. The length of this field is 5205 between 2 and 8 bytes. 5207 11.10.16. IEEE 802.11 Statistics 5209 The statistics message element is sent by the WTP to transmit it's 5210 current statistics. The value contains the following fields. 5212 0 1 2 3 5213 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 5214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5215 | Radio ID | Reserved | 5216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5217 | Tx Fragment Count | 5218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5219 | Multicast Tx Count | 5220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5221 | Failed Count | 5222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5223 | Retry Count | 5224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5225 | Multiple Retry Count | 5226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5227 | Frame Duplicate Count | 5228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5229 | RTS Success Count | 5230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5231 | RTS Failure Count | 5232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5233 | ACK Failure Count | 5234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5235 | Rx Fragment Count | 5236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5237 | Multicast RX Count | 5238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5239 | FCS Error Count | 5240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5241 | Tx Frame Count | 5242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5243 | Decryption Errors | 5244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5246 Type: 1039 for Statistics 5248 Length: 60 5250 Radio ID: An 8-bit value representing the radio. 5252 Tx Fragment Count: A 32-bit value representing the number of 5253 fragmented frames transmitted. 5255 Multicast Tx Count: A 32-bit value representing the number of 5256 multicast frames transmitted. 5258 Failed Count: A 32-bit value representing the transmit excessive 5259 retries. 5261 Retry Count: A 32-bit value representing the number of transmit 5262 retries. 5264 Multiple Retry Count: A 32-bit value representing the number of 5265 transmits that required more than one retry. 5267 Frame Duplicate Count: A 32-bit value representing the duplicate 5268 frames received. 5270 RTS Success Count: A 32-bit value representing the number of 5271 successfully transmitted Ready To Send (RTS). 5273 RTS Failure Count: A 32-bit value representing the failed 5274 transmitted RTS. 5276 ACK Failure Count: A 32-bit value representing the number of failed 5277 acknowledgements. 5279 Rx Fragment Count: A 32-bit value representing the number of 5280 fragmented frames received. 5282 Multicast RX Count: A 32-bit value representing the number of 5283 multicast frames received. 5285 FCS Error Count: A 32-bit value representing the number of FCS 5286 failures. 5288 Decryption Errors: A 32-bit value representing the number of 5289 Decryption errors that occurred on the WTP. Note that this field 5290 is only valid in cases where the WTP provides encryption/ 5291 decryption services. 5293 11.10.17. IEEE 802.11 Supported Rates 5295 The supported rates message element is sent by the WTP to indicate 5296 the rates that it supports. The value contains the following fields. 5298 0 1 2 3 5299 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 5300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5301 | Radio ID | Supported Rates... 5302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5304 Type: 1040 for IEEE 802.11 Supported Rates 5306 Length: >= 3 5308 Radio ID: An 8-bit value representing the radio. 5310 Supported Rates: The WTP includes the Supported Rates that its 5311 hardware supports. The format is identical to the Rate Set 5312 message element and is between 2 and 8 bytes in length. 5314 11.10.18. IEEE 802.11 Tx Power 5316 The Tx power message element value is bi-directional. When sent by 5317 the WTP, it contains the current power level of the radio in 5318 question. When sent by the AC, it contains the power level the WTP 5319 MUST adhere to. 5321 0 1 2 3 5322 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 5323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5324 | Radio ID | Reserved | Current Tx Power | 5325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5327 Type: 1041 for IEEE 802.11 Tx Power 5329 Length: 4 5331 Radio ID: An 8-bit value representing the radio to configure. 5333 Reserved: MUST be set to zero 5335 Current Tx Power: This attribute contains the transmit output power 5336 in mW. 5338 11.10.19. IEEE 802.11 Tx Power Level 5340 The Tx power level message element is sent by the WTP and contains 5341 the different power levels supported. The value contains the 5342 following fields. 5344 0 1 2 3 5345 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 5346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5347 | Radio ID | Num Levels | Power Level [n] | 5348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5350 Type: 1042 for IEEE 802.11 Tx Power Level 5352 Length: >= 4 5354 Radio ID: An 8-bit value representing the radio to configure. 5356 Num Levels: The number of power level attributes. 5358 Power Level: Each power level fields contains a supported power 5359 level, in mW. 5361 11.10.20. IEEE 802.11 Update Mobile QoS 5363 The Update Mobile QoS message element is used to change the Quality 5364 of Service policy on the WTP for a given mobile station. 5366 0 1 2 3 5367 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 5368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5369 | Radio ID | MAC Address | 5370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5371 | MAC Address | DSCP Tag | 802.1P Tag | 5372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5374 Type: 1043 for IEEE 802.11 Update Mobile QoS 5376 Length: 8 5378 Radio ID: The Radio Identifier, typically refers to some interface 5379 index on the WTP 5381 MAC Address: The mobile station's MAC Address. 5383 DSCP Tag: The DSCP label to use if packets are to be DSCP tagged. 5385 802.1P Tag: The 802.1P precedence value to use if packets are to be 5386 IEEE 802.1P tagged. 5388 11.10.21. IEEE 802.11 Update WLAN 5390 The Update WLAN message element is used by the AC to define a 5391 wireless LAN on the WTP. The inclusion of this message element MUST 5392 also include the IEEE 802.11 Information Element message element, 5393 containing the following 802.11 IEs: 5395 Power Capability information element 5397 WPA information element 5399 RSN information element 5401 EDCA Parameter Set information element 5403 QoS Capability information element 5405 WMM information element 5407 The message element uses the following format: 5409 0 1 2 3 5410 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 5411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5412 | Radio ID | WLAN ID |Encrypt Policy | 5413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5414 | Encryption Policy | Key... | 5415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5416 | Key ... | 5417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5418 | Key Index | Shared Key | 5419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5421 Type: 1044 for IEEE 802.11 Update WLAN 5423 Length: 43 5425 Radio ID: An 8-bit value representing the radio. 5427 WLAN ID: A 16-bit value specifying the WLAN Identifier. 5429 Encryption Policy: A 32-bit value specifying the encryption scheme 5430 to apply to traffic to and from the mobile station. The 5431 applicability of the encryption policy depends upon the security 5432 policy. For static WEP keys, which is true when the 'Shared Key' 5433 bit is set, this encryption policy is relevant for both unicast 5434 and multicast traffic. For encryption schemes that employ a 5435 separate encryption key for unicast and multicast traffic, the 5436 encryption policy defined here only applies to multicast data. In 5437 these scenarios, the unicast encryption policy is communicated via 5438 the Add Mobile Station (Section 4.4.8). 5440 The following values are supported: 5442 0 - Encrypt WEP 104: All packets to/from the mobile station must 5443 be encrypted using standard 104 bit WEP. 5445 1 - Clear Text: All packets to/from the mobile station do not 5446 require any additional crypto processing by the WTP. 5448 2 - Encrypt WEP 40: All packets to/from the mobile station must be 5449 encrypted using standard 40 bit WEP. 5451 3 - Encrypt WEP 128: All packets to/from the mobile station must 5452 be encrypted using standard 128 bit WEP. 5454 4 - Encrypt AES-CCMP 128: All packets to/from the mobile station 5455 must be encrypted using 128 bit AES CCMP [7] 5457 5 - Encrypt TKIP-MIC: All packets to/from the mobile station must 5458 be encrypted using TKIP and authenticated using Michael [24] 5460 Key: A 32 byte Session Key to use with the encryption policy. 5462 Key-Index: The Key Index associated with the key. 5464 Key Status: A 1 byte value that specifies the state and usage of the 5465 key that has been included. The following values describe the key 5466 usage and its status: 5468 0 - A value of zero, with the 'Encryption Policy' field set to any 5469 value other than 'Clear Text' means that the WLAN uses per-station 5470 encryption keys, and therefore the key in the 'Key' field is only 5471 used for multicast traffic. 5473 1 - When set to one, the WLAN employs a shared WEP key, also known as 5474 a static WEP key, and uses the encryption key for both unicast and 5475 multicast traffic for all stations. 5477 2 - The value of 2 indicates that the AC will begin rekeying the GTK 5478 with the STA's in the BSS. It is only valid when IEEE 802.11i is 5479 enabled as the security policy for the BSS. 5481 3 - The value of 3 indicates that the AC has completed rekeying the 5482 GTK and broadcast packets no longer need to be duplicated and 5483 transmitted with both GTK's. 5485 11.10.22. IEEE 802.11 WTP Quality of Service 5487 The WTP Quality of Service message element value is sent by the AC to 5488 the WTP to communicate quality of service configuration information. 5490 0 1 5491 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 5492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5493 | Radio ID | Tag Packets | 5494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5496 Type: 1045 for IEEE 802.11 WTP Quality of Service 5498 Length: >= 2 5500 Radio ID: The Radio Identifier, typically refers to some interface 5501 index on the WTP 5503 Tag Packets: An value indicating whether CAPWAP packets should be 5504 tagged with for QoS purposes. The following values are currently 5505 supported: 5507 0 - Untagged 5509 1 - 802.1P 5511 2 - DSCP 5513 Immediately following the above header is the following data 5514 structure. This data structure will be repeated five times; once 5515 for every QoS profile. The order of the QoS profiles are Voice, 5516 Video, Best Effort and Background. 5518 0 1 2 3 5519 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 5520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5521 | Queue Depth | CWMin | CWMax | 5522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5523 | CWMax | AIFS | Dot1P Tag | DSCP Tag | 5524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5526 Queue Depth: The number of packets that can be on the specific QoS 5527 transmit queue at any given time. 5529 CWMin: The Contention Window minimum value for the QoS transmit 5530 queue. 5532 CWMax: The Contention Window maximum value for the QoS transmit 5533 queue. 5535 AIFS: The Arbitration Inter Frame Spacing to use for the QoS 5536 transmit queue. 5538 Dot1P Tag: The 802.1P precedence value to use if packets are to be 5539 802.1P tagged. 5541 DSCP Tag: The DSCP label to use if packets are to be DSCP tagged. 5543 11.10.23. IEEE 802.11 WTP Radio Fail Alarm Indication 5545 The WTP Radio Fail Alarm Indication message element is sent by the 5546 WTP to the AC when it detects a radio failure. 5548 0 1 2 3 5549 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 5550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5551 | Radio ID | Type | Status | Pad | 5552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5554 Type: 1046 for WTP Radio Fail Alarm Indication 5556 Length: 4 5558 Radio ID: The Radio Identifier, typically refers to some interface 5559 index on the WTP 5561 Type: The type of radio failure detected. The following values are 5562 supported: 5564 1 - Receiver 5566 2 - Transmitter 5568 Status: An 8-bit boolean indicating whether the radio failure is 5569 being reported or cleared. A value of zero is used to clear the 5570 event, while a value of one is used to report the event. 5572 Pad: Reserved field MUST be set to zero (0). 5574 11.10.24. IEEE 802.11 WTP Radio Configuration 5576 The WTP WLAN radio configuration is used by the AC to configure a 5577 Radio on the WTP, and by the WTP to deliver its radio configuration 5578 to the AC. The message element value contains the following fields: 5580 0 1 2 3 5581 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 5582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5583 | Radio ID | Reserved | Num of BSSIDs | DTIM Period | 5584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5585 | BSSID | 5586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5587 | BSSID | Beacon Period | 5588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5589 | Country Code | 5590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5592 Type: 1047 for IEEE 802.11 WTP WLAN Radio Configuration 5594 Length: 16 5596 Radio ID: An 8-bit value representing the radio to configure. 5598 Reserved: MUST be set to zero 5600 BSSID: The WLAN Radio's base MAC Address. 5602 Number of BSSIDs: This attribute contains the maximum number of 5603 BSSIDs supported by the WTP. This value restricts the number of 5604 logical networks supported by the WTP, and is between 1 and 16. 5606 DTIM Period: This attribute specifies the number of beacon intervals 5607 that elapse between transmission of Beacons frames containing a 5608 TIM element whose DTIM Count field is 0. This value is 5609 transmitted in the DTIM Period field of Beacon frames. 5611 Beacon Period: This attribute specifies the number of TU that a 5612 station uses for scheduling Beacon transmissions. This value is 5613 transmitted in Beacon and Probe Response frames. 5615 Country Code: This attribute identifies the country in which the 5616 station is operating. Special attention is required with use of 5617 this field, as implementations which take action based on this 5618 field could violate regulatory requirements. Some regulatory 5619 bodies do permit configuration of the country code under certain 5620 restrictions, such as the FCC, when WTPs are certified as Software 5621 Defined Radios. 5623 The WTP and AC may ignore the value of this field, depending upon 5624 regulatory requirements, for example to avoid classification as a 5625 Software Defined Radio. When this field is used, the first two 5626 octets of this string is the two character country code as 5627 described in document ISO/IEC 3166- 1, and the third octet MUST 5628 have the value 1, 2 or 3 as defined below. When the value of the 5629 third octet is 255, the country code field is not used, and MUST 5630 be ignored 5632 1 an ASCII space character, if the regulations under which the 5633 station is operating encompass all environments in the country, 5635 2 an ASCII 'O' character, if the regulations under which the 5636 station is operating are for an outdoor environment only, or 5638 3 an ASCII 'I' character, if the regulations under which the 5639 station is operating are for an indoor environment only 5641 255 Country Code field is not used; ignore the field. 5643 11.10.25. Station QoS Profile 5645 The Station QoS Profile Payload message element contains the maximum 5646 IEEE 802.11e priority tag that may be used by the station. Any 5647 packet received that exceeds the value encoded in this message 5648 element must either be dropped or tagged using the maximum value 5649 permitted by to the user. The priority tag must be between zero (0) 5650 and seven (7). 5652 0 1 2 3 5653 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 5654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5655 | MAC Address | 5656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5657 | MAC Address | 802.1P Precedence Tag | 5658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5660 Type: 1048 for IEEE 802.11 Station QOS Profile 5662 Length: 8 5664 MAC Address: The mobile station's MAC Address 5665 802.1P Precedence Tag: The maximum 802.1P precedence value that the 5666 WTP will allow in the TID field in the extended 802.11e QOS Data 5667 header. 5669 11.11. Technology Specific Message Element Values 5671 This section lists IEEE 802.11 specific values for any generic CAPWAP 5672 message elements which include fields whose values are technology 5673 specific. 5675 IEEE 802.11 uses the following values: 5677 4 - Encrypt AES-CCMP 128: WTP supports AES-CCMP, as defined in [7]. 5679 5 - Encrypt TKIP-MIC: WTP supports TKIP and Michael, as defined in 5680 [24]. 5682 12. NAT Considerations 5684 There are two specific situations in which a NAT system may be used 5685 in conjunction with a CAPWAP-enabled system. The first consists of a 5686 configuration where the WTP is behind a NAT system. Given that all 5687 communication is initiated by the WTP, and all communication is 5688 performed over IP using two UDP ports, the protocol easily traverses 5689 NAT systems in this configuration. 5691 The second configuration is one where the AC sits behind a NAT. Two 5692 issues exist in this situation. First, an AC communicates its 5693 interfaces, and associated WTP load on these interfaces, through the 5694 WTP Manager Control IP Address. This message element is currently 5695 mandatory, and if NAT compliance became an issue, it would be 5696 possible to either: 5698 1. Make the WTP Manager Control IP Address optional, allowing the WTP 5699 to simply use the known IP Address. However, note that this 5700 approach would eliminate the ability to perform load balancing of 5701 WTP across ACs, and therefore is not the recommended approach. 5703 2. Allow an AC to be able to configure a NAT'ed address for every 5704 associated AC that would generally be communicated in the WTP 5705 Manager Control IP Address message element. 5707 3. Require that if a WTP determines that the AC List message element 5708 consists of a set of IP Addresses that are different from the AC's 5709 IP Address it is currently communicating with, then assume that 5710 NAT is being enforced, and require that the WTP communicate with 5711 the original AC's IP Address (and ignore the WTP Manager Control 5712 IP Address message element(s)). 5714 Another issue related to having an AC behind a NAT system is CAPWAP's 5715 support for the CAPWAP Objective to allow the control and data plane 5716 to be separated. In order to support this requirement, the CAPWAP 5717 protocol defines the WTP Manager Data IP Address message element, 5718 which allows the AC to inform the WTP that the CAPWAP data frames are 5719 to be forwarded to a separate IP Address. This feature MUST be 5720 disabled when an AC is behind a NAT. However, there is no easy way 5721 to provide some default mechanism that satisfies both the data/ 5722 control separation and NAT objectives, as they directly conflict with 5723 each other. As a consequence, user intervention will be required to 5724 support such networks. 5726 The CAPWAP protocol allows for all of the ACs identities supporting a 5727 group of WTPs to be communicated through the AC List message element. 5728 This feature must be disabled when the AC is behind a NAT and the IP 5729 Address that is embedded would be invalid. 5731 The CAPWAP protocol has a feature that allows an AC to configure a 5732 static IP address on a WTP. The WTP Static IP Address Information 5733 message element provides such a function, however this feature SHOULD 5734 NOT be used in NAT'ed environments, unless the administrator is 5735 familiar with the internal IP addressing scheme within the WTP's 5736 private network, and does not rely on the public address seen by the 5737 AC. 5739 When a WTP detects the duplicate address condition, it generates a 5740 message to the AC, which includes the Duplicate IP Address message 5741 element. The IP Address embedded within this message element is 5742 different from the public IP address seen by the AC. 5744 13. Security Considerations 5746 This section describes security considerations for the CAPWAP 5747 protocol. It also provides security recommendations for protocols 5748 used in conjunction with CAPWAP. 5750 13.1. CAPWAP Security 5752 As it is currently specified, the CAPWAP protocol sits between the 5753 security mechanisms specified by the wireless link layer protocol 5754 (e.g.IEEE 802.11i) and AAA. One goal of CAPWAP is to bootstrap trust 5755 between the STA and WTP using a series of preestablished trust 5756 relationships: 5758 STA WTP AC AAA 5759 ============================================== 5761 DTLS Cred AAA Cred 5762 <------------><-------------> 5764 EAP Credential 5765 <------------------------------------------> 5767 wireless link layer 5768 (e.g.802.11 PTK) 5769 <--------------> 5770 (derived) 5772 Within CAPWAP, DTLS is used to secure the link between the WTP and 5773 AC. In addition to securing control messages, it's also a link in 5774 this chain of trust for establishing link layer keys. Consequently, 5775 much rests on the security of DTLS. 5777 In some CAPWAP deployment scenarios, there are two channels between 5778 the WTP and AC: the control channel, carrying CAPWAP control 5779 messages, and the data channel, over which client data packets are 5780 tunneled between the AC and WTP. Typically, the control channel is 5781 secured by DTLS, while the data channel is not. In the remote WTP 5782 with local MAC deployment scenario, there is only one channel (a 5783 control channel) between the AC and WTP. 5785 The use of parallel protected and unprotected channels deserves 5786 special consideration, but does not create a threat. There are two 5787 potential concerns: attempting to convert protected data into un- 5788 protected data and attempting to convert un-protected data into 5789 protected data. These concerns are addressed below. 5791 13.1.1. Converting Protected Data into Unprotected Data 5793 Since CAPWAP does not support authentication-only ciphers (i.e. all 5794 supported ciphersuites include encryption and authentication), it is 5795 not possible to convert protected data into unprotected data. Since 5796 encrypted data is (ideally) indistinguishable from random data, the 5797 probability of an encrypted packet passing for a well-formed packet 5798 is effectively zero. 5800 13.1.2. Converting Unprotected Data into Protected Data (Insertion) 5802 The use of message authentication makes it impossible for the 5803 attacker to forge protected records. This makes conversion of 5804 unprotected records to protected records impossible. 5806 13.1.3. Deletion of Protected Records 5808 An attacker could remove protected records from the stream, though 5809 not undetectably so, due the built-in reliability of the underlying 5810 CAPWAP protocol. In the worst case, the attacker would remove the 5811 same record repeatedly, resulting in a CAPWAP session timeout and 5812 restart. This is effectively a DoS attack, and could be accomplished 5813 by a man in the middle regardless of the CAPWAP protocol security 5814 mechanisms chosen. 5816 13.1.4. Insertion of Unprotected Records 5818 An attacker could inject packets into the unprotected channel, but 5819 this may become evident if sequence number desynchronization occurs 5820 as a result. Only if the attacker is a MiM can packets be inserted 5821 undetectably. This is a consequence of that channel's lack of 5822 protection, and not a new threat resulting from the CAPWAP security 5823 mechanism. 5825 13.2. Use of Preshared Keys in CAPWAP 5827 While use of preshared keys may provide deployment and provisioning 5828 advantages not found in public key based deployments, it also 5829 introduces a number of operational and security concerns. In 5830 particular, because the keys must typically be entered manually, it 5831 is common for people to base them on memorable words or phrases. 5832 These are referred to as "low entropy passwords/passphrases". 5834 Use of low-entropy preshared keys, coupled with the fact that the 5835 keys are often not frequently updated, tends to significantly 5836 increase exposure. For these reasons, we make the following 5837 recommendations: 5839 o When DTLS is used with a preshared-key (PSK) ciphersuite, each WTP 5840 SHOULD have a unique PSK. Since WTPs will likely be widely 5841 deployed, their physical security is not guaranteed. If PSKs are 5842 not unique for each WTP, key reuse would allow the compromise of 5843 one WTP to result in the compromise of others 5845 o Generating PSKs from low entropy passwords is NOT RECOMMENDED. 5847 o It is RECOMMENDED that implementations that allow the 5848 administrator to manually configure the PSK also provide a 5849 capability for generation of new random PSKs, taking "RFC 1750 5850 [4]" into account. 5852 o Preshared keys SHOULD be periodically updated. Implementations 5853 may facilitate this by providing an administrative interface for 5854 automatic key generation and periodic update, or it may be 5855 accomplished manually instead. 5857 13.3. Use of Certificates in CAPWAP 5859 For public-key-based DTLS deployments, each device SHOULD have unique 5860 credentials, with a certificate profile authorizing them to act as 5861 either a WTP or AC. If devices do not have unique credentials, it is 5862 possible that by compromising one, any other one using the same 5863 credential may also be considered to be compromised. 5865 Each device is responsible for authenticating and authorizing devices 5866 with which they communicate. At minimum, such authentication entails 5867 validation of the chain of trust leading to the peer certificate, 5868 followed by the the peer certificate itself. Implementations SHOULD 5869 also provide a secure method for verifying that the credential in 5870 question has not been revoked. 5872 Note that if the WTP relies on the AC for network connectivity (e.g. 5873 the AC is a layer 2 switch to which the WTP is directly connected), 5874 there is a chicken and egg problem, in that the WTP may not be able 5875 to contact an OCSP server or otherwise obtain an up to date CRL if a 5876 compromised AC doesn't explicitly permit this. This cannot be 5877 avoided, except through effective physical security and monitoring 5878 measures at the AC. 5880 13.4. AAA Security 5882 The AAA protocol is used to distribute EAP keys to the ACs, and 5883 consequently its security is important to the overall system 5884 security. When used with TLS or IPsec, security guidelines specified 5885 in "RFC 3539 [12]" SHOULD be followed. 5887 In general, the link between the AC and AAA server SHOULD be secured 5888 using a strong ciphersuite keyed with mutually authenticated session 5889 keys. Implementations SHOULD NOT rely solely on Basic RADIUS shared 5890 secret authentication as it is often vulnerable to dictionary 5891 attacks, but rather SHOULD use stronger underlying security 5892 mechanisms. 5894 13.5. IEEE 802.11 Security 5896 When used with an IEEE 802.11 infrastructure with WEP encryption, the 5897 CAPWAP protocol does not add any new vulnerabilities. Derived 5898 session keys between the STA and WTP can be compromised, resulting in 5899 many well-documented attacks. Implementors SHOULD discourage the use 5900 of WEP and encourage use of technically sound cryptographic solutions 5901 such as those in an IEEE 802.11 RSN. 5903 STA authentication in CAPWAP is performed using IEEE 802.lX, and 5904 consequently EAP. Implementors SHOULD use EAP methods meeting the 5905 requirements specified in RFC 4017 [ref] 5907 14. IANA Considerations 5909 A separate UDP port for data channel communications is (currently) 5910 the selected demultiplexing mechanism, and a port must be assigned 5911 for this purpose. 5913 The Message element type fields must be IANA aassigned, see 5914 Section 4.4. 5916 15. References 5918 15.1. Normative References 5920 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 5921 Levels", BCP 14, RFC 2119, March 1997. 5923 [2] National Institute of Standards and Technology, "Advanced 5924 Encryption Standard (AES)", FIPS PUB 197, November 2001, 5925 . 5927 [3] Whiting, D., Housley, R., and N. Ferguson, "Counter with CBC- 5928 MAC (CCM)", RFC 3610, September 2003. 5930 [4] Eastlake, D., Crocker, S., and J. Schiller, "Randomness 5931 Recommendations for Security", RFC 1750, December 1994. 5933 [5] Manner, J. and M. Kojo, "Mobility Related Terminology", 5934 RFC 3753, June 2004. 5936 [6] "Information technology - Telecommunications and information 5937 exchange between systems - Local and metropolitan area networks 5938 - Specific requirements - Part 11: Wireless LAN Medium Access 5939 Control (MAC) and Physical Layer (PHY) specifications", 5940 IEEE Standard 802.11, 1999, 5941 . 5944 [7] "Information technology - Telecommunications and information 5945 exchange between systems - Local and metropolitan area networks 5946 - Specific requirements - Part 11: Wireless LAN Medium Access 5947 Control (MAC) and Physical Layer (PHY) specifications Amendment 5948 6: Medium Access Control (MAC) Security Enhancements", 5949 IEEE Standard 802.11i, July 2004, . 5952 [8] Clark, D., "IP datagram reassembly algorithms", RFC 815, 5953 July 1982. 5955 [9] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) 5956 Key Wrap Algorithm", RFC 3394, September 2002. 5958 [10] Mills, D., "Network Time Protocol (Version 3) Specification, 5959 Implementation", RFC 1305, March 1992. 5961 [11] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 5962 Public Key Infrastructure Certificate and Certificate 5963 Revocation List (CRL) Profile", RFC 3280, April 2002. 5965 [12] Aboba, B. and J. Wood, "Authentication, Authorization and 5966 Accounting (AAA) Transport Profile", RFC 3539, June 2003. 5968 [13] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for 5969 Transport Layer Security (TLS)", RFC 4279, December 2005. 5971 [14] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 5972 Protocol Version 1.1", RFC 4346, April 2006. 5974 [15] "Netscape Certificate Extensions Specification", 5975 . 5977 [16] Clancy, C., "Security Review of the Light Weight Access Point 5978 Protocol", May 2005, 5979 . 5981 [17] Rescorla et al, E., "Datagram Transport Layer Security", 5982 June 2004. 5984 [18] "Recommendation for Block Cipher Modes of Operation: the CMAC 5985 Mode for Authentication", May 2005, . 5988 15.2. Informational References 5990 [19] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On- 5991 line Database", RFC 3232, January 2002. 5993 [20] Bradner, S., "The Internet Standards Process -- Revision 3", 5994 BCP 9, RFC 2026, October 1996. 5996 [21] Kent, S. and R. Atkinson, "Security Architecture for the 5997 Internet Protocol", RFC 2401, November 1998. 5999 [22] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 6000 for Message Authentication", RFC 2104, February 1997. 6002 [23] Karn, P. and W. Simpson, "ICMP Security Failures Messages", 6003 RFC 2521, March 1999. 6005 [24] "WiFi Protected Access (WPA) rev 1.6", April 2003. 6007 [25] Dierks et al, T., "The TLS Protocol Version 1.1", June 2005. 6009 [26] Modadugu et al, N., "The Design and Implementation of Datagram 6010 TLS", Feb 2004. 6012 [27] "The Care and Feeding of Cookie Monsters", May 2006. 6014 [28] "Internet Key Exchange (IKEv2) Protocol", 6015 draft-ietf-ipsec-ikev2-17.txt", September 2004. 6017 Editors' Addresses 6019 Pat R. Calhoun 6020 Cisco Systems, Inc. 6021 170 West Tasman Drive 6022 San Jose, CA 95134 6024 Phone: +1 408-853-5269 6025 Email: pcalhoun@cisco.com 6027 Michael P. Montemurro 6028 Chantry Networks 6029 1900 Minnesota Court, Suite 125 6030 Mississauga, ON L5N 3C9 6031 Canada 6033 Phone: +1 905-363-6400 6034 Email: montemurro.michael@gmail.com 6036 Dorothy Stanley 6037 Aruba Networks 6038 1322 Crossman Ave 6039 Sunnyvale, CA 94089 6041 Phone: +1 630-363-1389 6042 Email: dstanley@arubanetworks.com 6044 Intellectual Property Statement 6046 The IETF takes no position regarding the validity or scope of any 6047 Intellectual Property Rights or other rights that might be claimed to 6048 pertain to the implementation or use of the technology described in 6049 this document or the extent to which any license under such rights 6050 might or might not be available; nor does it represent that it has 6051 made any independent effort to identify any such rights. Information 6052 on the procedures with respect to rights in RFC documents can be 6053 found in BCP 78 and BCP 79. 6055 Copies of IPR disclosures made to the IETF Secretariat and any 6056 assurances of licenses to be made available, or the result of an 6057 attempt made to obtain a general license or permission for the use of 6058 such proprietary rights by implementers or users of this 6059 specification can be obtained from the IETF on-line IPR repository at 6060 http://www.ietf.org/ipr. 6062 The IETF invites any interested party to bring to its attention any 6063 copyrights, patents or patent applications, or other proprietary 6064 rights that may cover technology that may be required to implement 6065 this standard. Please address the information to the IETF at 6066 ietf-ipr@ietf.org. 6068 Disclaimer of Validity 6070 This document and the information contained herein are provided on an 6071 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 6072 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 6073 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 6074 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 6075 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 6076 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 6078 Copyright Statement 6080 Copyright (C) The Internet Society (2006). This document is subject 6081 to the rights, licenses and restrictions contained in BCP 78, and 6082 except as set forth therein, the authors retain all their rights. 6084 Acknowledgment 6086 Funding for the RFC Editor function is currently provided by the 6087 Internet Society.