idnits 2.17.1 draft-ietf-capwap-protocol-specification-00.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 5088. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 5065. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 5072. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 5078. ** 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 51 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 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 (February 24, 2006) is 6628 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 922 == Unused Reference: '2' is defined on line 4949, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 4953, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 4978, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 4981, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 5001, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 5004, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 5013, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 5019, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 5024, 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) -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' -- Possible downref: Non-RFC (?) normative reference: ref. '16' -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. '19') (Obsoleted by RFC 4301) Summary: 11 errors (**), 0 flaws (~~), 12 warnings (==), 16 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: August 28, 2006 M. Montemurro, Editor 5 Chantry Networks 6 D. Stanley, Editor 7 Aruba Networks 8 February 24, 2006 10 CAPWAP Protocol Specification 11 draft-ietf-capwap-protocol-specification-00 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 August 28, 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. Conventions used in this document . . . . . . . . . . . 8 65 1.2. Contributing Authors . . . . . . . . . . . . . . . . . . 8 66 1.3. Acknowledgements . . . . . . . . . . . . . . . . . . . . 10 67 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 11 68 2.1. Wireless Binding Definition . . . . . . . . . . . . . . 12 69 2.2. CAPWAP State Machine Definition . . . . . . . . . . . . 12 70 2.3. Use of DTLS in the CAPWAP Protocol . . . . . . . . . . . 21 71 2.3.1. DTLS Error Handling Requirements . . . . . . . . . . 21 72 2.3.2. DTLS Cookie Exchange Failure . . . . . . . . . . . . 22 73 2.3.3. DTLS Re-Assembly Failure . . . . . . . . . . . . . . 23 74 3. CAPWAP Transport . . . . . . . . . . . . . . . . . . . . . . 24 75 3.1. UDP Transport . . . . . . . . . . . . . . . . . . . . . 24 76 3.2. AC Discovery . . . . . . . . . . . . . . . . . . . . . . 24 77 3.3. Fragmentation/Reassembly . . . . . . . . . . . . . . . . 25 78 4. CAPWAP Packet Formats . . . . . . . . . . . . . . . . . . . . 26 79 4.1. CAPWAP Transport Header . . . . . . . . . . . . . . . . 27 80 4.1.1. VER Field . . . . . . . . . . . . . . . . . . . . . 27 81 4.1.2. RID Field . . . . . . . . . . . . . . . . . . . . . 27 82 4.1.3. F Bit . . . . . . . . . . . . . . . . . . . . . . . 27 83 4.1.4. L Bit . . . . . . . . . . . . . . . . . . . . . . . 27 84 4.1.5. R Bit . . . . . . . . . . . . . . . . . . . . . . . 28 85 4.1.6. Fragment ID . . . . . . . . . . . . . . . . . . . . 28 86 4.1.7. Length . . . . . . . . . . . . . . . . . . . . . . . 28 87 4.1.8. Status and WLANS . . . . . . . . . . . . . . . . . . 28 88 4.1.9. Payload . . . . . . . . . . . . . . . . . . . . . . 28 89 4.2. CAPWAP Data Messages . . . . . . . . . . . . . . . . . . 28 90 4.3. CAPWAP Control Messages Overview . . . . . . . . . . . . 29 91 4.3.1. Control Message Format . . . . . . . . . . . . . . . 29 92 4.3.2. Message Element Format . . . . . . . . . . . . . . . 31 93 4.3.3. Quality of Service . . . . . . . . . . . . . . . . . 32 94 5. CAPWAP Discovery Operations . . . . . . . . . . . . . . . . . 33 95 5.1. Discovery Request . . . . . . . . . . . . . . . . . . . 33 96 5.1.1. Discovery Type . . . . . . . . . . . . . . . . . . . 34 97 5.1.2. WTP Descriptor . . . . . . . . . . . . . . . . . . . 34 98 5.1.3. WTP Radio Information . . . . . . . . . . . . . . . 35 99 5.1.4. WTP MAC Type . . . . . . . . . . . . . . . . . . . . 36 100 5.1.5. WTP Frame Type . . . . . . . . . . . . . . . . . . . 36 101 5.2. Discovery Response . . . . . . . . . . . . . . . . . . . 37 102 5.2.1. AC Address . . . . . . . . . . . . . . . . . . . . . 38 103 5.2.2. AC Descriptor . . . . . . . . . . . . . . . . . . . 38 104 5.2.3. AC Name . . . . . . . . . . . . . . . . . . . . . . 39 105 5.2.4. WTP Manager Control IPv4 Address . . . . . . . . . . 39 106 5.2.5. WTP Manager Control IPv6 Address . . . . . . . . . . 40 107 5.3. Primary Discovery Request . . . . . . . . . . . . . . . 41 108 5.3.1. Discovery Type . . . . . . . . . . . . . . . . . . . 41 109 5.3.2. WTP Descriptor . . . . . . . . . . . . . . . . . . . 41 110 5.3.3. WTP MAC Type . . . . . . . . . . . . . . . . . . . . 41 111 5.3.4. WTP Frame Type . . . . . . . . . . . . . . . . . . . 41 112 5.3.5. WTP Radio Information . . . . . . . . . . . . . . . 41 113 5.4. Primary Discovery Response . . . . . . . . . . . . . . . 41 114 5.4.1. AC Descriptor . . . . . . . . . . . . . . . . . . . 42 115 5.4.2. AC Name . . . . . . . . . . . . . . . . . . . . . . 42 116 5.4.3. WTP Manager Control IPv4 Address . . . . . . . . . . 42 117 5.4.4. WTP Manager Control IPv6 Address . . . . . . . . . . 42 118 6. Control Channel Management . . . . . . . . . . . . . . . . . 43 119 6.1. Echo Request . . . . . . . . . . . . . . . . . . . . . . 43 120 6.2. Echo Response . . . . . . . . . . . . . . . . . . . . . 43 121 7. WTP Configuration Management . . . . . . . . . . . . . . . . 44 122 7.1. Configuration Consistency . . . . . . . . . . . . . . . 44 123 7.1.1. Configuration Flexibility . . . . . . . . . . . . . 45 124 7.2. Configure Request . . . . . . . . . . . . . . . . . . . 45 125 7.2.1. Administrative State . . . . . . . . . . . . . . . . 45 126 7.2.2. AC Name . . . . . . . . . . . . . . . . . . . . . . 46 127 7.2.3. AC Name with Index . . . . . . . . . . . . . . . . . 46 128 7.2.4. WTP Board Data . . . . . . . . . . . . . . . . . . . 46 129 7.2.5. Statistics Timer . . . . . . . . . . . . . . . . . . 47 130 7.2.6. WTP Static IP Address Information . . . . . . . . . 48 131 7.2.7. WTP Reboot Statistics . . . . . . . . . . . . . . . 49 132 7.3. Configure Response . . . . . . . . . . . . . . . . . . . 50 133 7.3.1. Decryption Error Report Period . . . . . . . . . . . 50 134 7.3.2. Change State Event . . . . . . . . . . . . . . . . . 50 135 7.3.3. CAPWAP Timers . . . . . . . . . . . . . . . . . . . 51 136 7.3.4. AC IPv4 List . . . . . . . . . . . . . . . . . . . . 52 137 7.3.5. AC IPv6 List . . . . . . . . . . . . . . . . . . . . 52 138 7.3.6. WTP Fallback . . . . . . . . . . . . . . . . . . . . 53 139 7.3.7. Idle Timeout . . . . . . . . . . . . . . . . . . . . 53 140 7.4. Configuration Update Request . . . . . . . . . . . . . . 54 141 7.4.1. WTP Name . . . . . . . . . . . . . . . . . . . . . . 54 142 7.4.2. Change State Event . . . . . . . . . . . . . . . . . 54 143 7.4.3. Administrative State . . . . . . . . . . . . . . . . 54 144 7.4.4. Statistics Timer . . . . . . . . . . . . . . . . . . 55 145 7.4.5. Location Data . . . . . . . . . . . . . . . . . . . 55 146 7.4.6. Decryption Error Report Period . . . . . . . . . . . 55 147 7.4.7. AC IPv4 List . . . . . . . . . . . . . . . . . . . . 55 148 7.4.8. AC IPv6 List . . . . . . . . . . . . . . . . . . . . 55 149 7.4.9. Add MAC ACL Entry . . . . . . . . . . . . . . . . . 55 150 7.4.10. Delete MAC ACL Entry . . . . . . . . . . . . . . . . 56 151 7.4.11. Add Static MAC ACL Entry . . . . . . . . . . . . . . 56 152 7.4.12. Delete Static MAC ACL Entry . . . . . . . . . . . . 57 153 7.4.13. CAPWAP Timers . . . . . . . . . . . . . . . . . . . 57 154 7.4.14. AC Name with Index . . . . . . . . . . . . . . . . . 57 155 7.4.15. WTP Fallback . . . . . . . . . . . . . . . . . . . . 58 156 7.4.16. Idle Timeout . . . . . . . . . . . . . . . . . . . . 58 157 7.4.17. Timestamp . . . . . . . . . . . . . . . . . . . . . 58 158 7.5. Configuration Update Response . . . . . . . . . . . . . 58 159 7.5.1. Result Code . . . . . . . . . . . . . . . . . . . . 58 160 7.6. Change State Event Request . . . . . . . . . . . . . . . 59 161 7.6.1. Change State Event . . . . . . . . . . . . . . . . . 59 162 7.7. Change State Event Response . . . . . . . . . . . . . . 59 163 7.8. Clear Config Indication . . . . . . . . . . . . . . . . 60 164 8. Device Management Operations . . . . . . . . . . . . . . . . 61 165 8.1. Image Data Request . . . . . . . . . . . . . . . . . . . 61 166 8.1.1. Image Download . . . . . . . . . . . . . . . . . . . 61 167 8.1.2. Image Data . . . . . . . . . . . . . . . . . . . . . 61 168 8.2. Image Data Response . . . . . . . . . . . . . . . . . . 62 169 8.3. Reset Request . . . . . . . . . . . . . . . . . . . . . 62 170 8.4. Reset Response . . . . . . . . . . . . . . . . . . . . . 63 171 8.5. WTP Event Request . . . . . . . . . . . . . . . . . . . 63 172 8.5.1. Decryption Error Report . . . . . . . . . . . . . . 63 173 8.5.2. Duplicate IPv4 Address . . . . . . . . . . . . . . . 64 174 8.5.3. Duplicate IPv6 Address . . . . . . . . . . . . . . . 64 175 8.6. WTP Event Response . . . . . . . . . . . . . . . . . . . 65 176 8.7. Data Transfer Request . . . . . . . . . . . . . . . . . 65 177 8.7.1. Data Transfer Mode . . . . . . . . . . . . . . . . . 66 178 8.7.2. Data Transfer Data . . . . . . . . . . . . . . . . . 66 179 8.8. Data Transfer Response . . . . . . . . . . . . . . . . . 67 180 9. Mobile Session Management . . . . . . . . . . . . . . . . . . 68 181 9.1. Mobile Config Request . . . . . . . . . . . . . . . . . 68 182 9.1.1. Add Mobile . . . . . . . . . . . . . . . . . . . . . 68 183 9.1.2. Delete Mobile . . . . . . . . . . . . . . . . . . . 69 184 9.2. Mobile Config Response . . . . . . . . . . . . . . . . . 69 185 9.2.1. Result Code . . . . . . . . . . . . . . . . . . . . 70 186 10. CAPWAP Security . . . . . . . . . . . . . . . . . . . . . . . 71 187 10.1. Endpoint Authentication using DTLS . . . . . . . . . . . 71 188 10.1.1. Authenticating with Certificates . . . . . . . . . . 71 189 10.1.2. Authenticating with Preshared Keys . . . . . . . . . 72 190 10.2. Refreshing Cryptographic Keys . . . . . . . . . . . . . 73 191 10.3. Certificate Usage . . . . . . . . . . . . . . . . . . . 73 193 11. IEEE 802.11 Binding . . . . . . . . . . . . . . . . . . . . . 74 194 11.1. Division of labor . . . . . . . . . . . . . . . . . . . 74 195 11.1.1. Split MAC . . . . . . . . . . . . . . . . . . . . . 74 196 11.1.2. Local MAC . . . . . . . . . . . . . . . . . . . . . 76 197 11.2. Roaming Behavior and 802.11 security . . . . . . . . . . 79 198 11.3. Transport specific bindings . . . . . . . . . . . . . . 80 199 11.3.1. Payload encapsulation . . . . . . . . . . . . . . . 80 200 11.3.2. Status and WLANS field . . . . . . . . . . . . . . . 80 201 11.4. BSSID to WLAN ID Mapping . . . . . . . . . . . . . . . . 81 202 11.5. Quality of Service for Control Messages . . . . . . . . 81 203 11.6. Data Message bindings . . . . . . . . . . . . . . . . . 82 204 11.7. Control Message bindings . . . . . . . . . . . . . . . . 82 205 11.7.1. Mobile Config Request . . . . . . . . . . . . . . . 82 206 11.7.2. WTP Event Request . . . . . . . . . . . . . . . . . 86 207 11.8. 802.11 Control Messages . . . . . . . . . . . . . . . . 88 208 11.8.1. IEEE 802.11 WLAN Config Request . . . . . . . . . . 88 209 11.8.2. IEEE 802.11 WLAN Config Response . . . . . . . . . . 94 210 11.8.3. IEEE 802.11 WTP Event . . . . . . . . . . . . . . . 94 211 11.9. Message Element Bindings . . . . . . . . . . . . . . . . 96 212 11.9.1. IEEE 802.11 WTP WLAN Radio Configuration . . . . . . 96 213 11.9.2. IEEE 802.11 Rate Set . . . . . . . . . . . . . . . . 98 214 11.9.3. IEEE 802.11 Multi-domain Capability . . . . . . . . 98 215 11.9.4. IEEE 802.11 MAC Operation . . . . . . . . . . . . . 99 216 11.9.5. IEEE 802.11 Tx Power . . . . . . . . . . . . . . . . 101 217 11.9.6. IEEE 802.11 Tx Power Level . . . . . . . . . . . . . 101 218 11.9.7. IEEE 802.11 Direct Sequence Control . . . . . . . . 102 219 11.9.8. IEEE 802.11 OFDM Control . . . . . . . . . . . . . . 103 220 11.9.9. IEEE 802.11 Antenna . . . . . . . . . . . . . . . . 104 221 11.9.10. IEEE 802.11 Supported Rates . . . . . . . . . . . . 105 222 11.9.11. IEEE 802.11 CFP Status . . . . . . . . . . . . . . . 105 223 11.9.12. IEEE 802.11 Broadcast Probe Mode . . . . . . . . . . 106 224 11.9.13. IEEE 802.11 WTP Quality of Service . . . . . . . . . 106 225 11.9.14. IEEE 802.11 MIC Error Report From Mobile . . . . . . 108 226 11.10. IEEE 802.11 Message Element Values . . . . . . . . . . . 108 227 12. CAPWAP Protocol Timers . . . . . . . . . . . . . . . . . . . 109 228 12.1. MaxDiscoveryInterval . . . . . . . . . . . . . . . . . . 109 229 12.2. SilentInterval . . . . . . . . . . . . . . . . . . . . . 109 230 12.3. NeighborDeadInterval . . . . . . . . . . . . . . . . . . 109 231 12.4. WaitJoin . . . . . . . . . . . . . . . . . . . . . . . . 109 232 12.5. EchoInterval . . . . . . . . . . . . . . . . . . . . . . 109 233 12.6. DiscoveryInterval . . . . . . . . . . . . . . . . . . . 109 234 12.7. RetransmitInterval . . . . . . . . . . . . . . . . . . . 110 235 12.8. ResponseTimeout . . . . . . . . . . . . . . . . . . . . 110 236 12.9. KeyLifetime . . . . . . . . . . . . . . . . . . . . . . 110 237 13. CAPWAP Protocol Variables . . . . . . . . . . . . . . . . . . 111 238 13.1. MaxDiscoveries . . . . . . . . . . . . . . . . . . . . . 111 239 13.2. DiscoveryCount . . . . . . . . . . . . . . . . . . . . . 111 240 13.3. RetransmitCount . . . . . . . . . . . . . . . . . . . . 111 241 13.4. MaxRetransmit . . . . . . . . . . . . . . . . . . . . . 111 242 14. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 112 243 15. Security Considerations . . . . . . . . . . . . . . . . . . . 114 244 15.1. PSK based Session Key establishment . . . . . . . . . . 114 245 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 115 246 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 116 247 17.1. Normative References . . . . . . . . . . . . . . . . . . 116 248 17.2. Informational References . . . . . . . . . . . . . . . . 117 249 Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 118 250 Intellectual Property and Copyright Statements . . . . . . . . . 119 252 1. Introduction 254 The emergence of centralized architectures, in which simple IEEE 255 802.11 WTPs are managed by an Access Controller (AC) suggests that a 256 standards based, interoperable protocol could radically simplify the 257 deployment and management of wireless networks. WTPs require a set 258 of dynamic management and control functions related to their primary 259 task of connecting the wireless and wired mediums. Traditional 260 protocols for managing WTPs are either manual static configuration 261 via HTTP, proprietary Layer 2 specific or non-existent (if the WTPs 262 are self-contained). This document describes the CAPWAP Protocol, a 263 standard, interoperable protocol which enables an AC to manage a 264 collection of WTPs. The protocol is defined to be independent of 265 layer 2 technology. An IEEE 802.11 binding is provided to support 266 IEEE 802.11 wireless LAN networks. 268 CAPWAP assumes a network configuration consisting of multiple WTPs 269 communicating via the Internet Protocol (IP) to an AC. WTPs are 270 viewed as remote RF interfaces controlled by the AC. The AC forwards 271 all L2 frames to be transmitted by a WTP to that WTP via the CAPWAP 272 protocol. L2 frames from mobile nodes (STAs) are forwarded by the 273 WTP to the AC using the CAPWAP protocol. Both Split-MAC and Local 274 MAC arhcitectures are supported. Figure 1 illustrates this 275 arrangement as applied to an IEEE 802.11 binding. 277 +-+ 802.11 frames +-+ 278 | |--------------------------------| | 279 | | +-+ | | 280 | |--------------| |---------------| | 281 | | 802.11 PHY/ | | CAPWAP | | 282 | | MAC sublayer | | | | 283 +-+ +-+ +-+ 284 STA WTP AC 286 Figure 1: Representative CAPWAP Architecture for Split MAC 288 Provisioning WTPs with security credentials, and managing which WTPs 289 are authorized to provide service are traditionally handled by 290 proprietary solutions. Allowing these functions to be performed from 291 a centralized AC in an interoperable fashion increases manageability 292 and allows network operators to more tightly control their wireless 293 network infrastructure. 295 Goals 297 Goals for the CAPWAP protocol are listed below: 299 1. To centralize the bridging, forwarding, authentication and policy 300 enforcement functions for a wireless network. Optionally, the AC 301 may also provide centralized encryption of user traffic. 302 Centralization of these functions will enable reduced cost and 303 higher efficiency by applying the capabilities of network 304 processing silicon to the wireless network, as in wired LANs. 306 2. To enable shifting of the higher level protocol processing from 307 the WTP. This leaves the time critical applications of wireless 308 control and access in the WTP, making efficient use of the 309 computing power available in WTPs which are the subject to severe 310 cost pressure. 312 3. To provide a generic encapsulation and transport mechanism, 313 enabling the CAPWAP protocol to be applied to other access point 314 types in the future, via a specific wireless binding. 316 The CAPWAP protocol concerns itself solely with the interface between 317 the WTP and the AC. Inter-AC, or mobile node (STA) to AC 318 communication is strictly outside the scope of this document. 320 1.1. Conventions used in this document 322 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 323 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 324 document are to be interpreted as described in RFC 2119 [1]. 326 1.2. Contributing Authors 328 This section lists and acknowledges the authors of significant text 329 and concepts included in this specification. [Note: This section 330 needs work to accurately reflect the contribution of each author and 331 this work will be done in revision 01 of this document.] 333 The CAPWAP Working Group selected the Lightweight Access Point 334 Protocol (LWAPP) [add reference, when available]to be used as the 335 basis of the CAPWAP protocol specification. The following people are 336 authors of the LWAPP document: 338 Bob O'Hara, Cisco Systems, Inc.,170 West Tasman Drive, San Jose, CA 95134 339 Phone: +1 408-853-5513, Email: bob.ohara@cisco.com 341 Pat Calhoun, Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134 342 Phone: +1 408-853-5269, Email: pcalhoun@cisco.com 344 Rohit Suri, Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134 345 Phone: +1 408-853-5548, Email: rsuri@cisco.com 347 Nancy Cam Winget, Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134 348 Phone: +1 408-853-0532, Email: ncamwing@cisco.com 350 Scott Kelly, Facetime Communications, 1159 Triton Dr, Foster City, CA 94404 351 Phone: +1 650 572-5846, Email: scott@hyperthought.com 353 Michael Glenn Williams, Nokia, Inc., 313 Fairchild Drive, Mountain View, CA 94043 354 Phone: +1 650-714-7758, Email: Michael.G.Williams@Nokia.com 356 Sue Hares, Nexthop Technologies, Inc., 825 Victors Way, Suite 100, Ann Arbor, MI 48108 357 Phone: +1 734 222 1610, Email: shares@nexthop.com 359 DTLS is used as the security solution for the CAPWAP protocol. The 360 following people are authors of significant DTLS-related text 361 included in this document: 363 Scott Kelly, Facetime Communications, 1159 Triton Dr, Foster City, CA 94404 364 Phone: +1 650 572-5846, Email: scott@hyperthought.com 366 Eric Rescorla, Network Resonance, 2483 El Camino Real, #212,Palo Alto CA, 94303 367 Email: ekr@networkresonance.com 369 The concept of using DTLS to secure the CAPWAP protocol was part of 370 the Secure Light Access Point Protocol (SLAPP) proposal [add 371 reference when available]. The following people are authors of the 372 SLAPP proposal: 374 Partha Narasimhan, Aruba Networks, 1322 Crossman Ave, Sunnyvale, CA 94089 375 Phone: +1 408-480-4716, Email: partha@arubanetworks.com 377 Dan Harkins, Tropos Networks, 555 Del Rey Avenue, Sunnyvale, CA, 95085 378 Phone: +1 408 470 7372, Email: dharkins@tropos.com 380 Subbu Ponnuswammy, Aruba Networks, 1322 Crossman Ave, Sunnyvale, CA 94089 381 Phone: +1 408-754-1213, Email: subbu@arubanetworks.com 383 [Ed note: Additional authors to be added as required.] 385 1.3. Acknowledgements 387 The authors thank Michael Vakulenko for contributing text that 388 describes how CAPWAP can be used over a layer 3 (IP/UDP) network. 390 The authors thank Russ Housley and Charles Clancy for their 391 assistance in provide a security review of the LWAPP specification. 392 Charles' review can be found at [14]. 394 [Ed note: Additional acknowledgements to be added as required.] 396 2. Protocol Overview 398 The CAPWAP protocol is a generic protocol defining AC and WTP control 399 and data plane communication via a CAPWAP protocol transport 400 mechanism. CAPWAP control messages, and optionally CAPWAP data 401 messages are secured using Datagram Transport Layer Security (DTLS). 402 DTLS is a standards-track IETF protocol based upon TLS. The 403 underlying security-related protocol mechanisms of TLS have been 404 successfully deployed for many years. 406 The CAPWAP protocol Transport layer carries two types of payload, 407 CAPWAP Data messages and CAPWAP Control messages. CAPWAP Data 408 messages are forwarded wireless frames. CAPWAP protocol Control 409 messages are management messages exchanged between a WTP and an AC. 410 The CAPWAP Data and Control packets are sent over separate UDP ports. 411 Since both data and control frames can exceed the PMTU, the payload 412 of a CAPWAP data or control message can be fragmented. The 413 fragmentation behavior is highly dependent upon the lower layer 414 transport and is defined in Section 3. 416 The CAPWAP Protocol begins with a discovery phase. The WTPs send a 417 Discovery Request message, causing any Access Controller (AC) 418 receiving the message to respond with a Discovery Response message. 419 From the Discovery Response messages received, a WTP will select an 420 AC with which to establish a secure DTLS session, using the DTLS 421 initialization request message. [MTU discovery mechanism? to 422 determine the MTU supported by the network between the WTP and AC.] 423 CAPWAP protocol messages will be fragmented to the maximum length 424 discovered to be supported by the network. 426 Once the WTP and the AC have completed DTLS session establishment, a 427 configuration exchange occurs in which both devices to agree on 428 version information. During this exchange the WTP may receive 429 provisioning settings. For the IEEE 802.11 binding, this information 430 typically includes a name (IEEE 802.11 Service Set Identifier, SSID) 431 security parameters, the data rates to be advertised and the 432 associated radio channel(s) to be used. The WTP is then enabled for 433 operation. 435 When the WTP and AC have completed the version and provision exchange 436 and the WTP is enabled, the CAPWAP protocol is used to encapsulate 437 the wireless data frames sent between the WTP and AC. The CAPWAP 438 protocol will fragment the L2 frames if the size of the encapsulated 439 wireless user data (Data) or protocol control (Management) frames 440 causes the resultant CAPWAP protocol packet to exceed the MTU 441 supported between the WTP and AC. Fragmented CAPWAP packets are 442 reassembled to reconstitute the original encapsulated payload. 444 The CAPWAP protocol provides for the delivery of commands from the AC 445 to the WTP for the management of mobile units (STAs) that are 446 communicating with the WTP. This may include the creation of local 447 data structures in the WTP for the mobile units and the collection of 448 statistical information about the communication between the WTP and 449 the mobile units. The CAPWAP protocol provides a mechanism for the 450 AC to obtain statistical information collected by the WTP. 452 The CAPWAP protocol provides for a keep alive feature that preserves 453 the communication channel between the WTP and AC. If the AC fails to 454 appear alive, the WTP will try to discover a new AC. 456 This Document uses terminology defined in [5]. 458 2.1. Wireless Binding Definition 460 The CAPWAP protocol is independent of a specific WTP radio 461 technology. Elements of the CAPWAP protocol are designed to 462 accommodate the specific needs of each wireless technology in a 463 standard way. Implementation of the CAPWAP protocol for a particular 464 wireless technology must follow the binding requirements defined for 465 that technology. This specification includes a binding for the IEEE 466 802.11 standard(see Section 11). 468 When defining a binding for other wireless technologies, the authors 469 MUST include any necessary definitions for technology-specific 470 messages and all technology-specific message elements for those 471 messages. At a minimum, a binding MUST provide the definition for a 472 binding-specific Statistics message element, carried in the WTP Event 473 Request message, and a Mobile message element, carried in the Mobile 474 Configure Request. If technology specific message elements are 475 required for any of the existing CAPWAP messages defined in this 476 specification, they MUST also be defined in the technology binding 477 document. 479 The naming of binding-specific message elements MUST begin with the 480 name of the technology type, e.g., the binding for IEEE 802.11, 481 provided in this specification, begins with "IEEE 802.11"." 483 2.2. CAPWAP State Machine Definition 485 The following state diagram represents the lifecycle of a WTP-AC 486 session: 488 /-------------\ 489 | v 490 | +------------+ 491 | C| Idle |<---------------------------------------+ 492 | +------------+ | 493 | ^ |a ^ | 494 | | | \----\ y | 495 | | | | +-------------+------------+ | 496 | | | | | | DTLS-rekey | | 497 | | | | | +--------->+------------+ | 498 | | | | | | |6 ^ 499 | | | |t V | x V | 500 | | | +--------+--+ +------------+ | 501 | / | C| Run |------>| DTLS-Reset |<---|----\ 502 | / | r+-----------+ u +------------+ | | 503 | / | ^ ^ v| | | 504 | | v | | | | | 505 | | +--------------+ | /----/ V | | 506 | | C| Discovery | q| k| +-------+ | | 507 | | b+--------------+ +-------------+ | Reset |-+ w | 508 | | |d f| ^ | Configure | +-------+ | 509 | | | | | +-------------+ | 510 | |e v | | ^ | 511 | +---------+ v |i 2| | 512 | C| Sulking | +------------+ +--------------+ | 513 | +---------+ C| DTLS-Init |--->| DTLS-Complete| | 514 | +------------+ z +--------------+ | 515 | |h |4 | 516 | | v o / 517 \ | +------------+-------/ 518 \-----------------/ | Image Data |C 519 +------------+n 521 Figure 2: CAPWAP State Machine 523 The CAPWAP protocol state machine, depicted above, is used by both 524 the AC and the WTP. For every state defined, only certain messages 525 are permitted to be sent and received. In all of the CAPWAP control 526 messages defined in this document, the state for which each command 527 is valid is specified. 529 Note that in the state diagram figure above, the 'C' character is 530 used to represent a condition that causes the state to remain the 531 same. 533 The following text discusses the various state transitions, and the 534 events that cause them. 536 Idle to Discovery (a): This is the initialization state. 538 WTP: The WTP enters the Discovery state prior to transmitting the 539 first Discovery Request message (see Section 5.1). Upon 540 entering this state, the WTP sets the DiscoveryInterval timer 541 (see Section 12). The WTP resets the DiscoveryCount counter to 542 zero (0) (see Section 13). The WTP also clears all information 543 from ACs (e.g., AC Addresses) it may have received during a 544 previous Discovery phase. 546 AC: The AC does not need to maintain state information for the WTP 547 upon reception of the Discovery Request message, but it MUST 548 respond with a Discovery Response message (see Section 5.2). 550 Discovery to Discovery (b): This is the state in which the WTP 551 determines which AC to connect to. 553 WTP: This event occurs when the DiscoveryInterval timer expires. 554 The WTP transmits a Discovery Request message to every AC from 555 which the WTP has not received a Discovery Response message. 556 For every transition to this event, the WTP increments the 557 DiscoveryCount counter. See Section 5.1 for more information 558 on how the WTP knows the ACs to which ACs it should transmit 559 the Discovery Request messages. The WTP restarts the 560 DiscoveryInterval timer. 562 AC: This is a no-op. 564 Discovery to Sulking (d): This state occurs on a WTP when Discovery 565 or connectivity to the AC fails. 567 WTP: The WTP enters this state when the DiscoveryInterval timer 568 expires and the DiscoveryCount variable is equal to the 569 MaxDiscoveries variable (see Section 13). Upon entering this 570 state, the WTP shall start the SilentInterval timer. While in 571 the Sulking state, all received CAPWAP protocol messages 572 received shall be ignored. 574 AC: This is a no-op. 576 Sulking to Idle (e): This state occurs on a WTP when it must restart 577 the discovery phase. 579 WTP: The WTP enters this state when the SilentInterval timer (see 580 Section 12) expires. 582 AC: This is a no-op. 584 Discovery to DTLS-Init (f): This state is used by the WTP to confirm 585 its commitment to an AC that it wishes to be provided service and 586 to simultaneously establish a secure channel with that AC. 588 WTP: The WTP selects the best AC based on the information it 589 gathered during the Discovery Phase. It then sends a 590 ClientHello to its preferred AC, sets the WaitJoin timer, and 591 awaits the outcome of the DTLS handshake. 593 AC: The AC enters this state for the given WTP upon reception 594 of a ClientHello. The AC responds by sending either the 595 ServerHello or the HelloVerifyRequest to the WTP. For the AC, 596 this is a meta-state; in actuality, it remains in the Discovery 597 state. To do otherwise resuls in loss of the stateless nature 598 of the cookie exchange. 600 DTLS-Init to Idle (h): This state transition is used when the DTLS 601 Initialization process failed. 603 WTP: This state transition occurs if the WTP is unable to 604 successfully establish a DTLS session. 606 AC: This state transition occurs if the AC is unable to 607 successfully establish a DTLS session. 609 DTLS-Init to Discovery (i): This state transition is used to return 610 the WTP to discovery mode when an unresponsive AC is encountered. 612 WTP: The WTP enters the Discovery state when the DTLS handshake 613 fails. 615 AC: This state transition is invalid. 617 DTLS-Init to DTLS-Complete (z): This state transition is used to 618 indicate DTLS session establishment. 620 WTP: The DTLS-Complete state is entered when the WTP receives the 621 Finished message from the AC. 623 AC: The DTLS-Complete state is entered when the AC receives the 624 Finished mesage from the WTP. 626 DTLS-Complete to Configure (2): This state transition is used by the 627 WTP and the AC to exchange configuration information. 629 WTP: The WTP enters the Configure state when it successfully 630 completes DTLS session establishment and determines that its 631 version number and the version number advertised by the AC are 632 the same. The WTP transmits the Configure Request message(see 633 Section 7.2) message to the AC with a snapshot of its current 634 configuration. The WTP also starts the ResponseTimeout timer 635 (see Section 12). 637 AC: This state transition occurs when the AC receives the 638 Configure Request message from the WTP. The AC must transmit a 639 Configure Response message(see Section 7.3) to the WTP, and may 640 include specific message elements to override the WTP's 641 configuration. 643 DTLS Complete to Image Data (4): This state transition is used by the 644 WTP and the AC to download executable firmware. 646 WTP: The WTP enters the Image Data state when it successfully 647 comletes DTLS session establishment, and determines that its 648 version number and the version number advertised by the AC are 649 different. The WTP transmits the Image Data Request (see 650 Section 8.1) message requesting that the AC's latest firmware 651 be initiated. 653 AC: This state transition occurs when the AC receives the Image 654 Data Request message from the WTP. The AC must transmit an 655 Image Data Response message(see Section 8.2) to the WTP, which 656 includes a portion of the firmware. 658 Image Data to Image Data (n): The Image Data state is used by WTP and 659 the AC during the firmware download phase. 661 WTP: The WTP enters the Image Data state when it receives a Image 662 Data Response message indicating that the AC has more data to 663 send. 665 AC: This state transition occurs when the AC receives the Image 666 Data Request message from the WTP while already in the Image 667 Data state, and it detects that the firmware download has not 668 completed. 670 Configure to DTLS-Reset (k): This state is used to reset the DTLS 671 connection prior to restarting the WTP with a new configuration. 673 WTP: The WTP enters the DTLS-Reset state when it determines that a 674 new configuration is required. 676 AC: The AC transitions to the DTLS-Reset state when the DTLS 677 connection tear-down is complete. 679 Image Data to DTLS-Reset (o): This state transition is used to reset 680 the DTLS connection prior to restarting the WTP after an image 681 download. 683 WTP: The WTP enters the DTLS-Reset state when image download 684 completes. 686 AC: The AC enters the DTLS-Reset state upon receipt of TLS 687 Finished message from the WTP. 689 Configure to Run (q): This state transition occurs when the WTP and 690 AC enter their normal state of operation. 692 WTP: The WTP enters this state when it receives a successful 693 Configure Response message from the AC. The WTP initializes 694 the HeartBeat Timer (see Section 12), and transmits the Change 695 State Event Request message (see Section 7.6). 697 AC: This state transition occurs when the AC receives the Change 698 State Event Request message (see Section 7.6) from the WTP. 699 The AC responds with a Change State Event Response (see 700 Section 7.7) message. The AC must start the 701 NeighborDeadInterval timer (see Section 12). 703 Run to Run (r): This is the normal state of operation. 705 WTP: This is the WTP's normal state of operation. There are many 706 events that result this state transition: 708 Configuration Update: The WTP receives a Configuration Update 709 Request message(see Section 7.4). The WTP MUST respond with 710 a Configuration Update Response message (see Section 7.5). 712 Change State Event: The WTP receives a Change State Event 713 Response message, or determines that it must initiate a 714 Change State Event Request message, as a result of a failure 715 or change in the state of a radio. 717 Echo Request: The WTP receives an Echo Request message (see 718 Section 6.1), to which it MUST respond with an Echo Response 719 message(see Section 6.2). 721 Clear Config Indication: The WTP receives a Clear Config 722 Indication message (see Section 7.8). The WTP MUST reset 723 its configuration back to manufacturer defaults. 725 WTP Event: The WTP generates a WTP Event Request message to 726 send information to the AC (see Section 8.5). The WTP 727 receives a WTP Event Response message from the AC (see 728 Section 8.6). 730 Data Transfer: The WTP generates a Data Transfer Request 731 message to the AC (see Section 8.7). The WTP receives a 732 Data Transfer Response message from the AC (see 733 Section 8.8). 735 WLAN Config Request: The WTP receives a WLAN Config Request 736 message (see Section 11.8.1), to which it MUST respond with 737 a WLAN Config Response message (see Section 11.8.2). 739 Mobile Config Request: The WTP receives a Mobile Config Request 740 message (see Section 9.1), to which it MUST respond with a 741 Mobile Config Response message (see Section 9.2). 743 AC: This is the AC's normal state of operation: 745 Configuration Update: The AC sends a Configuration Update 746 Request message (see Section 7.4) to the WTP to update its 747 configuration. The AC receives a Configuration Update 748 Response message (see Section 7.5) from the WTP. 750 Change State Event: The AC receives a Change State Event 751 Request message (see Section 7.6), to which it MUST respond 752 with the Change State Event Response message (see 753 Section 7.7). 755 Echo: The AC sends an Echo Request message Section 6.1) or 756 receives the corresponding Echo Response message (see 757 Section 6.2) from the WTP. 759 Clear Config Indication: The AC sends a Clear Config Indication 760 message (see Section 7.8). 762 WLAN Config: The AC sends a WLAN Config Request message (see 763 Section 11.8.1) or receives the corresponding WLAN Config 764 Response message (see Section 11.8.2) from the WTP. 766 Mobile Config: The AC sends a Mobile Config Request message 767 (see Section 9.1) or receives the corresponding Mobile 768 Config Response message (see Section 9.2) from the WTP. 770 Data Transfer: The AC receives a Data Transfer Request message 771 from the AC (see Section 8.7) and MUST generate a 772 corresponding Data Transfer Response message (see 773 Section 8.8). 775 WTP Event: The AC receives a WTP Event Request message from the 776 AC (see Section 8.5) and MUST generate a corresponding WTP 777 Event Response message (see Section 8.6). 779 Run to Idle (t): This event occurs when an error occurs in the 780 communication between the WTP and the AC. 782 WTP: The WTP enters the Idle state when the underlying reliable 783 transport in unable to transmit a message within the 784 RetransmitInterval timer (see Section 12), and the maximum 785 number of RetransmitCount counter has reached the MaxRetransmit 786 variable (see Section 13). 788 AC: The AC enters the Idle state when the underlying reliable 789 transport in unable to transmit a message within the 790 RetransmitInterval timer (see Section 12), and the maximum 791 number of RetransmitCount counter has reached the MaxRetransmit 792 variable (see Section 13). 794 Run to DTLS-Reset(u): This state transition is used to when the AC or 795 WTP wish to tear down the connection. 797 WTP: The WTP enters the DTLS-Reset state when it initiates orderly 798 termination of the DTLS connection; The WTP sends a TLS 799 Finished message to the AC. 801 AC: The AC enters the DTLS-Reset state upon receipt of a TLS 802 Finished message from the WTP. 804 Run to DTLS-Rekey (x): This state is used to initiate a new DTLS 805 handshake. Either the WTP or AC may initiate the state 806 transition. DTLS protected CAPWAP packets may continue to flow 807 while a new handshake is being performed. Because packets may be 808 reordered, records encrypted under the new cipher suite may be 809 received before one side receives the ChangeCipherSpec from the 810 other side. 812 The epoch value in the DTLS record header allows the data from the 813 two associations/cryptographic states to be distinguished. 814 Implementations SHOULD retain the state for the old association 815 until it is likely that all old records have been received or 816 dropped, e.g., for the maximum packet lifetime. If the state is 817 dropped too early, the only effect will be that some data is lost, 818 which is a condition that systems running over unreliable 819 protocols need to consider in any case. 821 Because the new handshake is performed over the existing DTLS 822 association, both sides can be confident that the handshake was 823 properly initiated and was not tampered with. All data is 824 protected under either the old or new keys--and these can be 825 distinguished by both the epoch and the authentication (MAC) 826 verification. Thus, there is no period during which data is 827 unprotected. 829 WTP: The WTP enters the DTLS-Rekey state when either (1) a rekey 830 is required, or (2) the AC initiates a DTLS handshake. 832 AC: The AC enters the DTLS-Rekey state when either (1) a rekey is 833 required, or (2) the WTP initiates a DTLS handshake. 835 DTLS-rekey to Run (y): This event occurs when the DTLS rehandshake is 836 completed. 838 WTP: This state transition occurs when the WTP completes the DTLS 839 rehandshake. 841 AC: This state transition occurrs when the AC completed the DTLS 842 rehandshake. 844 DTLS-rekey to Reset (6): This event occurs when the DTLS rehandshake 845 exchange phase times out. 847 WTP: This state transition occurs when the WTP does not 848 successfully complete the DTLS rehandshake phase. 850 AC: This state transition occurs when the AC does not successfully 851 complete the DTLS rehandshake phase. 853 DTLS-Reset to Reset (v): This state transition is used to complete 854 DTLS session tear-down. 856 WTP: The WTP enters the Reset state when it has completed DTLS 857 session clean-up, and it is ready to complete the CAPWAP 858 protocol session clean-up. 860 AC: The AC enters the Reset state when it has completed DTLS 861 session clean-up, and it is ready to complete the CAPWAP 862 protocol session clean-up. 864 Reset to Idle (w): This event occurs when the state machine is 865 restarted. 867 WTP: The WTP reboots. After reboot the WTP will start its CAPWAP 868 state machine in the Idle state. 870 AC: The AC clears any state associated with the WTP. The AC 871 generally does this as a result of the reliable link layer 872 timing out. 874 2.3. Use of DTLS in the CAPWAP Protocol 876 DTLS is used as a tightly-integrated secure wrapper for the CAPWAP 877 protocol. Certain errors may occur during the DTLS negotiation 878 and/or the resulting session; the following section describes those, 879 along with handling requirements. It is important to note that the 880 CAPWAP protocol, being the controlling entity for the DTLS session, 881 must establish its own timers outside of DTLS (e.g. WaitJoin), and 882 is responsible for terminating sessions which timeout. DTLS 883 implements a retransmission backoff timer, but will not terminate a 884 session unless instructed to do so. 886 2.3.1. DTLS Error Handling Requirements 888 DTLS uses all of the same handshake messages and flows as TLS, with 889 three principal changes: 891 1. A stateless cookie exchange has been added to prevent denial of 892 service attacks. 894 2. Modifications to the handshake header have been made to handle 895 message loss, reordering, and fragmentation 897 3. Retransmission timers to handle message loss have been added. 899 Each of these features can cause the DTLS session to fail, as 900 discussed below. For reference, an illustration of a normal DTLS 901 session establishment (in this particular case, using certificates 902 for authentication) is as follows: 904 Client (WTP) Server (AC) 905 ------------ ------------ 906 ClientHello ------> 908 <----- HelloVerifyRequest 909 (contains cookie) 911 ClientHello ------> 912 (with cookie) 913 <------ ServerHello (seq=1) 914 <------ Certificate (seq=2) 915 <------ ServerHelloDone (seq=3) 916 Certificate* 917 ClientKeyExchange 918 CertificateVerify* 919 [ChangeCipherSpec] 920 Finished ------> 922 [ChangeCipherSpec] 923 <------ Finished 925 2.3.2. DTLS Cookie Exchange Failure 927 The cookie exchange is optional in DTLS. For use with the CAPWAP 928 protocol, it may not be required if the network on which the AC and 929 WTP reside is entirely within the same administrative domain. 930 However, if AC-WTP communications traverse multiple administrative 931 domains, the cookie exchange SHOULD be supported. There are three 932 potential points of failure in Hello exchange, assuming cookies are 933 used: 935 o The AC does not respond to the ClientHello (this may occur 936 independently of cookie usage) 938 o The WTP does not respond to the HelloVerifyRequest 940 o The ClientHello contains an invalid cookie 942 In determining appropriate error handling behavior for any of these 943 cases, it is important to remember that the stateless cookie 944 implements a defense mechanism from the point of view of the AC. 945 That is, it is explictly designed to minimize AC-side processing 946 prior to verifying that the WTP can receive and respond to packets at 947 the specified address. Hence, any processing associated with this 948 mechanism SHOULD be minimized. 950 In the case of AC non-responsiveness to the ClientHello, the WaitJoin 951 timer will eventually expire. When this occurs, the WTP SHOULD log 952 an error message and choose an alternative AC if one exists, or 953 return to the CAPWAP protocol Discovery state. 955 In the case of WTP non-responsiveness to the HelloVerifyRequest, the 956 DTLS implementation purposely does not set a timer (the 957 HelloVerifyRequest is stateless by design). This means that DTLS 958 itself will provide no indication of WTP non-responsiveness. To 959 mitigate this, the AC MAY log a message when sending a 960 HelloVerifyRequest, and SHOULD log a message upon receipt of a valid 961 corresponding ClientHello. In this way, optional external detection 962 of non-responsive WTP's can be used to troubleshoot such problems 963 using data from the AC alone. In reality, administrators will 964 typically have access to WTP logs as well, making detection of such 965 problems straightforward. 967 In case of an invalid cookie in the ClientHello, the AC MUST 968 terminate the DTLS handshake, returing to Discovery state. A DTLS 969 alert MAY be sent to the WTP indicating the failure. 971 2.3.3. DTLS Re-Assembly Failure 973 Since DTLS handshake messages are potentially larger than the maximum 974 record size, DTLS supports fragmenting of handshake messages across 975 multiple records. There are several potential causes of re-assembly 976 errors, including overlapping and/or lost fragments. The DTLS 977 implementation should return an error to the CAPWAP protocol 978 implementation when such errors occur. The precise error value is an 979 API issue, and hence is beyond the scope of this document. Upon 980 receipt of such an error, the CAPWAP protocol implementation SHOULD 981 log an appropriate error message. Whether processing continues or 982 the DTLS session is terminated is implementation dependent. 984 3. CAPWAP Transport 986 The CAPWAP protocol uses UDP as a transport, and can be used with 987 IPv4 or IPv6. This section details the specifics of how the CAPWAP 988 protocol works in conjunction with IP. 990 3.1. UDP Transport 992 Communication between a WTP and an AC is established according to the 993 standard UDP client/server model. One of the CAPWAP requirements is 994 to allow a WTP to reside behind a firewall and/or Network Address 995 Translation (NAT) device. Since the connection is initiated by the 996 WTP (client) to the well-known UDP port of the AC (server), the use 997 of UDP is a logical choice. 999 CAPWAP protocol control packets sent between the WTP and the AC use 1000 well known UDP port 12222. CAPWAP protocol data packets sent between 1001 the WTP and the AC use UDP port [to be IANA assigned]. 1003 3.2. AC Discovery 1005 A WTP and an AC will frequently not reside in the same IP subnet 1006 (broadcast domain). When this occurs, the WTP must be capable of 1007 discovering the AC, without requiring that multicast services are 1008 enabled in the network. This section describes how AC discovery is 1009 performed by WTPs. 1011 As the WTP attempts to establish communication with an AC, it sends 1012 the Discovery Request message and receives the corresponding response 1013 message from the AC(s). The WTP must send the Discovery Request 1014 message to either the limited broadcast IP address (255.255.255.255), 1015 a well known multicast address or to the unicast IP address of the 1016 AC. Upon receipt of the Discovery Request message, the AC issues a 1017 Discovery Response message to the unicast IP address of the WTP, 1018 regardless of whether the Discovery Request message was sent as a 1019 broadcast, multicast or unicast message. 1021 WTP use of a limited IP broadcast, multicast or unicast IP address is 1022 implementation dependent. 1024 When a WTP transmits a Discovery Request message to a unicast 1025 address, the WTP must first obtain the IP address of the AC. Any 1026 static configuration of an AC's IP address on the WTP non-volatile 1027 storage is implementation dependent. However, additional dynamic 1028 schemes are possible, for example: 1030 DHCP: A comma delimited ASCII encoded list of AC IP addresses is 1031 embedded in the DHCP vendor specific option 43 extension. An 1032 example of the actual format of the vendor specific payload for 1033 IPv4 is of the form "10.1.1.1, 10.1.1.2". 1035 DNS: The DNS name "CAPWAP-AC-Address" MAY be resolvable to one or 1036 more AC addresses. 1038 3.3. Fragmentation/Reassembly 1040 While fragmentation and reassembly services are provided by IP, the 1041 CAPWAP protocol also provides such services. Environments where the 1042 CAPWAP protocol is used involve firewall, Network Address Translation 1043 (NAT) and "middle box" devices, which tend to drop IP fragments in 1044 order to minimize possible Denial of Service attacks. By providing 1045 fragmentation and reassembly at the application layer, any 1046 fragmentation required due to the tunneling component of the CAPWAP 1047 protocol becomes transparent to these intermediate devices. 1048 Consequently, the CAPWAP protocol is not impacted by any network 1049 configurations. 1051 4. CAPWAP Packet Formats 1053 This section contains the CAPWAP protocol packet formats. A CAPWAP 1054 protocol packet consists of a CAPWAP Transport Layer packet header 1055 followed by a CAPWAP message. The CAPWAP message can be either of 1056 type Control or Data, where Control packets carry signaling, and Data 1057 packets carry user payloads. The CAPWAP frame formats for CAPWAP 1058 Data packets, and for DTLS encapsulated CAPWAP Data and Control 1059 packets. are as shown below: 1061 CAPWAP Data Packet : 1062 +--------------------------------+ 1063 | IP |UDP | CAPWAP | Wireless | 1064 | Hdr |Hdr | Header | Payload | 1065 +--------------------------------+ 1067 CAPWAP + Optional DTLS Data Packet Security: 1068 +------------------------------------------------+ 1069 | IP |UDP | DTLS | CAPWAP | Wireless | DTLS | 1070 | Hdr |Hdr | Hdr | Hdr | Payload | Trailer| 1071 +------------------------------------------------+ 1072 \--authenticated-----------/ 1073 \--- encrypted-----------/ 1075 CAPWAP Control Packet (DTLS Security Required): 1076 +-----------------------------------------------------------+ 1077 | IP |UDP | DTLS | CAPWAP | Control | Message | DTLS | 1078 | Hdr |Hdr | Hdr | Header | Header | Element(s) | Trailer | 1079 +-----------------------------------------------------------+ 1080 \-------authenticated-----------------/ 1081 \------------encrypted-------------------/ 1083 UDP: All CAPWAP packets are encapsulated within UDP. Section 1084 Section 3.1 defines the specific UDP usage. 1086 CAPWAP Header: All CAPWAP protocol packets use a common header that 1087 immediately follows the UDP header. This header, is defined in 1088 Section 4.1. 1090 Wireless Payload: A CAPWAP protocol packet that contains a wireless 1091 payload is known as a data frame. The CAPWAP protocol does not 1092 dictate the format of the wireless payload, which is defined by 1093 the appropriate wireless standard. Additional information is in 1094 Section 4.2. 1096 Control Header: The CAPWAP protocol includes a signalling component, 1097 known as the CAPWAP control protocol. All CAPWAP control packets 1098 include a Control Header, which is defined in Section 4.3.1. 1100 Message Elements: A CAPWAP Control packet includes one or more 1101 message elements, which are found immediately following the 1102 control header. These message elements are in a Type/Length/value 1103 style header, defined in Section 4.3.2. 1105 4.1. CAPWAP Transport Header 1107 All CAPWAP protocol messages are encapsulated using a common header 1108 format, regardless of the CAPWAP control or CAPWAP Data transport 1109 used to carry the messages. However, certain flags are not 1110 applicable for a given transport. Refer to the specific transport 1111 section in order to determine which flags are valid. 1113 0 1 2 3 1114 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 1115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 |VER| RID |F|L|R| Frag ID | Length | 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 | Status/WLANs | Payload... | 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1121 4.1.1. VER Field 1123 A 2 bit field which contains the version of CAPWAP used in this 1124 packet. The value for this draft is 0. 1126 4.1.2. RID Field 1128 A 3 bit field which contains the Radio ID number for this packet. 1129 WTPs with multiple radios but a single MAC Address use this field to 1130 indicate which radio is associated with the packet. 1132 4.1.3. F Bit 1134 The Fragment 'F' bit indicates whether this packet is a fragment. 1135 When this bit is one (1), the packet is a fragment and MUST be 1136 combined with the other corresponding fragments to reassemble the 1137 complete information exchanged between the WTP and AC. 1139 4.1.4. L Bit 1141 The Not Last 'L' bit is valid only if the 'F' bit is set and 1142 indicates whether the packet contains the last fragment of a 1143 fragmented exchange between WTP and AC. When this bit is 1, the 1144 packet is not the last fragment. When this bit is 0, the packet is 1145 the last fragment. 1147 4.1.5. R Bit 1149 The R bit is reserved and set to 0 in this version of the CAPWAP 1150 protocol. 1152 4.1.6. Fragment ID 1154 An 8 bit field whose value is assigned to each group of fragments 1155 making up a complete set. The fragment ID space is managed 1156 individually for every WTP/AC pair. The value of Fragment ID is 1157 incremented with each new set of fragments. The Fragment ID wraps to 1158 zero after the maximum value has been used to identify a set of 1159 fragments. The CAPWAP protocol only supports up to 2 fragments per 1160 frame. 1162 4.1.7. Length 1164 The 16 bit length field contains the number of bytes in the Payload. 1165 The field is encoded as an unsigned number. 1167 4.1.8. Status and WLANS 1169 The interpretation of this 16 bit field is binding specific. Refer 1170 to the transport portion of the binding for a specific wireless 1171 technology for the definition of this field. 1173 4.1.9. Payload 1175 This field contains the header for a CAPWAP Data Message or CAPWAP 1176 Control Message, followed by the data associated with that message. 1178 4.2. CAPWAP Data Messages 1180 A CAPWAP protocol data message is a forwarded wireless frame. The 1181 CAPWAP protocol defines two different modes of encapsulations; IEEE 1182 802.3 and native wireless. IEEE 802.3 encapsulation requires that 1183 the bridging function be performed in the WTP. An IEEE 802.3 1184 encapsulated user payload frame has the following format: 1186 +------------------------------------------------------+ 1187 | IP Header | UDP Header | CAPWAP Header | 802.3 Frame | 1188 +------------------------------------------------------+ 1190 The CAPWAP protocol also defines the native wireless encapsulation 1191 mode. The actual format of the encapsulated CAPWAP data frame is 1192 subject to the rules defined under the specific wireless technology 1193 binding. As a consequence, each wireless technology binding MUST 1194 define a section entitled "Payload encapsulation", which defines the 1195 format of the wireless payload that is encapsulated within the CAPWAP 1196 Data messages. 1198 In the event that the encapsulated frame would exceed the transport 1199 layer's MTU, the sender is responsible for the fragmentation of the 1200 frame, as specified in Section 3.3. 1202 4.3. CAPWAP Control Messages Overview 1204 The CAPWAP Control protocol provides a control channel between the 1205 WTP and the AC. Control messages are divided into the following 1206 distinct message types: 1208 Discovery: CAPWAP Discovery messages are used to identify potential 1209 ACs, their load and capabilities. 1211 WTP Configuration: The WTP Configuration messages are used by the AC 1212 to push a specific configuration to the WTP it has a control 1213 channel with. Messages that deal with the retrieval of statistics 1214 from the WTP also fall in this category. 1216 Mobile Session Management: Mobile session management messages are 1217 used by the AC to push specific mobile policies to the WTP. 1219 Firmware Management: Messages in this category are used by the AC to 1220 push a new firmware image to the WTP. 1222 Discovery, WTP Configuration and Mobile Session Management messages 1223 MUST be implemented. Firmware Management MAY be implemented. 1225 In addition, technology specific bindings may introduce new control 1226 channel commands. 1228 4.3.1. Control Message Format 1230 All CAPWAP control messages are sent encapsulated within the CAPWAP 1231 header (see Section 4.1). Immediately following the CAPWAP header, 1232 is the control header, which has the following format: 1234 0 1 2 3 1235 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 1236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1237 | Message Type | Seq Num | Msg Element Length | 1238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1239 | Msg Element [0..N] | 1240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1242 4.3.1.1. Message Type 1244 The Message Type field identifies the function of the CAPWAP control 1245 message. The valid values for Message Type are the following: 1247 Description Value 1248 Discovery Request 1 1249 Discovery Response 2 1250 Configure Request 3 1251 Configure Response 4 1252 Configuration Update Request 5 1253 Configuration Update Response 6 1254 WTP Event Request 7 1255 WTP Event Response 8 1256 Change State Event Request 9 1257 Change State Event Response 10 1258 Echo Request 11 1259 Echo Response 12 1260 Unused 13 1261 Image Data Request 14 1262 Image Data Response 15 1263 Reset Request 16 1264 Reset Response 17 1265 Primary Discovery Request 18 1266 Primary Discovery Response 19 1267 Data Transfer Request 20 1268 Data Transfer Response 21 1269 Clear Config Indication 22 1270 WLAN Config Request 23 1271 WLAN Config Response 24 1272 Mobile Config Request 25 1273 Mobile Config Response 26 1275 4.3.1.2. Sequence Number 1277 The Sequence Number Field is an identifier value to match request/ 1278 response packet exchanges. When a CAPWAP packet with a request 1279 message type is received, the value of the sequence number field is 1280 copied into the corresponding response packet. 1282 When a CAPWAP control message is sent, its internal sequence number 1283 counter is monotonically incremented, ensuring that no two requests 1284 pending have the same sequence number. This field will wrap back to 1285 zero. 1287 4.3.1.3. Message Element Length 1289 The Length field indicates the number of bytes following the Sequence 1290 Num field. 1292 4.3.1.4. Message Element[0..N] 1294 The message element(s) carry the information pertinent to each of the 1295 control message types. Every control message in this specification 1296 specifies which message elements are permitted. 1298 4.3.2. Message Element Format 1300 The message element is used to carry information pertinent to a 1301 control message. Every message element is identified by the Type 1302 field, whose numbering space is managed via IANA (see Section 16). 1303 The total length of the message elements is indicated in the Message 1304 Element Length field. 1306 All of the message element definitions in this document use a diagram 1307 similar to the one below in order to depict its format. Note that in 1308 order to simplify this specification, these diagrams do not include 1309 the header fields (Type and Length). The header field values are 1310 defined in the Message element descriptions. 1312 Additional message elements may be defined in separate IETF 1313 documents. 1315 The format of a message element uses the TLV format shown here: 1317 0 1 2 3 1318 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 1319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1320 | Type | Length | 1321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1322 | Value ... | 1323 +-+-+-+-+-+-+-+-+ 1325 Where Type (16 bit) identifies the character of the information 1326 carried in the Value field and Length (16 bits) indicates the number 1327 of bytes in the Value field. 1329 4.3.2.1. Generic Message Elements 1331 This section includes message elements that are not bound to a 1332 specific control message. 1334 4.3.2.1.1. Vendor Specific 1336 The Vendor Specific Payload is used to communicate vendor specific 1337 information between the WTP and the AC. The value contains the 1338 following format: 1340 0 1 2 3 1341 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 1342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1343 | Vendor Identifier | 1344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1345 | Element ID | Value... | 1346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1348 Type: 104 for Vendor Specific 1350 Length: >= 7 1352 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 1353 Network Management Private Enterprise Codes" [17] 1355 Element ID: A 16-bit Element Identifier which is managed by the 1356 vendor. 1358 Value: The value associated with the vendor specific element. 1360 4.3.3. Quality of Service 1362 It is recommended that CAPWAP control messages be sent by both the AC 1363 and the WTP with an appropriate Quality of Service precedence value, 1364 ensuring that congestion in the network minimizes occurrences of 1365 CAPWAP control channel disconnects. Therefore, a Quality of Service 1366 enabled CAPWAP device should use: 1368 802.1P: The precedence value of 7 SHOULD be used. 1370 DSCP: The DSCP tag value of 46 SHOULD be used. 1372 5. CAPWAP Discovery Operations 1374 The Discovery messages are used by a WTP to determine which ACs are 1375 available to provide service, and the capabilities and load of the 1376 ACs. 1378 5.1. Discovery Request 1380 The Discovery Request message is used by the WTP to automatically 1381 discover potential ACs available in the network. The Discovery 1382 Request message provides ACs with the primary capabilities of the 1383 WTP. A WTP must exchange this information to ensure subsequent 1384 exchanges with the ACs are consistent with the WTP's functional 1385 characteristics. A WTP must transmit this command even if it has a 1386 statically configured AC. 1388 Discovery Request messages MUST be sent by a WTP in the Discover 1389 state after waiting for a random delay less than 1390 MaxDiscoveryInterval, after a WTP first comes up or is 1391 (re)initialized. A WTP MUST send no more than the maximum of 1392 MaxDiscoveries Discovery Request messages, waiting for a random delay 1393 less than MaxDiscoveryInterval between each successive message. 1395 This is to prevent an explosion of WTP Discovery Request messages. 1396 An example of this occurring is when many WTPs are powered on at the 1397 same time. 1399 Discovery Request messages MUST be sent by a WTP when no Echo 1400 Response messages are received for NeighborDeadInterval and the WTP 1401 returns to the Idle state. Discovery Request messages are sent after 1402 NeighborDeadInterval. They MUST be sent after waiting for a random 1403 delay less than MaxDiscoveryInterval. A WTP MAY send up to a maximum 1404 of MaxDiscoveries Discovery Request messages, waiting for a random 1405 delay less than MaxDiscoveryInterval between each successive message. 1407 If a Discovery Response message is not received after sending the 1408 maximum number of Discovery Request messages, the WTP enters the 1409 Sulking state and MUST wait for an interval equal to SilentInterval 1410 before sending further Discovery Request messages. 1412 The Discovery Request message may be sent as a unicast, broadcast or 1413 multicast message. 1415 Upon receiving a Discovery Request message, the AC will respond with 1416 a Discovery Response message sent to the address in the source 1417 address of the received discovery request message. 1419 The following subsections define the message elements that MUST be 1420 included in the Discovery Request message. 1422 5.1.1. Discovery Type 1424 The Discovery message element is used to configure a WTP to operate 1425 in a specific mode. 1427 0 1428 0 1 2 3 4 5 6 7 1429 +-+-+-+-+-+-+-+-+ 1430 | Discovery Type| 1431 +-+-+-+-+-+-+-+-+ 1433 Type: 58 for Discovery Type 1435 Length: 1 1437 Discovery Type: An 8-bit value indicating how the AC was discovered. 1438 The following values are supported: 1440 0 - Broadcast 1442 1 - Configured 1444 5.1.2. WTP Descriptor 1446 The WTP descriptor message element is used by the WTP to communicate 1447 it's current hardware/firmware configuration. The value contains the 1448 following fields. 1450 0 1 2 3 1451 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 1452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1453 | Hardware Version | 1454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1455 | Software Version | 1456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1457 | Boot Version | 1458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1459 | Max Radios | Radios in use | Encryption Capabilities | 1460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1462 Type: 3 for WTP Descriptor 1464 Length: 16 1465 Hardware Version: A 32-bit integer representing the WTP's hardware 1466 version number 1468 Software Version: A 32-bit integer representing the WTP's Firmware 1469 version number 1471 Boot Version: A 32-bit integer representing the WTP's boot loader's 1472 version number 1474 Max Radios: An 8-bit value representing the number of radios (where 1475 each radio is identified via the RID field) supported by the WTP 1477 Radios in use: An 8-bit value representing the number of radios 1478 present in the WTP 1480 Encryption Capabilities: This 16-bit field is used by the WTP to 1481 communicate it's capabilities to the AC. Since most WTP's support 1482 link layer encryption, the AC may make use of these services. 1483 There are binding dependent encryption capabilities. A WTP that 1484 does not have any encryption capabilities would set this field to 1485 zero (0). Refer to the specific binding for further specification 1486 of the Encryption Capabilities field. 1488 5.1.3. WTP Radio Information 1490 The WTP radios information message element is used to communicate the 1491 radio information in a specific slot. The Discovery Request MUST 1492 include one such message element per radio in the WTP. The Radio- 1493 Type field is used by the AC in order to determine which technology 1494 specific binding is to be used with the WTP. 1496 The value contains two fields, as shown. 1498 0 1 2 1499 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1501 | Radio ID | Radio Type | 1502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1504 Type: 4 for WTP Radio Information 1506 Length: 3 1508 Radio ID: The Radio Identifier, which typically refers to an 1509 interface index on the WTP 1511 Radio Type: The type of radio present. Note this bitfield can be 1512 used to specify support for more than a single type of PHY/MAC. 1513 The following values are supported: 1515 1 - 802.11b: An IEEE 802.11b radio. 1517 2 - 802.11a: An IEEE 802.11a radio. 1519 4 - 802.11g: An IEEE 802.11g radio. 1521 8 - 802.11n: An IEEE 802.11n radio. 1523 65535 - all: Used to specify all radios in the WTP. 1525 5.1.4. WTP MAC Type 1527 The WTP MAC-Type message element allows the WTP to communicate its 1528 mode of operation to the AC. A WTP that advertises support for both 1529 modes allows the AC to select the mode to use, based on local policy. 1531 0 1532 0 1 2 3 4 5 6 7 1533 +-+-+-+-+-+-+-+-+ 1534 | MAC Type | 1535 +-+-+-+-+-+-+-+-+ 1537 Type: TBD for WTP MAC Type 1539 Length: 1 1541 MAC Type: The MAC mode of operation supported by the WTP. The 1542 following values are supported 1544 0 - Local-MAC: Local-MAC is the default mode that MUST be 1545 supported by all WTPs. 1547 1 - Split-MAC: Split-MAC support is optional, and allows the AC 1548 to receive and process native wireless frames. 1550 2 - Both: WTP is capable of supporting both Local-MAC and Split- 1551 MAC. 1553 5.1.5. WTP Frame Type 1555 The WTP Frame-Type message element allows the WTP to communicate the 1556 tunneling modes of operation which it supports to the AC. A WTP that 1557 advertises support for all modes allows the AC to select which mode 1558 will be used, based on its local policy. 1560 0 1561 0 1 2 3 4 5 6 7 1562 +-+-+-+-+-+-+-+-+ 1563 | Frame Type | 1564 +-+-+-+-+-+-+-+-+ 1566 Type: TBD for WTP Frame Type 1568 Length: 1 1570 Frame Type: The Frame type specifies the encapsulation modes 1571 supported by the WTP. The following values are supported 1573 1 - Local Bridging: Local Bridging allows the WTP to perform the 1574 bridging function. This value MUST NOT be used when the MAC 1575 Type is set to Split-MAC. 1577 2 - 802.3 Bridging: 802.3 Bridging requires the WTP and AC to 1578 encapsulate all user payload as native IEEE 802.3 frames (see 1579 Section 4.2). This value MUST NOT be used when the MAC Type is 1580 set to Split-MAC. 1582 4 - Native Bridging: Native Bridging requires the WTP and AC to 1583 encapsulate all user payloads as native wireless frames, as 1584 defined by the wireless binding (see Section 4.2). 1586 7 - All: The WTP is capable of supporting all frame types. 1588 5.2. Discovery Response 1590 The Discovery Response message provides a mechanism for an AC to 1591 advertise its services to requesting WTPs. 1593 Discovery Response messages are sent by an AC after receiving a 1594 Discovery Request message from a WTP. 1596 When a WTP receives a Discovery Response message, it MUST wait for an 1597 interval not less than DiscoveryInterval for receipt of additional 1598 Discovery Response messages. After the DiscoveryInterval elapses, 1599 the WTP enters the DTLS-Init state and selects one of the ACs that 1600 sent a Discovery Response message and send a DTLS Handshake to that 1601 AC. 1603 The following subsections define the message elements that MUST be 1604 included in the Discovery Response Message. 1606 5.2.1. AC Address 1608 The AC address message element is used to communicate the identity of 1609 the AC. The value contains two fields, as shown. 1611 0 1 2 3 1612 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 1613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1614 | Reserved | MAC Address | 1615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1616 | MAC Address | 1617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1619 Type: 2 for AC Address 1621 Length: 7 1623 Reserved: MUST be set to zero 1625 Mac Address: The MAC Address of the AC 1627 5.2.2. AC Descriptor 1629 The AC payload message element is used by the AC to communicate it's 1630 current state. The value contains the following fields. 1632 0 1 2 3 1633 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 1634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1635 | Reserved | Hardware Version ... | 1636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1637 | HW Ver | Software Version ... | 1638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1639 | SW Ver | Stations | Limit | 1640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1641 | Limit | Radios | Max Radio | 1642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1643 | Max Radio | Security | 1644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1646 Type: 6 for AC Descriptor 1648 Length: 18 1650 Reserved: MUST be set to zero 1651 Hardware Version: The AC's hardware version number 1653 Software Version: The AC's Firmware version number 1655 Stations: The number of mobile stations currently associated with 1656 the AC 1658 Limit: The maximum number of stations supported by the AC 1660 Radios: The number of WTPs currently attached to the AC 1662 Max Radio: The maximum number of WTPs supported by the AC 1664 Security: A 8 bit bit mask specifying the authentication credential 1665 type supported by the AC. The following values are supported (see 1666 Section 10): 1668 1 - X.509 Certificate Based 1670 2 - Pre-Shared Secret 1672 5.2.3. AC Name 1674 The AC name message element contains an ASCII representation of the 1675 AC's identity. The value is a variable length byte string. The 1676 string is NOT zero terminated. 1678 0 1679 0 1 2 3 4 5 6 7 1680 +-+-+-+-+-+-+-+-+ 1681 | Name ... 1682 +-+-+-+-+-+-+-+-+ 1684 Type: 31 for AC Name 1686 Length: > 0 1688 Name: A variable length ASCII string containing the AC's name 1690 5.2.4. WTP Manager Control IPv4 Address 1692 The WTP Manager Control IPv4 Address message element is sent by the 1693 AC to the WTP during the discovery process and is used by the AC to 1694 provide the interfaces available on the AC, and the current number of 1695 WTPs connected. In the event that multiple WTP Manager Control IPV4 1696 Address message elements are returned, the WTP is expected to perform 1697 load balancing across the multiple interfaces. 1699 0 1 2 3 1700 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 1701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1702 | IP Address | 1703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1704 | WTP Count | 1705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1707 Type: 99 for WTP Manager Control IPv4 Address 1709 Length: 6 1711 IP Address: The IP Address of an interface. 1713 WTP Count: The number of WTPs currently connected to the interface. 1715 5.2.5. WTP Manager Control IPv6 Address 1717 The WTP Manager Control IPv6 Address message element is sent by the 1718 AC to the WTP during the discovery process and is used by the AC to 1719 provide the interfaces available on the AC, and the current number of 1720 WTPs connected. This message element is useful for the WTP to 1721 perform load balancing across multiple interfaces. 1723 0 1 2 3 1724 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 1725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1726 | IP Address | 1727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1728 | IP Address | 1729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1730 | IP Address | 1731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1732 | IP Address | 1733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1734 | WTP Count | 1735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1737 Type: 142 for WTP Manager Control IPv6 Address 1739 Length: 18 1741 IP Address: The IP Address of an interface. 1743 WTP Count: The number of WTPs currently connected to the interface. 1745 5.3. Primary Discovery Request 1747 The Primary Discovery Request message is sent by the WTP to determine 1748 whether its preferred (or primary) AC is available. 1750 A Primary Discovery Request message is sent by a WTP when it has a 1751 primary AC configured, and is connected to another AC. This 1752 generally occurs as a result of a failover, and is used by the WTP as 1753 a means to discover when its primary AC becomes available. As a 1754 consequence, this message is only sent by a WTP when it is in the Run 1755 state. 1757 The frequency of the Primary Discovery Request messages should be no 1758 more often than the sending of the Echo Request message. 1760 Upon receipt of a Discovery Request message, the AC responds with a 1761 Primary Discovery Response message sent to the address in the source 1762 address of the received Primary Discovery Request message. 1764 The following subsections define the message elements that MUST be 1765 included in the Primary Discovery message. 1767 5.3.1. Discovery Type 1769 The Discovery Type message element is defined in Section 5.1.1. 1771 5.3.2. WTP Descriptor 1773 The WTP Descriptor message element is defined in Section 5.1.2. 1775 5.3.3. WTP MAC Type 1777 The Discovery Type message element is defined in Section 5.1.4. 1779 5.3.4. WTP Frame Type 1781 The WTP Frame Type message element is defined in Section 5.1.5. 1783 5.3.5. WTP Radio Information 1785 A WTP Radio Information message element must be present for every 1786 radio in the WTP. This message element is defined in Section 5.1.3. 1788 5.4. Primary Discovery Response 1790 The Primary Discovery Response message enables an AC to advertise its 1791 availability and services to requesting WTPs that are configured to 1792 have the AC as its primary AC. 1794 Primary Discovery Response messages are sent by an AC after receiving 1795 a Primary Discovery Request message. 1797 When a WTP receives a Primary Discovery Response message, it may 1798 establish a CAPWAP protocol connection to its primary AC, based on 1799 the configuration of the WTP Fallback Status message element on the 1800 WTP. 1802 The following subsections define the message elements that MUST be 1803 included in the Primary Discovery Request message. 1805 5.4.1. AC Descriptor 1807 The Discovery Type message element is defined in Section 5.2.2. 1809 5.4.2. AC Name 1811 The AC Name message element is defined in Section 5.2.3. 1813 5.4.3. WTP Manager Control IPv4 Address 1815 A WTP Radio Information message element MAY be present for every 1816 radio in the WTP which are reachable via IPv4. This message element 1817 is defined in Section 5.2.4. 1819 5.4.4. WTP Manager Control IPv6 Address 1821 A WTP Radio Information message element must be present for every 1822 radio in the WTP which are reachable via IPv6. This message element 1823 is defined in Section 5.2.5. 1825 6. Control Channel Management 1827 The Control Channel Management messages are used by the WTP and AC to 1828 maintain a control communication channel. 1830 6.1. Echo Request 1832 The Echo Request message is a keep alive mechanism for CAPWAP control 1833 messages. 1835 Echo Request messages are sent periodically by a WTP in the Run state 1836 (see Section 2.2) to determine the state of the connection between 1837 the WTP and the AC. The Echo Request message is sent by the WTP when 1838 the Heartbeat timer expires. The WTP MUST start its 1839 NeighborDeadInterval timer when the Heartbeat timer expires. 1841 The Echo Request message carries no message elements. 1843 When an AC receives an Echo Request message it responds with an Echo 1844 Response message. 1846 6.2. Echo Response 1848 The Echo Response message acknowledges the Echo Request message, and 1849 is only processed while in the Run state (see Section 2.2). 1851 An Echo Response message is sent by an AC after receiving an Echo 1852 Request message. After transmitting the Echo Response message, the 1853 AC SHOULD reset its Heartbeat timer to expire in the value configured 1854 for EchoInterval. If another Echo Request message is not received by 1855 the AC when the timer expires, the AC SHOULD consider the WTP to be 1856 no longer be reachable. 1858 The Echo Response message carries no message elements. 1860 When a WTP receives an Echo Response message it stops the 1861 NeighborDeadInterval timer, and initializes the Heartbeat timer to 1862 the EchoInterval. 1864 If the NeighborDeadInterval timer expires prior to receiving an Echo 1865 Response message, the WTP enters the Idle state. 1867 7. WTP Configuration Management 1869 Wireless Termination Point Configuration messages are used to 1870 exchange configuration information between the AC and the WTP. 1872 7.1. Configuration Consistency 1874 The CAPWAP protocol provides flexibility in how WTP configuration is 1875 managed. A WTP has two options: 1877 1. The WTP retains no configuration and accepts the configuration 1878 provided by the AC. 1880 2. The WTP retains the configuration of parameters provided by the AC 1881 that are non-default values. 1883 If the WTP opts to save configuration locally, the CAPWAP protocol 1884 state machine defines the Configure state, which allows for 1885 configuration exchange. In the Configure state, the WTP sends its 1886 current configuration overrides to the AC via the Configure Request 1887 message. A configuration override is a parameter that is non- 1888 default. One example is that in the CAPWAP protocol, the default 1889 antenna configuration is internal omni antenna. A WTP that either 1890 has no internal antennas, or has been explicitly configured by the AC 1891 to use external antennas, sends its antenna configuration during the 1892 configure phase, allowing the AC to become aware of the WTP's current 1893 configuration. 1895 Once the WTP has provided its configuration to the AC, the AC sends 1896 its own configuration. This allows the WTP to inherit the 1897 configuration and policies from the AC. 1899 An AC maintains a copy of each active WTP's configuration. There is 1900 no need for versioning or other means to identify configuration 1901 changes. If a WTP becomes inactive, the AC MAY delete the 1902 configuration associated with it. If a WTP fails, and connects to a 1903 new AC, it provides its overridden configuration parameters, allowing 1904 the new AC to be aware of the WTP's configuration. 1906 This model allows for resiliency in case of an AC failure, that 1907 another AC can provide service to the WTP. In this scenario, the new 1908 AC would be automatically updated with WTP configuration changes, 1909 eliminating the need for inter-AC communication or the need for all 1910 ACs to be aware of the configuration of all WTPs in the network. 1912 Once the CAPWAP protocol enters the Run state, the WTPs begin to 1913 provide service. It is quite common for administrators to require 1914 that configuration changes be made while the network is operational. 1916 Therefore, the Configuration Update Request is sent by the AC to the 1917 WTP to make these changes at run-time. 1919 7.1.1. Configuration Flexibility 1921 The CAPWAP protocol provides the flexibility to configure and manage 1922 WTPs of varying design and functional characteristics. When a WTP 1923 first discovers an AC, it provides primary functional information 1924 relating to its type of MAC and to the nature of frames to be 1925 exchanged. The AC configures the WTP appropriately. The AC also 1926 establishes corresponding internal operations to deal with the WTP 1927 according to its functionalities. 1929 7.2. Configure Request 1931 The Configure Request message is sent by a WTP to deliver its current 1932 configuration to its AC. 1934 Configure Request messages are sent by a WTP while in the Configure 1935 state. 1937 The Configure Request message carries binding specific message 1938 elements. Refer to the appropriate binding for the definition of 1939 this structure. 1941 When an AC receives a Configure Request message it will act upon the 1942 content of the packet and respond to the WTP with a Configure 1943 Response message. 1945 The Configure Request message includes multiple Administrative State 1946 message Elements. There is one such message element for the WTP, and 1947 one message element per radio in the WTP. 1949 The following subsections define the message elements that MUST be 1950 included in the Configure Request message. 1952 7.2.1. Administrative State 1954 The administrative event message element is used to communicate the 1955 state of a particular radio. The value contains the following 1956 fields. 1958 0 1 1959 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1961 | Radio ID | Admin State | 1962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1964 Type: 27 for Administrative State 1966 Length: 2 1968 Radio ID: An 8-bit value representing the radio to configure. The 1969 Radio ID field may also include the value of 0xff, which is used 1970 to identify the WTP itself. Therefore, if an AC wishes to change 1971 the administrative state of a WTP, it would include 0xff in the 1972 Radio ID field. 1974 Admin State: An 8-bit value representing the administrative state of 1975 the radio. The following values are supported: 1977 1 - Enabled 1979 2 - Disabled 1981 7.2.2. AC Name 1983 The AC Name message element is defined in Section Section 5.2.3. 1985 7.2.3. AC Name with Index 1987 The AC Name with Index message element is sent by the AC to the WTP 1988 to configure preferred ACs. The number of instances where this 1989 message element would be present is equal to the number of ACs 1990 configured on the WTP. 1992 0 1 1993 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1995 | Index | AC Name... 1996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1998 Type: 90 for AC Name with Index 2000 Length: > 2 2002 Index: The index of the preferred server (e.g., 1=primary, 2003 2=secondary). 2005 AC Name: A variable length ASCII string containing the AC's name. 2007 7.2.4. WTP Board Data 2009 The WTP Board Data message element is sent by the WTP to the AC and 2010 contains information about the hardware present. 2012 0 1 2 3 2013 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 2014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2015 | Card ID | Card Revision | 2016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2017 | WTP Model | 2018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2019 | WTP Model | 2020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2021 | WTP Serial Number | 2022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2023 | WTP Serial Number | 2024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2025 | WTP Serial Number | 2026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2027 | WTP Serial Number | 2028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2029 | WTP Serial Number | 2030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2031 | WTP Serial Number | 2032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2034 | Ethernet MAC Address | 2035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2036 | Ethernet MAC Address | 2037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2039 Type: 50 for WTP Board Data 2041 Length: 26 2043 Card ID: A 2 byte hardware identifier. 2045 Card Revision: A 2 byte Revision of the card. 2047 WTP Model: 8 byte WTP Model Number. 2049 WTP Serial Number: 24 byte WTP Serial Number. 2051 Ethernet MAC Address: MAC Address of the WTP's Ethernet interface. 2053 7.2.5. Statistics Timer 2055 The statistics timer message element value is used by the AC to 2056 inform the WTP of the frequency which it expects to receive updated 2057 statistics. 2059 0 1 2060 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2062 | Statistics Timer | 2063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2065 Type: 37 for Statistics Timer 2067 Length: 2 2069 Statistics Timer: A 16-bit unsigned integer indicating the time, in 2070 seconds 2072 7.2.6. WTP Static IP Address Information 2074 The WTP Static IP Address Information message element is used by an 2075 AC to configure or clear a previously configured static IP address on 2076 a WTP. 2078 0 1 2 3 2079 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 2080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2081 | IP Address | 2082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2083 | Netmask | 2084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2085 | Gateway | 2086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2087 | Static | 2088 +-+-+-+-+-+-+-+-+ 2090 Type: 82 for WTP Static IP Address Information 2092 Length: 13 2094 IP Address: The IP Address to assign to the WTP. This field is only 2095 valid if the static field is set to one. 2097 Netmask: The IP Netmask. This field is only valid if the static 2098 field is set to one. 2100 Gateway: The IP address of the gateway. This field is only valid if 2101 the static field is set to one. 2103 Netmask: The IP Netmask. This field is only valid if the static 2104 field is set to one. 2106 Static: An 8-bit boolean stating whether the WTP should use a static 2107 IP address or not. A value of zero disables the static IP 2108 address, while a value of one enables it. 2110 7.2.7. WTP Reboot Statistics 2112 The WTP Reboot Statistics message element is sent by the WTP to the 2113 AC to communicate reasons why reboots have occurred. 2115 0 1 2 3 2116 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 2117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2118 | Crash Count | CAPWAP Initiated Count | 2119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2120 | Link Failure Count | Failure Type | 2121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2123 Type: 67 for WTP Reboot Statistics 2125 Length: 7 2127 Crash Count: The number of reboots that have occurred due to a WTP 2128 crash. A value of 65535 implies that this information is not 2129 available on the WTP. 2131 CAPWAP Initiated Count: The number of reboots that have occurred at 2132 the request of a CAPWAP protocol message, such as a change in 2133 configuration that required a reboot or an explicit CAPWAP reset 2134 request. A value of 65535 implies that this information is not 2135 available on the WTP. 2137 Link Failure Count: The number of times that a CAPWAP protocol 2138 connection with an AC has failed. 2140 Failure Type: The last WTP failure. The following values are 2141 supported: 2143 0 - Link Failure 2145 1 - CAPWAP Initiated (see Section 8.3) 2147 2 - WTP Crash 2149 255 - Unknown (e.g., WTP doesn't keep track of info) 2151 7.3. Configure Response 2153 The Configure Response message is sent by an AC and provides a 2154 mechanism for the AC to override a WTP's requested configuration. 2156 Configure Response messages are sent by an AC after receiving a 2157 Configure Request message. 2159 The Configure Response message carries binding specific message 2160 elements. Refer to the appropriate binding for the definition of 2161 this structure. 2163 When a WTP receives a Configure Response message it acts upon the 2164 content of the message, as appropriate. If the Configure Response 2165 message includes a Change State Event message element that causes a 2166 change in the operational state of one of the Radio, the WTP will 2167 transmit a Change State Event to the AC, as an acknowledgement of the 2168 change in state. 2170 The following subsections define the message elements that MUST be 2171 included in the Configure Response message. 2173 7.3.1. Decryption Error Report Period 2175 The Decryption Error Report Period message element value is used by 2176 the AC to inform the WTP how frequently it should send decryption 2177 error report messages. 2179 0 1 2 2180 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2182 | Radio ID | Report Interval | 2183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2185 Type: 38 for Decryption Error Report Period 2187 Length: 3 2189 Radio ID: The Radio Identifier, typically refers to some interface 2190 index on the WTP 2192 Report Interval: A 16-bit unsigned integer indicating the time, in 2193 seconds 2195 7.3.2. Change State Event 2197 The Change State message element is used to communicate a change in 2198 the operational state of a radio. The value contains two fields, as 2199 shown. 2201 0 1 2202 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2204 | Radio ID | State | Cause | 2205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2207 Type: 26 for Change State Event 2209 Length: 3 2211 Radio ID: The Radio Identifier, typically refers to some interface 2212 index on the WTP. 2214 State: An 8-bit boolean value representing the state of the radio. 2215 A value of one disables the radio, while a value of two enables 2216 it. 2218 Cause: In the event of a radio being inoperable, the cause field 2219 would contain the reason the radio is out of service. 2221 Cause: In the event of a radio being inoperable, the cause field 2222 would contain the reason the radio is out of service. The 2223 following values are supported: 2225 0 - Normal 2227 1 - Radio Failure 2229 2 - Software Failure 2231 7.3.3. CAPWAP Timers 2233 The CAPWAP Timers message element is used by an AC to configure 2234 CAPWAP timers on a WTP. 2236 0 1 2237 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2239 | Discovery | Echo Request | 2240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2242 Type: 68 for CAPWAP Timers 2243 Length: 2 2245 Discovery: The number of seconds between CAPWAP Discovery packets, 2246 when the WTP is in the discovery mode. 2248 Echo Request: The number of seconds between WTP Echo Request CAPWAP 2249 messages. 2251 7.3.4. AC IPv4 List 2253 The AC List message element is used to configure a WTP with the 2254 latest list of ACs in a cluster. 2256 0 1 2 3 2257 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 2258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2259 | AC IP Address[] | 2260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2262 Type: 59 for AC List 2264 Length: 4 2266 The AC IP Address: An array of 32-bit integers containing an AC's 2267 IPv4 Address. 2269 7.3.5. AC IPv6 List 2271 The AC List message element is used to configure a WTP with the 2272 latest list of ACs in a cluster. 2274 0 1 2 3 2275 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 2276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2277 | AC IP Address[] | 2278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2279 | AC IP Address[] | 2280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2281 | AC IP Address[] | 2282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2283 | AC IP Address[] | 2284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2286 Type: 141 for AC IPV6 List 2288 Length: 16 2290 The AC IP Address: An array of 32-bit integers containing an AC's 2291 IPv6 Address. 2293 7.3.6. WTP Fallback 2295 The WTP Fallback message element is sent by the AC to the WTP to 2296 enable or disable automatic CAPWAP fallback in the event that a WTP 2297 detects its preferred AC, and is not currently connected to it. 2299 0 2300 0 1 2 3 4 5 6 7 2301 +-+-+-+-+-+-+-+-+ 2302 | Mode | 2303 +-+-+-+-+-+-+-+-+ 2305 Type: 91 for WTP Fallback 2307 Length: 1 2309 Mode: The 8-bit value indicates the status of automatic CAPWAP 2310 fallback on the WTP. A value of zero disables fallback, while a 2311 value of one enables it. When enabled, if the WTP detects that 2312 its primary AC is available, and it is not connected to it, it 2313 SHOULD automatically disconnect from its current AC and reconnect 2314 to its primary. If disabled, the WTP will only reconnect to its 2315 primary through manual intervention (e.g., through the Reset 2316 Request command). 2318 7.3.7. Idle Timeout 2320 The Idle Timeout message element is sent by the AC to the WTP to 2321 provide it with the idle timeout that it should enforce on its active 2322 mobile station entries. 2324 0 1 2 3 2325 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 2326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2327 | Timeout | 2328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2330 Type: 97 for Idle Timeout 2332 Length: 4 2334 Timeout: The current idle timeout to be enforced by the WTP. 2336 7.4. Configuration Update Request 2338 Configure Update Request messages are sent by the AC to provision the 2339 WTP while in the Run state. This is used to modify the configuration 2340 of the WTP while it is operational. 2342 When an AC receives a Configuration Update Request message it will 2343 respond with a Configuration Update Response message, with the 2344 appropriate Result Code. 2346 The following subsections define the message elements included in the 2347 Configuration Update message. 2349 7.4.1. WTP Name 2351 The WTP Name message element is a variable length bye string. The 2352 string is not zero terminated. 2354 0 2355 0 1 2 3 4 5 6 7 2356 +-+-+-+-+-+-+-+-+- 2357 | WTP Name ... 2358 +-+-+-+-+-+-+-+-+- 2360 Type: 5 for WTP Name 2362 Length: 0 2364 Timeout: A non-zero terminated string containing the WTP name. 2366 7.4.2. Change State Event 2368 The Change State Event message element is defined in Section 2369 Section 7.3.2. 2371 7.4.3. Administrative State 2373 The Administrative State message element is defined in Section 2374 Section 7.2.1. 2376 7.4.4. Statistics Timer 2378 The Statistics Timer message element is defined in Section 2379 Section 7.2.5. 2381 7.4.5. Location Data 2383 The Location Data message elementis a variable length byte string 2384 containing user defined location information (e.g. "Next to 2385 Fridge"). This information is configurable by the network 2386 administrator, and allows for the WTP location to be determined 2387 through this field. The string is not zero terminated. 2389 0 2390 0 1 2 3 4 5 6 7 2391 +-+-+-+-+-+-+-+-+- 2392 | Location ... 2393 +-+-+-+-+-+-+-+-+- 2395 Type: 35 for Location Data 2397 Length: 0 2399 Timeout: A non-zero terminated string containing the WTP location. 2401 7.4.6. Decryption Error Report Period 2403 The Decryption Error Report Period message element is defined in 2404 Section 7.3.1. 2406 7.4.7. AC IPv4 List 2408 The AC List message element is defined in Section 7.3.4. 2410 7.4.8. AC IPv6 List 2412 The AC List message element is defined in Section 7.3.5. 2414 7.4.9. Add MAC ACL Entry 2416 The Add MAC Access Control List (ACL) Entry message element is used 2417 by an AC to add a MAC ACL list entry on a WTP, ensuring that the WTP 2418 no longer provides any service to the MAC addresses provided in the 2419 message. The MAC Addresses provided in this message element are not 2420 expected to be saved in non-volatile memory on the WTP. 2422 0 1 2 3 2423 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 2424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2425 | Num of Entries| MAC Address[] | 2426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2427 | MAC Address[] | 2428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2430 Type: 65 for Add MAC ACL Entry 2432 Length: >= 7 2434 Num of Entries: The number of MAC Addresses in the array. 2436 MAC Address: An array of MAC Addresses to add to the ACL. 2438 7.4.10. Delete MAC ACL Entry 2440 The Delete MAC ACL Entry message element is used by an AC to delete a 2441 MAC ACL entry on a WTP, ensuring that the WTP provides service to the 2442 MAC addresses provided in the message. 2444 0 1 2 3 2445 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 2446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2447 | Num of Entries| MAC Address[] | 2448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2449 | MAC Address[] | 2450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2452 Type: 66 for Delete MAC ACL Entry 2454 Length: >= 7 2456 Num of Entries: The number of MAC Addresses in the array. 2458 MAC Address: An array of MAC Addresses to delete from the ACL. 2460 7.4.11. Add Static MAC ACL Entry 2462 The Add Static MAC ACL Entry message element is used by an AC to add 2463 a permanent ACL entry on a WTP, ensuring that the WTP no longer 2464 provides any service to the MAC addresses provided in the message. 2465 The MAC Addresses provided in this message element are expected to be 2466 saved in non-volative memory on the WTP. 2468 0 1 2 3 2469 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 2470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2471 | Num of Entries| MAC Address[] | 2472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2473 | MAC Address[] | 2474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2476 Type: 70 for Add Static MAC ACL Entry 2478 Length: >= 7 2480 Num of Entries: The number of MAC Addresses in the array. 2482 MAC Address: An array of MAC Addresses to add to the permanent ACL. 2484 7.4.12. Delete Static MAC ACL Entry 2486 The Delete Static MAC ACL Entry message element is used by an AC to 2487 delete a previously added static MAC ACL entry on a WTP, ensuring 2488 that the WTP provides service to the MAC addresses provided in the 2489 message. 2491 0 1 2 3 2492 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 2493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2494 | Num of Entries| MAC Address[] | 2495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2496 | MAC Address[] | 2497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2499 Type: 71 for Delete MAC ACL Entry 2501 Length: >= 7 2503 Num of Entries: The number of MAC Addresses in the array. 2505 MAC Address: An array of MAC Addresses to delete from the static MAC 2506 ACL entry. 2508 7.4.13. CAPWAP Timers 2510 The CAPWAP Timers message element is defined in Section 7.3.3. 2512 7.4.14. AC Name with Index 2514 The AC Name with Index message element is defined in Section 7.2.3. 2516 7.4.15. WTP Fallback 2518 The WTP Fallback message element is defined in Section 7.3.6. 2520 7.4.16. Idle Timeout 2522 The Idle Timeout message element is defined in Section 7.3.7. 2524 7.4.17. Timestamp 2526 The Timestamp message element is sent by the AC to to synchronize the 2527 WTP's clock. 2529 0 1 2 3 2530 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 2531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2532 | Timestamp | 2533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2535 Type: TBD for Timestamp 2537 Length: 4 2539 Timestamp: The AC's current time, allowing all of the WTPs to be 2540 time synchronized in the format defined by Network Time Protocol 2541 (NTP) in RFC 1305 [10]. 2543 7.5. Configuration Update Response 2545 The Configuration Update Response message is the acknowledgement 2546 message for the Configuration Update Request message. 2548 The Configuration Update Response message is sent by a WTP after 2549 receiving a Configuration Update Request message. 2551 When an AC receives a Configure Update Response message the result 2552 code indicates if the WTP successfully accepted the configuration. 2554 The following subsections define the message elements that must be 2555 present in the Configuration Update message. 2557 7.5.1. Result Code 2559 The Result Code message element value is a 32-bit integer value, 2560 indicating the result of the request operation corresponding to the 2561 sequence number in the message. 2563 0 1 2 3 2564 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 2565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2566 | Result Code | 2567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2569 Type: 2 for Result Code 2571 Length: 4 2573 Result Code: The following values are defined: 2575 0 Success 2577 1 Failure (AC List message element MUST be present) 2579 7.6. Change State Event Request 2581 The Change State Event Request message is used by the WTP to inform 2582 the AC of a change in the operational state. 2584 The Change State Event Request message is sent by the WTP when it 2585 receives a Configuration Response message that includes a Change 2586 State Event message element. It is also sent when the WTP detects an 2587 operational failure with a radio. The Change State Event Request 2588 message may be sent in either the Configure or Run state (see 2589 Section 2.2. 2591 When an AC receives a Change State Event message it will respond with 2592 a Change State Event Response message and make any necessary 2593 modifications to internal WTP data structures. 2595 The following subsections define the message elements that must be 2596 present in the Change State Event Request message. 2598 7.6.1. Change State Event 2600 The Change State Event message element is defined in Section 7.3.2. 2602 7.7. Change State Event Response 2604 The Change State Event Response message acknowledges the Change State 2605 Event Request message. 2607 A Change State Event Response message is by a WTP after receiving a 2608 Change State Event Request message. 2610 The Change State Event Response message carries no message elements. 2612 Its purpose is to acknowledge the receipt of the Change State Event 2613 Request message. 2615 The WTP does not need to perform any special processing of the Change 2616 State Event Response message. 2618 7.8. Clear Config Indication 2620 The Clear Config Indication message is used to reset a WTP's 2621 configuration. 2623 The Clear Config Indication message is sent by an AC to request that 2624 a WTP reset its configuration to the manufacturing default 2625 configuration. The Clear Config Indication message is sent while in 2626 the Run CAPWAP state. 2628 The Clear Config Indication message carries no message elements. 2630 When a WTP receives a Clear Config Indication message it resets its 2631 configuration to the manufacturing default configuration. 2633 8. Device Management Operations 2635 This section defines CAPWAP operations responsible for debugging, 2636 gathering statistics, logging, and firmware management. 2638 8.1. Image Data Request 2640 The Image Data Request message is used to update firmware on the WTP. 2641 This message and its companion response message are used by the AC to 2642 ensure that the image being run on each WTP is appropriate. 2644 Image Data Request messages are exchanged between the WTP and the AC 2645 to download a new program image to the WTP. 2647 When a WTP or AC receives an Image Data Request message it will 2648 respond with an Image Data Response message. 2650 The format of the Image Data and Image Download message elements are 2651 described in the following subsections. 2653 8.1.1. Image Download 2655 The image download message element is sent by the WTP to the AC and 2656 contains the image filename. The value is a variable length byte 2657 string. The string is NOT zero terminated. 2659 0 1 2 3 2660 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 2661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2662 | Filename ... | 2663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2665 Type: 32 for Image Download 2667 Length: >= 1 2669 Filename: A variable length string containing the filename to 2670 download. 2672 8.1.2. Image Data 2674 The image data message element is present in the Image Data Request 2675 message sent by the AC and contains the following fields. 2677 0 1 2 3 2678 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 2679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2680 | Opcode | Checksum | Image Data | 2681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2682 | Image Data ... | 2683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2685 Type: 33 for Image Data 2687 Length: >= 4 (allows 0 length element if last data unit is 1024 2688 bytes) 2690 Opcode: An 8-bit value representing the transfer opcode. The 2691 following values are supported: 2693 3 - Image data is included 2695 5 - An error occurred. Transfer is aborted 2697 Checksum: A 16-bit value containing a checksum of the image data 2698 that follows 2700 Image Data: The Image Data field contains 1024 characters, unless 2701 the payload being sent is the last one (end of file). If the last 2702 block was 1024 in length, an Image Data with a zero length payload 2703 is sent. 2705 8.2. Image Data Response 2707 The Image Data Response message acknowledges the Image Data Request 2708 message. 2710 An Image Data Response message is sent in response to a received 2711 Image Data Request message. Its purpose is to acknowledge the 2712 receipt of the Image Data Request message. 2714 The Image Data Response message carries no message elements. 2716 No action is necessary on receipt. 2718 8.3. Reset Request 2720 The Reset Request message is used to cause a WTP to reboot. 2722 A Reset Request message is sent by an AC to cause a WTP to 2723 reinitialize its operation. 2725 The Reset Request carries no message elements. 2727 When a WTP receives a Reset Request it will respond with a Reset 2728 Response and then reinitialize itself. 2730 8.4. Reset Response 2732 The Reset Response message acknowledges the Reset Request message. 2734 A Reset Response message is sent by the WTP after receiving a Reset 2735 Request message. 2737 The Reset Response message carries no message elements. Its purpose 2738 is to acknowledge the receipt of the Reset Request message. 2740 When an AC receives a Reset Response message, it is notified that the 2741 WTP will reinitialize its operation. 2743 8.5. WTP Event Request 2745 WTP Event Request message is used by a WTP to send information to its 2746 AC. The WTP Event Request message may be sent periodically, or sent 2747 in response to an asynchronous event on the WTP. For example, a WTP 2748 MAY collect statistics and use the WTP Event Request message to 2749 transmit the statistics to the AC. 2751 When an AC receives a WTP Event Request message it will respond with 2752 a WTP Event Response message. 2754 The WTP Event Request message MUST contain one of the message 2755 elements described below, or a message element that is defined for a 2756 specific wireless technology. 2758 8.5.1. Decryption Error Report 2760 The Decryption Error Report message element value is used by the WTP 2761 to inform the AC of decryption errors that have occurred since the 2762 last report. Note that this error reporting mechanism is not used if 2763 encryption and decryption services are provided via the AC. 2765 0 1 2 2766 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2768 | Radio ID |Num Of Entries | Mobile MAC Address | 2769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2770 | Mobile MAC Address[] | 2771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2773 Type: 39 for Decryption Error Report 2775 Length: >= 8 2777 Radio ID: The Radio Identifier, which typically refers to an 2778 interface index on the WTP 2780 Num Of Entries: An 8-bit unsigned integer indicating the number of 2781 mobile MAC addresses. 2783 Mobile MAC Address: An array of mobile station MAC addresses that 2784 have caused decryption errors. 2786 8.5.2. Duplicate IPv4 Address 2788 The Duplicate IPv4 Address message element is used by a WTP to inform 2789 an AC that it has detected another IP device using the same IP 2790 address it is currently using. 2792 0 1 2 3 2793 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 2794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2795 | IP Address | 2796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2797 | MAC Address | 2798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2799 | MAC Address | 2800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2802 Type: 77 for Duplicate IPv4 Address 2804 Length: 10 2806 IP Address: The IP Address currently used by the WTP. 2808 MAC Address: The MAC Address of the offending device. 2810 8.5.3. Duplicate IPv6 Address 2812 The Duplicate IPv6 Address message element is used by a WTP to inform 2813 an AC that it has detected another host using the same IP address it 2814 is currently using. 2816 0 1 2 3 2817 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 2818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2819 | IP Address | 2820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2821 | IP Address | 2822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2823 | IP Address | 2824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2825 | IP Address | 2826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2827 | MAC Address | 2828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2829 | MAC Address | 2830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2832 Type: 77 for Duplicate IPv6 Address 2834 Length: 22 2836 IP Address: The IP Address currently used by the WTP. 2838 MAC Address: The MAC Address of the offending device. 2840 8.6. WTP Event Response 2842 The WTP Event Response message acknowledges receipt of the WTP Event 2843 Request message. 2845 A WTP Event Response message issent by an AC after receiving a WTP 2846 Event Request message. 2848 The WTP Event Response message carries no message elements. 2850 8.7. Data Transfer Request 2852 The Data Transfer Request message is used to deliver debug 2853 information from the WTP to the AC. 2855 Data Transfer Request messages are sent by the WTP to the AC when the 2856 WTP determines that it has important information to send to the AC. 2857 For instance, if the WTP detects that its previous reboot was caused 2858 by a system crash, it can send the crash file to the AC. The remote 2859 debugger function in the WTP also uses the Data Transfer Request 2860 message to send console output to the AC for debugging purposes. 2862 When the AC receives a Data Transfer Request message it responds to 2863 the WTP ith a Data Transfer Response message. The AC MAY log the 2864 information received. 2866 The Data Transfer Request message MUST contain one of the following 2867 message element listed below. 2869 8.7.1. Data Transfer Mode 2871 The Data Transfer Mode message element is used by the AC to request 2872 information from the WTP for debugging purposes. 2874 0 2875 0 1 2 3 4 5 6 7 2876 +-+-+-+-+-+-+-+-+ 2877 | Data Type | 2878 +-+-+-+-+-+-+-+-+ 2880 Type: 52 for Data Transfer Mode 2882 Length: 1 2884 Data Type: An 8-bit value the type of information being requested. 2885 The following values are supported: 2887 1 - WTP Crash Data 2889 2 - WTP Memory Dump 2891 8.7.2. Data Transfer Data 2893 The Data Transfer Data message element is used by the WTP to provide 2894 information to the AC for debugging purposes. 2896 0 1 2 3 2897 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 2898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2899 | Data Type | Data Length | Data .... 2900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2902 Type: 53 for Data Transfer Data 2904 Length: >= 3 2906 Data Type: An 8-bit value the type of information being sent. The 2907 following values are supported: 2909 1 - WTP Crash Data 2911 2 - WTP Memory Dump 2913 Data Length: Length of data field. 2915 Data: Debug information. 2917 8.8. Data Transfer Response 2919 The Data Transfer Response message acknowledges the Data Transfer 2920 Request message. 2922 A Data Transfer Response message is sent in response to a received 2923 Data Transfer Request message. Its purpose is to acknowledge receipt 2924 of the Data Transfer Request message. 2926 The Data Transfer Response message carries no message elements. 2928 Upon receipt of a Data Transfer Response message, the WTP transmits 2929 more information, if more information is available. 2931 9. Mobile Session Management 2933 Messages in this section are used by the AC to create, modify or 2934 delete mobile station session state on the WTPs. 2936 9.1. Mobile Config Request 2938 The Mobile Config Request message is used to create, modify or delete 2939 mobile session state on a WTP. The message is sent by the AC to the 2940 WTP, and may contain one or more message elements. The message 2941 elements for this CAPWAP control message include information that is 2942 generally highly technology specific. Therefore, please refer to the 2943 appropriate binding section or document for the definitions of the 2944 messages elements that may be used in this control message. 2946 9.1.1. Add Mobile 2948 The Add Mobile message element is used by the AC to inform a WTP that 2949 it should forward traffic for a particular mobile station. The Add 2950 Mobile message element will be accompanied by technology specific 2951 binding information element which may include security parameters. 2952 Consequently, the security parameters must be applied by the WTP for 2953 the particular mobile. 2955 Once a mobile station's policy has been pushed to the WTP through 2956 this message element, an AC may change any policies by simply sending 2957 a modified Add Mobile message element. When a WTP receives an Add 2958 Mobile message element for an existing mobile station, it must 2959 override any existing state it may have for the mobile station in 2960 question. The latest Add Mobile overrides any previously received 2961 messages. 2963 0 1 2 3 2964 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 2965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2966 | Radio ID | MAC Address | 2967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2968 | MAC Address | VLAN Name... 2969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2971 Type: 29 for Add Mobile 2973 Length: >= 7 2975 Radio ID: An 8-bit value representing the radio 2976 MAC Address: The mobile station's MAC Address 2978 VLAN Name: An optional variable string containing the VLAN Name on 2979 which the WTP is to locally bridge user data. Note this field is 2980 only valid with WTPs configured in Local MAC mode. 2982 9.1.2. Delete Mobile 2984 The Delete Mobile message element is used by the AC to inform an WTP 2985 that it should no longer provide service to a particular mobile 2986 station. The WTP must terminate service immediately upon receiving 2987 this message element. 2989 The transmission of a Delete Mobile message element could occur for 2990 various reasons, including for administrative reasons, as a result of 2991 the fact that the mobile has roamed to another WTP, etc. 2993 Once access has been terminated for a given station, any future 2994 packets received from the mobile must result in a deauthenticate 2995 message, as specified in [6]. 2997 0 1 2 3 2998 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 2999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3000 | Radio ID | MAC Address | 3001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3002 | MAC Address | 3003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3005 Type: 30 for Delete Mobile 3007 Length: 7 3009 Radio ID: An 8-bit value representing the radio 3011 MAC Address: The mobile station's MAC Address 3013 9.2. Mobile Config Response 3015 The Mobile Configuration Response message is used to acknowledge a 3016 previously received Mobile Configuration Request message, and 3017 includes a Result Code message element which indicates whether an 3018 error occurred on the WTP. 3020 This message requires no special processing, and is only used to 3021 acknowledge the Mobile Configuration Request message. 3023 9.2.1. Result Code 3025 The Result Code message element is defined in Section 7.5.1. 3027 10. CAPWAP Security 3029 This version of the CAPWAP protocol uses DTLS with both certificate 3030 and shared secret based credentials to secure CAPWAP protocol 3031 Control, and (optionally) Data packets. CAPWAP protocol Discovery 3032 Request and Discover Response messages are sent in the clear, as they 3033 are sent prior to esablishment of a secure DTLS session between the 3034 WTP and the AC. Once the DTLS session is established, and the CAPWAP 3035 state machine (see Section 2.2) is in the Configure state, all CAPWAP 3036 control frames are encrypted. 3038 An in-depth security analysis of threats and risks to AC-AP 3039 communication is beyond the scope of this document. The list below 3040 provides a summary of the assumptions made in the CAPWAP protocol 3041 security design: 3043 o WTP-AC communications may be accessible to a sophisticated 3044 attacker. 3046 o When authentication and/or privacy of end to end traffic for which 3047 the WTP and AC are intermediaries is required, IPSEC [19] or 3048 another end to end security protocol must be used. 3050 o Privacy and authentication for at least some WTP-AC control 3051 traffic is required, for example to enable secure delivery of user 3052 sessions keys from the AC to the WTP. 3054 10.1. Endpoint Authentication using DTLS 3056 Certificate-based authentication is natively supported in DTLS, and 3057 support for preshared keys has been standardized (see [12]). The TLS 3058 algorithm suites for each endpoint authentication method are 3059 described below. 3061 10.1.1. Authenticating with Certificates 3063 Note that only block ciphers are currently recommended for use with 3064 DTLS. To understand the reasoning behind this, see [23]. 3065 However,support for AES counter mode encryption is currently 3066 progressing in the TLS working group, and once protocol identifiers 3067 are available, they will be added below. At present, the following 3068 algorithms MUST be supported when using certificates for CAPWAP 3069 authentication: 3071 o TLS_RSA_WITH_AES_128_CBC_SHA 3073 o TLS_RSA_WITH_3DES_EDE_CBC_SHA 3074 The following algorithms SHOULD be supported when using certificates: 3076 o TLS_DH_RSA_WITH_AES_128_CBC_SHA 3078 o TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA 3080 The following algorithms MAY be supported when using certificates: 3082 o TLS_RSA_WITH_AES_256_CBC_SHA 3084 o TLS_DH_RSA_WITH_AES_256_CBC_SHA 3086 10.1.2. Authenticating with Preshared Keys 3088 Pre-shared keys present significant challenges from a security 3089 perspective, and for that reason, their use is strongly discouraged. 3090 However, [12] defines 3 different methods for authenticating with 3091 preshared keys: 3093 o PSK key exchange algorithm - simplest method, ciphersuites use 3094 only symmetric key algorithms 3096 o DHE_PSK key exchange algorithm - use a PSK to authenticate a 3097 Diffie-Hellman exchange. These ciphersuites give some additional 3098 protection against dictionary attacks and also provide Perfect 3099 Forward Secrecy (PFS). 3101 o RSA_PSK key exchange algorithm - use RSA and certificates to 3102 authenticate the server, in addition to using a PSK. Not 3103 susceptible to passive attacks. 3105 The first approach (plain PSK) is susceptible to passive dictionary 3106 attacks; hence, while this alorithm MAY be supported, special care 3107 should be taken when choosing that method. In particular, user- 3108 readable passphrases SHOULD NOT be used, and use of short PSKs should 3109 be strongly discouraged. Additionally, DHE_PSK MUST be supported, 3110 and RSA_PSK MAY be supported. 3112 The following cryptographic algorithms MUST be supported when using 3113 preshared keys: 3115 o TLS_DHE_PSK_WITH_AES_128_CBC_SHA 3117 o TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA 3119 The following algorithms SHOULD be supported when using preshared 3120 keys: 3122 o TLS_DHE_PSK_WITH_AES_256_CBC_SHA 3124 The following algorithms MAY be supported when using preshared keys: 3126 o TLS_PSK_WITH_AES_128_CBC_SHA 3128 o TLS_PSK_WITH_AES_256_CBC_SHA 3130 o TLS_PSK_WITH_3DES_EDE_CBC_SHA 3132 o TLS_RSA_PSK_WITH_AES_128_CBC_SHA 3134 o TLS_RSA_PSK_WITH_AES_256_CBC_SHA 3136 o TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA 3138 10.2. Refreshing Cryptographic Keys 3140 Since AC-WTP associations will tend to be relatively long-lived, a 3141 mechanism is provided to periodically refresh the encryption and 3142 authentication keys; this is referred to as "rekeying". When the key 3143 lifetime reaches 95% of the configured value, identified in the 3144 KeyLifetime timer (see Section 12), a new DTLS seesion SHOULD be 3145 initiated (via a CAPWAP implementation API). 3147 10.3. Certificate Usage 3149 Validation of the certificates by the AC and WTP is required so that 3150 only an AC may perform the functions of an AC and that only a WTP may 3151 perform the functions of a WTP. This restriction of functions to the 3152 AC or WTP requires that the certificates used by the AC MUST be 3153 distinguishable from the certificate used by the WTP. To accomplish 3154 this differentiation, the x.509v3 certificates MUST include the 3155 Extensions field [11] and MUST include the NetscapeComment [13] 3156 extension. 3158 For an AC, the value of the NetscapeComment extension MUST be the 3159 string "CAPWAP AC Device Certificate". For a WTP, the value of the 3160 NetscapeComment extension MUST be the string "CAPWAP WTP Device 3161 Certificate". 3163 Part of the CAPWAP certificate validation process includes ensuring 3164 that the proper string is included in the NetscapeComment extension, 3165 and only allowing the CAPWAP session to be established if the 3166 extension does not represent the same role as the device validating 3167 the certificate. For instance, a WTP MUST NOT accept a certificate 3168 whose NetscapeComment field is set to "CAPWAP WTP Device 3169 Certificate". 3171 11. IEEE 802.11 Binding 3173 This section defines the extensions required for the CAPWAP protocol 3174 to be used with the IEEE 802.11 protocol. 3176 11.1. Division of labor 3178 The CAPWAP protocol, when used with IEEE 802.11 devices, requires a 3179 specific behavior from the WTP and the AC, specifically in terms of 3180 which IEEE 802.11 protocol functions are handled. 3182 For both the Split and Local MAC approaches, the CAPWAP functions, as 3183 defined in the taxonomy specification, reside in the AC. 3185 11.1.1. Split MAC 3187 This section shows the division of labor between the WTP and the AC 3188 in a Split MAC architecture. Figure 4 shows the clear separation of 3189 functionality among CAPWAP components. 3191 Function Location 3192 Distribution Service AC 3193 Integration Service AC 3194 Beacon Generation WTP 3195 Probe Response WTP 3196 Power Mgmt/Packet Buffering WTP 3197 Fragmentation/Defragmentation WTP 3198 Assoc/Disassoc/Reassoc AC 3200 802.11e 3201 Classifying AC 3202 Scheduling WTP/AC 3203 Queuing WTP 3205 802.11i 3206 802.1X/EAP AC 3207 Key Management AC 3208 802.11 Encryption/Decryption WTP or AC 3210 Figure 4: Mapping of 802.11 Functions for Split MAC Architecture 3212 The Distribution and Integration services reside on the AC, and 3213 therefore all user data is tunneled between the WTP and the AC. As 3214 noted above, all real-time 802.11 services, including the control 3215 protocol and the beacon and probe response frames, are handled on the 3216 WTP. 3218 All remaining IEEE 802.11 MAC management frames are supported on the 3219 AC, including the Association Request which allows the AC to be 3220 involved in the access policy enforcement portion of the IEEE 802.11 3221 protocol. The IEEE 802.1X and IEEE 802.11i key management function 3222 are also located on the AC. 3224 While the admission control component of IEEE 802.11e resides on the 3225 AC, the real time scheduling and queuing functions are on the WTP. 3226 Note this does not exclude the AC from providing additional policing 3227 and scheduling functionality. 3229 Note that in the following figure, the use of '( - )' indicates that 3230 processing of the frames is done on the WTP. 3232 Client WTP AC 3234 Beacon 3235 <----------------------------- 3236 Probe Request 3237 ----------------------------( - )-------------------------> 3238 Probe Response 3239 <----------------------------- 3240 802.11 AUTH/Association 3241 <---------------------------------------------------------> 3242 Add Mobile (Clear Text, 802.1X Only) 3243 <-------------------------> 3244 802.1X Authentication & 802.11i Key Exchange 3245 <---------------------------------------------------------> 3246 Add Mobile (AES-CCMP, PTK=x) 3247 <-------------------------> 3248 802.11 Action Frames 3249 <---------------------------------------------------------> 3250 802.11 DATA (1) 3251 <---------------------------( - )-------------------------> 3253 Figure 5: Split MAC Message Flow 3255 Figure 5 provides an illustration of the division of labor in a Split 3256 MAC architecture. In this example, a WLAN has been created that is 3257 configured for IEEE 802.11i, using AES-CCMP for privacy. The 3258 following process occurs: 3260 o The WTP generates the IEEE 802.11 beacon frames, using information 3261 provided to it through the Add WLAN (see Section Section 11.8.1.1) 3262 message element. 3264 o The WTP processes the probe request and responds with a 3265 corresponding probe response. The probe request is then forwarded 3266 to the AC for optional processing. 3268 o The WTP forwards the IEEEE 802.11 Authentication and Association 3269 frames to the AC, which is responsible for responding to the 3270 client. 3272 o Once the association is complete, the AC transmits an CAPWAP Add 3273 Mobile request to the WTP (see Section Section 9.1.1. In the 3274 above example, the WLAN is configured for IEEE 802.1X, and 3275 therefore the '802.1X only' policy bit is enabled. 3277 o If the WTP is providing encryption/decryption services, once the 3278 client has completed the IEEE 802.11i key exchange, the AC 3279 transmits another Add Mobile request to the WTP, stating the 3280 security policy to enforce for the client (in this case AES-CCMP), 3281 as well as the encryption key to use. If encryption/decryption is 3282 handled in the AC, the Add Mobile request would have the 3283 encryption policy set to "Clear Text". 3285 o The WTP forwards any 802.11 Action frames received to the AC. 3287 o All client data frames are tunneled between the WTP and the AC. 3288 Note that the WTP is responsible for encrypting and decrypting 3289 frames, if it was indicated in the Add Mobile request. 3291 11.1.2. Local MAC 3293 This section shows the division of labor between the WTP and the AC 3294 in a Local MAC architecture. Figure 6 shows the clear separation of 3295 functionality among CAPWAP components. 3297 Function Location 3298 Distribution Service WTP 3299 Integration Service WTP 3300 Beacon Generation WTP 3301 Probe Response WTP 3302 Power Mgmt/Packet Buffering WTP 3303 Fragmentation/Defragmentation WTP 3304 Assoc/Disassoc/Reassoc WTP 3306 802.11e 3307 Classifying WTP 3308 Scheduling WTP 3309 Queuing WTP 3311 802.11i 3312 802.1X/EAP AC 3313 Key Management AC 3314 802.11 Encryption/Decryption WTP 3316 Figure 6: Mapping of 802.11 Functions for Local AP Architecture 3318 Given the Distribution and Integration Services exist on the WTP, 3319 client data frames are not forwarded to the AC, with the exception 3320 listed in the following paragraphs. 3322 While the MAC is terminated on the WTP, it is necessary for the AC to 3323 be aware of mobility events within the WTPs. As a consequence, the 3324 WTP MUST forward the IEEE 802.11 Association Requests to the AC, and 3325 the AC MAY reply with a failed Association Response if it deems it 3326 necessary. 3328 The IEEE 802.1X and IEEE 802.11i Key Management function resides in 3329 the AC. Therefore, the WTP MUST forward all IEEE 802.1X/Key 3330 Management frames to the AC and forward the associated responses to 3331 the station. 3333 Note that in the following figure, the use of '( - )' indicates that 3334 processing of the frames is done on the WTP. 3336 Client WTP AC 3338 Beacon 3339 <----------------------------- 3340 Probe 3341 <----------------------------> 3342 802.11 AUTH 3343 <----------------------------- 3344 802.11 Association 3345 <---------------------------( - )-------------------------> 3346 Add Mobile (Clear Text, 802.1X Only) 3347 <-------------------------> 3348 802.1X Authentication & 802.11i Key Exchange 3349 <---------------------------------------------------------> 3350 802.11 Action Frames 3351 <---------------------------------------------------------> 3352 Add Mobile (AES-CCMP, PTK=x) 3353 <-------------------------> 3354 802.11 DATA 3355 <-----------------------------> 3357 Figure 7: Local MAC Message Flow 3359 Figure 7 provides an illustration of the division of labor in a Local 3360 MAC architecture. In this example, a WLAN has been created that is 3361 configured for IEEE 802.11i, using AES-CCMP for privacy. The 3362 following process occurs: 3364 o The WTP generates the IEEE 802.11 beacon frames, using information 3365 provided to it through the Add WLAN (see Section 11.8.1.1) message 3366 element. 3368 o The WTP processes the probe request and responds with a 3369 corresponding probe response. 3371 o The WTP forwards the IEEE 802.11 Authentication and Association 3372 frames to the AC, which is responsible for responding to the 3373 client. 3375 o Once the association is complete, the AC transmits an CAPWAP Add 3376 Mobile request to the WTP (see Section Section 9.1.1. In the 3377 above example, the WLAN is configured for IEEE 802.1X, and 3378 therefore the '802.1X only' policy bit is enabled. 3380 o The WTP forwards all IEEE 802.1X and IEEE 802.11i key exchange 3381 messages to the AC for processing. 3383 o The AC transmits another Add Mobile request to the WTP, stating 3384 the security policy to enforce for the client (in this case AES- 3385 CCMP), as well as the encryption key to use. The Add Mobile 3386 request MAY include a VLAN name, which when present is used by the 3387 WTP to identify the VLAN on which the user's data frames are to be 3388 bridged. 3390 o The WTP forwards any IEEE 802.11 Action frames received to the AC. 3392 o The WTP optionally may tunnel client data frames to the AC. If 3393 client data frames are locally bridged, the WTP will need to 3394 provide the necessary encryption and decryption services. 3396 11.2. Roaming Behavior and 802.11 security 3398 It is important that CAPWAP implementations react properly to mobile 3399 devices associating to the networks in how they generate Add Mobile 3400 and Delete Mobile messages. This section expands upon the examples 3401 provided in the previous section, and describes how the CAPWAP 3402 control protocol is used in order to provide secure roaming. 3404 Once a client has successfully associated with the network in a 3405 secure fashion, it is likely to attempt to roam to another access 3406 point. Figure 8 shows an example of a currently associated station 3407 moving from its "Old WTP" to a new WTP. The figure is useful for 3408 multiple different security policies, including standard IEEE 802.1X 3409 and dynamic WEP keys, WPA or even WPA2 both with key caching (where 3410 the IEEE 802.1x exchange would be bypassed) and without. 3412 Client Old WTP WTP AC 3414 Association Request/Response 3415 <--------------------------------------( - )--------------> 3416 Add Mobile (Clear Text, 802.1X Only) 3417 <----------------> 3418 802.1X Authentication (if no key cache entry exists) 3419 <--------------------------------------( - )--------------> 3420 802.11i 4-way Key Exchange 3421 <--------------------------------------( - )--------------> 3422 Delete Mobile 3423 <----------------------------------> 3424 Add Mobile (AES-CCMP, PTK=x) 3425 <----------------> 3427 Figure 8: Client Roaming Example 3429 11.3. Transport specific bindings 3431 All CAPWAP transports have the following IEEE 802.11 specific 3432 bindings: 3434 11.3.1. Payload encapsulation 3436 The CAPWAP protocol defines the data frame, which allows a wireless 3437 payload to be encapsulated. For IEEE 802.11, the IEEE 802.11 header 3438 and payload is encapsulated (excluding the IEEE 802.11 FCS checksum). 3439 The IEEE 802.11 FCS checksum is handled by the WTP. This allows the 3440 WTP to validate a frame prior to sending it to the AC. Similarly, 3441 when an AC wishes to transmit a frame towards a station, the WTP 3442 computes and adds the FCS checksum. 3444 11.3.2. Status and WLANS field 3446 The interpretation of this 16 bit field depends on the direction of 3447 transmission of the packet. Refer to the figure in Section 4.1. 3449 Status 3451 When a CAPWAP packet is transmitted from a WTP to an AC, this field 3452 is called the status field and indicates radio resource information 3453 associated with the frame. When the message is a CAPWAP control 3454 message this field is transmitted as zero. 3456 The status field is divided into the signal strength and signal to 3457 noise ratio with which an IEEE 802.11 frame was received, encoded in 3458 the following manner: 3460 0 1 3461 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3463 | RSSI | SNR | 3464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3466 RSSI: RSSI is a signed, 8-bit value. It is the received signal 3467 strength indication, in dBm. 3469 SNR: SNR is a signed, 8-bit value. It is the signal to noise ratio 3470 of the received IEEE 802.11 frame, in dB. 3472 WLANs field: When a CAPWAP data message is transmitted from an AC to 3473 a WTP, this 16 bit field indicates on which WLANs the encapsulated 3474 IEEE 802.11 frame is to be transmitted. For unicast packets, this 3475 field is not used by the WTP. For broadcast or multicast packets, 3476 the WTP might require this information if it provides encryption 3477 services. 3479 Given that a single broadcast or multicast packet might need to be 3480 sent to multiple wireless LANs (presumably each with a different 3481 broadcast key), this field is defined as a bit field. A bit set 3482 indicates a WLAN ID (see Section Section 11.8.1.1) which will be 3483 sent the data. The WLANS field is encoded in the following 3484 manner: 3486 0 1 3487 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3489 | WLAN ID(s) | 3490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3492 11.4. BSSID to WLAN ID Mapping 3494 The CAPWAP protocol makes assumptions regarding the BSSIDs used on 3495 the WTP. It is a requirement for the WTP to use a contiguous block 3496 of BSSIDs. The WLAN Identifier field, which is managed by the AC, is 3497 used as an offset into the BSSID list. 3499 For instance, if a WTP had a base BSSID address of 00:01:02:00:00:00, 3500 and the AC sent an Add WLAN message with a WLAN Identifier of 2 (see 3501 Section Section 11.8.1.1), the BSSID for the specific WLAN on the WTP 3502 would be 00:01:02:00:00:02. 3504 The WTP communicates the maximum number of BSSIDs that it supports 3505 during the Config Request within the IEEE 802.11 WTP WLAN Radio 3506 Configuration message element (see Section 11.9.1). 3508 11.5. Quality of Service for Control Messages 3510 It is recommended that IEEE 802.11 MAC management frames be sent by 3511 both the AC and the WTP with appropriate Quality of Service values, 3512 ensuring that congestion in the network minimizes occurrences of 3513 packet loss. Therefore, a Quality of Service enabled CAPWAP device 3514 should use: 3516 802.1P: The precedence value of 6 SHOULD be used for all IEEE 802.11 3517 MAC management frames, except for Probe Requests which SHOULD use 3518 4. 3520 DSCP: The DSCP tag value of 46 SHOULD be used for all IEEE 802.11 3521 MAC management frames, except for Probe Requests which SHOULD use 3522 34. 3524 11.6. Data Message bindings 3526 There are no CAPWAP Data Message bindings for IEEE 802.11. 3528 11.7. Control Message bindings 3530 The IEEE 802.11 binding has the following Control Message 3531 definitions. 3533 11.7.1. Mobile Config Request 3535 This section contains the IEEE 802.11 specific message elements that 3536 are used with the Mobile Config Request. 3538 11.7.1.1. IEEE 802.11 Mobile 3540 The IEEE 802.11 Mobile message element accompanies the Add Mobile 3541 message element, and is used to push the IEEE 802.11 station policy. 3543 The latest IEEE 802.11 Mobile message element overrides any 3544 previously received message elements. If the IEEE 802.11 Mobile 3545 message element's EAP Only bit is set, the WTP MUST drop all IEEE 3546 802.11 packets that do not contain EAP packets. Note that when EAP 3547 Only is set, the Encryption Policy field MAY be set, and therefore it 3548 is possible to inform a WTP to only accept encrypted EAP packets. 3549 Once the mobile station has successfully completed EAP 3550 authentication, the AC must send a new Add Mobile message element to 3551 remove the EAP Only restriction, and optionally push the session key 3552 down to the WTP. 3554 If the QoS field is set, the WTP MUST observe and provide policing of 3555 the 802.11e priority tag to ensure that it does not exceed the value 3556 provided by the AC. 3558 0 1 2 3 3559 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 3560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3561 | Radio ID | Association ID | Flags | 3562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3563 | Capabilities | WLAN ID |Supported Rates 3564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3566 Type: TBD for Add IEEE 802.11 Mobile 3568 Length: >= 8 3570 Radio ID: An 8-bit value representing the radio 3572 Association ID: A 16-bit value specifying the IEEE 802.11 3573 Association Identifier 3575 MAC Address: The mobile station's MAC Address 3577 Capabilities: A 16-bit field containing the IEEE 802.11 capabilities 3578 to use with the mobile. 3580 WLAN ID: An 8-bit value specifying the WLAN Identifier 3582 Supported Rates: The variable length field containing the supported 3583 rates to be used with the mobile station. 3585 11.7.1.2. IEEE 802.11 Mobile Session Key 3587 The Mobile Session Key Payload message element is sent when the AC 3588 determines that encryption of a mobile station must be performed in 3589 the WTP. This message element MUST NOT be present without the IEEE 3590 802.11 Mobile (see Section 11.7.1.1) message element, and MUST NOT be 3591 sent if the WTP had not specifically advertised support for the 3592 requested encryption scheme. 3594 0 1 2 3 3595 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 3596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3597 | MAC Address | 3598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3599 | MAC Address |E|C| Flags | 3600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3601 | Encryption Policy | 3602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3603 | Pairwise TSC | 3604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3605 | Pairwise TSC | Pairwise RSC | 3606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3607 | Pairwise RSC | 3608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3609 | Session Key... 3610 +-+-+-+-+-+-+-+- 3612 Type: 105 for IEEE 802.11 Mobile Session Key 3614 Length: >= 25 3616 MAC Address: The mobile station's MAC Address 3618 Flags: A 16 bit field, whose unused bits MUST be set to zero. The 3619 following bits are defined: 3621 E: The one bit field is set by the AC to inform the WTP that is 3622 MUST NOT accept any 802.11 data frames, other than IEEE 802.1X 3623 frames. This is the equivalent of the WTP's IEEE 802.1X port 3624 for the mobile station to be in the closed state. When set, 3625 the WTP MUST drop any non-IEEE 802.1X packets it receives from 3626 the mobile station. 3628 C: The one bit field is set by the AC to inform the WTP that 3629 encryption services will be provided by the AC. When set, the 3630 WTP SHOULD police frames received from stations to ensure that 3631 they comply to the stated encryption policy, but does not need 3632 to take specific cryptographic action on the frame. Similarly, 3633 for transmitted frames, the WTP only needs to forward already 3634 encrypted frames. 3636 Encryption Policy: The policy field informs the WTP how to handle 3637 packets from/to the mobile station. The following values are 3638 supported: 3640 0 - Encrypt WEP 104: All packets to/from the mobile station must 3641 be encrypted using standard 104 bit WEP. 3643 1 - Clear Text: All packets to/from the mobile station do not 3644 require any additional crypto processing by the WTP. 3646 2 - Encrypt WEP 40: All packets to/from the mobile station must be 3647 encrypted using standard 40 bit WEP. 3649 3 - Encrypt WEP 128: All packets to/from the mobile station must 3650 be encrypted using standard 128 bit WEP. 3652 4 - Encrypt AES-CCMP 128: All packets to/from the mobile station 3653 must be encrypted using 128 bit AES CCMP [7] 3655 5 - Encrypt TKIP-MIC: All packets to/from the mobile station must 3656 be encrypted using TKIP and authenticated using Michael [21] 3658 Pairwise TSC: The 6 byte Transmit Sequence Counter (TSC) field to 3659 use for unicast packets transmitted to the mobile. 3661 Pairwise RSC: The 6 byte Receive Sequence Counter (RSC) to use for 3662 unicast packets received from the mobile. 3664 Session Key: The session key the WTP is to use when encrypting 3665 traffic to/from the mobile station. For dynamically created keys, 3666 this is commonly known as a Pairwise Transient Key (PTK). 3668 11.7.1.3. Station QoS Profile 3670 The Station QoS Profile Payload message element contains the maximum 3671 IEEE 802.11e priority tag that may be used by the station. Any 3672 packets received that exceeds the value encoded in this message 3673 element must either be dropped or tagged using the maximum value 3674 permitted by to the user. The priority tag must be between zero (0) 3675 and seven (7). 3677 0 1 2 3 3678 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 3679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3680 | MAC Address | 3681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3682 | MAC Address | 802.1P Precedence Tag | 3683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3685 Type: 140 for IEEE 802.11 Station QOS Profile 3687 Length: 8 3689 MAC Address: The mobile station's MAC Address 3691 802.1P Precedence Tag: The maximum 802.1P precedence value that the 3692 WTP will allow in the TID field in the extended 802.11e QOS Data 3693 header. 3695 11.7.1.4. IEEE 802.11 Update Mobile QoS 3697 The Update Mobile QoS message element is used to change the Quality 3698 of Service policy on the WTP for a given mobile station. 3700 0 1 2 3701 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 3702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3703 | Radio ID | MAC Address | 3704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3705 | MAC Address | DSCP Tag | 802.1P Tag | 3706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3708 Type: 106 for IEEE 802.11 Update Mobile QoS 3710 Length: 14 3712 Radio ID: The Radio Identifier, typically refers to some interface 3713 index on the WTP 3715 MAC Address: The mobile station's MAC Address. 3717 DSCP Tag: The DSCP label to use if packets are to be DSCP tagged. 3719 802.1P Tag: The 802.1P precedence value to use if packets are to be 3720 IEEE 802.1P tagged. 3722 11.7.2. WTP Event Request 3724 This section contains the 802.11 specific message elements that are 3725 used with the WTP Event Request message. 3727 11.7.2.1. IEEE 802.11 Statistics 3729 The statistics message element is sent by the WTP to transmit it's 3730 current statistics. The value contains the following fields. 3732 0 1 2 3 3733 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 3734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3735 | Radio ID | Reserved | 3736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3737 | Tx Fragment Count | 3738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3739 | Multicast Tx Count | 3740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3741 | Failed Count | 3742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3743 | Retry Count | 3744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3745 | Multiple Retry Count | 3746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3747 | Frame Duplicate Count | 3748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3749 | RTS Success Count | 3750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3751 | RTS Failure Count | 3752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3753 | ACK Failure Count | 3754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3755 | Rx Fragment Count | 3756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3757 | Multicast RX Count | 3758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3759 | FCS Error Count | 3760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3761 | Tx Frame Count | 3762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3763 | Decryption Errors | 3764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3766 Type: 38 for Statistics 3768 Length: 60 3770 Radio ID: An 8-bit value representing the radio. 3772 Tx Fragment Count: A 32-bit value representing the number of 3773 fragmented frames transmitted. 3775 Multicast Tx Count: A 32-bit value representing the number of 3776 multicast frames transmitted. 3778 Failed Count: A 32-bit value representing the transmit excessive 3779 retries. 3781 Retry Count: A 32-bit value representing the number of transmit 3782 retries. 3784 Multiple Retry Count: A 32-bit value representing the number of 3785 transmits that required more than one retry. 3787 Frame Duplicate Count: A 32-bit value representing the duplicate 3788 frames received. 3790 RTS Success Count: A 32-bit value representing the number of 3791 successfully transmitted Ready To Send (RTS). 3793 RTS Failure Count: A 32-bit value representing the failed 3794 transmitted RTS. 3796 ACK Failure Count: A 32-bit value representing the number of failed 3797 acknowledgements. 3799 Rx Fragment Count: A 32-bit value representing the number of 3800 fragmented frames received. 3802 Multicast RX Count: A 32-bit value representing the number of 3803 multicast frames received. 3805 FCS Error Count: A 32-bit value representing the number of FCS 3806 failures. 3808 Decryption Errors: A 32-bit value representing the number of 3809 Decryption errors that occurred on the WTP. Note that this field 3810 is only valid in cases where the WTP provides encryption/ 3811 decryption services. 3813 11.8. 802.11 Control Messages 3815 This section defines CAPWAP Control Messages that are specific to the 3816 IEEE 802.11 binding. 3818 11.8.1. IEEE 802.11 WLAN Config Request 3820 The IEEE 802.11 WLAN Configuration Request is sent by the AC to the 3821 WTP in order to change services provided by the WTP. This control 3822 message is used to either create, update or delete a WLAN on the WTP. 3824 The IEEE 802.11 WLAN Configuration Request is sent as a result of 3825 either some manual admistrative process (e.g., deleting a WLAN), or 3826 automatically to create a WLAN on a WTP. When sent automatically to 3827 create a WLAN, this control message is sent after the CAPWAP 3828 Configuration Request message has been received by the WTP. 3830 Upon receiving this control message, the WTP will modify the 3831 necessary services, and transmit an IEEE 802.11 WLAN Configuration 3832 Response. 3834 A WTP MAY provide service for more than one WLAN, therefore every 3835 WLAN is identified through a numerical index. For instance, a WTP 3836 that is capable of supporting up to 16 SSIDs, could accept up to 16 3837 IEEE 802.11 WLAN Configuration Request messages that include the Add 3838 WLAN message element. 3840 Since the index is the primary identifier for a WLAN, an AC SHOULD 3841 attempt to ensure that the same WLAN is identified through the same 3842 index number on all of its WTPs. An AC that does not follow this 3843 approach MUST find some other means of maintaining a WLAN Identifier 3844 to SSID mapping table. 3846 The following subsections define the message elements that are value 3847 for this CAPWAP operation. Only one message MUST be present. 3849 11.8.1.1. IEEE 802.11 Add WLAN 3851 The Add WLAN message element is used by the AC to define a wireless 3852 LAN on the WTP. The value contains the following format: 3854 0 1 2 3 3855 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 3856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3857 | Radio ID | WLAN Capability | WLAN ID | 3858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3859 | Encryption Policy | 3860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3861 | Key | 3862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3863 | Key | 3864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3865 | Key | 3866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3867 | Key | 3868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3869 | Key | 3870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3871 | Key | 3872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3873 | Key | 3874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3875 | Key | 3876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3877 | Key Index | Shared Key | WPA Data Len |WPA IE Data ...| 3878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3879 | RSN Data Len |RSN IE Data ...| WME Data Len |WME IE Data ...| 3880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3881 | 11e Data Len |11e IE Data ...| QoS | Auth Type | 3882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3883 | Suppress SSID | SSID ... 3884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3886 Type: 7 for IEEE 802.11 Add WLAN 3888 Length: >= 49 3890 Radio ID: An 8-bit value representing the radio. 3892 WLAN Capability: A 16-bit value containing the capabilities to be 3893 advertised by the WTP within the Probe and Beacon messages. 3895 WLAN ID: An 8-bit value specifying the WLAN Identifier. 3897 Encryption Policy: A 32-bit value specifying the encryption scheme 3898 to apply to traffic to and from the mobile station. 3900 The following values are supported: 3902 0 - Encrypt WEP 104: All packets to/from the mobile station must 3903 be encrypted using standard 104 bit WEP. 3905 1 - Clear Text: All packets to/from the mobile station do not 3906 require any additional crypto processing by the WTP. 3908 2 - Encrypt WEP 40: All packets to/from the mobile station must be 3909 encrypted using standard 40 bit WEP. 3911 3 - Encrypt WEP 128: All packets to/from the mobile station must 3912 be encrypted using standard 128 bit WEP. 3914 4 - Encrypt AES-CCMP 128: All packets to/from the mobile station 3915 must be encrypted using 128 bit AES CCMP [7] 3917 5 - Encrypt TKIP-MIC: All packets to/from the mobile station must 3918 be encrypted using TKIP and authenticated using Michael [21] 3920 6 - Encrypt CKIP: All packets to/from the mobile station must be 3921 encrypted using Cisco TKIP. 3923 Key: A 32 byte Session Key to use with the encryption policy. 3925 Key-Index: The Key Index associated with the key. 3927 Shared Key: A 1 byte boolean that specifies whether the key included 3928 in the Key field is a shared WEP key. A value of zero is used to 3929 state that the key is not a shared WEP key, while a value of one 3930 is used to state that the key is a shared WEP key. 3932 WPA Data Len: Length of the WPA IE. 3934 WPA IE: A 32 byte field containing the WPA Information Element. 3936 RSN Data Len: Length of the RSN IE. 3938 RSN IE: A 64 byte field containing the RSN Information Element. 3940 WME Data Len: Length of the WME IE. 3942 WME IE: A 32 byte field containing the WME Information Element. 3944 DOT11E Data Len: Length of the 802.11e IE. 3946 DOT11E IE: A 32 byte field containing the 802.11e Information 3947 Element. 3949 QOS: An 8-bit value specifying the QoS policy to enforce for the 3950 station. 3952 The following values are supported: 3954 0 - Best Effort 3956 1 - Video 3958 2 - Voice 3960 3 - Background 3962 Auth Type: An 8-bit value specifying the station's authentication 3963 type. 3965 The following values are supported: 3967 0 - Open System 3969 1 - WEP Shared Key 3971 2 - WPA/WPA2 802.1X 3973 3 - WPA/WPA2 PSK 3975 Supress SSID: A boolean indicating whether the SSID is to be 3976 advertised by the WTP. A value of zero supresses the SSID in the 3977 802.11 Beacon and Probe Response frames, while a value of one will 3978 cause the WTP to populate the field. 3980 SSID: The SSID attribute is the service set identifier that will be 3981 advertised by the WTP for this WLAN. 3983 11.8.1.2. IEEE 802.11 Delete WLAN 3985 The delete WLAN message element is used to inform the WTP that a 3986 previously created WLAN is to be deleted. The value contains the 3987 following fields: 3989 0 1 2 3990 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 3991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3992 | Radio ID | WLAN ID | 3993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3995 Type: 28 for IEEE 802.11 Delete WLAN 3997 Length: 3 3999 Radio ID: An 8-bit value representing the radio 4001 WLAN ID: A 16-bit value specifying the WLAN Identifier 4003 11.8.1.3. IEEE 802.11 Update WLAN 4005 The Update WLAN message element is used by the AC to define a 4006 wireless LAN on the WTP. The value contains the following format: 4008 0 1 2 3 4009 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 4010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4011 | Radio ID | WLAN ID |Encrypt Policy | 4012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4013 | Encryption Policy | Key... | 4014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4015 | Key ... | 4016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4017 | Key Index | Shared Key | WLAN Capability | 4018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4020 Type: 34 for IEEE 802.11 Update WLAN 4022 Length: 43 4024 Radio ID: An 8-bit value representing the radio. 4026 WLAN ID: A 16-bit value specifying the WLAN Identifier. 4028 Encryption Policy: A 32-bit value specifying the encryption scheme 4029 to apply to traffic to and from the mobile station. 4031 The following values are supported: 4033 0 - Encrypt WEP 104: All packets to/from the mobile station must 4034 be encrypted using standard 104 bit WEP. 4036 1 - Clear Text: All packets to/from the mobile station do not 4037 require any additional crypto processing by the WTP. 4039 2 - Encrypt WEP 40: All packets to/from the mobile station must be 4040 encrypted using standard 40 bit WEP. 4042 3 - Encrypt WEP 128: All packets to/from the mobile station must 4043 be encrypted using standard 128 bit WEP. 4045 4 - Encrypt AES-CCMP 128: All packets to/from the mobile station 4046 must be encrypted using 128 bit AES CCMP [7] 4048 5 - Encrypt TKIP-MIC: All packets to/from the mobile station must 4049 be encrypted using TKIP and authenticated using Michael [21] 4051 6 - Encrypt CKIP: All packets to/from the mobile station must be 4052 encrypted using Cisco TKIP. 4054 Key: A 32 byte Session Key to use with the encryption policy. 4056 Key-Index: The Key Index associated with the key. 4058 Shared Key: A 1 byte boolean that specifies whether the key included 4059 in the Key field is a shared WEP key. A value of zero means that 4060 the key is not a shared WEP key, while a value of one is used to 4061 state that the key is a shared WEP key. 4063 WLAN Capability: A 16-bit value containing the capabilities to be 4064 advertised by the WTP within the Probe and Beacon messages. 4066 11.8.2. IEEE 802.11 WLAN Config Response 4068 The IEEE 802.11 WLAN Configuration Response is sent by the AC to the 4069 WTP as an acknowledgement of the receipt of an IEEE 802.11 WLAN 4070 Configuration Request. 4072 This CAPWAP control message does not include any message elements. 4074 11.8.3. IEEE 802.11 WTP Event 4076 The IEEE 802.11 WTP Event CAPWAP message is used by the WTP in order 4077 to report asynchronous events to the AC. There is no reply message 4078 expected from the AC, except that the message is acknowledged via the 4079 reliable transport. 4081 When the AC receives the IEEE 802.11 WTP Event, it will take whatever 4082 action is necessary, depending upon the message elements present in 4083 the message. 4085 The IEEE 802.11 WTP Event message MUST contain one of the following 4086 message element described in the next subsections. 4088 11.8.3.1. IEEE 802.11 MIC Countermeasures 4090 The MIC Countermeasures message element is sent by the WTP to the AC 4091 to indicate the occurrence of a MIC failure. 4093 0 1 2 3 4094 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 4095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4096 | Radio ID | WLAN ID | MAC Address | 4097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4098 | MAC Address | 4099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4101 Type: 61 for IEEE 802.11 MIC Countermeasures 4103 Length: 8 4105 Radio ID: The Radio Identifier, typically refers to some interface 4106 index on the WTP. 4108 WLAN ID: This 8-bit unsigned integer includes the WLAN Identifier, 4109 on which the MIC failure occurred. 4111 MAC Address: The MAC Address of the mobile station that caused the 4112 MIC failure. 4114 11.8.3.2. IEEE 802.11 WTP Radio Fail Alarm Indication 4116 The WTP Radio Fail Alarm Indication message element is sent by the 4117 WTP to the AC when it detects a radio failure. 4119 0 1 2 3 4120 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 4121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4122 | Radio ID | Type | Status | Pad | 4123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4125 Type: 95 for WTP Radio Fail Alarm Indication 4127 Length: 4 4129 Radio ID: The Radio Identifier, typically refers to some interface 4130 index on the WTP 4132 Type: The type of radio failure detected. The following values are 4133 supported: 4135 1 - Receiver 4137 2 - Transmitter 4139 Status: An 8-bit boolean indicating whether the radio failure is 4140 being reported or cleared. A value of zero is used to clear the 4141 event, while a value of one is used to report the event. 4143 Pad: Reserved field MUST be set to zero (0). 4145 11.9. Message Element Bindings 4147 The IEEE 802.11 Message Element binding has the following 4148 definitions: 4150 Conf Conf Conf Add 4151 Req Resp Upd Mobile 4153 IEEE 802.11 WTP WLAN Radio Configuration X X X 4154 IEEE 802.11 Rate Set X X 4155 IEEE 802.11 Multi-domain Capability X X X 4156 IEEE 802.11 MAC Operation X X X 4157 IEEE 802.11 Tx Power X X X 4158 IEEE 802.11 Tx Power Level X 4159 IEEE 802.11 Direct Sequence Control X X X 4160 IEEE 802.11 OFDM Control X X X 4161 IEEE 802.11 Supported Rates X X 4162 IEEE 802.11 Antenna X X X 4163 IEEE 802.11 CFP Status X X 4164 IEEE 802.11 Broadcast Probe Mode X X 4165 IEEE 802.11 WTP Mode and Type X? X 4166 IEEE 802.11 WTP Quality of Service X X 4167 IEEE 802.11 MIC Error Report From Mobile X 4168 IEEE 802.11 Update Mobile QoS X 4169 IEEE 802.11 Mobile Session Key X 4171 11.9.1. IEEE 802.11 WTP WLAN Radio Configuration 4173 The WTP WLAN radio configuration is used by the AC to configure a 4174 Radio on the WTP. The message element value contains the following 4175 Fields: 4177 0 1 2 3 4178 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 4179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4180 | Radio ID | Reserved | Occupancy Limit | 4181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4182 | CFP Per | CFP Maximum Duration | BSS ID | 4183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4184 | BSS ID | 4185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4186 | BSS ID | Beacon Period | DTIM Per | 4187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4188 | Country String | 4189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4190 | Num Of BSSIDs | 4191 +-+-+-+-+-+-+-+-+ 4193 Type: 8 for IEEE 802.11 WTP WLAN Radio Configuration 4195 Length: 20 4197 Radio ID: An 8-bit value representing the radio to configure. 4199 Reserved: MUST be set to zero 4201 Occupancy Limit: This attribute indicates the maximum amount of 4202 time, in TU, that a point coordinator MAY control the usage of the 4203 wireless medium without relinquishing control for long enough to 4204 allow at least one instance of DCF access to the medium. The 4205 default value of this attribute SHOULD be 100, and the maximum 4206 value SHOULD be 1000. 4208 CFP Period: The attribute describes the number of DTIM intervals 4209 between the start of CFPs. 4211 CFP Maximum Duration: The attribute describes the maximum duration 4212 of the CFP in TU that MAY be generated by the PCF. 4214 BSSID: The WLAN Radio's base MAC Address. For WTPs that support 4215 more than a single WLAN, the value of the WLAN Identifier is added 4216 to the last octet of the BSSID. Therefore, a WTP that supports 16 4217 WLANs MUST have 16 MAC Addresses reserved for it, and the last 4218 nibble is used to represent the WLAN ID. 4220 Beacon Period: This attribute specifies the number of TU that a 4221 station uses for scheduling Beacon transmissions. This value is 4222 transmitted in Beacon and Probe Response frames. 4224 DTIM Period: This attribute specifies the number of beacon intervals 4225 that elapses between transmission of Beacons frames containing a 4226 TIM element whose DTIM Count field is 0. This value is 4227 transmitted in the DTIM Period field of Beacon frames. 4229 Country Code: This attribute identifies the country in which the 4230 station is operating. The first two octets of this string is the 4231 two character country code as described in document ISO/IEC 3166- 4232 1. The third octet MUST be one of the following: 4234 1. an ASCII space character, if the regulations under which the 4235 station is operating encompass all environments in the country, 4237 2. an ASCII 'O' character, if the regulations under which the 4238 station is operating are for an outdoor environment only, or 4240 3. an ASCII 'I' character, if the regulations under which the 4241 station is operating are for an indoor environment only 4243 Number of BSSIDs: This attribute contains the maximum number of 4244 BSSIDs supported by the WTP. This value restricts the number of 4245 logical networks supported by the WTP, and is between 1 and 16. 4247 11.9.2. IEEE 802.11 Rate Set 4249 The rate set message element value is sent by the AC and contains the 4250 supported operational rates. It contains the following fields. 4252 0 1 2 3 4253 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 4254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4255 | Radio ID | Rate Set... 4256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4258 Type: 16 for IEEE 802.11 Rate Set 4260 Length: >= 3 4262 Radio ID: An 8-bit value representing the radio to configure. 4264 Rate Set: The AC generates the Rate Set that the WTP is to include 4265 in it's Beacon and Probe messages. The length of this field is 4266 between 2 and 8 bytes. 4268 11.9.3. IEEE 802.11 Multi-domain Capability 4270 The multi-domain capability message element is used by the AC to 4271 inform the WTP of regulatory limits. The value contains the 4272 following fields. 4274 0 1 2 3 4275 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 4276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4277 | Radio ID | Reserved | First Channel # | 4278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4279 | Number of Channels | Max Tx Power Level | 4280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4282 Type: 10 for IEEE 802.11 Multi-Domain Capability 4284 Length: 8 4286 Radio ID: An 8-bit value representing the radio to configure. 4288 Reserved: MUST be set to zero 4290 First Channnel #: This attribute indicates the value of the lowest 4291 channel number in the subband for the associated domain country 4292 string. 4294 Number of Channels: This attribute indicates the value of the total 4295 number of channels allowed in the subband for the associated 4296 domain country string. 4298 Max Tx Power Level: This attribute indicates the maximum transmit 4299 power, in dBm, allowed in the subband for the associated domain 4300 country string. 4302 11.9.4. IEEE 802.11 MAC Operation 4304 The MAC operation message element is sent by the AC to set the 802.11 4305 MAC parameters on the WTP. The value contains the following fields. 4307 0 1 2 3 4308 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 4309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4310 | Radio ID | Reserved | RTS Threshold | 4311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4312 | Short Retry | Long Retry | Fragmentation Threshold | 4313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4314 | Tx MSDU Lifetime | 4315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4316 | Rx MSDU Lifetime | 4317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4319 Type: 11 for IEEE 802.11 MAC Operation 4321 Length: 16 4323 Radio ID: An 8-bit value representing the radio to configure. 4325 Reserved: MUST be set to zero 4327 RTS Threshold: This attribute indicates the number of octets in an 4328 MPDU, below which an RTS/CTS handshake MUST NOT be performed. An 4329 RTS/CTS handshake MUST be performed at the beginning of any frame 4330 exchange sequence where the MPDU is of type Data or Management, 4331 the MPDU has an individual address in the Address1 field, and the 4332 length of the MPDU is greater than this threshold. Setting this 4333 attribute to be larger than the maximum MSDU size MUST have the 4334 effect of turning off the RTS/CTS handshake for frames of Data or 4335 Management type transmitted by this STA. Setting this attribute 4336 to zero MUST have the effect of turning on the RTS/CTS handshake 4337 for all frames of Data or Management type transmitted by this STA. 4338 The default value of this attribute MUST be 2347. 4340 Short Retry: This attribute indicates the maximum number of 4341 transmission attempts of a frame, the length of which is less than 4342 or equal to RTSThreshold, that MUST be made before a failure 4343 condition is indicated. The default value of this attribute MUST 4344 be 7. 4346 Long Retry: This attribute indicates the maximum number of 4347 transmission attempts of a frame, the length of which is greater 4348 than dot11RTSThreshold, that MUST be made before a failure 4349 condition is indicated. The default value of this attribute MUST 4350 be 4. 4352 Fragmentation Threshold: This attribute specifies the current 4353 maximum size, in octets, of the MPDU that MAY be delivered to the 4354 PHY. An MSDU MUST be broken into fragments if its size exceeds 4355 the value of this attribute after adding MAC headers and trailers. 4356 An MSDU or MMPDU MUST be fragmented when the resulting frame has 4357 an individual address in the Address1 field, and the length of the 4358 frame is larger than this threshold. The default value for this 4359 attribute MUST be the lesser of 2346 or the aMPDUMaxLength of the 4360 attached PHY and MUST never exceed the lesser of 2346 or the 4361 aMPDUMaxLength of the attached PHY. The value of this attribute 4362 MUST never be less than 256. 4364 Tx MSDU Lifetime: This attribute speficies the elapsed time in TU, 4365 after the initial transmission of an MSDU, after which further 4366 attempts to transmit the MSDU MUST be terminated. The default 4367 value of this attribute MUST be 512. 4369 Rx MSDU Lifetime: This attribute specifies the elapsed time in TU, 4370 after the initial reception of a fragmented MMPDU or MSDU, after 4371 which further attempts to reassemble the MMPDU or MSDU MUST be 4372 terminated. The default value MUST be 512. 4374 11.9.5. IEEE 802.11 Tx Power 4376 The Tx power message element value is bi-directional. When sent by 4377 the WTP, it contains the current power level of the radio in 4378 question. When sent by the AC, it contains the power level the WTP 4379 MUST adhere to. 4381 0 1 2 3 4382 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 4383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4384 | Radio ID | Reserved | Current Tx Power | 4385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4387 Type: 12 for IEEE 802.11 Tx Power 4389 Length: 4 4391 Radio ID: An 8-bit value representing the radio to configure. 4393 Reserved: MUST be set to zero 4395 Current Tx Power: This attribute contains the transmit output power 4396 in mW. 4398 11.9.6. IEEE 802.11 Tx Power Level 4400 The Tx power level message element is sent by the WTP and contains 4401 the different power levels supported. The value contains the 4402 following fields. 4404 0 1 2 3 4405 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 4406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4407 | Radio ID | Num Levels | Power Level [n] | 4408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4410 Type: 13 for IEEE 802.11 Tx Power Level 4412 Length: >= 4 4414 Radio ID: An 8-bit value representing the radio to configure. 4416 Num Levels: The number of power level attributes. 4418 Power Level: Each power level fields contains a supported power 4419 level, in mW. 4421 11.9.7. IEEE 802.11 Direct Sequence Control 4423 The direct sequence control message element is a bi-directional 4424 element. When sent by the WTP, it contains the current state. When 4425 sent by the AC, the WTP MUST adhere to the values. This element is 4426 only used for 802.11b radios. The value has the following fields. 4428 0 1 2 3 4429 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 4430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4431 | Radio ID | Reserved | Current Chan | Current CCA | 4432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4433 | Energy Detect Threshold | 4434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4436 Type: 14 for IEEE 802.11 Direct Sequence Control 4438 Length: 8 4440 Radio ID: An 8-bit value representing the radio to configure. 4442 Reserved: MUST be set to zero 4444 Current Channel: This attribute contains the current operating 4445 frequency channel of the DSSS PHY. 4447 Current CCA: The current CCA method in operation. Valid values are: 4449 1 - energy detect only (edonly) 4451 2 - carrier sense only (csonly) 4453 4 - carrier sense and energy detect (edandcs) 4454 8 - carrier sense with timer (cswithtimer) 4456 16 - high rate carrier sense and energy detect (hrcsanded) 4458 Energy Detect Threshold: The current Energy Detect Threshold being 4459 used by the DSSS PHY. 4461 11.9.8. IEEE 802.11 OFDM Control 4463 The OFDM control message element is a bi-directional element. When 4464 sent by the WTP, it contains the current state. When sent by the AC, 4465 the WTP MUST adhere to the values. This element is only used for 4466 802.11a radios. The value contains the following fields: 4468 0 1 2 3 4469 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 4470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4471 | Radio ID | Reserved | Current Chan | Band Support | 4472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4473 | TI Threshold | 4474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4476 Type: 15 for IEEE 802.11 OFDM Control 4478 Length: 8 4480 Radio ID: An 8-bit value representing the radio to configure. 4482 Reserved: MUST be set to zero 4484 Current Channel: This attribute contains the current operating 4485 frequency channel of the OFDM PHY. 4487 Band Supported: The capability of the OFDM PHY implementation to 4488 operate in the three U-NII bands. Coded as an integer value of a 4489 three bit field as follows: 4491 capable of operating in the lower (5.15-5.25 GHz) U-NII band 4493 capable of operating in the middle (5.25-5.35 GHz) U-NII band 4495 capable of operating in the upper (5.725-5.825 GHz) U-NII band 4497 For example, for an implementation capable of operating in the 4498 lower and mid bands this attribute would take the value 4500 TI Threshold: The Threshold being used to detect a busy medium 4501 (frequency). CCA MUST report a busy medium upon detecting the 4502 RSSI above this threshold. 4504 11.9.9. IEEE 802.11 Antenna 4506 The antenna message element is communicated by the WTP to the AC to 4507 provide information on the antennas available. The AC MAY use this 4508 element to reconfigure the WTP's antennas. The value contains the 4509 following fields: 4511 0 1 2 3 4512 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 4513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4514 | Radio ID | Diversity | Combiner | Antenna Cnt | 4515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4516 | Antenna Selection [0..N] | 4517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4519 Type: 41 for IEEE 802.11 Antenna 4521 Length: >= 5 4523 Radio ID: An 8-bit value representing the radio to configure. 4525 Diversity: An 8-bit value specifying whether the antenna is to 4526 provide receive diversity. The following values are supported: 4528 0 - Disabled 4530 1 - Enabled (may only be true if the antenna can be used as a 4531 receive antenna) 4533 Combiner: An 8-bit value specifying the combiner selection. The 4534 following values are supported: 4536 1 - Sectorized (Left) 4538 2 - Sectorized (Right) 4540 3 - Omni 4542 4 - Mimo 4544 Antenna Count: An 8-bit value specifying the number of Antenna 4545 Selection fields. 4547 Antenna Selection: One 8-bit antenna configuration value per antenna 4548 in the WTP. The following values are supported: 4550 1 - Internal Antenna 4552 2 - External Antenna 4554 11.9.10. IEEE 802.11 Supported Rates 4556 The supported rates message element is sent by the WTP to indicate 4557 the rates that it supports. The value contains the following fields. 4559 0 1 2 3 4560 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 4561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4562 | Radio ID | Supported Rates... 4563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4565 Type: 16 for IEEE 802.11 Supported Rates 4567 Length: >= 3 4569 Radio ID: An 8-bit value representing the radio. 4571 Supported Rates: The WTP includes the Supported Rates that it's 4572 hardware supports. The format is identical to the Rate Set 4573 message element and is between 2 and 8 bytes in length. 4575 11.9.11. IEEE 802.11 CFP Status 4577 The CFP Status message element is sent to provide the CF Polling 4578 configuration. 4580 0 1 4581 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 4582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4583 | Radio ID | Status | 4584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4586 Type: 48 for IEEE 802.11 CFP Status 4588 Length: 2 4589 Radio ID: The Radio Identifier, typically refers to some interface 4590 index on the WTP 4592 Status: An 8-bit boolean containing the status of the CF Polling 4593 feature. A value of zero disables CFP Status, while a value of 4594 one enables it. 4596 11.9.12. IEEE 802.11 Broadcast Probe Mode 4598 The Broadcast Probe Mode message element indicates whether a WTP will 4599 respond to NULL SSID probe requests. Since broadcast NULL probes are 4600 not sent to a specific BSSID, the WTP cannot know which SSID the 4601 sending station is querying. Therefore, this behavior must be global 4602 to the WTP. 4604 0 4605 0 1 2 3 4 5 6 7 4606 +-+-+-+-+-+-+-+-+ 4607 | Status | 4608 +-+-+-+-+-+-+-+-+ 4610 Type: 51 for IEEE 802.11 Broadcast Probe Mode 4612 Length: 1 4614 Status: An 8-bit boolean indicating the status of whether a WTP 4615 shall response to a NULL SSID probe request. A value of zero 4616 disables NULL SSID probe response, while a value of one enables 4617 it. 4619 11.9.13. IEEE 802.11 WTP Quality of Service 4621 The WTP Quality of Service message element value is sent by the AC to 4622 the WTP to communicate quality of service configuration information. 4624 0 1 4625 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 4626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4627 | Radio ID | Tag Packets | 4628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4630 Type: 57 for IEEE 802.11 WTP Quality of Service 4632 Length: >= 2 4633 Radio ID: The Radio Identifier, typically refers to some interface 4634 index on the WTP 4636 Tag Packets: An value indicating whether CAPWAP packets should be 4637 tagged with for QoS purposes. The following values are currently 4638 supported: 4640 0 - Untagged 4642 1 - 802.1P 4644 2 - DSCP 4646 Immediately following the above header is the following data 4647 structure. This data structure will be repeated five times; once 4648 for every QoS profile. The order of the QoS profiles are Voice, 4649 Video, Best Effort and Background. 4651 0 1 2 3 4652 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 4653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4654 | Queue Depth | CWMin | CWMax | 4655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4656 | CWMax | AIFS | CBR | 4657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4658 | Dot1P Tag | DSCP Tag | 4659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4661 Queue Depth: The number of packets that can be on the specific QoS 4662 transmit queue at any given time. 4664 CWMin: The Contention Window minimum value for the QoS transmit 4665 queue. 4667 CWMax: The Contention Window maximum value for the QoS transmit 4668 queue. 4670 AIFS: The Arbitration Inter Frame Spacing to use for the QoS 4671 transmit queue. 4673 CBR: The CBR value to observe for the QoS transmit queue. 4675 Dot1P Tag: The 802.1P precedence value to use if packets are to be 4676 802.1P tagged. 4678 DSCP Tag: The DSCP label to use if packets are to be DSCP tagged. 4680 11.9.14. IEEE 802.11 MIC Error Report From Mobile 4682 The MIC Error Report From Mobile message element is sent by an AC to 4683 an WTP when it receives a MIC failure notification, via the Error bit 4684 in the EAPOL-Key frame. 4686 0 1 2 3 4687 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 4688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4689 | Client MAC Address | 4690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4691 | Client MAC Address | BSSID | 4692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4693 | BSSID | 4694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4695 | Radio ID | WLAN ID | 4696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4698 Type: 79 for IEEE 802.11 MIC Error Report From Mobile 4700 Length: 14 4702 Client MAC Address: The Client MAC Address of the station reporting 4703 the MIC failure. 4705 BSSID: The BSSID on which the MIC failure is being reported. 4707 Radio ID: The Radio Identifier, typically refers to some interface 4708 index on the WTP 4710 WLAN ID: The WLAN ID on which the MIC failure is being reported. 4712 11.10. IEEE 802.11 Message Element Values 4714 This section lists IEEE 802.11 specific values for any generic CAPWAP 4715 message elements which include fields whose values are technology 4716 specific. 4718 IEEE 802.11 uses the following values: 4720 4 - Encrypt AES-CCMP 128: WTP supports AES-CCMP, as defined in [7]. 4722 5 - Encrypt TKIP-MIC: WTP supports TKIP and Michael, as defined in 4723 [21]. 4725 12. CAPWAP Protocol Timers 4727 A WTP or AC that implements CAPWAP discovery MUST implement the 4728 following timers. 4730 12.1. MaxDiscoveryInterval 4732 The maximum time allowed between sending discovery requests from the 4733 interface, in seconds. Must be no less than 2 seconds and no greater 4734 than 180 seconds. 4736 Default: 20 seconds. 4738 12.2. SilentInterval 4740 The minimum time, in seconds, a WTP MUST wait after failing to 4741 receive any responses to its discovery requests, before it MAY again 4742 send discovery requests. 4744 Default: 30 4746 12.3. NeighborDeadInterval 4748 The minimum time, in seconds, a WTP MUST wait without having received 4749 Echo Responses to its Echo Requests, before the destination for the 4750 Echo Request may be considered dead. Must be no less than 4751 2*EchoInterval seconds and no greater than 240 seconds. 4753 Default: 60 4755 12.4. WaitJoin 4757 The maximum time, in seconds, a WTP MUST wait without having received 4758 a DTLS Handshake message from an AC. This timer must be greater than 4759 TBD seconds. 4761 Default: TBD 4763 12.5. EchoInterval 4765 The minimum time, in seconds, between sending echo requests to the AC 4766 with which the WTP has joined. 4768 Default: 30 4770 12.6. DiscoveryInterval 4772 The minimum time, in seconds, that a WTP MUST wait after receiving a 4773 Discovery Response, before initiating a DTLS handshake. 4775 Default: 5 4777 12.7. RetransmitInterval 4779 The minimum time, in seconds, which a non-acknowledged CAPWAP packet 4780 will be retransmitted. 4782 Default: 3 4784 12.8. ResponseTimeout 4786 The minimum time, in seconds, which the WTP or AC must respond to a 4787 CAPWAP Request message. 4789 Default: 1 4791 12.9. KeyLifetime 4793 The maximum time, in seconds, which a CAPWAP DTLS session key is 4794 valid. 4796 Default: 28800 4798 13. CAPWAP Protocol Variables 4800 A WTP or AC that implements CAPWAP discovery MUST allow for the 4801 following variables to be configured by system management; default 4802 values are specified so as to make it unnecessary to configure any of 4803 these variables in many cases. 4805 13.1. MaxDiscoveries 4807 The maximum number of discovery requests that will be sent after a 4808 WTP boots. 4810 Default: 10 4812 13.2. DiscoveryCount 4814 The number of discoveries transmitted by a WTP to a single AC. This 4815 is a monotonically increasing counter. 4817 13.3. RetransmitCount 4819 The number of retransmissions for a given CAPWAP packet. This is a 4820 monotonically increasing counter. 4822 13.4. MaxRetransmit 4824 The maximum number of retransmissions for a given CAPWAP packet 4825 before the link layer considers the peer dead. 4827 Default: 5 4829 14. NAT Considerations 4831 There are two specific situations in which a NAT system may be used 4832 in conjunction with a CAPWAP-enabled system. The first consists of a 4833 configuration where the WTP is behind a NAT system. Given that all 4834 communication is initiated by the WTP, and all communication is 4835 performed over IP using two UDP ports, the protocol easily traverses 4836 NAT systems in this configuration. 4838 The second configuration is one where the AC sits behind a NAT. Two 4839 issues exist in this situation. First, an AC communicates its 4840 interfaces, and associated WTP load on these interfaces, through the 4841 WTP Manager Control IP Address. This message element is currently 4842 mandatory, and if NAT compliance became an issue, it would be 4843 possible to either: 4845 1. Make the WTP Manager Control IP Address optional, allowing the WTP 4846 to simply use the known IP Address. However, note that this 4847 approach would eliminate the ability to perform load balancing of 4848 WTP across ACs, and therefore is not the recommended approach. 4850 2. Allow an AC to be able to configure a NAT'ed address for every 4851 associated AC that would generally be communicated in the WTP 4852 Manager Control IP Address message element. 4854 3. Require that if a WTP determines that the AC List message element 4855 consists of a set of IP Addresses that are different from the AC's 4856 IP Address it is currently communicating with, then assume that 4857 NAT is being enforced, and require that the WTP communicate with 4858 the original AC's IP Address (and ignore the WTP Manager Control 4859 IP Address message element(s)). 4861 Another issue related to having an AC behind a NAT system is CAPWAP's 4862 support for the CAPWAP Objective to allow the control and data plane 4863 to be separated. In order to support this requirement, the CAPWAP 4864 protocol defines the WTP Manager Data IP Address message element, 4865 which allows the AC to inform the WTP that the CAPWAP data frames are 4866 to be forwarded to a separate IP Address. This feature MUST be 4867 disabled when an AC is behind a NAT. However, there is no easy way 4868 to provide some default mechanism that satisfies both the data/ 4869 control separation and NAT objectives, as they directly conflict with 4870 each other. As a consequence, user intervention will be required to 4871 support such networks. 4873 The CAPWAP protocol allows for all of the ACs identities supporting a 4874 group of WTPs to be communicated through the AC List message element. 4875 This feature must be disabled when the AC is behind a NAT and the IP 4876 Address that is embedded would be invalid. 4878 The CAPWAP protocol has a feature that allows an AC to configure a 4879 static IP address on a WTP. The WTP Static IP Address Information 4880 message element provides such a function, however this feature SHOULD 4881 NOT be used in NAT'ed environments, unless the administrator is 4882 familiar with the internal IP addressing scheme within the WTP's 4883 private network, and does not rely on the public address seen by the 4884 AC. 4886 When a WTP detects the duplicate address condition, it generates a 4887 message to the AC, which includes the Duplicate IP Address message 4888 element. The IP Address embedded within this message element is 4889 different from the public IP address seen by the AC. 4891 15. Security Considerations 4893 The security of the CAPWAP protocol over DTLS is completely dependent 4894 on the security of DTLS. Any flaws in DTLS compromise the security 4895 of the CAPWAP protocol. In particular, it is critical that the 4896 communicating parties verify their peer's credentials. In the case 4897 of pre-shared keys, this happens automatically via the key. In the 4898 case of certificates, the parties must check the peer's certificate. 4899 The appropriate checks are described in Section 10.3. 4901 The use of parallel protected and unprotected channels deserves 4902 special consideration, but does not create a threat. There are two 4903 potential concerns: attempting to convert protected data into un- 4904 protected data and attempting to convert un-protected data into 4905 protected data. The use of message authentication makes it 4906 impossible for the attacker to forge protected records. The attacker 4907 can easily remove protected records from the stream (this is a 4908 consequence of unreliability), though not undetectably so. If a non- 4909 encrypted cipher suite is in use, the attacker can turn such a record 4910 into an un-protected record. However, this attack is really no 4911 different from simple injection into the unprotected stream. 4913 Perfect Forward Secrecy is not a requirement for the CAPWAP protocol. 4915 The CAPWAP protocol does not add any new vulnerabilities to IEEE 4916 802.11 infrastructure which uses WEP for encryption. However, 4917 implementors SHOULD discourage the use of WEP to allow the market to 4918 move towards technically sound cryptographic solutions, such as IEEE 4919 802.11i. 4921 15.1. PSK based Session Key establishment 4923 Use of a fixed shared secret of limited entropy (for example, a PSK 4924 that is relatively short, or was chosen by a human and thus may 4925 contain less entropy than its length would imply) may allow an 4926 attacker to perform a brute-force or dictionary attack to recover the 4927 secret. 4929 It is RECOMMENDED that implementations that allow the administrator 4930 to manually configure the PSK also provide a functionality for 4931 generating a new random PSK, taking RFC 1750 [4] into account. 4933 16. IANA Considerations 4935 A separate UDP port for data channel communications is (currently) 4936 the selected demultiplexing mechanism, and a port must be assigned 4937 for this purpose. 4939 The Message element type fields must be IANA aassigned, see 4940 Section 4.3.2. 4942 17. References 4944 17.1. Normative References 4946 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 4947 Levels", BCP 14, RFC 2119, March 1997. 4949 [2] National Institute of Standards and Technology, "Advanced 4950 Encryption Standard (AES)", FIPS PUB 197, November 2001, 4951 . 4953 [3] Whiting, D., Housley, R., and N. Ferguson, "Counter with CBC- 4954 MAC (CCM)", RFC 3610, September 2003. 4956 [4] Eastlake, D., Crocker, S., and J. Schiller, "Randomness 4957 Recommendations for Security", RFC 1750, December 1994. 4959 [5] Manner, J. and M. Kojo, "Mobility Related Terminology", 4960 RFC 3753, June 2004. 4962 [6] "Information technology - Telecommunications and information 4963 exchange between systems - Local and metropolitan area networks 4964 - Specific requirements - Part 11: Wireless LAN Medium Access 4965 Control (MAC) and Physical Layer (PHY) specifications", 4966 IEEE Standard 802.11, 1999, 4967 . 4970 [7] "Information technology - Telecommunications and information 4971 exchange between systems - Local and metropolitan area networks 4972 - Specific requirements - Part 11: Wireless LAN Medium Access 4973 Control (MAC) and Physical Layer (PHY) specifications Amendment 4974 6: Medium Access Control (MAC) Security Enhancements", 4975 IEEE Standard 802.11i, July 2004, . 4978 [8] Clark, D., "IP datagram reassembly algorithms", RFC 815, 4979 July 1982. 4981 [9] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) 4982 Key Wrap Algorithm", RFC 3394, September 2002. 4984 [10] Mills, D., "Network Time Protocol (Version 3) Specification, 4985 Implementation", RFC 1305, March 1992. 4987 [11] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 4988 Public Key Infrastructure Certificate and Certificate 4989 Revocation List (CRL) Profile", RFC 3280, April 2002. 4991 [12] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for 4992 Transport Layer Security (TLS)", RFC 4279, December 2005. 4994 [13] "Netscape Certificate Extensions Specification", 4995 . 4997 [14] Clancy, C., "Security Review of the Light Weight Access Point 4998 Protocol", May 2005, 4999 . 5001 [15] Rescorla et al, E., "Datagram Transport Layer Security", 5002 June 2004. 5004 [16] "Recommendation for Block Cipher Modes of Operation: the CMAC 5005 Mode for Authentication", May 2005, . 5008 17.2. Informational References 5010 [17] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On- 5011 line Database", RFC 3232, January 2002. 5013 [18] Bradner, S., "The Internet Standards Process -- Revision 3", 5014 BCP 9, RFC 2026, October 1996. 5016 [19] Kent, S. and R. Atkinson, "Security Architecture for the 5017 Internet Protocol", RFC 2401, November 1998. 5019 [20] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 5020 for Message Authentication", RFC 2104, February 1997. 5022 [21] "WiFi Protected Access (WPA) rev 1.6", April 2003. 5024 [22] Dierks et al, T., "The TLS Protocol Version 1.1", June 2005. 5026 [23] Modadugu et al, N., "The Design and Implementation of Datagram 5027 TLS", Feb 2004. 5029 Editors' Addresses 5031 Pat R. Calhoun 5032 Cisco Systems, Inc. 5033 170 West Tasman Drive 5034 San Jose, CA 95134 5036 Phone: +1 408-853-5269 5037 Email: pcalhoun@cisco.com 5039 Michael P. Montemurro 5040 Chantry Networks 5041 1900 Minnesota Court, Suite 125 5042 Mississauga, ON L5N 3C9 5043 Canada 5045 Phone: +1 905-363-6413 5046 Email: michael.montemurro@siemens.com 5048 Dorothy Stanley 5049 Aruba Networks 5050 1322 Crossman Ave 5051 Sunnyvale, CA 94089 5053 Phone: +1 630-363-1389 5054 Email: dstanley@arubanetworks.com 5056 Intellectual Property Statement 5058 The IETF takes no position regarding the validity or scope of any 5059 Intellectual Property Rights or other rights that might be claimed to 5060 pertain to the implementation or use of the technology described in 5061 this document or the extent to which any license under such rights 5062 might or might not be available; nor does it represent that it has 5063 made any independent effort to identify any such rights. Information 5064 on the procedures with respect to rights in RFC documents can be 5065 found in BCP 78 and BCP 79. 5067 Copies of IPR disclosures made to the IETF Secretariat and any 5068 assurances of licenses to be made available, or the result of an 5069 attempt made to obtain a general license or permission for the use of 5070 such proprietary rights by implementers or users of this 5071 specification can be obtained from the IETF on-line IPR repository at 5072 http://www.ietf.org/ipr. 5074 The IETF invites any interested party to bring to its attention any 5075 copyrights, patents or patent applications, or other proprietary 5076 rights that may cover technology that may be required to implement 5077 this standard. Please address the information to the IETF at 5078 ietf-ipr@ietf.org. 5080 Disclaimer of Validity 5082 This document and the information contained herein are provided on an 5083 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 5084 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 5085 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 5086 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 5087 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 5088 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 5090 Copyright Statement 5092 Copyright (C) The Internet Society (2006). This document is subject 5093 to the rights, licenses and restrictions contained in BCP 78, and 5094 except as set forth therein, the authors retain all their rights. 5096 Acknowledgment 5098 Funding for the RFC Editor function is currently provided by the 5099 Internet Society.