idnits 2.17.1 draft-ietf-capwap-protocol-specification-06.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, updated by RFC 4748 on line 5709. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 5720. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 5727. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 5733. 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 16 instances of too long lines in the document, the longest one being 18 characters in excess of 72. ** The abstract seems to contain references ([14]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == 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 IETF Trust Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Unless otherwise specified, a control message that lists a set of supported (or expected) message elements MUST not expect the message elements to be in any specific order. The sender may include the message elements in any order. Unless otherwise noted, one message element of each type is present in a given control message. -- 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 (April 2007) is 6220 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 1315 ** Obsolete normative reference: RFC 1750 (ref. '2') (Obsoleted by RFC 4086) ** Obsolete normative reference: RFC 1305 (ref. '3') (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 3280 (ref. '4') (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 4346 (ref. '7') (Obsoleted by RFC 5246) ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '8') ** Obsolete normative reference: RFC 4347 (ref. '9') (Obsoleted by RFC 6347) ** Obsolete normative reference: RFC 1533 (ref. '10') (Obsoleted by RFC 2132) ** Obsolete normative reference: RFC 2246 (ref. '11') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2434 (ref. '12') (Obsoleted by RFC 5226) Summary: 12 errors (**), 0 flaws (~~), 5 warnings (==), 9 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: September 11, 2007 M. Montemurro, Editor 5 Research In Motion 6 D. Stanley, Editor 7 Aruba Networks 8 April 2007 10 CAPWAP Protocol Specification 11 draft-ietf-capwap-protocol-specification-06 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 September 2, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This specification defines the Control And Provisioning of Wireless 45 Access Points (CAPWAP) Protocol. The CAPWAP protocol meets the IETF 46 CAPWAP working group protocol requirements. The CAPWAP protocol is 47 designed to be flexible, allowing it to be used for a variety of 48 wireless technologies. This document describes the base CAPWAP 49 protocol. The CAPWAP protocol binding which defines extensions for 50 use with the IEEE 802.11 wireless LAN protocol is available in [14]. 51 Extensions are expected to be defined to enable use of the CAPWAP 52 protocol with additional wireless technologies. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 57 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 1.2. Conventions used in this document . . . . . . . . . . . . 8 59 1.3. Contributing Authors . . . . . . . . . . . . . . . . . . 9 60 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 10 61 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 11 62 2.1. Wireless Binding Definition . . . . . . . . . . . . . . . 12 63 2.2. CAPWAP Session Establishment Overview . . . . . . . . . . 13 64 2.3. CAPWAP State Machine Definition . . . . . . . . . . . . . 14 65 2.3.1. CAPWAP Protocol State Transitions . . . . . . . . . . 16 66 2.3.2. CAPWAP/DTLS Interface . . . . . . . . . . . . . . . . 27 67 2.4. Use of DTLS in the CAPWAP Protocol . . . . . . . . . . . 29 68 2.4.1. DTLS Handshake Processing . . . . . . . . . . . . . . 29 69 2.4.2. DTLS Session Establishment . . . . . . . . . . . . . 30 70 2.4.3. DTLS Error Handling . . . . . . . . . . . . . . . . . 31 71 2.4.4. DTLS EndPoint Authentication and Authorization . . . 32 72 3. CAPWAP Transport . . . . . . . . . . . . . . . . . . . . . . 36 73 3.1. UDP Transport . . . . . . . . . . . . . . . . . . . . . . 36 74 3.2. UDP-Lite Transport . . . . . . . . . . . . . . . . . . . 36 75 3.3. AC Discovery . . . . . . . . . . . . . . . . . . . . . . 36 76 3.4. Fragmentation/Reassembly . . . . . . . . . . . . . . . . 38 77 4. CAPWAP Packet Formats . . . . . . . . . . . . . . . . . . . . 39 78 4.1. CAPWAP Preamble . . . . . . . . . . . . . . . . . . . . . 41 79 4.2. CAPWAP Header . . . . . . . . . . . . . . . . . . . . . . 41 80 4.3. CAPWAP Data Messages . . . . . . . . . . . . . . . . . . 45 81 4.3.1. CAPWAP Data Keepalive . . . . . . . . . . . . . . . . 45 82 4.3.2. Data Payload . . . . . . . . . . . . . . . . . . . . 46 83 4.3.3. Establishment of a DTLS Data Channel . . . . . . . . 47 84 4.4. CAPWAP Control Messages . . . . . . . . . . . . . . . . . 47 85 4.4.1. Control Message Format . . . . . . . . . . . . . . . 48 86 4.4.2. Control Message Quality of Service . . . . . . . . . 51 87 4.4.3. Retransmissions . . . . . . . . . . . . . . . . . . . 51 88 4.5. CAPWAP Protocol Message Elements . . . . . . . . . . . . 52 89 4.5.1. AC Descriptor . . . . . . . . . . . . . . . . . . . . 54 90 4.5.2. AC IPv4 List . . . . . . . . . . . . . . . . . . . . 56 91 4.5.3. AC IPv6 List . . . . . . . . . . . . . . . . . . . . 57 92 4.5.4. AC Name . . . . . . . . . . . . . . . . . . . . . . . 57 93 4.5.5. AC Name with Index . . . . . . . . . . . . . . . . . 58 94 4.5.6. AC Timestamp . . . . . . . . . . . . . . . . . . . . 58 95 4.5.7. Add MAC ACL Entry . . . . . . . . . . . . . . . . . . 59 96 4.5.8. Add Station . . . . . . . . . . . . . . . . . . . . . 59 97 4.5.9. Add Static MAC ACL Entry . . . . . . . . . . . . . . 60 98 4.5.10. CAPWAP Control IPv4 Address . . . . . . . . . . . . . 61 99 4.5.11. CAPWAP Control IPv6 Address . . . . . . . . . . . . . 61 100 4.5.12. CAPWAP Timers . . . . . . . . . . . . . . . . . . . . 62 101 4.5.13. Data Transfer Data . . . . . . . . . . . . . . . . . 63 102 4.5.14. Data Transfer Mode . . . . . . . . . . . . . . . . . 63 103 4.5.15. Decryption Error Report . . . . . . . . . . . . . . . 64 104 4.5.16. Decryption Error Report Period . . . . . . . . . . . 64 105 4.5.17. Delete MAC ACL Entry . . . . . . . . . . . . . . . . 65 106 4.5.18. Delete Station . . . . . . . . . . . . . . . . . . . 66 107 4.5.19. Delete Static MAC ACL Entry . . . . . . . . . . . . . 66 108 4.5.20. Discovery Type . . . . . . . . . . . . . . . . . . . 67 109 4.5.21. Duplicate IPv4 Address . . . . . . . . . . . . . . . 68 110 4.5.22. Duplicate IPv6 Address . . . . . . . . . . . . . . . 69 111 4.5.23. Idle Timeout . . . . . . . . . . . . . . . . . . . . 70 112 4.5.24. Image Data . . . . . . . . . . . . . . . . . . . . . 70 113 4.5.25. Image Identifier . . . . . . . . . . . . . . . . . . 71 114 4.5.26. Image Information . . . . . . . . . . . . . . . . . . 71 115 4.5.27. Initiate Download . . . . . . . . . . . . . . . . . . 72 116 4.5.28. Location Data . . . . . . . . . . . . . . . . . . . . 72 117 4.5.29. Maximum Message Length . . . . . . . . . . . . . . . 73 118 4.5.30. MTU Discovery Padding . . . . . . . . . . . . . . . . 73 119 4.5.31. Radio Administrative State . . . . . . . . . . . . . 74 120 4.5.32. Radio Operational State . . . . . . . . . . . . . . . 74 121 4.5.33. Result Code . . . . . . . . . . . . . . . . . . . . . 75 122 4.5.34. Returned Message Element . . . . . . . . . . . . . . 77 123 4.5.35. Session ID . . . . . . . . . . . . . . . . . . . . . 77 124 4.5.36. Statistics Timer . . . . . . . . . . . . . . . . . . 78 125 4.5.37. Vendor Specific Payload . . . . . . . . . . . . . . . 78 126 4.5.38. WTP Board Data . . . . . . . . . . . . . . . . . . . 79 127 4.5.39. WTP Descriptor . . . . . . . . . . . . . . . . . . . 80 128 4.5.40. WTP Fallback . . . . . . . . . . . . . . . . . . . . 81 129 4.5.41. WTP Frame Tunnel Mode . . . . . . . . . . . . . . . . 82 130 4.5.42. WTP IPv4 IP Address . . . . . . . . . . . . . . . . . 83 131 4.5.43. WTP MAC Type . . . . . . . . . . . . . . . . . . . . 83 132 4.5.44. WTP Name . . . . . . . . . . . . . . . . . . . . . . 84 133 4.5.45. WTP Operational Statistics . . . . . . . . . . . . . 84 134 4.5.46. WTP Radio Statistics . . . . . . . . . . . . . . . . 85 135 4.5.47. WTP Reboot Statistics . . . . . . . . . . . . . . . . 86 136 4.5.48. WTP Static IP Address Information . . . . . . . . . . 88 138 4.6. CAPWAP Protocol Timers . . . . . . . . . . . . . . . . . 89 139 4.6.1. ChangeStatePendingTimer . . . . . . . . . . . . . . . 89 140 4.6.2. DataChannelDeadInterval . . . . . . . . . . . . . . . 89 141 4.6.3. DiscoveryInterval . . . . . . . . . . . . . . . . . . 89 142 4.6.4. DTLSSessionDelete . . . . . . . . . . . . . . . . . . 89 143 4.6.5. EchoInterval . . . . . . . . . . . . . . . . . . . . 89 144 4.6.6. KeyLifetime . . . . . . . . . . . . . . . . . . . . . 90 145 4.6.7. MaxDiscoveryInterval . . . . . . . . . . . . . . . . 90 146 4.6.8. MaxFailedDTLSSessionRetry . . . . . . . . . . . . . . 90 147 4.6.9. NeighborDeadInterval . . . . . . . . . . . . . . . . 90 148 4.6.10. ResponseTimeout . . . . . . . . . . . . . . . . . . . 90 149 4.6.11. RetransmitInterval . . . . . . . . . . . . . . . . . 90 150 4.6.12. SilentInterval . . . . . . . . . . . . . . . . . . . 91 151 4.6.13. StatisticsTimer . . . . . . . . . . . . . . . . . . . 91 152 4.6.14. WaitDTLS . . . . . . . . . . . . . . . . . . . . . . 91 153 4.6.15. WaitJoin . . . . . . . . . . . . . . . . . . . . . . 91 154 4.7. CAPWAP Protocol Variables . . . . . . . . . . . . . . . . 91 155 4.7.1. AdminState . . . . . . . . . . . . . . . . . . . . . 91 156 4.7.2. DiscoveryCount . . . . . . . . . . . . . . . . . . . 91 157 4.7.3. FailedDTLSAuthFailCount . . . . . . . . . . . . . . . 92 158 4.7.4. FailedDTLSSessionCount . . . . . . . . . . . . . . . 92 159 4.7.5. IdleTimeout . . . . . . . . . . . . . . . . . . . . . 92 160 4.7.6. MaxDiscoveries . . . . . . . . . . . . . . . . . . . 92 161 4.7.7. MaxRetransmit . . . . . . . . . . . . . . . . . . . . 92 162 4.7.8. ReportInterval . . . . . . . . . . . . . . . . . . . 92 163 4.7.9. RetransmitCount . . . . . . . . . . . . . . . . . . . 92 164 4.7.10. WTPFallBack . . . . . . . . . . . . . . . . . . . . . 92 165 4.8. WTP Saved Variables . . . . . . . . . . . . . . . . . . . 92 166 4.8.1. AdminRebootCount . . . . . . . . . . . . . . . . . . 93 167 4.8.2. FrameEncapType . . . . . . . . . . . . . . . . . . . 93 168 4.8.3. LastRebootReason . . . . . . . . . . . . . . . . . . 93 169 4.8.4. MacType . . . . . . . . . . . . . . . . . . . . . . . 93 170 4.8.5. PreferredACs . . . . . . . . . . . . . . . . . . . . 93 171 4.8.6. RebootCount . . . . . . . . . . . . . . . . . . . . . 93 172 4.8.7. Static ACL Table . . . . . . . . . . . . . . . . . . 93 173 4.8.8. Static IP Address . . . . . . . . . . . . . . . . . . 93 174 4.8.9. WTPLinkFailureCount . . . . . . . . . . . . . . . . . 93 175 4.8.10. WTPLocation . . . . . . . . . . . . . . . . . . . . . 93 176 4.8.11. WTPName . . . . . . . . . . . . . . . . . . . . . . . 94 177 5. CAPWAP Discovery Operations . . . . . . . . . . . . . . . . . 95 178 5.1. Discovery Request Message . . . . . . . . . . . . . . . . 95 179 5.2. Discovery Response Message . . . . . . . . . . . . . . . 96 180 5.3. Primary Discovery Request Message . . . . . . . . . . . . 97 181 5.4. Primary Discovery Response . . . . . . . . . . . . . . . 98 182 6. CAPWAP Join Operations . . . . . . . . . . . . . . . . . . . 100 183 6.1. Join Request . . . . . . . . . . . . . . . . . . . . . . 100 184 6.2. Join Response . . . . . . . . . . . . . . . . . . . . . . 101 185 7. Control Channel Management . . . . . . . . . . . . . . . . . 103 186 7.1. Echo Request . . . . . . . . . . . . . . . . . . . . . . 103 187 7.2. Echo Response . . . . . . . . . . . . . . . . . . . . . . 103 188 8. WTP Configuration Management . . . . . . . . . . . . . . . . 105 189 8.1. Configuration Consistency . . . . . . . . . . . . . . . . 105 190 8.1.1. Configuration Flexibility . . . . . . . . . . . . . . 106 191 8.2. Configuration Status . . . . . . . . . . . . . . . . . . 106 192 8.3. Configuration Status Response . . . . . . . . . . . . . . 107 193 8.4. Configuration Update Request . . . . . . . . . . . . . . 108 194 8.5. Configuration Update Response . . . . . . . . . . . . . . 109 195 8.6. Change State Event Request . . . . . . . . . . . . . . . 109 196 8.7. Change State Event Response . . . . . . . . . . . . . . . 110 197 8.8. Clear Configuration Request . . . . . . . . . . . . . . . 111 198 8.9. Clear Configuration Response . . . . . . . . . . . . . . 111 199 9. Device Management Operations . . . . . . . . . . . . . . . . 112 200 9.1. Firmware Management . . . . . . . . . . . . . . . . . . . 112 201 9.1.1. Image Data Request . . . . . . . . . . . . . . . . . 115 202 9.1.2. Image Data Response . . . . . . . . . . . . . . . . . 116 203 9.2. Reset Request . . . . . . . . . . . . . . . . . . . . . . 117 204 9.3. Reset Response . . . . . . . . . . . . . . . . . . . . . 117 205 9.4. WTP Event Request . . . . . . . . . . . . . . . . . . . . 118 206 9.5. WTP Event Response . . . . . . . . . . . . . . . . . . . 119 207 9.6. Data Transfer Request . . . . . . . . . . . . . . . . . . 119 208 9.7. Data Transfer Response . . . . . . . . . . . . . . . . . 119 209 10. Station Session Management . . . . . . . . . . . . . . . . . 121 210 10.1. Station Configuration Request . . . . . . . . . . . . . . 121 211 10.2. Station Configuration Response . . . . . . . . . . . . . 121 212 11. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 122 213 12. Security Considerations . . . . . . . . . . . . . . . . . . . 124 214 12.1. CAPWAP Security . . . . . . . . . . . . . . . . . . . . . 124 215 12.1.1. Converting Protected Data into Unprotected Data . . . 125 216 12.1.2. Converting Unprotected Data into Protected Data 217 (Insertion) . . . . . . . . . . . . . . . . . . . . . 125 218 12.1.3. Deletion of Protected Records . . . . . . . . . . . . 125 219 12.1.4. Insertion of Unprotected Records . . . . . . . . . . 125 220 12.2. Session ID Security . . . . . . . . . . . . . . . . . . . 125 221 12.3. Discovery Attacks . . . . . . . . . . . . . . . . . . . . 126 222 12.4. Interference with a DTLS Session . . . . . . . . . . . . 126 223 12.5. Use of Preshared Keys in CAPWAP . . . . . . . . . . . . . 126 224 12.6. Use of Certificates in CAPWAP . . . . . . . . . . . . . . 127 225 12.7. AAA Security . . . . . . . . . . . . . . . . . . . . . . 128 226 13. Management Considerations . . . . . . . . . . . . . . . . . . 129 227 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 130 228 14.1. CAPWAP Message Types . . . . . . . . . . . . . . . . . . 130 229 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 131 230 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 132 231 16.1. Normative References . . . . . . . . . . . . . . . . . . 132 232 16.2. Informational References . . . . . . . . . . . . . . . . 133 233 16.3. Informational References . . . . . . . . . . . . . . . . 133 235 Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 134 236 Intellectual Property and Copyright Statements . . . . . . . . . 135 238 1. Introduction 240 This document describes the CAPWAP Protocol, a standard, 241 interoperable protocol which enables an Access Controller (AC) to 242 manage a collection of Wireless Termination Points (WTPs). The 243 CAPWAP protocol is defined to be independent of layer 2 technology. 245 The emergence of centralized IEEE 802.11 Wireless Local Area Network 246 (WLAN) architectures, in which simple IEEE 802.11 WTPs are managed by 247 an Access Controller (AC) suggested that a standards based, 248 interoperable protocol could radically simplify the deployment and 249 management of wireless networks. WTPs require a set of dynamic 250 management and control functions related to their primary task of 251 connecting the wireless and wired mediums. Traditional protocols for 252 managing WTPs are either manual static configuration via HTTP, 253 proprietary Layer 2 specific or non-existent (if the WTPs are self- 254 contained). An IEEE 802.11 binding is defined in [14] to support use 255 of the CAPWAP protocol with IEEE 802.11 WLAN networks. 257 CAPWAP assumes a network configuration consisting of multiple WTPs 258 communicating via the Internet Protocol (IP) to an AC. WTPs are 259 viewed as remote RF interfaces controlled by the AC. The CAPWAP 260 protocol supports two modes of operation: Split and Local MAC. In 261 Split MAC mode all L2 wireless data and management frames are 262 encapsulated via the CAPWAP protocol and exchanged between the AC and 263 the WTP. As shown in Figure 1, the wireless frames received from a 264 mobile device, which is referred to in this specification as a 265 Station (STA), are directly encapsulated by the WTP and forwarded to 266 the AC. 268 +-+ wireless frames +-+ 269 | |--------------------------------| | 270 | | +-+ | | 271 | |--------------| |---------------| | 272 | |wireless PHY/ | | CAPWAP | | 273 | | MAC sublayer | | | | 274 +-+ +-+ +-+ 275 STA WTP AC 277 Figure 1: Representative CAPWAP Architecture for Split MAC 279 The Local MAC mode of operation allows for the data frames to be 280 either locally bridged, or tunneled as 802.3 frames. The latter 281 implies that the WTP performs the 802 bridging function. In either 282 case the L2 wireless management frames are processed locally by the 283 WTP, and then forwarded to the AC. Figure 2 shows the Local MAC 284 mode, in which a station transmits a wireless frame which is 285 encapsulated in an 802.3 frame and forwarded to the AC. 287 +-+wireless frames +-+ 802.3 frames +-+ 288 | |----------------| |--------------| | 289 | | | | | | 290 | |----------------| |--------------| | 291 | |wireless PHY/ | | CAPWAP | | 292 | | MAC sublayer | | | | 293 +-+ +-+ +-+ 294 STA WTP AC 296 Figure 2: Representative CAPWAP Architecture for Local MAC 298 Provisioning WTPs with security credentials, and managing which WTPs 299 are authorized to provide service are traditionally handled by 300 proprietary solutions. Allowing these functions to be performed from 301 a centralized AC in an interoperable fashion increases manageability 302 and allows network operators to more tightly control their wireless 303 network infrastructure. 305 1.1. Goals 307 The goals for the CAPWAP protocol are listed below: 309 1. To centralize the authentication and policy enforcement functions 310 for a wireless network. The AC may also provide centralized 311 bridging, forwarding, and encryption of user traffic. 312 Centralization of these functions will enable reduced cost and 313 higher efficiency by applying the capabilities of network 314 processing silicon to the wireless network, as in wired LANs. 316 2. To enable shifting of the higher level protocol processing from 317 the WTP. This leaves the time critical applications of wireless 318 control and access in the WTP, making efficient use of the 319 computing power available in WTPs which are the subject to severe 320 cost pressure. 322 3. To provide a generic encapsulation and transport mechanism, 323 enabling the CAPWAP protocol to be applied to many access point 324 types in the future, via a specific wireless binding. 326 The CAPWAP protocol concerns itself solely with the interface between 327 the WTP and the AC. Inter-AC and station-to AC-communication are 328 strictly outside the scope of this document. 330 1.2. Conventions used in this document 332 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 333 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 334 document are to be interpreted as described in RFC 2119 [1]. 336 1.3. Contributing Authors 338 This section lists and acknowledges the authors of significant text 339 and concepts included in this specification. 341 The CAPWAP Working Group selected the Lightweight Access Point 342 Protocol (LWAPP) [add reference, when available] to be used as the 343 basis of the CAPWAP protocol specification. The following people are 344 authors of the LWAPP document: 346 Bob O'Hara, Cisco Systems, Inc.,170 West Tasman Drive, San Jose, CA 95134 347 Phone: +1 408-853-5513, Email: bob.ohara@cisco.com 349 Pat Calhoun, Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134 350 Phone: +1 408-853-5269, Email: pcalhoun@cisco.com 352 Rohit Suri, Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134 353 Phone: +1 408-853-5548, Email: rsuri@cisco.com 355 Nancy Cam Winget, Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134 356 Phone: +1 408-853-0532, Email: ncamwing@cisco.com 358 Scott Kelly, Aruba Networks, 1322 Crossman Ave, Sunnyvale, CA 94089 359 Phone: +1 408-754-8408, Email: skelly@arubanetworks.com 361 Michael Glenn Williams, Nokia, Inc., 313 Fairchild Drive, Mountain View, CA 94043 362 Phone: +1 650-714-7758, Email: Michael.G.Williams@Nokia.com 364 Sue Hares, Nexthop Technologies, Inc., 825 Victors Way, Suite 100, Ann Arbor, MI 48108 365 Phone: +1 734 222 1610, Email: shares@nexthop.com 367 DTLS is used as the security solution for the CAPWAP protocol. The 368 following people are authors of significant DTLS-related text 369 included in this document: 371 Scott Kelly, Aruba Networks, 1322 Crossman Ave, Sunnyvale, CA 94089 372 Phone: +1 408-754-8408, Email: skelly@arubanetworks.com 374 Eric Rescorla, Network Resonance, 2483 El Camino Real, #212,Palo Alto CA, 94303 375 Email: ekr@networkresonance.com 377 The concept of using DTLS to secure the CAPWAP protocol was part of 378 the Secure Light Access Point Protocol (SLAPP) proposal [add 379 reference when available]. The following people are authors of the 380 SLAPP proposal: 382 Partha Narasimhan, Aruba Networks, 1322 Crossman Ave, Sunnyvale, CA 94089 383 Phone: +1 408-480-4716, Email: partha@arubanetworks.com 385 Dan Harkins, Tropos Networks, 555 Del Rey Avenue, Sunnyvale, CA, 95085 386 Phone: +1 408 470 7372, Email: dharkins@tropos.com 388 Subbu Ponnuswamy, Aruba Networks, 1322 Crossman Ave, Sunnyvale, CA 94089 389 Phone: +1 408-754-1213, Email: subbu@arubanetworks.com 391 The following individuals contributed significant security related 392 text to the draft: 394 T. Charles Clancy, Laboratory for Telecommunications Sciences, 395 8080 Greenmead Drive, College Park, MD 20740 396 Phone: +1 240-373-5069, Email: clancy@ltsnet.net 398 Scott Kelly, Aruba Networks, 1322 Crossman Ave, Sunnyvale, CA 94089 399 Phone: +1 408-754-8408, Email: skelly@arubanetworks.com 401 1.4. Terminology 403 Access Controller (AC): The network entity that provides WTPs access 404 to the network infrastructure in the data plane, control plane, 405 management plane, or a combination therein. 407 Station (STA): A device that contains an IEEE 802.11 conformant 408 medium access control (MAC) and physical layer (PHY) interface to the 409 wireless medium (WM). 411 Wireless Termination Point (WTP): The physical or network entity that 412 contains an RF antenna and wireless PHY to transmit and receive 413 station traffic for wireless access networks. 415 This document uses additional terminology defined in [8]. 417 2. Protocol Overview 419 The CAPWAP protocol is a generic protocol defining AC and WTP control 420 and data plane communication via a CAPWAP protocol transport 421 mechanism. CAPWAP control messages, and optionally CAPWAP data 422 messages, are secured using Datagram Transport Layer Security (DTLS) 423 [7]. DTLS is a standards-track IETF protocol based upon TLS. The 424 underlying security-related protocol mechanisms of TLS have been 425 successfully deployed for many years. 427 The CAPWAP protocol Transport layer carries two types of payload, 428 CAPWAP Data messages and CAPWAP Control messages. CAPWAP Data 429 messages encapsulate forwarded wireless frames. CAPWAP protocol 430 Control messages are management messages exchanged between a WTP and 431 an AC. The CAPWAP Data and Control packets are sent over separate 432 UDP ports. Since both data and control packets can exceed the 433 Maximum Transmission Unit (MTU) length, the payload of a CAPWAP data 434 or control message can be fragmented. The fragmentation behavior is 435 defined in Section 3. 437 The CAPWAP Protocol begins with a discovery phase. The WTPs send a 438 Discovery Request message, causing any Access Controller (AC) 439 receiving the message to respond with a Discovery Response message. 440 From the Discovery Response messages received, a WTP selects an AC 441 with which to establish a secure DTLS session. CAPWAP protocol 442 messages will be fragmented to the maximum length discovered to be 443 supported by the network. 445 Once the WTP and the AC have completed DTLS session establishment, a 446 configuration exchange occurs in which both devices agree on version 447 information. During this exchange the WTP may receive provisioning 448 settings. The WTP is then enabled for operation. 450 When the WTP and AC have completed the version and provision exchange 451 and the WTP is enabled, the CAPWAP protocol is used to encapsulate 452 the wireless data frames sent between the WTP and AC. The CAPWAP 453 protocol will fragment the L2 frames if the size of the encapsulated 454 wireless user data (Data) or protocol control (Management) frames 455 causes the resulting CAPWAP protocol packet to exceed the MTU 456 supported between the WTP and AC. Fragmented CAPWAP packets are 457 reassembled to reconstitute the original encapsulated payload. 459 The CAPWAP protocol provides for the delivery of commands from the AC 460 to the WTP for the management of stations that are communicating with 461 the WTP. This may include the creation of local data structures in 462 the WTP for the stations and the collection of statistical 463 information about the communication between the WTP and the stations. 464 The CAPWAP protocol provides a mechanism for the AC to obtain 465 statistical information collected by the WTP. 467 The CAPWAP protocol provides for a keep alive feature that preserves 468 the communication channel between the WTP and AC. If the AC fails to 469 appear alive, the WTP will try to discover a new AC. 471 2.1. Wireless Binding Definition 473 The CAPWAP protocol is independent of a specific WTP radio 474 technology. Elements of the CAPWAP protocol are designed to 475 accommodate the specific needs of each wireless technology in a 476 standard way. Implementation of the CAPWAP protocol for a particular 477 wireless technology must follow the binding requirements defined for 478 that technology. 480 When defining a binding for wireless technologies, the authors MUST 481 include any necessary definitions for technology-specific messages 482 and all technology-specific message elements for those messages. At 483 a minimum, a binding MUST provide: 485 1 - The definition for a binding-specific Statistics message 486 element, carried in the WTP Event Request message 488 2 - A message element carried in the Station Configuration Request 489 message to configure station information on the WTP 491 3 - A WTP Radio Information message element carried in the 492 Discovery, Primary Discovery and Join Request and Response 493 messages, indicating the binding specific radio types supported at 494 the WTP and AC. 496 If technology specific message elements are required for any of the 497 existing CAPWAP messages defined in this specification, they MUST 498 also be defined in the technology binding document. 500 The naming of binding-specific message elements MUST begin with the 501 name of the technology type, e.g., the binding for IEEE 802.11, 502 provided in [14], begins with "IEEE 802.11". 504 The CAPWAP binding concept is also used in any future specifications 505 that add functionality to either the base CAPWAP protocol 506 specification, or any published CAPWAP binding specification. A 507 separate WTP Radio Information message element MUST be created to 508 properly advertise support for the specification. This mechanism 509 allows for future protocol extensibility, while providing the 510 necessary capabilities advertisement, through the WTP Radio 511 Information message element, to ensure WTP/AC interoperability. 513 2.2. CAPWAP Session Establishment Overview 515 This section describes the session establishment process message 516 exchanges in the ideal case. The annotated ladder diagram shows the 517 AC on the right, the WTP on the left, and assumes the use of 518 certificates for DTLS authentication. The CAPWAP Protocol State 519 Machine is described in detail in Section 2.3. 521 ============ ============ 522 WTP AC 523 ============ ============ 524 [----------- begin optional discovery ------------] 526 Discover Request ------> 527 <------ Discover Response 529 [----------- end optional discovery ------------] 531 (--- begin DTLS handshake ---) 533 ClientHello ------> 534 <------ HelloVerifyRequest 535 (with cookie) 537 ClientHello ------> 538 (with cookie) 539 <------ ServerHello 540 <------ Certificate 541 <------ ServerHelloDone 543 (WTP callout for AC authorization) 545 Certificate* 546 ClientKeyExchange 547 CertificateVerify* 548 [ChangeCipherSpec] 549 Finished ------> 551 (AC callout for WTP 552 authorization) 554 [ChangeCipherSpec] 555 <------ Finished 557 (--- DTLS session is established now ---) 559 Join Request ------> 560 <------ Join Response 562 ( ---assume image is up to date ---) 564 Configuration Status Request -------> 565 <------ Configuration Status Response 567 (--- enter RUN state ---) 569 : 570 : 572 Echo Request -------> 573 <------ Echo Response 575 : 576 : 578 Event Request -------> 579 <------ Event Response 581 : 582 : 584 At the end of the illustrated CAPWAP message exchange, the AC and WTP 585 are securely exchanging CAPWAP control messages. This is an 586 idealized illustration, provided to clarify protocol operation. 587 Section 2.3 provides a detailed description of the corresponding 588 state machine. 590 2.3. CAPWAP State Machine Definition 592 The following state diagram represents the lifecycle of a WTP-AC 593 session. Use of DTLS by the CAPWAP protocol results in the 594 juxtaposition of two nominally separate yet tightly bound state 595 machines. The DTLS and CAPWAP state machines are coupled through an 596 API consisting of commands (see Section 2.3.2.1) and notifications 597 (see Section 2.3.2.2). Certain transitions in the DTLS state machine 598 are triggered by commands from the CAPWAP state machine, while 599 certain transitions in the CAPWAP state machine are triggered by 600 notifications from the DTLS state machine. 602 /-------------------------\ 603 w| | 604 5+----------+ x +------------+ | 605 | Run |-->| Reset |-\| 606 +----------+ +------------+ || 607 u ^ ^ ^ y|| 608 +------------+--------/ | | || 609 | Data Check | /-------/ | || 610 +------------+<-------\ | | || 611 | | || 612 /------------------+--------\ | || 613 r| t| s| 4 v o| || 614 +--------+ +-----------+ +--------------+|| 615 | Join |---->| Configure | | Image Data ||| 616 +--------+ q +-----------+ +--------------+|| 617 ^ p| V| x| || 618 | | \-------------------\ | || 619 | \--------------------------------------\| | || 620 \------------------------\ || | || 621 /--------------<----------------+--------------\ || | || 622 | /------------<-------------\ | | || | || 623 | | m| |n z| vv v vv 624 | | +----------------+ +--------------+ +-----------+ 625 | | | DTLS Setup | | DTLS Connect | | DTLS TD | 626 | | +----------------+ +--------------+ +-----------+ 627 | | g| ^ ^ |h ^ ^ 628 v v | | | | | | 629 | | | | | \-------\ | /-----------/ 630 | | | | | | | | 631 | | v |e f| 2 v |j |k 632 | \->+------+ +------+ +-----------+ 633 | | Idle |-->| Disc | | Authorize | 634 \--->+------+ a +------+ +-----------+ 635 b| ^ |c 636 | | /----/ 637 v d| | 638 +---------+ | 639 | Sulking |<-/ 640 3 +---------+ 642 Figure 3: CAPWAP Integrated State Machine 644 The CAPWAP protocol state machine, depicted above, is used by both 645 the AC and the WTP. In cases where states are not shared (i.e. not 646 implemented in one or the other of the AC or WTP), this is explicitly 647 called out in the transition descriptions below. For every state 648 defined, only certain messages are permitted to be sent and received. 649 The CAPWAP control messages definitions specify the state(s) in which 650 each message is valid. 652 Since the WTP only communicates with a single AC, it only has a 653 single instance of the CAPWAP state machine. The AC has a separate 654 instance of the CAPWAP state machine per WTP it is communicating 655 with. 657 2.3.1. CAPWAP Protocol State Transitions 659 This section describes the various state transitions, and the events 660 that cause them. This section does not discuss interactions between 661 DTLS- and CAPWAP-specific states. Those interactions, and DTLS- 662 specific states and transitions, are discussed in Section 2.3.2. 664 Idle to Discovery (a): This transition occurs once device 665 initialization is complete. 667 WTP: The WTP enters the Discovery state prior to transmitting the 668 first Discovery Request message (see Section 5.1). Upon 669 entering this state, the WTP sets the DiscoveryInterval timer 670 (see Section 4.6). The WTP resets the DiscoveryCount counter 671 to zero (0) (see Section 4.7). The WTP also clears all 672 information from ACs it may have received during a previous 673 Discovery phase. 675 AC: The AC does not maintain state information for the WTP upon 676 reception of the Discovery Request message, but it SHOULD 677 respond with a Discovery Response message (see Section 5.2). 678 This transition is a no-op for the AC. 680 Idle to Sulking (b): This transition occurs to force the WTP and AC 681 to enter a quiet period to avoid repeatedly attempting to 682 establish a connection. 684 WTP: The WTP enters this state when the FailedDTLSSessionCount or 685 the FailedDTLSAuthFailCount counter reaches 686 MaxFailedDTLSSessionRetry variable (see Section 4.7). Upon 687 entering this state, the WTP MUST start the SilentInterval 688 timer. While in the Sulking state, all received CAPWAP and 689 DTLS protocol messages received MUST be ignored. 691 AC: The AC enters this state with the specific WTP when the 692 FailedDTLSSessionCount or the FailedDTLSAuthFailCount counter 693 reaches MaxFailedDTLSSessionRetry variable (see Section 4.7). 694 Upon entering this state, the AC MUST start the SilentInterval 695 timer. While in the Sulking state, all received CAPWAP and 696 DTLS protocol messages received from the WTP MUST be ignored. 698 Discovery to Discovery (2): In the Discovery state, the WTP 699 determines which AC to connect to. 701 WTP: This transition occurs when the DiscoveryInterval timer 702 expires. If the WTP is configured with a list of ACs, it 703 transmits a Discovery Request message to every AC from which it 704 has not received a Discovery Response message. For every 705 transition to this event, the WTP increments the DiscoveryCount 706 counter. See Section 5.1 for more information on how the WTP 707 knows the ACs to which it should transmit the Discovery Request 708 messages. The WTP restarts the DiscoveryInterval timer 709 whenever it transmits Discovery Request messages. 711 AC: This is a no-op. 713 Discovery to Sulking (c): This transition occurs on a WTP when 714 Discovery or connectivity to the AC fails. 716 WTP: The WTP enters this state when the DiscoveryInterval timer 717 expires or the DiscoveryCount variable is equal to the 718 MaxDiscoveries variable (see Section 4.7). Upon entering this 719 state, the WTP MUST start the SilentInterval timer. While in 720 the Sulking state, all received CAPWAP protocol messages 721 received MUST be ignored. 723 AC: This is a no-op. 725 Sulking to Idle (d): This transition occurs on a WTP when it must 726 restart the discovery phase. 728 WTP: The WTP enters this state when the SilentInterval timer (see 729 Section 4.6) expires. The FailedDTLSSessionCount, 730 DiscoveryCount and FailedDTLSAuthFailCount counters are reset 731 to zero. 733 AC: The AC enters this state when the SilentInterval timer (see 734 Section 4.6) expires. The FailedDTLSSessionCount, 735 DiscoveryCount and FailedDTLSAuthFailCount counters are reset 736 to zero. 738 Sulking to Sulking (3): The Sulking state provides the silent 739 period, minimizing the possibility for Denial of Service (DoS) 740 attacks. 742 WTP: All packets received from the AC while in the sulking state 743 are ignored. 745 AC: All packets receive from the WTP while in the sulking state 746 are ignored. 748 Idle to DTLS Setup (e): This transition occurs to establish a secure 749 DTLS session with the peer. 751 WTP: The WTP initiates this transition by invoking the DTLSStart 752 command, which starts the DTLS session establishment with the 753 chosen AC. When the discovery phase is bypassed, it is assumed 754 the WTP has a locally configured AC. 756 AC: The AC initiates this transition by invoking the DTLSListen 757 command, which informs the DTLS stack that it is willing to 758 listen for an incoming session. The AC MAY provide optional 759 qualifiers in the DTLSListen command to only accept session 760 requests from specific WTPs. 762 Discovery to DTLS Setup (f): This transition occurs to establish a 763 secure DTLS session with the peer. 765 WTP: The WTP initiates this transition by invoking the DTLSStart 766 command (see Section 2.3.2.1), which starts the DTLS session 767 establishment with the chosen AC. The decision of which AC to 768 connect to is the result of the discovery phase, which is 769 described in Section 3.3. 771 AC: The AC initiates this transition by invoking the DTLSListen 772 command (see Section 2.3.2.1), which informs the DTLS stack 773 that it is willing to listen for an incoming session. The AC 774 MAY have maintained state information when it received the 775 Discovery Request message to provide optional qualifiers in the 776 DTLSListen command to only accept session requests from a 777 specific WTP. Note that maintaining state information based on 778 an unsecured Discovery Request message MAY lead to a Denial of 779 Service attack. Therefore the AC SHOULD ensure that the state 780 information is freed after a period, which is implementation 781 specific. 783 DTLS Setup to Idle (g): This transition occurs when the DTLS Session 784 failed to be established. 786 WTP: The WTP initiates this state transition when it receives a 787 DTLSEstablishFail notification from DTLS (see Section 2.3.2.2). 788 This error notification aborts the secure DTLS session 789 establishment. When this notification is received, the 790 FailedDTLSSessionCount counter is incremented. 792 AC: The WTP initiates this state transition when it receives a 793 DTLSEstablishFail notification from DTLS (see Section 2.3.2.2). 794 This error notification aborts the secure DTLS session 795 establishment. When this notification is received, the 796 FailedDTLSSessionCount counter is incremented. 798 DTLS Setup to Authorize (h): This transition occurs when an incoming 799 DTLS session is being established, and the DTLS stack needs 800 authorization to proceed with the session establishment. 802 WTP: This state transition occurs when the WTP receives the 803 DTLSPeerAuthorize notification (see Section 2.3.2.2). Upon 804 entering this state, the WTP performs an authorization check 805 against the AC credentials. See Section 2.4.4 for more 806 information on AC authorization. 808 AC: This state transition occurs when the AC receives the 809 DTLSPeerAuthorize notification (see Section 2.3.2.2). Upon 810 entering this state, the AC performs an authorization check 811 against the WTP credentials. See Section 2.4.4 for more 812 information on WTP authorization. 814 Authorize to DTLS Connect (j): This transition occurs to notify the 815 DTLS stack that the session should be established. 817 WTP: This state transition occurs when the WTP has either opted 818 to forgo the authorization check of the AC's credentials, or 819 the credentials were successfully authorized. This is done by 820 invoking the DTLSAccept DTLS command (see Section 2.3.2.1). 822 AC: This state transition occurs when the AC has either opted to 823 forgo the authorization check of the WTP's credentials, or the 824 credentials were successfully authorized. This is done by 825 invoking the DTLSAccept DTLS command (see Section 2.3.2.1). 827 Authorize to DTLS Teardown (k): This transition occurs to notify the 828 DTLS stack that the session should be aborted. 830 WTP: This state transition occurs when the WTP was unable to 831 authorize the AC, using the AC credentials. The WTP then 832 aborts the DTLS session by invoking the DTLSAbortSession 833 command (see Section 2.3.2.1). 835 AC: This state transition occurs when the AC was unable to 836 authorize the WTP, using the WTP credentials. The AC then 837 aborts the DTLS session by invoking the DTLSAbortSession 838 command (see Section 2.3.2.1). 840 DTLS Connect to Idle (m): This transition occurs when the DTLS 841 Session failed to be established. 843 WTP: This state transition occurs when the WTP receives either a 844 DTLSAborted or DTLSAuthenticateFail notification (see 845 Section 2.3.2.2), indicating that the DTLS session was not 846 successfully established. When this transition occurs due to 847 the DTLSAuthenticateFail notification, the 848 FailedDTLSAuthFailCount is incremented, otherwise the 849 FailedDTLSSessionCount counter is incremented. 851 AC: This state transition occurs when the AC receives either a 852 DTLSAborted or DTLSAuthenticateFail notification (see 853 Section 2.3.2.2), indicating that the DTLS session was not 854 successfully established. When this transition occurs due to 855 the DTLSAuthenticateFail notification, the 856 FailedDTLSAuthFailCount is incremented, otherwise the 857 FailedDTLSSessionCount counter is incremented. 859 DTLS Connect to Join (n): This transition occurs when the DTLS 860 Session is successfully established. 862 WTP: This state transition occurs when the WTP receives the 863 DTLSEstablished notification (see Section 2.3.2.2), indicating 864 that the DTLS session was successfully established. When this 865 notification is received, the FailedDTLSSessionCount counter is 866 set to zero. 868 AC: This state transition occurs when the AC receives the 869 DTLSEstablished notification (see Section 2.3.2.2), indicating 870 that the DTLS session was successfully established. When this 871 notification is received, the FailedDTLSSessionCount counter is 872 set to zero, and the WaitJoin timer is started (see 873 Section 4.6). 875 Join to DTLS Teardown (p): This transition occurs when the join 876 process failed. 878 WTP: This state transition occurs when the WTP receives a Join 879 Response message with a Result Code message element containing 880 an error, if the Image Identifier provided by the AC in the 881 Join Response message differs from the WTP's currently running 882 firmware version and the WTP has the requested image in its 883 non-volatile memory, or if the WaitDTLS timer expires. This 884 causes the WTP to initiate the DTLSShutdown command (see 885 Section 2.3.2.1). This transition also occurs if the WTP 886 receives one of the following DTLS notifications: DTLSAborted, 887 DTLSReassemblyFailure or DTLSPeerDisconnect. 889 AC: This state transition occurs either if the WaitJoin timer 890 expires or if the AC transmits a Join Response message with a 891 Result Code message element containing an error. This causes 892 the AC to initiate the DTLSShutdown command (see 893 Section 2.3.2.1). This transition also occurs if the AC 894 receives one of the following DTLS notifications: DTLSAborted, 895 DTLSReassemblyFailure or DTLSPeerDisconnect. 897 Join to Image Data (r): This state transition is used by the WTP and 898 the AC to download executable firmware. 900 WTP: The WTP enters the Image Data state when it receives a 901 successful Join Response message and determines and the 902 included Image Identifier message element is not the same as 903 its currently running image. The WTP also detects that the 904 requested image version is not currently available in the WTP's 905 non-volatile storage (see Section 9.1 for a full description of 906 the firmware download process). The WTP transmits the Image 907 Data Request message (see Section 9.1.1) requesting the start 908 of the firwware download. 910 AC: This state transition occurs when the AC receives the Image 911 Data Request message from the WTP. The AC must transmit an 912 Image Data Response message (see Section 9.1.2) to the WTP, 913 which includes a portion of the firmware. 915 Join to Configure (q): This state transition is used by the WTP and 916 the AC to exchange configuration information. 918 WTP: The WTP enters the Configure state when it receives a 919 successful Join Response, and determines that the included 920 Image Identifier message element is the same as its currently 921 running image. The WTP transmits the Configuration Status 922 message (see Section 8.2) to the AC with message elements 923 describing its current configuration. The WTP also starts the 924 ResponseTimeout timer (see Section 4.6). 926 AC: This state transition occurs immediately after the AC 927 transmits the Join Response message to the WTP. If the AC 928 receives the Configuration Status message from the WTP, the AC 929 must transmit a Configuration Status Response message (see 930 Section 8.3) to the WTP, and may include specific message 931 elements to override the WTP's configuration. The WTP also 932 starts the ChangeStatePendingTimer timer (see Section 4.6). 934 Configure to Reset (s): This state transition is used to reset the 935 connection either due to an error during the configuration phase, 936 or when the WTP determines it needs to reset in order for the new 937 configuration to take effect. 939 WTP: The WTP enters the Reset state when it receives a 940 Configuration Status Response indicating an error or when it 941 determines that a reset of the WTP is required, due to the 942 characteristics of a new configuration. 944 AC: The AC transitions to the Reset state when it receives a 945 Change State Event message from the WTP that contains an error 946 for which AC policy does not permit the WTP to provide service. 947 This state transition also occurs when the AC 948 ChangeStatePendingTimer timer expires. 950 Configure to DTLS Teardown (V): This transition occurs when the 951 configuration process aborts due to a DTLS error. 953 WTP: The WTP enters this state when it receives one of the 954 following DTLS notifications: DTLSAborted, 955 DTLSReassemblyFailure or DTLSPeerDisconnect (see 956 Section 2.3.2.2). The WTP MAY tear down the DTLS session if it 957 receives frequent DTLSDecapFailure notifications. 959 AC: The AC enters this state when it receives one of the 960 following DTLS notifications: DTLSAborted, 961 DTLSReassemblyFailure or DTLSPeerDisconnect (see 962 Section 2.3.2.2). The WTP MAY tear down the DTLS session if it 963 receives frequent DTLSDecapFailure notifications. 965 Image Data to Image Data (4): The Image Data state is used by the 966 WTP and the AC during the firmware download phase. 968 WTP: The WTP enters the Image Data state when it receives an 969 Image Data Response message indicating that the AC has more 970 data to send. 972 AC: This state transition occurs when the AC receives the Image 973 Data Request message from the WTP while already in the Image 974 Data state, and it detects that the firmware download has not 975 completed. 977 Image Data to Reset (o): This state transition is used to reset the 978 DTLS connection prior to restarting the WTP after an image 979 download. 981 WTP: When an image download completes, the WTP enters the Reset 982 state. The WTP MAY also transition to this state upon 983 receiving an Image Data Response message from the AC (see 984 Section 9.1.2) indicating a failure. 986 AC: The AC enters the Reset state when the image download is 987 complete, or if an error occurs during the image download 988 process. 990 Image Data to DTLS Teardown (x): This transition occurs when the 991 firmware download process aborts due to a DTLS error. 993 WTP: The WTP enters this state when it receives one of the 994 following DTLS notifications: DTLSAborted, 995 DTLSReassemblyFailure or DTLSPeerDisconnect (see 996 Section 2.3.2.2). The WTP MAY tear down the DTLS session if it 997 receives frequent DTLSDecapFailure notifications. 999 AC: The AC enters this state when it receives one of the 1000 following DTLS notifications: DTLSAborted, 1001 DTLSReassemblyFailure or DTLSPeerDisconnect (see 1002 Section 2.3.2.2). The WTP MAY tear down the DTLS session if it 1003 receives frequent DTLSDecapFailure notifications. 1005 Configure to Data Check (t): This state transition occurs when the 1006 WTP and AC confirm the configuration. 1008 WTP: The WTP enters this state when it receives a successful 1009 Configuration Status Response message from the AC. The WTP 1010 initializes the EchoInterval timer (see Section 4.6), and 1011 transmits the Change State Event Request message (see 1012 Section 8.6). 1014 AC: This state transition occurs when the AC receives the Change 1015 State Event Request message (see Section 8.6) from the WTP. 1016 The AC responds with a Change State Event Response message (see 1017 Section 8.7). The AC must start the NeighborDeadInterval timer 1018 (see Section 4.6). 1020 Data Check to Run (u): This state transition occurs when the linkage 1021 between the control and data channels has occured, causing the WTP 1022 and AC to enter their normal state of operation. 1024 WTP: The WTP enters this state when it receives a successful 1025 Change State Event Response message from the AC. The WTP 1026 initiates the data channel, which MAY require the establishment 1027 of a DTLS session, starts the DataChannelKeepAlive timer (see 1028 Section 4.6) and transmits a Data Channel Keep Alive packet 1029 (see Section 4.3.1). The WTP then starts the 1030 DataChannelDeadInterval timer (see Section 4.6). 1032 AC: This state transition occurs when the AC receives the Data 1033 Channel Keep Alive packet (see Section 4.3.1), with a Session 1034 ID message element matching that included by the WTP in the 1035 Join Request message. Note that if AC policy is to require the 1036 data channel to be encrypted, this process would also require 1037 the establishment of a data channel DTLS session. Upon 1038 receiving the Data Channel Keep Alive packet, the AC transmits 1039 its own Data Channel Keep Alive packet. 1041 Run to DTLS Teardown (u): This state transition occurs when an error 1042 has occured in the DTLS stack, causing the DTLS session to be 1043 torndown. 1045 WTP: The WTP enters this state when it receives one of the 1046 following DTLS notifications: DTLSAborted, 1047 DTLSReassemblyFailure or DTLSPeerDisconnect (see 1048 Section 2.3.2.2). The WTP MAY tear down the DTLS session if it 1049 receives frequent DTLSDecapFailure notifications. The WTP also 1050 transitions to this state if the underlying reliable 1051 transport's RetransmitCount counter has reached the 1052 MaxRetransmit variable (see Section 4.6). 1054 AC: The AC enters this state when it receives one of the 1055 following DTLS notifications: DTLSAborted, 1056 DTLSReassemblyFailure or DTLSPeerDisconnect (see 1057 Section 2.3.2.2). The WTP MAY tear down the DTLS session if it 1058 receives frequent DTLSDecapFailure notifications. The AC 1059 transitions to this state if the underlying reliable 1060 transport's RetransmitCount counter has reached the 1061 MaxRetransmit variable (see Section 4.6). 1063 Run to Run (5): This is the normal state of operation. 1065 WTP: This is the WTP's normal state of operation. There are many 1066 events that result this state transition: 1068 Configuration Update: The WTP receives a Configuration Update 1069 Request message(see Section 8.4). The WTP MUST respond with 1070 a Configuration Update Response message (see Section 8.5). 1072 Change State Event: The WTP receives a Change State Event 1073 Response message, or determines that it must initiate a 1074 Change State Event Request message, as a result of a failure 1075 or change in the state of a radio. 1077 Echo Request: The WTP sends an Echo Request message 1078 (Section 7.1) or receives the corresponding Echo Response 1079 message, (see Section 7.2) from the AC. 1081 Clear Config Request: The WTP receives a Clear Configuration 1082 Request message (see Section 8.8). The WTP MUST reset its 1083 configuration back to manufacturer defaults. 1085 WTP Event: The WTP sends a WTP Event Request message, 1086 delivering information to the AC (see Section 9.4). The WTP 1087 receives a WTP Event Response message from the AC (see 1088 Section 9.5). 1090 Data Transfer: The WTP sends a Data Transfer Request message 1091 to the AC (see Section 9.6). The WTP receives a Data 1092 Transfer Response message from the AC (see Section 9.7). 1094 Station Configuration Request: The WTP receives a Station 1095 Configuration Request message (see Section 10.1), to which 1096 it MUST respond with a Station Configuration Response 1097 message (see Section 10.2). 1099 AC: This is the AC's normal state of operation: 1101 Configuration Update: The AC sends a Configuration Update 1102 Request message (see Section 8.4) to the WTP to update its 1103 configuration. The AC receives a Configuration Update 1104 Response message (see Section 8.5) from the WTP. 1106 Change State Event: The AC receives a Change State Event 1107 Request message (see Section 8.6), to which it MUST respond 1108 with the Change State Event Response message (see 1109 Section 8.7). 1111 Echo Request: The AC receives an Echo Request message (see 1112 Section 7.1), to which it MUST respond with an Echo Response 1113 message(see Section 7.2). 1115 Clear Config Response: The AC receives a Clear Configuration 1116 Response message from the WTP (see Section 8.9). 1118 WTP Event: The AC receives a WTP Event Request message from 1119 the WTP (see Section 9.4) and MUST generate a corresponding 1120 WTP Event Response message (see Section 9.5). 1122 Data Transfer: The AC receives a Data Transfer Request message 1123 from the WTP (see Section 9.6) and MUST generate a 1124 corresponding Data Transfer Response message (see 1125 Section 9.7). 1127 Station Configuration Request: The AC sends a Station 1128 Configuration Request message (see Section 10.1) or receives 1129 the corresponding Station Configuration Response message 1130 (see Section 10.2) from the WTP. 1132 Run to Reset (x): This state transition is used when either the AC 1133 or WTP tear down the connection. This may occur as part of normal 1134 operation, or due to error conditions. 1136 WTP: The WTP enters the Reset state when it receives a Reset 1137 Request message from the AC. 1139 AC: The AC enters the Reset state when it transmits a Reset 1140 Request message to the WTP. 1142 Reset to DTLS Teardown (y): This transition occurs when the CAPWAP 1143 reset is complete, to terminate the DTLS session. 1145 WTP: This state transition occurs when the WTP receives a Reset 1146 Response message. This causes the WTP to initiate the 1147 DTLSShutdown command (see Section 2.3.2.1). 1149 AC: This state transition occurs when the AC transmits a Reset 1150 Response message. The AC does not invoke the DTLSShutdown 1151 command (see Section 2.3.2.1). 1153 DTLS Teardown to Idle (z): This transition occurs when the DTLS 1154 session has been shutdown. 1156 WTP: This state transition occurs when the WTP has successfully 1157 cleaned up all resources associated with the control plane DTLS 1158 session. The data plane DTLS session is also shutdown, and all 1159 resources freed, if a DTLS session was established for the data 1160 plane. Any timers set for the current instance of the state 1161 machine are also cleared. 1163 AC: This state transition occurs when the AC has successfully 1164 cleaned up all resources associated with the control plane DTLS 1165 session. The data plane DTLS session is also shutdown, and all 1166 resources freed, if a DTLS session was established for the data 1167 plane. Any timers set for the current instance of the state 1168 machine are also cleared. 1170 2.3.2. CAPWAP/DTLS Interface 1172 This section describes the DTLS Commands used by CAPWAP, and the 1173 notifications received from DTLS to the CAPWAP protocol stack. 1175 2.3.2.1. CAPWAP to DTLS Commands 1177 Six commands are defined for the CAPWAP to DTLS API. These 1178 "commands" are conceptual, and may be implemented as one or more 1179 function calls. This API definition is provided to clarify 1180 interactions between the DTLS and CAPWAP components of the integrated 1181 CAPWAP state machine. 1183 Below is a list of the minimal command API: 1185 o DTLSStart is sent to the DTLS component to cause a DTLS session to 1186 be established. Upon invoking the DTLSStart command, the WaitDTLS 1187 timer is started. The WTP initiates this DTLS command, as the AC 1188 does not initiate DTLS sessions. 1190 o DTLSListen is sent to the DTLS component to allow the DTLS 1191 component to listen for incoming DTLS session requests. 1193 o DTLSAccept is sent to the DTLS component to allow the DTLS session 1194 establishment to continue successfully. 1196 o DTLSAbortSession is sent to the DTLS component to cause the 1197 session that is in the process of being established to be aborted. 1198 This command is also sent when the WaitDTLS timer expires. When 1199 this command is executed, the FailedDTLSSessionCount counter is 1200 incremented. 1202 o DTLSShutdown is sent to the DTLS component to cause session 1203 teardown. 1205 o DTLSMtuUpdate is sent by the CAPWAP component to modify the MTU 1206 size used by the DTLS component. The default size is 1468 bytes. 1208 2.3.2.2. DTLS to CAPWAP Notifications 1210 DTLS notifications are defined for the DTLS to CAPWAP API. These 1211 "notifications" are conceptual, and may be implemented in numerous 1212 ways (e.g. as function return values). This API definition is 1213 provided to clarify interactions between the DTLS and CAPWAP 1214 components of the integrated CAPWAP state machine. It is important 1215 to note that the notifications listed below MAY cause the CAPWAP 1216 state machine to jump from one state to another using a state 1217 transition not listed in Section 2.3.1. When a notification listed 1218 below occurs, the target CAPWAP state shown in Figure 3 becomes the 1219 current state. 1221 Below is a list of the API notifications: 1223 o DTLSPeerAuthorize is sent to the CAPWAP component during DTLS 1224 session establishment once the peer's identity has been received. 1225 This notification MAY be used by the CAPWAP component to authorize 1226 the session, based on the peer's identity. The authorization 1227 process will lead to the CAPWAP component initiating either the 1228 DTLSAccept or DTLSAbortSession commands. 1230 o DTLSEstablished is sent to the CAPWAP component to indicate that 1231 that a secure channel now exists, using the parameters provided 1232 during the DTLS initialization process. When this notification is 1233 received, the FailedDTLSSessionCount counter is reset to zero. 1234 When this notification is received, the WaitDTLS timer is stopped. 1236 o DTLSEstablishFail is sent when the DTLS session establishment has 1237 failed, either due to a local error, or due to the peer rejecting 1238 the session establishment. When this notification is received, 1239 the FailedDTLSSessionCount counter is incremented. 1241 o DTLSAuthenticateFail is sent when DTLS session establishment 1242 failed due to an authentication error. When this notification is 1243 received, the FailedDTLSAuthFailCount counter is incremented. 1245 o DTLSAborted is sent to the CAPWAP component to indicate that 1246 session abort (as requested by CAPWAP) is complete; this occurs to 1247 confirm a DTLS session abort, or when the WaitDTLS timer expires. 1248 When this notification is received, the WaitDTLS timer is stopped. 1250 o DTLSReassemblyFailure may be sent to the CAPWAP component to 1251 indicate DTLS fragment reassembly failure. 1253 o DTLSDecapFailure may be sent to the CAPWAP module to indicate a 1254 decapsulation failure. DTLSDecapFailure may be sent to the CAPWAP 1255 module to indicate an encryption/authentication failure. This 1256 notification is intended for informative purposes only, and is not 1257 intended to cause a change in the CAPWAP state machine (see 1258 Section 12.4). 1260 o DTLSPeerDisconnect is sent to the CAPWAP component to indicate the 1261 DTLS session has been torn down. Note that this notification is 1262 only received if the DTLS session has been established. 1264 2.4. Use of DTLS in the CAPWAP Protocol 1266 DTLS is used as a tightly-integrated, secure wrapper for the CAPWAP 1267 protocol. In this document DTLS and CAPWAP are discussed as 1268 nominally distinct entitites; however they are very closely coupled, 1269 and may even be implemented inseparably. Since there are DTLS 1270 library implementations currently available, and since security 1271 protocols (e.g. IPsec, TLS) are often implemented in widely 1272 available acceleration hardware, it is both convenient and forward- 1273 looking to maintain a modular distinction in this document. 1275 This section describes a detailed walk-through of the interactions 1276 between the DTLS module and the CAPWAP module, via 'commands' (CAPWAP 1277 to DTLS) and 'notifications' (DTLS to CAPWAP) as they would be 1278 encountered during the normal course of operation. 1280 2.4.1. DTLS Handshake Processing 1282 Details of the DTLS handshake process are specified in [9]. This 1283 section describes the interactions between the DTLS session 1284 establishment process and the CAPWAP protocol. Note that the 1285 conceptual DTLS state is shown below to help understand the point at 1286 which the DTLS states transition. In the normal case, the DTLS 1287 handshake will proceed as follows (NOTE: this example uses 1288 certificates, but preshared keys are also supported): 1290 ============ ============ 1291 WTP AC 1292 ============ ============ 1293 ClientHello ------> 1294 <------ HelloVerifyRequest 1295 (with cookie) 1297 ClientHello ------> 1298 (with cookie) 1299 <------ ServerHello 1300 <------ Certificate 1301 <------ ServerHelloDone 1303 (WTP callout for AC authorization 1304 occurs in CAPWAP Auth state) 1306 Certificate* 1307 ClientKeyExchange 1308 CertificateVerify* 1309 [ChangeCipherSpec] 1310 Finished ------> 1312 (AC callout for WTP authorization 1313 occurs in CAPWAP Auth state) 1315 [ChangeCipherSpec] 1316 <------ Finished 1318 DTLS, as specified, provides its own retransmit timers with an 1319 exponential back-off. However, DTLS will never terminate the 1320 handshake due to non-responsiveness; instead, DTLS will continue to 1321 increase its back-off timer period. Hence, timing out incomplete 1322 DTLS handshakes is entirely the responsiblity of the CAPWAP module. 1324 The DTLS implementation used by CAPWAP MUST support TLS Session 1325 Resumption. Session resumption is used to establish the DTLS session 1326 used for the data channel. The DTLS implementation on the WTP MUST 1327 return some unique identifier to the CAPWAP module to enable 1328 subsequent establishment of a DTLS-encrypted data channel, if 1329 necessary. 1331 2.4.2. DTLS Session Establishment 1333 The WTP, either through the Discovery process, or through pre- 1334 configuration, determines the AC to connect to. The WTP uses the 1335 DTLSStart command to request that a secure connection be established 1336 to the selected AC. Prior to initiation of the DTLS handshake, the 1337 WTP sets the WaitDTLS timer. Upon receiving the DTLSPeerAuthorize 1338 DTLS notification, the AC sets the WaitDTLS timer. If the 1339 DTLSEstablished notification is not received prior to timer 1340 expiration, the DTLS session is aborted by issuing the 1341 DTLSAbortSession DTLS command. This notification causes the CAPWAP 1342 module to transition to the Idle state. Upon receiving a 1343 DTLSEstablished notification, the WaitDTLS timer is deactivated. 1345 2.4.3. DTLS Error Handling 1347 If the AC does not respond to any DTLS messages sent by the WTP, the 1348 DTLS specification calls for the WTP to retransmit these messages. 1349 If the WaitDTLS timer expires, CAPWAP will issue the DTLSAbortSession 1350 command, causing DTLS to terminate the handshake and remove any 1351 allocated session context. Note that DTLS MAY send a single TLS 1352 Alert message to the AC to indicate session termination. 1354 If the WTP does not respond to any DTLS messages sent by the AC, the 1355 CAPWAP protocol allows for three possiblities, listed below. Note 1356 that DTLS MAY send a single TLS Alert message to the AC to indicate 1357 session termination. 1359 o The message was lost in transit; in this case, the WTP will re- 1360 transmit its last outstanding message, since it did not receive a 1361 reply. 1363 o The WTP sent a DTLS Alert, which was lost in transit; in this 1364 case, the AC's WaitDTLS timer will expire, and the session will be 1365 terminated. 1367 o Communication with the WTP has completely failed; in this case, 1368 the AC's WaitDTLS timer will expire, and the session will be 1369 terminated. 1371 The DTLS specification provides for retransmission of unacknowledged 1372 requests. If retransmissions remain unacknowledged, the WaitDTLS 1373 timer will eventually expire, at which time the CAPWAP component will 1374 terminate the session. 1376 If a cookie fails to validate, this could represent a WTP error, or 1377 it could represent a DoS attack. Hence, AC resource utilization 1378 SHOULD be minimized. The AC MAY log a message indicating the 1379 failure, but SHOULD NOT attempt to reply to the WTP. 1381 Since DTLS handshake messages are potentially larger than the maximum 1382 record size, DTLS supports fragmenting of handshake messages across 1383 multiple records. There are several potential causes of re-assembly 1384 errors, including overlapping and/or lost fragments. The DTLS 1385 component MUST send a DTLSReassemblyFailure notification to the 1386 CAPWAP component. Whether precise information is given along with 1387 notification is an implementation issue, and hence is beyond the 1388 scope of this document. Upon receipt of such an error, the CAPWAP 1389 component SHOULD log an appropriate error message. Whether 1390 processing continues or the DTLS session is terminated is 1391 implementation dependent. 1393 DTLS decapsulation errors consist of three types: decryption errors, 1394 authentication errors, and malformed DTLS record headers. Since DTLS 1395 authenticates the data prior to encapsulation, if decryption fails, 1396 it is difficult to detect this without first attempting to 1397 authenticate the packet. If authentication fails, a decryption error 1398 is also likely, but not guaranteed. Rather than attempt to derive 1399 (and require the implementation of) algorithms for detecting 1400 decryption failures, decryption failures are reported as 1401 authentication failures. The DTLS component MUST provide a 1402 DTLSDecapFailure notification to the CAPWAP component when such 1403 errors occur. If a malformed DTLS record header is detected, the 1404 packets SHOULD be silently discarded, and the receiver MAY log an 1405 error message. 1407 There is currently only one encapsulation error defined: MTU 1408 exceeded. As part of DTLS session establishment, the CAPWAP 1409 component informs the DTLS component of the MTU size. This may be 1410 dynamically modified at any time when the CAPWAP component sends the 1411 DTLSMtuUpdate command to the DTLS component (see Section 2.3.2.1). 1412 The DTLS component returns this notification to the CAPWAP component 1413 whenever a transmission request will result in a packet which exceeds 1414 the MTU. 1416 2.4.4. DTLS EndPoint Authentication and Authorization 1418 DTLS supports endpoint authentication with certificates or preshared 1419 keys. The TLS algorithm suites for each endpoint authentication 1420 method are described below. 1422 2.4.4.1. Authenticating with Certificates 1424 Note that only block ciphers are currently recommended for use with 1425 DTLS. To understand the reasoning behind this, see [17]. At 1426 present, the following algorithms MUST be supported when using 1427 certificates for CAPWAP authentication: 1429 o TLS_RSA_WITH_AES_128_CBC_SHA 1431 The following algorithms SHOULD be supported when using certificates: 1433 o TLS_DH_RSA_WITH_AES_128_CBC_SHA 1435 The following algorithms MAY be supported when using certificates: 1437 o TLS_RSA_WITH_AES_256_CBC_SHA 1439 o TLS_DH_RSA_WITH_AES_256_CBC_SHA 1441 2.4.4.2. Authenticating with Preshared Keys 1443 Pre-shared keys present significant challenges from a security 1444 perspective, and for that reason, their use is strongly discouraged. 1445 Several methods for authenticating with preshared keys are defined 1446 [6], and we focus on the following two: 1448 o PSK key exchange algorithm - simplest method, ciphersuites use 1449 only symmetric key algorithms 1451 o DHE_PSK key exchange algorithm - use a PSK to authenticate a 1452 Diffie-Hellman exchange. These ciphersuites give some additional 1453 protection against dictionary attacks and also provide Perfect 1454 Forward Secrecy (PFS). 1456 The first approach (plain PSK) is susceptible to passive dictionary 1457 attacks; hence, while this alorithm MUST be supported, special care 1458 should be taken when choosing that method. In particular, user- 1459 readable passphrases SHOULD NOT be used, and use of short PSKs SHOULD 1460 be strongly discouraged. 1462 The following cryptographic algorithms MUST be supported when using 1463 preshared keys: 1465 o TLS_PSK_WITH_AES_128_CBC_SHA 1467 o TLS_DHE_PSK_WITH_AES_128_CBC_SHA 1469 The following algorithms MAY be supported when using preshared keys: 1471 o TLS_PSK_WITH_AES_256_CBC_SHA 1473 o TLS_DHE_PSK_WITH_AES_256_CBC_SHA 1475 2.4.4.3. Certificate Usage 1477 Certificate authorization by the AC and WTP is required so that only 1478 an AC may perform the functions of an AC and that only a WTP may 1479 perform the functions of a WTP. This restriction of functions to the 1480 AC or WTP requires that the certificates used by the AC MUST be 1481 distinguishable from the certificate used by the WTP. To accomplish 1482 this differentiation, the x.509 certificates MUST include the 1483 Extended Key Usage (EKU) certificate extension [4]. 1485 The EKU field indicates one or more purposes for which a certificate 1486 may be used. It is an essential part in authorization. Its syntax 1487 is as follows: 1489 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 1491 KeyPurposeId ::= OBJECT IDENTIFIER 1493 Here we define two KeyPurposeId values, one for the WTP and one for 1494 the AC. Inclusion of one of these two values indicates a certificate 1495 is authorized for use by a WTP or AC, respectively. These values are 1496 formatted as id-kp fields. 1498 id-kp OBJECT IDENTIFIER ::= 1499 { iso(1) identified-organization(3) dod(6) internet(1) 1500 security(5) mechanisms(5) pkix(7) 3 } 1502 id-kp-capwapAC OBJECT IDENTIFIER ::= { id-kp 18 } 1504 id-kp-capwapWTP OBJECT IDENTIFIER ::= { id-kp 19 } 1506 For an AC, the id-kp-capwapAC EKU MUST be present in the certificate. 1507 For a WTP, the id-kp-capwapWTP EKU MUST be present in the 1508 certificate. 1510 Part of the CAPWAP certificate validation process includes ensuring 1511 that the proper EKU is included and allowing the CAPWAP session to be 1512 established only if the extension properly represents the device. 1514 The certificate common name (CN) for both the WTP and AC MUST be the 1515 MAC address of that device. The MAC address MUST be formatted as 1516 ASCII HEX, e.g. 01:23:45:67:89:ab. 1518 ACs and WTPs SHOULD authorize (e.g. through access control lists) 1519 certificates of devices to which they are connecting, based on the 1520 MAC address and organizational information specified in the O and OU 1521 fields. The identities specified in the certificates bind a 1522 particular DTLS session to a specific pair of mutually-authenticated 1523 and authorized MAC addresses. 1525 2.4.4.4. PSK Usage 1527 When DTLS uses PSK Ciphersuites, the ServerKeyExchange message MUST 1528 contain the "PSK identity hint" field and the ClientKeyExchange 1529 message MUST contain the "PSK identity" field. These fields are used 1530 to help the WTP select the appropriate PSK for use with the AC, and 1531 then indicate to the AC which key is being used. When PSKs are 1532 provisioned to WTPs and ACs, both the PSK Hint and PSK Identity for 1533 the key MUST be specified. 1535 The PSK Hint SHOULD uniquely identify the AC and the PSK Identity 1536 SHOULD uniquely identify the WTP. It is RECOMMENDED that these hints 1537 and identities be the ASCII HEX-formatted MAC addresses of the 1538 respective devices, since each pairwise combination of WTP and AC 1539 SHOULD have a unique PSK. The PSK hint and identity SHOULD be 1540 sufficient to perform authorization, as simply having knowledge of a 1541 PSK does not necessarily imply authorization. 1543 If a single PSK is being used for multiple devices on a CAPWAP 1544 network, which is NOT RECOMMENDED, the PSK Hint and Identity can no 1545 longer be a MAC address, so appropriate hints and identities SHOULD 1546 be selected to identify the group of devices to which the PSK is 1547 provisioned. 1549 3. CAPWAP Transport 1551 Communication between a WTP and an AC is established according to the 1552 standard UDP client/server model. The CAPWAP protocol supports two 1553 different transport protocols. When used over IPv4, the UDP protocol 1554 is utilized. When CAPWAP is used over IPv6, the UDP-Lite RFC 3828 1555 [13] is used. This section details the specifics of how the CAPWAP 1556 protocol works with IP. 1558 3.1. UDP Transport 1560 One of the CAPWAP protocol requirements is to allow a WTP to reside 1561 behind a firewall and/or Network Address Translation (NAT) device. 1562 Since the connection is initiated by the WTP (client) to the well- 1563 known UDP port of the AC (server), the use of UDP is a logical 1564 choice. The UDP checksum field in CAPWAP packets MUST be set to 1565 zero. 1567 CAPWAP protocol control packets sent between the WTP and the AC use 1568 well known UDP port [to be IANA assigned]. CAPWAP protocol data 1569 packets sent between the WTP and the AC use UDP port [to be IANA 1570 assigned]. 1572 3.2. UDP-Lite Transport 1574 When CAPWAP is run over IPv6, the UDP-Lite is used as the transport. 1575 The reason for using UDP-Lite is because when UDP is run over IPv6, 1576 it MUST NOT have its checksum field set to zero, which increases the 1577 processing cost for each CAPWAP packet. When UDP-Lite is used, the 1578 checksum field MUST have a coverage of 8 RFC 3828 [13]. 1580 As defined in RFC 3828 [13], UDP-Lite uses the same port assignments 1581 as UDP. 1583 3.3. AC Discovery 1585 The AC discovery phase allows the WTP to determine which ACs are 1586 available, and chose the best AC with which to establish a CAPWAP 1587 session. The discovery phase occurs when the WTP enters the optional 1588 Discovery state. A WTP does not need to complete the AC Discovery 1589 phase if it uses a pre-configured AC. This section details the 1590 mechanism used by a WTP to dynamically discover candidate ACs. 1592 A WTP and an AC will frequently not reside in the same IP subnet 1593 (broadcast domain). When this occurs, the WTP must be capable of 1594 discovering the AC, without requiring that multicast services are 1595 enabled in the network. 1597 When the WTP attempts to establish communication with an AC, it sends 1598 the Discovery Request message and receives the Discovery Response 1599 message from the AC(s). The WTP must send the Discovery Request 1600 message to either the limited broadcast IP address (255.255.255.255), 1601 a well known multicast address or to the unicast IP address of the 1602 AC. For IPv6 networks, since broadcast does not exist, the use of 1603 "All ACs multicast address" is used instead. Upon receipt of the 1604 Discovery Request message, the AC sends a Discovery Response message 1605 to the unicast IP address of the WTP, regardless of whether the 1606 Discovery Request message was sent as a broadcast, multicast or 1607 unicast message. 1609 WTP use of a limited IP broadcast, multicast or unicast IP address is 1610 implementation dependent. 1612 When a WTP transmits a Discovery Request message to a unicast 1613 address, the WTP must first obtain the IP address of the AC. Any 1614 static configuration of an AC's IP address on the WTP non-volatile 1615 storage is implementation dependent. However, additional dynamic 1616 schemes are possible, for example: 1618 DHCP: A comma delimited ASCII encoded list of AC IP addresses is 1619 embedded in DHCP code number TBD. An example of the actual format 1620 of the vendor specific payload for IPv4 is of the form "10.1.1.1, 1621 10.1.1.2". 1623 DNS: The DNS name "CAPWAP-AC-Address" MAY be resolvable to one or 1624 more AC addresses. 1626 An AC MAY also communicate alternative ACs to the WTP within the 1627 Discovery Response message through the AC IPv4 List (see 1628 Section 4.5.2) and AC IPv6 List (see Section 4.5.2). The addresses 1629 provided in these two message elements are intended to help the WTP 1630 discover additional ACs through means other than those listed above. 1632 The AC Name with Index message element (see Section 4.5.5), is used 1633 to communicate a list of preferred ACs to the WTP. The WTP SHOULD 1634 attempt to utilize the ACs listed in the order provided by the AC. 1635 The Name to IP Address mapping is handled via the Discovery message 1636 exchange, in which the ACs provide their identity in the AC Name (see 1637 Section 4.5.4) message element in the Discovery Response message. 1639 Once the WTP has received Discovery Response messages from the 1640 candidate ACs, it MAY use other factors to determine the preferred 1641 AC. For instance, each binding defines a WTP Radio Information 1642 message element (see Section 2.1), which the AC includes in Discovery 1643 Response messages. The presence of one or more of these message 1644 elements is used to identify the CAPWAP bindings supported by the AC. 1646 A WTP MAY connect to an AC based on the supported bindings 1647 advertised. 1649 3.4. Fragmentation/Reassembly 1651 While fragmentation and reassembly services are provided by IP, the 1652 CAPWAP protocol also provides such services. Environments where the 1653 CAPWAP protocol is used involve firewall, NAT and "middle box" 1654 devices, which tend to drop IP fragments to minimize possible DoS 1655 attacks. By providing fragmentation and reassembly at the 1656 application layer, any fragmentation required due to the tunneling 1657 component of the CAPWAP protocol becomes transparent to these 1658 intermediate devices. Consequently, the CAPWAP protocol can be used 1659 in any network configuration. 1661 4. CAPWAP Packet Formats 1663 This section contains the CAPWAP protocol packet formats. A CAPWAP 1664 protocol packet consists of a CAPWAP Transport Layer packet header 1665 followed by a CAPWAP message. The CAPWAP message can be either of 1666 type Control or Data, where Control packets carry signaling, and Data 1667 packets carry user payloads. The CAPWAP frame formats for CAPWAP 1668 Data packets, and for DTLS encapsulated CAPWAP Data and Control 1669 packets are defined below. 1671 The CAPWAP Control protocol includes two messages that are never 1672 protected by DTLS: the Discovery Request message and the Discovery 1673 Response message. These messages need to be in the clear to allow 1674 the CAPWAP protocol to properly identify and process them. The 1675 format of these packets are as follows: 1677 CAPWAP Control Packet (Discovery Request/Response): 1678 +-----------------------------------------------------+ 1679 | IP | UDP | CAPWAP | CAPWAP | Control | Message | 1680 | Hdr | Hdr | Preamble| Header | Header | Element(s) | 1681 +-----------------------------------------------------+ 1683 All other CAPWAP control protocol messages MUST be protected via the 1684 DTLS protocol, which ensures that the packets are both authenticated 1685 and encrypted. The format of these packets is as follows: 1687 CAPWAP Control Packet (DTLS Security Required): 1688 +-----------------------------------------------------------------+ 1689 | IP | UDP | CAPWAP | DTLS | CAPWAP | Control| Message | DTLS | 1690 | Hdr | Hdr | Preamble| Hdr | Header | Header | Element(s)| Trlr | 1691 +-----------------------------------------------------------------+ 1692 \---------- authenticated -----------/ 1693 \------------- encrypted ------------/ 1695 The CAPWAP protocol allows optional protection of data packets, using 1696 DTLS. Use of data packet protection is determined by AC policy. The 1697 format of CAPWAP data packets is shown below: 1699 CAPWAP Plain Text Data Packet : 1700 +-----------------------------------------+ 1701 | IP | UDP | CAPWAP | CAPWAP | Wireless | 1702 | Hdr | Hdr | Preamble| Header | Payload | 1703 +-----------------------------------------+ 1705 DTLS Secured CAPWAP Data Packet: 1706 +-------------------------------------------------------+ 1707 | IP | UDP | CAPWAP | DTLS | CAPWAP | Wireless | DTLS | 1708 | Hdr | Hdr | Preamble| Hdr | Hdr | Payload | Trlr | 1709 +-------------------------------------------------------+ 1710 \------ authenticated -----/ 1711 \------- encrypted --------/ 1713 UDP Header: All CAPWAP packets are encapsulated within UDP. Section 1714 Section 3 defines the specific UDP usage. 1716 CAPWAP Preamble: All CAPWAP protocol packets are prefixed with the 1717 CAPWAP Preamble header, used to identify the frame type that 1718 follows. The CAPWAP Preamble header is defined in Section 4.1. 1720 DTLS Header: The DTLS header provides authentication and encrytion 1721 services to the CAPWAP payload it encapsulates. This protocol is 1722 defined in RFC 4347 [9]. 1724 CAPWAP Header: All CAPWAP protocol packets use a common header that 1725 immediately follows the CAPWAP preamble or DTLS header. The 1726 CAPWAP Header is defined in Section 4.2. 1728 Wireless Payload: A CAPWAP protocol packet that contains a wireless 1729 payload is a CAPWAP data packet. The CAPWAP protocol does not 1730 specify the format of the wireless payload, which is defined by 1731 the appropriate wireless standard. Additional information is in 1732 Section 4.3. 1734 Control Header: The CAPWAP protocol includes a signalling component, 1735 known as the CAPWAP control protocol. All CAPWAP control packets 1736 include a Control Header, which is defined in Section 4.4.1. 1737 CAPWAP data packets do not contain a Control Header field. 1739 Message Elements: A CAPWAP Control packet includes one or more 1740 message elements, which are found immediately following the 1741 Control Header. These message elements are in a Type/Length/value 1742 style header, defined in Section 4.5. 1744 A CAPWAP implementation MUST be capable of receiving a reassembled 1745 CAPWAP message of length 4096 bytes. A CAPWAP implementation MAY 1746 indicate that it supports a higher maximum message length, by 1747 including the Maximum Message Length message element, see 1748 Section 4.5.29 in the Join Request message or the Join Response 1749 message. 1751 4.1. CAPWAP Preamble 1753 The CAPWAP Preamble header is used to identify the payload type that 1754 immediately follows, to avoid needing to perform byte comparisons to 1755 determine if the packet is DTLS encrypted or not. The format of the 1756 CAPWAP Preamble is as follows: 1758 0 1 2 3 1759 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 1760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1761 |Version| Type | Reserved | 1762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1764 Version: A 4 bit field which contains the version of CAPWAP used in 1765 this packet. The value for this specification is zero (0). 1767 Payload Type: A 4 bit field which specifies the payload type that 1768 follows the preamble header. The following values are supported: 1770 0 - Clear text. If the packet is received on the data UDP port, 1771 the CAPWAP stack MUST treat the packet as a clear text CAPWAP 1772 data packet. If received on the control UDP port, the CAPWAP 1773 stack MUST treat the packet as a clear text CAPWAP control 1774 packet. If the control packet is not a Discovery Request or 1775 Response packet, the packet MUST be dropped. 1777 1 - DTLS Payload. The packet is a DTLS packet and MAY be a data 1778 or control packet, based on the UDP port it was received on 1779 (see Section 3). 1781 Reserved: The 24-bit field is reserved for future use. All 1782 implementations complying with this protocol MUST set to zero any 1783 bits that are reserved in the version of the protocol supported by 1784 that implementation. Receivers MUST ignore all bits not defined 1785 for the version of the protocol they support. 1787 4.2. CAPWAP Header 1789 All CAPWAP protocol messages are encapsulated using a common header 1790 format, regardless of the CAPWAP control or CAPWAP Data transport 1791 used to carry the messages. However, certain flags are not 1792 applicable for a given transport. Refer to the specific transport 1793 section in order to determine which flags are valid. 1795 The Version field in the CAPWAP header MUST NOT be modified in any 1796 future CAPWAP specifications unless the Version field in the CAPWAP 1797 Preamble Header is modified. The Version field value is used to 1798 parse the CAPWAP headers. 1800 Note that the optional fields defined in this section MUST be present 1801 in the precise order shown below. 1803 0 1 2 3 1804 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 1805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1806 |Version| RID | HLEN | WBID |T|F|L|W|M|K| Flags | 1807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1808 | Fragment ID | Frag Offset |Rsvd | 1809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1810 | (optional) Radio MAC Address | 1811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1812 | (optional) Wireless Specific Information | 1813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1814 | Payload .... | 1815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1817 Version: A 4 bit field which contains the version of the CAPWAP 1818 protocol used in this packet. The value of this field MUST match 1819 the version field set in the CAPWAP preamble header (see 1820 Section 4.1). The reason for this duplicate field is to avoid any 1821 possible tampering of the version field in the preamble header 1822 which is not encrypted or authenticated. 1824 RID: A 5 bit field which contains the Radio ID number for this 1825 packet. Given that MAC Addresses are not necessarily unique 1826 across physical radios in a WTP, the Radio Identifier (RID) field 1827 is used to indiciate which physical radio the message is 1828 associated with. 1830 HLEN: A 5 bit field containing the length of the CAPWAP transport 1831 header in 4 byte words (Similar to IP header length). This length 1832 includes the optional headers. 1834 WBID: A 5 bit field which is the wireless binding identifier. The 1835 identifier will indicate the type of wireless packet type 1836 associated with the radio. The following values are defined: 1838 1 - IEEE 802.11 1839 2 - IEEE 802.16 1841 3 - EPCGlobal 1843 T: The Type 'T' bit indicates the format of the frame being 1844 transported in the payload. When this bit is set to one (1), the 1845 payload has the native frame format indicated by the WBID field. 1846 When this bit is zero (0) the payload is an IEEE 802.3 frame. 1848 F: The Fragment 'F' bit indicates whether this packet is a fragment. 1849 When this bit is one (1), the packet is a fragment and MUST be 1850 combined with the other corresponding fragments to reassemble the 1851 complete information exchanged between the WTP and AC. 1853 L: The Last 'L' bit is valid only if the 'F' bit is set and indicates 1854 whether the packet contains the last fragment of a fragmented 1855 exchange between WTP and AC. When this bit is 1, the packet is 1856 the last fragment. When this bit is 0, the packet is not the last 1857 fragment. 1859 W: The Wireless 'W' bit is used to specify whether the optional 1860 Wireless Specific Information field is present in the header. A 1861 value of one (1) is used to represent the fact that the optional 1862 header is present. 1864 M: The M bit is used to indicate that the Radio MAC Address optional 1865 header is present. This is used to communicate the MAC address of 1866 the receiving radio. 1868 K: The 'Keep-alive' K bit indicates the packet is a Data Channel Keep 1869 Alive packet. This packet is used to map the data channel to the 1870 control channel for the specified Session ID and to maintain 1871 freshness of the data channel. The K bit MUST NOT be set for data 1872 packets containing user data. 1874 Flags: A set of reserved bits for future flags in the CAPWAP header. 1875 All implementations complying with this protocol MUST set to zero 1876 any bits that are reserved in the version of the protocol 1877 supported by that implementation. Receivers MUST ignore all bits 1878 not defined for the version of the protocol they support. 1880 Fragment ID: A 16 bit field whose value is assigned to each group of 1881 fragments making up a complete set. The fragment ID space is 1882 managed individually for every WTP/AC pair. The value of Fragment 1883 ID is incremented with each new set of fragments. The Fragment ID 1884 wraps to zero after the maximum value has been used to identify a 1885 set of fragments. 1887 Fragment Offset: A 13 bit field that indicates where in the payload 1888 this fragment belongs during re-assembly. This field is valid 1889 when the 'F' bit is set to 1. The fragment offset is measured in 1890 units of 8 octets (64 bits). The first fragment has offset zero. 1891 Note the CAPWAP protocol does not allow for overlapping fragments. 1893 Reserved: The 3-bit field is reserved for future use. All 1894 implementations complying with this protocol MUST set to zero any 1895 bits that are reserved in the version of the protocol supported by 1896 that implementation. Receivers MUST ignore all bits not defined 1897 for the version of the protocol they support. 1899 Radio MAC Address: This optional field contains the MAC address of 1900 the radio receiving the packet. This is useful in packets sent 1901 from the WTP to the AC, when the native wireless frame format is 1902 converted to 802.3 by the WTP. This field is only present if the 1903 'M' bit is set. The HLEN field assumes 4 byte alignment, and this 1904 field MUST be padded with zeroes (0x00) if it is not 4 byte 1905 aligned. 1907 The field contains the basic format: 1909 0 1 2 3 1910 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 1911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1912 | Type | MAC Address 1913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1915 Type: The format of the MAC Address field. The following values 1916 are supported: 1918 1 - MAC-48 or EUI-48 [18], which is a 48 bit MAC Address. 1920 2 - EUI-64 [19] which is a 64 bit MAC Address. 1922 MAC Address: The MAC Address of the receiving radio. 1924 Wireless Specific Information: This optional field contains 1925 technology specific information that may be used to carry per 1926 packet wireless information. This field is only present if the 1927 'W' bit is set. The HLEN field assumes 4 byte alignment, and this 1928 field MUST be padded with zeroes (0x00) if it is not 4 byte 1929 aligned. 1931 The Wireless Specific Information field uses the following format: 1933 0 1 2 3 1934 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 1935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1936 | Wireless ID | Length | Data 1937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1939 Wireless ID: The wireless binding identifier. The following 1940 values are defined: 1942 1 - IEEE 802.11 1944 2 - IEEE 802.16 1946 3 - EPCGlobal 1948 Length: The length of the data field 1950 Data: Wireless specific information, defined by the wireless 1951 specific binding. 1953 Payload: This field contains the header for a CAPWAP Data Message or 1954 CAPWAP Control Message, followed by the data contained in the 1955 message. 1957 4.3. CAPWAP Data Messages 1959 There are two different types of CAPWAP data packets, CAPWAP Data 1960 Channel Keep Alive packets and Data Payload packets. The first is 1961 used by the WTP to synchronize the control and data channels, and to 1962 maintain freshness of the data channel. The second is used to 1963 transmit user payloads between the AC and WTP. This section 1964 describes both types of CAPWAP data packet formats. 1966 Both CAPWAP data messages are transmitted on the data channel UDP 1967 port. 1969 4.3.1. CAPWAP Data Keepalive 1971 The CAPWAP Data Channel Keep Alive packet is used to bind the CAPWAP 1972 control channel with the data channel, and to maintain freshness of 1973 the data channel, ensuring that the channel is still functioning. 1974 The CAPWAP Data Channel Keep Alive packet is transmitted by the WTP 1975 when the DataChannelKeepAlive timer expires. When the CAPWAP Data 1976 Channel Keep Alive packet is transmitted, the WTP sets the 1977 DataChannelDeadInterval timer. 1979 In the CAPWAP Data Channel Keep Alive packet, all of the fields in 1980 the CAPWAP header, except the HLEN field and the K bit, are set to 1981 zero upon transmission. Upon receiving a CAPWAP Data Channel Keep 1982 Alive packet, the AC transmits a CAPWAP Data Channel Keep Alive 1983 packet back to the WTP. The contents of the transmitted packet are 1984 identical to the contents of the received packet. 1986 Upon receiving a CAPWAP Data Channel Keep Alive packet, the WTP 1987 cancels the DataChannelDeadInterval timer and resets the 1988 DataChannelKeepAlive timer. The CAPWAP Data Channel Keep Alive 1989 packet is retransmitted by the WTP in the same manner as the CAPWAP 1990 control messages. If the DataChannelDeadInterval timer expires, the 1991 WTP tears down the control DTLS session, and the data DTLS session if 1992 one existed. 1994 The CAPWAP Data Channel Keep Alive packet contains the following 1995 payload immediately following the CAPWAP Header (see Section 4.2) 1997 0 1 2 3 1998 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2000 | Message Element Length | Message Element [0..N] ... 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2003 Message Element Length: The Length field indicates the number of 2004 bytes following the CAPWAP Header. 2006 Message Element[0..N]: The message element(s) carry the information 2007 pertinent to each of the CAPWAP Data Keepalive message. The 2008 following message elements MUST be present in this CAPWAP message: 2010 Session ID, see Section 4.5.35 2012 4.3.2. Data Payload 2014 A CAPWAP protocol Data Payload packet encapsulates a forwarded 2015 wireless frame. The CAPWAP protocol defines two different modes of 2016 encapsulation; IEEE 802.3 and native wireless. IEEE 802.3 2017 encapsulation requires that the bridging function be performed in the 2018 WTP. An IEEE 802.3 encapsulated user payload frame has the following 2019 format: 2021 +------------------------------------------------------+ 2022 | IP Header | UDP Header | CAPWAP Header | 802.3 Frame | 2023 +------------------------------------------------------+ 2025 The CAPWAP protocol also defines the native wireless encapsulation 2026 mode. The format of the encapsulated CAPWAP data frame is subject to 2027 the rules defined by the specific wireless technology binding. Each 2028 wireless technology binding MUST contain a section entitled "Payload 2029 Encapsulation", which defines the format of the wireless payload that 2030 is encapsulated within CAPWAP Data packets. 2032 If the encapsulated frame would exceed the transport layer's MTU, the 2033 sender is responsible for fragmentation of the frame, as specified in 2034 Section 3.4. 2036 4.3.3. Establishment of a DTLS Data Channel 2038 If the AC and WTP are configured to tunnel the data channel over 2039 DTLS, the proper DTLS session must be initiated. To avoid having to 2040 reauthenticate and reauthorize an AC and WTP, the DTLS data channel 2041 MUST be initiated using the TLS session resumption feature [11]. 2043 When establishing the DTLS-encrypted data channel, the WTP MUST 2044 provide the identifier returned during the initialization of the 2045 control channel to the DTLS component so it can perform the 2046 resumption using the proper session information. 2048 The AC DTLS implementation MUST NOT accept a session resumption 2049 request for a DTLS session in which the control channel for the 2050 session has been torn down. 2052 4.4. CAPWAP Control Messages 2054 The CAPWAP Control protocol provides a control channel between the 2055 WTP and the AC. Control messages are divided into the following 2056 message types: 2058 Discovery: CAPWAP Discovery messages are used to identify potential 2059 ACs, their load and capabilities. 2061 Join: CAPWAP Join messages are used by a WTP to request service from 2062 an AC, and for the AC to respond to the WTP. 2064 Control Channel Management: CAPWAP control channel management 2065 messages are used to maintain the control channel. 2067 WTP Configuration Management: The WTP Configuration messages are 2068 used by the AC to deliver a specific configuration to the WTP. 2069 Messages which retrieve statistics from a WTP are also included in 2070 WTP Configuration Management. 2072 Station Session Management: Station Session Management messages are 2073 used by the AC to deliver specific station policies to the WTP. 2075 Device Management Operations: Device management operations are used 2076 to request and deliver a firmware image to the WTP. 2078 Binding Specific CAPWAP Management Messages: Messages in this 2079 category are used by the AC and the WTP to exchange protocol- 2080 specific CAPWAP management messages. These messages may or may 2081 not be used to change the link state of a station. 2083 Discovery, Join, Control Channel Management, WTP Configuration 2084 Management and Station Session Management CAPWAP control messages 2085 MUST be implemented. Device Management Operations messages MAY be 2086 implemented. 2088 CAPWAP control messages sent from the WTP to the AC indicate that the 2089 WTP is operational, providing an implicit keep-alive mechanism for 2090 the WTP. The Control Channel Management Echo Request and Echo 2091 Response messages provide an explicit keep-alive mechanism when other 2092 CAPWAP control messages are not exchanged. 2094 4.4.1. Control Message Format 2096 All CAPWAP control messages are sent encapsulated within the CAPWAP 2097 header (see Section 4.2). Immediately following the CAPWAP header, 2098 is the control header, which has the following format: 2100 0 1 2 3 2101 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 2102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2103 | Message Type | 2104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2105 | Seq Num | Msg Element Length | Flags | 2106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2107 | Msg Element [0..N] ... 2108 +-+-+-+-+-+-+-+-+-+-+-+-+ 2110 4.4.1.1. Message Type 2112 The Message Type field identifies the function of the CAPWAP control 2113 message. The Message Type field is comprised of an IANA Enterprise 2114 Number and an enterprise specific message type number. The first 2115 three octets contain the enterprise number in network byte order, 2116 with zero used for CAPWAP protocol defined message types and the IEEE 2117 802.11 IANA assigned enterprise number 13277 is used for IEEE 802.11 2118 technology specific message types. The last octet is the enterprise 2119 specific message type number, which has a range from 0 to 255. 2121 The message type field is defined as: 2123 Message Type = IANA Enterprise Number * 256 + Enterprise Specific Message Type Number 2125 The CAPWAP protocol reliability mechanism requires that messages be 2126 defined in pairs, consisting of both a Request and a Response 2127 message. The Response message MUST acknowledge the Request message. 2128 The assignment of CAPWAP control Message Type Values always occurs in 2129 pairs. All Request messages have odd numbered Message Type Values, 2130 and all Response messages have even numbered Message Type Values. 2131 The Request value MUST be assigned first. As an example, assigning a 2132 Message Type Value of 3 for a Request message and 4 for a Response 2133 message is valid, while assigning a Message Type Value of 4 for a 2134 Response message and 5 for the corresponding Request message is 2135 invalid. 2137 When a WTP or AC receives a message with a Message Type Value field 2138 that is not recognized and is an odd number, the number in the 2139 Message Type Value Field is incremented by one, and a Response 2140 message with a Message Type Value field containing the incremented 2141 value and containing the Result Code message element with the value 2142 (Unrecognized Request) is returned to the sender of the received 2143 message. If the unknown message type is even, the message is 2144 ignored. 2146 The valid values for CAPWAP Control Message Types are specified in 2147 the table below: 2149 CAPWAP Control Message Message Type 2150 Value 2151 Discovery Request 1 2152 Discovery Response 2 2153 Join Request 3 2154 Join Response 4 2155 Configuration Status 5 2156 Configuration Status Response 6 2157 Configuration Update Request 7 2158 Configuration Update Response 8 2159 WTP Event Request 9 2160 WTP Event Response 10 2161 Change State Event Request 11 2162 Change State Event Response 12 2163 Echo Request 13 2164 Echo Response 14 2165 Image Data Request 15 2166 Image Data Response 16 2167 Reset Request 17 2168 Reset Response 18 2169 Primary Discovery Request 19 2170 Primary Discovery Response 20 2171 Data Transfer Request 21 2172 Data Transfer Response 22 2173 Clear Configuration Request 23 2174 Clear Configuration Response 24 2175 Station Configuration Request 25 2176 Station Configuration Response 26 2178 4.4.1.2. Sequence Number 2180 The Sequence Number Field is an identifier value used to match 2181 Request and Response packets. When a CAPWAP packet with a Request 2182 Message Type Value is received, the value of the Sequence Number 2183 field is copied into the corresponding Response message. 2185 When a CAPWAP control message is sent, the sender's internal sequence 2186 number counter is monotonically incremented, ensuring that no two 2187 pending Request messages have the same Sequence Number. The Sequence 2188 Number field wraps back to zero. 2190 4.4.1.3. Message Element Length 2192 The Length field indicates the number of bytes following the Sequence 2193 Number field. 2195 4.4.1.4. Flags 2197 The Flags field MUST be set to zero. 2199 4.4.1.5. Message Element[0..N] 2201 The message element(s) carry the information pertinent to each of the 2202 control message types. Every control message in this specification 2203 specifies which message elements are permitted. 2205 When a WTP or AC receives a CAPWAP message without a message element 2206 that is specified as mandatory for the CAPWAP message, then the 2207 CAPWAP message is discarded. If the received message was a Request 2208 message for which the corresponding Response message carries message 2209 elements, then a corresponding Response message with a Result Code 2210 message element indicating "Failure - Missing Mandatory Message 2211 Element" is returned to the sender. 2213 When a WTP or AC receives a CAPWAP message with a message element 2214 that the WTP or AC does not recognize, the CAPWAP message is 2215 discarded. If the received message was a Request message for which 2216 the corresponding Response message carries message elements, then a 2217 corresponding Response message with a Result Code message element 2218 indicating "Failure - Unrecognized Message Element" and one or more 2219 Returned Message Element message elements is included, containing the 2220 unrecognized message element(s). 2222 4.4.2. Control Message Quality of Service 2224 It is recommended that CAPWAP control messages be sent by both the AC 2225 and the WTP with an appropriate Quality of Service precedence value, 2226 ensuring that congestion in the network minimizes occurrences of 2227 CAPWAP control channel disconnects. Therefore, a Quality of Service 2228 enabled CAPWAP device SHOULD use the following values: 2230 802.1P: The precedence value of 7 SHOULD be used. 2232 DSCP: The DSCP tag value of 46 SHOULD be used. 2234 4.4.3. Retransmissions 2236 The CAPWAP control protocol operates as a reliable transport. For 2237 each Request message, a Response message is defined, which is used to 2238 acknowledge receipt of the Request message. In addition, the control 2239 header Sequence Number field is used to pair the Request and Response 2240 messages (see Section 4.4.1). 2242 Response messages are not explicitly acknowledged, therefore if a 2243 Response message is not received, the original Request message is 2244 retransmitted. Implementations MAY cache Response messages to 2245 respond to a retransmitted Request messages with minimal local 2246 processing. Retransmitted Request messages MUST NOT be altered by 2247 the sender. The sender MUST assume that the original Request message 2248 was processed, but that the Response message was lost. Any 2249 alterations to the original Request message MUST have a new Sequence 2250 Number, and be treated as a new Request message by the receiver. 2252 After transmitting a Request message, the RetransmitInterval (see 2253 Section 4.6) timer and MaxRetransmit (see Section 4.7) variable are 2254 used to determine if the original Request message needs to be 2255 retransmitted. The RetransmitInterval timer is used the first time 2256 the Request is retransmitted. The timer is then doubled every 2257 subsequent time the same Request message is retransmitted, up to 2258 MaxRetransmit but no more than half the EchoInterval timer (see 2259 Section 4.6.5). Response messages are not subject to these timers. 2261 When a Request message is retransmitted, it MUST be re-encrypted via 2262 the DTLS stack. If the peer had received the Request message, and 2263 the corresponding Response message was lost, it is necessary to 2264 ensure that retransmitted Request messages are not identified as 2265 replays by the DTLS stack. Similarly, any cached Response messages 2266 that are retransmitted as a result of receiving a retransmitted 2267 Request message MUST be re-encrypted via DTLS. 2269 Duplicate Response messages, identified by the Sequence Number field 2270 in the CAPWAP control message header, SHOULD be discarded upon 2271 receipt. 2273 4.5. CAPWAP Protocol Message Elements 2275 This section defines the CAPWAP Protocol message elements which are 2276 included in CAPWAP protocol control messages. 2278 Message elements are used to carry information needed in control 2279 messages. Every message element is identified by the Type Value 2280 field, defined below. The total length of the message elements is 2281 indicated in the message element Length field. 2283 All of the message element definitions in this document use a diagram 2284 similar to the one below in order to depict its format. Note that to 2285 simplify this specification, these diagrams do not include the header 2286 fields (Type and Length). The header field values are defined in the 2287 message element descriptions. 2289 Unless otherwise specified, a control message that lists a set of 2290 supported (or expected) message elements MUST not expect the message 2291 elements to be in any specific order. The sender may include the 2292 message elements in any order. Unless otherwise noted, one message 2293 element of each type is present in a given control message. 2295 Additional message elements may be defined in separate IETF 2296 documents. 2298 The format of a message element uses the TLV format shown here: 2300 0 1 2 3 2301 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 2302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2303 | Type | Length | 2304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2305 | Value ... | 2306 +-+-+-+-+-+-+-+-+ 2308 The 16 bit Type field identifies the information carried in the Value 2309 field and Length (16 bits) indicates the number of bytes in the Value 2310 field. Type field values are allocated as follows: 2312 Usage Type Values 2314 CAPWAP Protocol Message Elements 1-1023 2315 IEEE 802.11 Message Elements 1024-2047 2316 IEEE 802.16 Message Elements 2048 - 3071 2317 EPCGlobal Message Elements 3072 - 4095 2318 Reserved for Future Use 4096 - 65024 2320 The table below lists the CAPWAP protocol Message Elements and their 2321 Type values. 2323 CAPWAP Message Element Type Value 2325 AC Descriptor 1 2326 AC IPv4 List 2 2327 AC IPv6 List 3 2328 AC Name 4 2329 AC Name with Index 5 2330 AC Timestamp 6 2331 Add MAC ACL Entry 7 2332 Add Station 8 2333 Add Static MAC ACL Entry 9 2334 CAPWAP Control IPV4 Address 10 2335 CAPWAP Control IPV6 Address 11 2336 CAPWAP Timers 12 2337 Data Transfer Data 13 2338 Data Transfer Mode 14 2339 Decryption Error Report 15 2340 Decryption Error Report Period 16 2341 Delete MAC ACL Entry 17 2342 Delete Station 18 2343 Delete Static MAC ACL Entry 19 2344 Discovery Type 20 2345 Duplicate IPv4 Address 21 2346 Duplicate IPv6 Address 22 2347 Idle Timeout 23 2348 Image Data 24 2349 Image Identifier 25 2350 Image Info 26 2351 Initiate Download 27 2352 Location Data 28 2353 Maximum Message Length 29 2354 MTU Discovery Padding 30 2355 Radio Administrative State 31 2356 Radio Operational State 32 2357 Result Code 33 2358 Returned Message Element 34 2359 Session ID 35 2360 Statistics Timer 36 2361 Vendor Specific Payload 37 2362 WTP Board Data 38 2363 WTP Descriptor 39 2364 WTP Fallback 40 2365 WTP Frame Tunnel Mode 41 2366 WTP IPv4 IP Address 42 2367 WTP MAC Type 43 2368 WTP Name 44 2369 WTP Operational Statistics 45 2370 WTP Radio Statistics 46 2371 WTP Reboot Statistics 47 2372 WTP Static IP Address Information 48 2374 4.5.1. AC Descriptor 2376 The AC Descriptor message element is used by the AC to communicate 2377 its current state. The value contains the following fields. 2379 0 1 2 3 2380 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 2381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2382 | Stations | Limit | 2383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2384 | Active WTPs | Max WTPs | 2385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2386 | Security | R-MAC Field | Reserved1 | DTLS Policy | 2387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2388 | Vendor Identifier | 2389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2390 | Type=4 | Length | 2391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2392 | Value... 2393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2394 | Vendor Identifier | 2395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2396 | Type=5 | Length | 2397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2398 | Value... 2399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2401 Type: 1 for AC Descriptor 2403 Length: >= 12 2405 Stations: The number of stations currently served by the AC 2407 Limit: The maximum number of stations supported by the AC 2409 Active WTPs: The number of WTPs currently attached to the AC 2411 Max WTPs: The maximum number of WTPs supported by the AC 2413 Security: A 8 bit bit mask specifying the authentication credential 2414 type supported by the AC. The following values are supported (see 2415 Section 2.4.4): 2417 1 - X.509 Certificate Based 2419 2 - Pre-Shared Secret 2421 R-MAC Field: The AC supports the optional Radio MAC Address field 2422 in the CAPWAP transport Header (see Section 4.2). 2424 Reserved: A set of reserved bits for future use. All 2425 implementations complying with this protocol MUST set to zero any 2426 bits that are reserved in the version of the protocol supported by 2427 that implementation. Receivers MUST ignore all bits not defined 2428 for the version of the protocol they support. 2430 DTLS Policy: The AC communicates its policy on the use of DTLS for 2431 the CAPWAP data channel. The AC MAY communicate more than one 2432 supported option, represented by the bit field below. The WTP 2433 MUST abide by one of the options communicated by AC. The 2434 following bit field values are supported: 2436 1 - Clear Text Data Channel Supported 2438 2 - DTLS Enabled Data Channel Supported 2440 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 2441 Network Management Private Enterprise Codes" 2443 Type: Vendor specific encoding of AC information. The following 2444 values are supported. The Hardware and Software Version values 2445 MUST be included. 2447 4 - Hardware Version: The AC's hardware version number. 2449 5 - Software Version: The AC's Software (firmware) version 2450 number. 2452 Length: Length of vendor specific encoding of AC information. 2454 Value: Vendor specific encoding of AC information. 2456 4.5.2. AC IPv4 List 2458 The AC IPv4 List message element is used to configure a WTP with the 2459 latest list of ACs available for the WTP to join. 2461 0 1 2 3 2462 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 2463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2464 | AC IP Address[] | 2465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2467 Type: 2 for AC IPv4 List 2469 Length: >= 4 2471 The AC IP Address: An array of 32-bit integers containing AC IPv4 2472 Addresses. 2474 4.5.3. AC IPv6 List 2476 The AC IPv6 List message element is used to configure a WTP with the 2477 latest list of ACs available for the WTP to join. 2479 0 1 2 3 2480 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 2481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2482 | AC IP Address[] | 2483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2484 | AC IP Address[] | 2485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2486 | AC IP Address[] | 2487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2488 | AC IP Address[] | 2489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2491 Type: 3 for AC IPV6 List 2493 Length: >= 16 2495 The AC IP Address: An array of 128-bit integers containing AC IPv6 2496 Addresses. 2498 4.5.4. AC Name 2500 The AC Name message element contains an UTF-8 representation of the 2501 AC identity. The value is a variable length byte string. The string 2502 is NOT zero terminated. 2504 0 2505 0 1 2 3 4 5 6 7 2506 +-+-+-+-+-+-+-+-+ 2507 | Name ... 2508 +-+-+-+-+-+-+-+-+ 2510 Type: 4 for AC Name 2512 Length: > 0 2514 Name: A variable length UTF-8 encoded string containing the AC's 2515 name 2517 4.5.5. AC Name with Index 2519 The AC Name with Index message element is sent by the AC to the WTP 2520 to configure preferred ACs. The number of instances of this message 2521 element is equal to the number of ACs configured on the WTP. 2523 0 1 2524 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2526 | Index | AC Name... 2527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2529 Type: 5 for AC Name with Index 2531 Length: > 2 2533 Index: The index of the preferred server (1=primary, 2=secondary). 2535 AC Name: A variable length UTF-8 encoded string containing the AC 2536 name. 2538 4.5.6. AC Timestamp 2540 The AC Timestamp message element is sent by the AC to synchronize the 2541 WTP clock. 2543 0 1 2 3 2544 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 2545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2546 | Timestamp | 2547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2549 Type: 6 for AC Timestamp 2551 Length: 4 2553 Timestamp: The AC's current time, allowing all of the WTPs to be 2554 time synchronized in the format defined by Network Time Protocol 2555 (NTP) in RFC 1305 [3]. 2557 4.5.7. Add MAC ACL Entry 2559 The Add MAC Access Control List (ACL) Entry message element is used 2560 by an AC to add a MAC ACL list entry on a WTP, ensuring that the WTP 2561 no longer provides service to the MAC addresses provided in the 2562 message. The MAC Addresses provided in this message element are not 2563 expected to be saved in non-volatile memory on the WTP. 2565 0 1 2 3 2566 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 2567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2568 | Num of Entries| Type | MAC Address ... 2569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2571 Type: 7 for Add MAC ACL Entry 2573 Length: >= 8 2575 Num of Entries: The number of instances of the Type/MAC Addresses 2576 fields in the array. 2578 Type: The format of the following MAC Address field. One of the 2579 following values are supported: 2581 1 - MAC-48 or EUI-48 [18], which is a 48 bit MAC Address. 2583 2 - EUI-64 [19] which is a 64 bit MAC Address. 2585 MAC Address: MAC Addresses to add to the ACL. 2587 4.5.8. Add Station 2589 The Add Station message element is used by the AC to inform a WTP 2590 that it should forward traffic for a station. The Add Station 2591 message element is accompanied by technology specific binding 2592 information element(s) which may include security parameters. 2593 Consequently, the security parameters must be applied by the WTP for 2594 the station. 2596 After station policy has been delivered to the WTP through the Add 2597 Station message element, an AC may change any policies by sending a 2598 modified Add Station message element. When a WTP receives an Add 2599 Station message element for an existing station, it MUST override any 2600 existing state for the station. 2602 0 1 2 3 2603 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 2604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2605 | Radio ID | Type | MAC Address ... 2606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2607 | VLAN Name... 2608 +-+-+-+-+-+-+-+-+ 2610 Type: 8 for Add Station 2612 Length: >= 8 2614 Radio ID: An 8-bit value representing the radio 2616 Type: The format of the following MAC Address field. One of the 2617 following values are supported: 2619 1 - MAC-48 or EUI-48 [18], which is a 48 bit MAC Address. 2621 2 - EUI-64 [19] which is a 64 bit MAC Address. 2623 MAC Address: The station's MAC Address 2625 VLAN Name: An optional variable length UTF-8 encoded string 2626 containing the VLAN Name on which the WTP is to locally bridge 2627 user data. Note this field is only valid with WTPs configured in 2628 Local MAC mode. 2630 4.5.9. Add Static MAC ACL Entry 2632 The Add Static MAC ACL Entry message element is used by an AC to add 2633 a permanent ACL entry on a WTP, ensuring that the WTP no longer 2634 provides any service to the MAC addresses provided in the message. 2635 The MAC Addresses provided in this message element are expected to be 2636 saved in non-volative memory on the WTP. 2638 0 1 2 3 2639 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 2640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2641 | Num of Entries| Type | MAC Address ... 2642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2644 Type: 9 for Add Static MAC ACL Entry 2646 Length: >= 8 2647 Num of Entries: The number of instances of the Type/MAC Addresses 2648 fields in the array. 2650 Type: The format of the following MAC Address field. One of the 2651 following values are supported: 2653 1 - MAC-48 or EUI-48 [18], which is a 48 bit MAC Address. 2655 2 - EUI-64 [19] which is a 64 bit MAC Address. 2657 MAC Address: MAC Addresses to add to the permanent ACL. 2659 4.5.10. CAPWAP Control IPv4 Address 2661 The CAPWAP Control IPv4 Address message element is sent by the AC to 2662 the WTP during the discovery process and is used by the AC to provide 2663 the interfaces available on the AC, and the current number of WTPs 2664 connected. When multiple CAPWAP Control IPV4 Address message 2665 elements are returned, the WTP SHOULD perform load balancing across 2666 the multiple interfaces. 2668 0 1 2 3 2669 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 2670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2671 | IP Address | 2672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2673 | WTP Count | 2674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2676 Type: 10 for CAPWAP Control IPv4 Address 2678 Length: 6 2680 IP Address: The IP Address of an interface. 2682 WTP Count: The number of WTPs currently connected to the interface. 2684 4.5.11. CAPWAP Control IPv6 Address 2686 The CAPWAP Control IPv6 Address message element is sent by the AC to 2687 the WTP during the discovery process and is used by the AC to provide 2688 the interfaces available on the AC, and the current number of WTPs 2689 connected. This message element is useful for the WTP to perform 2690 load balancing across multiple interfaces. 2692 0 1 2 3 2693 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 2694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2695 | IP Address | 2696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2697 | IP Address | 2698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2699 | IP Address | 2700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2701 | IP Address | 2702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2703 | WTP Count | 2704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2706 Type: 11 for CAPWAP Control IPv6 Address 2708 Length: 18 2710 IP Address: The IP Address of an interface. 2712 WTP Count: The number of WTPs currently connected to the interface. 2714 4.5.12. CAPWAP Timers 2716 The CAPWAP Timers message element is used by an AC to configure 2717 CAPWAP timers on a WTP. 2719 0 1 2720 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2722 | Discovery | Echo Request | 2723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2725 Type: 12 for CAPWAP Timers 2727 Length: 2 2729 Discovery: The number of seconds between CAPWAP Discovery messages, 2730 when the WTP is in the discovery phase. 2732 Echo Request: The number of seconds between WTP Echo Request CAPWAP 2733 messages. The default value for this message element is specified 2734 in Section 4.6.5. 2736 4.5.13. Data Transfer Data 2738 The Data Transfer Data message element is used by the WTP to provide 2739 information to the AC for debugging purposes. 2741 0 1 2 2742 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2744 | Data Type | Data Length | Data .... 2745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2747 Type: 13 for Data Transfer Data 2749 Length: >= 3 2751 Data Type: An 8-bit value the type of information being sent. The 2752 following values are supported: 2754 1 - WTP Crash Data 2756 2 - WTP Memory Dump 2758 Data Length: Length of data field. 2760 Data: Debug information. 2762 4.5.14. Data Transfer Mode 2764 The Data Transfer Mode message element is used by the WTP to indicate 2765 the type of data transfer information it is sending to the AC for 2766 debugging purposes. 2768 0 2769 0 1 2 3 4 5 6 7 2770 +-+-+-+-+-+-+-+-+ 2771 | Data Type | 2772 +-+-+-+-+-+-+-+-+ 2774 Type: 14 for Data Transfer Mode 2776 Length: 1 2778 Data Type: An 8-bit value the type of information being requested. 2779 The following values are supported: 2781 1 - WTP Crash Data 2783 2 - WTP Memory Dump 2785 4.5.15. Decryption Error Report 2787 The Decryption Error Report message element value is used by the WTP 2788 to inform the AC of decryption errors that have occurred since the 2789 last report. Note that this error reporting mechanism is not used if 2790 encryption and decryption services are provided in the AC. 2792 0 1 2 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 2794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2795 | Radio ID |Num Of Entries | Type |MAC Address... 2796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2798 Type: 15 for Decryption Error Report 2800 Length: >= 9 2802 Radio ID: The Radio Identifier refers to an interface index on the 2803 WTP. 2805 Num of Entries: The number of instances of the Type/MAC Addresses 2806 fields in the array. 2808 Type: The format of the following MAC Address field. One of the 2809 following values are supported: 2811 1 - MAC-48 or EUI-48 [18], which is a 48 bit MAC Address. 2813 2 - EUI-64 [19] which is a 64 bit MAC Address. 2815 MAC Address: MAC addresses of the station that has caused 2816 decryption errors. 2818 4.5.16. Decryption Error Report Period 2820 The Decryption Error Report Period message element value is used by 2821 the AC to inform the WTP how frequently it should send decryption 2822 error report messages. Note that this error reporting mechanism is 2823 not used if encryption and decryption services are provided in the 2824 AC. 2826 0 1 2 2827 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2829 | Radio ID | Report Interval | 2830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2832 Type: 16 for Decryption Error Report Period 2834 Length: 3 2836 Radio ID: The Radio Identifier refers to an interface index on the 2837 WTP. 2839 Report Interval: A 16-bit unsigned integer indicating the time, in 2840 seconds. The default value for this message element can be found 2841 in Section 4.7.8. 2843 4.5.17. Delete MAC ACL Entry 2845 The Delete MAC ACL Entry message element is used by an AC to delete a 2846 MAC ACL entry on a WTP, ensuring that the WTP provides service to the 2847 MAC addresses provided in the message. 2849 0 1 2 3 2850 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 2851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2852 | Num of Entries| Type | MAC Address ... 2853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2855 Type: 17 for Delete MAC ACL Entry 2857 Length: >= 8 2859 Num of Entries: The number of instances of the Type/MAC Addresses 2860 fields in the array. 2862 Type: The format of the following MAC Address field. One of the 2863 following values are supported: 2865 1 - MAC-48 or EUI-48 [18], which is a 48 bit MAC Address. 2867 2 - EUI-64 [19] which is a 64 bit MAC Address. 2869 MAC Address: An array of MAC Addresses to delete from the ACL. 2871 4.5.18. Delete Station 2873 The Delete Station message element is used by the AC to inform a WTP 2874 that it should no longer provide service to a particular station. 2875 The WTP MUST terminate service to the station immediately upon 2876 receiving this message element. 2878 The transmission of a Delete Station message element could occur for 2879 various reasons, including for administrative reasons, or if the 2880 station has roamed to another WTP. 2882 The Delete Station message element MAY be sent by the WTP, in the WTP 2883 Event Request message, to inform the AC that a particular station is 2884 no longer being provided service. This could occur as a result of an 2885 Idle Timeout (see section 4.4.43), due to internal resource shortages 2886 or for some other reason. 2888 0 1 2 3 2889 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 2890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2891 | Radio ID | Type | MAC Address... 2892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2894 Type: 18 for Delete Station 2896 Length: >= 8 2898 Radio ID: An 8-bit value representing the radio 2900 Type: The format of the following MAC Address field. One of the 2901 following values are supported: 2903 1 - MAC-48 or EUI-48 [18], which is a 48 bit MAC Address. 2905 2 - EUI-64 [19] which is a 64 bit MAC Address. 2907 MAC Address: The station's MAC Address 2909 4.5.19. Delete Static MAC ACL Entry 2911 The Delete Static MAC ACL Entry message element is used by an AC to 2912 delete a previously added static MAC ACL entry on a WTP, ensuring 2913 that the WTP provides service to the MAC addresses provided in the 2914 message. 2916 0 1 2 3 2917 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 2918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2919 | Num of Entries| Type | MAC Address ... 2920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2922 Type: 19 for Delete Static MAC ACL Entry 2924 Length: >= 8 2926 Num of Entries: The number of instances of the Type/MAC Addresses 2927 fields in the array. 2929 Type: The format of the following MAC Address field. One of the 2930 following values are supported: 2932 1 - MAC-48 or EUI-48 [18], which is a 48 bit MAC Address. 2934 2 - EUI-64 [19] which is a 64 bit MAC Address. 2936 MAC Address: An array of MAC Addresses to delete from the static 2937 MAC ACL entry. 2939 4.5.20. Discovery Type 2941 The Discovery Type message element is used by the WTP to indicate how 2942 it has come to know about the existence of the AC to which it is 2943 sending the Discovery Request message. 2945 0 2946 0 1 2 3 4 5 6 7 2947 +-+-+-+-+-+-+-+-+ 2948 | Discovery Type| 2949 +-+-+-+-+-+-+-+-+ 2951 Type: 20 for Discovery Type 2953 Length: 1 2955 Discovery Type: An 8-bit value indicating how the WTP discovered 2956 the AC. The following values are supported: 2958 0 - Unknown 2960 1 - Static Configuration 2961 2 - DHCP 2963 3 - DNS 2965 4 - AC Referral (used when the AC was configured either through 2966 the AC IPv4 List or AC IPv6 List message element) 2968 4.5.21. Duplicate IPv4 Address 2970 The Duplicate IPv4 Address message element is used by a WTP to inform 2971 an AC that it has detected another IP device using the same IP 2972 address that the WTP is currently using. 2974 The WTP MUST transmit this message element with the status set to 1 2975 after it has detected a duplicate IP address. When the WTP detects 2976 that the duplicate IP address has been cleared, it MUSY send this 2977 message element with the status set to 0. 2979 0 1 2 3 2980 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 2981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2982 | IP Address | 2983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2984 | Status | Type | MAC Address ... 2985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2987 Type: 21 for Duplicate IPv4 Address 2989 Length: >= 12 2991 IP Address: The IP Address currently used by the WTP. 2993 Status: The status of the duplicate IP address. The value MUST be 2994 set to 1 when a duplicate address is detected, and 0 when the 2995 duplicate address has been cleared. 2997 Type: The format of the following MAC Address field. One of the 2998 following values are supported: 3000 1 - MAC-48 or EUI-48 [18], which is a 48 bit MAC Address. 3002 2 - EUI-64 [19] which is a 64 bit MAC Address. 3004 MAC Address: The MAC Address of the offending device. 3006 4.5.22. Duplicate IPv6 Address 3008 The Duplicate IPv6 Address message element is used by a WTP to inform 3009 an AC that it has detected another host using the same IP address 3010 that the WTP is currently using. 3012 The WTP MUST transmit this message element with the status set to 1 3013 after it has detected a duplicate IP address. When the WTP detects 3014 that the duplicate IP address has been cleared, it MUST send this 3015 message element with the status set to 0. 3017 0 1 2 3 3018 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 3019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3020 | IP Address | 3021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3022 | IP Address | 3023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3024 | IP Address | 3025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3026 | IP Address | 3027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3028 | Status | Type | MAC Address ... 3029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3031 Type: 23 for Duplicate IPv6 Address 3033 Length: >= 24 3035 IP Address: The IP Address currently used by the WTP. 3037 Status: The status of the duplicate IP address. The value MUST be 3038 set to 1 when a duplicate address is detected, and 0 when the 3039 duplicate address has been cleared. 3041 Type: The format of the following MAC Address field. One of the 3042 following values are supported: 3044 1 - MAC-48 or EUI-48 [18], which is a 48 bit MAC Address. 3046 2 - EUI-64 [19] which is a 64 bit MAC Address. 3048 MAC Address: The MAC Address of the offending device. 3050 4.5.23. Idle Timeout 3052 The Idle Timeout message element is sent by the AC to the WTP to 3053 provide the idle timeout value that the WTP SHOULD enforce for its 3054 active stations. The value applies to all radios on the WTP. 3056 0 1 2 3 3057 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 3058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3059 | Timeout | 3060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3062 Type: 23 for Idle Timeout 3064 Length: 4 3066 Timeout: The current idle timeout to be enforced by the WTP. The 3067 default value for this message element is specified in 3068 Section 4.7.5. 3070 4.5.24. Image Data 3072 The Image Data message element is present in the Image Data Request 3073 message sent by the AC and contains the following fields. 3075 0 1 2 3 3076 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 3077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3078 | Opcode | Value ... 3079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3081 Type: 24 for Image Data 3083 Length: >= 1 3085 Opcode: An 8-bit value representing the transfer opcode. The 3086 following values are supported: 3088 1 - Image data is included 3090 2 - Last Image Data Block is included (EOF) 3092 5 - An error occurred. Transfer is aborted 3094 Value: The Image Data field contains up to 1024 characters. If the 3095 block being sent is the last one, the Opcode is set to 2. The AC 3096 MAY opt to abort the data transfer by setting the Opcode to 5. 3097 When the Opcode is 5, the Value field has a zero length. 3099 4.5.25. Image Identifier 3101 The Image Identifier message element is sent by the AC to the WTP and 3102 is used to indicate the expected active software version that is to 3103 be run on the WTP. The value is a variable length UTF-8 encoded 3104 string, which is NOT zero terminated. 3106 0 1 2 3 3107 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 3108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3109 | Vendor Identifier | 3110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3111 | Value... 3112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3114 Type: 25 for Image Identifier 3116 Length: >= 1 3118 Value: A variable length UTF-8 encoded string containing the 3119 firmware identifier to be run on the WTP. 3121 4.5.26. Image Information 3123 The Image Information message element is present in the Image Data 3124 Response message sent by the AC to the WTP and contains the following 3125 fields. 3127 0 1 2 3 3128 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 3129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3130 | File Size | Hash | 3131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3132 | Hash | 3133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3134 | Hash | 3135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3136 | Hash | 3137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3138 | Hash | 3139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3141 Type: 26 for Image Information 3143 Length: 18 3145 File Size: A 16-bit value containing the size of the file that will 3146 be transfered by the AC to the WTP. 3148 Hash: A 16 octet hash of the image. The hash is computed using 3149 MD5, using the following pseudo-code: 3151 #include 3152 CapwapCreateHash(char *hash, char *image, int image_len) 3153 { 3154 MD_CTX context; 3156 MDInit (&context); 3157 MDUpdate (&context, buffer, len); 3158 MDFinal (hash, &context); 3159 } 3161 4.5.27. Initiate Download 3163 The Initiate Download message element is used by the AC to inform the 3164 WTP that the WTP should initiate a firmware upgrade. The WTP 3165 subsequently transmits an Image Data Request message which includes 3166 the Image Download message element. This message element does not 3167 contain any data. 3169 Type: 27 for Initiate Download 3171 Length: 0 3173 4.5.28. Location Data 3175 The Location Data message element is a variable length byte UTF-8 3176 encoded string containing user defined location information (e.g. 3177 "Next to Fridge"). This information is configurable by the network 3178 administrator, and allows the WTP location to be determined. The 3179 string is not zero terminated. 3181 0 3182 0 1 2 3 4 5 6 7 3183 +-+-+-+-+-+-+-+-+- 3184 | Location ... 3185 +-+-+-+-+-+-+-+-+- 3187 Type: 28 for Location Data 3189 Length: > 0 3191 Location: A non-zero terminated UTF-8 encoded string containing the 3192 WTP location. 3194 4.5.29. Maximum Message Length 3196 The Maximum Message Length message element is included in the Join 3197 Request message by the WTP to indicate the maximum CAPWAP message 3198 length that it supports to the AC. The Maximum Message Length 3199 message element is optionally included in Join Response message by 3200 the AC to indicate the maximum CAPWAP message length that it supports 3201 to the WTP. 3203 0 1 2 3204 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 3206 | Maximum Message Length | 3207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 3209 Type: 29 for Maximim Message Length 3211 Length: 2 3213 Maximum Message Length An 16-bit unsigned integer indicating the 3214 maximum message length. 3216 4.5.30. MTU Discovery Padding 3218 The MTU Discovery Padding message element is used as padding to 3219 perform MTU discovery, and MUST contain octets of value 0xFF, of any 3220 length 3222 0 3223 0 1 2 3 4 5 6 7 3224 +-+-+-+-+-+-+-+-+ 3225 | Padding... 3226 +-+-+-+-+-+-+-+- 3228 Type: 30 for MTU Discovery Padding 3229 Length: variable 3231 Pad: A variable length pad. 3233 4.5.31. Radio Administrative State 3235 The Radio Administrative State message element is used to communicate 3236 the state of a particular radio. The Radio Administrative State 3237 message element is sent by the AC to change the state of the WTP. 3238 The WTP saves the value, to ensure that it remains across WTP resets. 3239 The WTP communicates this message element during the configuration 3240 phase, in the Configuration Status Request message, to ensure that AC 3241 has the WTP radio current administrative state settings. The message 3242 element contains the following fields. 3244 0 1 3245 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3247 | Radio ID | Admin State | 3248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3250 Type: 31 for Radio Administrative State 3252 Length: 2 3254 Radio ID: An 8-bit value representing the radio to configure. The 3255 Radio ID field may also include the value of 0xff, which is used 3256 to identify the WTP. If an AC wishes to change the administrative 3257 state of a WTP, it includes 0xff in the Radio ID field. 3259 Admin State: An 8-bit value representing the administrative state 3260 of the radio. The default value for the Admin State field is 3261 listed in Section 4.7.1. The following values are supported: 3263 1 - Enabled 3265 2 - Disabled 3267 4.5.32. Radio Operational State 3269 The Radio Operational State message element is sent by the WTP to the 3270 AC to communicate a radio's operational state. This message element 3271 is included in the Configuration Update Response message by the WTP 3272 if it was requested to change the state of its radio, via the Radio 3273 Administrative State message element, but was unable to comply to the 3274 request. This message element is included in the Change State Event 3275 message when a WTP radio state was changed unexpectedly. This could 3276 occur due to a hardware failure. Note that the operational state 3277 setting is not saved on the WTP, and therefore does not remain across 3278 WTP resets. The value contains three fields, as shown below. 3280 0 1 2 3281 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 3282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3283 | Radio ID | State | Cause | 3284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3286 Type: 32 for Radio Operational State 3288 Length: 3 3290 Radio ID: The Radio Identifier refers to an interface index on the 3291 WTP. A value of 0xFF is invalid, as it is not possible to change 3292 the WTP's operational state. 3294 State: An 8-bit boolean value representing the state of the radio. 3295 A value of one disables the radio, while a value of two enables 3296 it. 3298 Cause: When a radio is inoperable, the cause field contains the 3299 reason the radio is out of service. The following values are 3300 supported: 3302 0 - Normal 3304 1 - Radio Failure 3306 2 - Software Failure 3308 3 - Administratively Set 3310 4.5.33. Result Code 3312 The Result Code message element value is a 32-bit integer value, 3313 indicating the result of the Request message corresponding to the 3314 Sequence Number included in the Response message. 3316 0 1 2 3 3317 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 3318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3319 | Result Code | 3320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3322 Type: 33 for Result Code 3324 Length: 4 3326 Result Code: The following values are defined: 3328 0 Success 3330 1 Failure (AC List message element MUST be present) 3332 2 Success (NAT detected) 3334 3 Join Failure (unspecified) 3336 4 Join Failure (Resource Depletion) 3338 5 Join Failure (Unknown Source) 3340 6 Join Failure (Incorrect Data) 3342 7 Join Failure (Session ID already in use) 3344 8 Join Failure (WTP Hardware not supported) 3346 9 Join Failure (Binding Not Supported) 3348 10 Reset Failure (Unable to Reset) 3350 11 Reset Failure (Firmware Write Error) 3352 12 Configuration Failure (Unable to Apply Requested Configuration 3353 - Service Provided Anyhow) 3355 13 Configuration Failure (Unable to Apply Requested Configuration 3356 - Service Not Provided) 3358 14 Image Data Error (Invalid Checksum) 3360 15 Image Data Error (Invalid Data Length) 3362 16 Image Data Error (Other Error) 3364 17 Image Data Error (Image Already Present) 3366 18 Message Unexpected (Invalid in current state) 3367 19 Message Unexpected (Unrecognized Request) 3369 20 Failure - Missing Mandatory Message Element 3371 21 Failure - Unrecognized Message Element 3373 4.5.34. Returned Message Element 3375 The Returned Message Element is sent by the WTP in the Change State 3376 Event Request message to communicate to the AC which message elements 3377 in the Configuration Status Response it was unable to apply locally. 3378 The Returned Message Element message element contains a result code 3379 indicating the reason that the configuration could not be applied, 3380 and encapsulates the failed message element. 3382 0 1 2 3383 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 3384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3385 | Reason | Message Element... 3386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3388 Type: 34 for Returned Message Element 3390 Length: >= 1 3392 Reason: The reason why the configuration in the offending message 3393 element could not be applied by the WTP. 3395 1 - Unknown Message Element 3397 2 - Unsupported Message Element 3399 3 - Unknown Message Element Value 3401 4 - Unsupported Message Element Value 3403 Message Element: The Message Element field encapsulates the message 3404 element sent by the AC in the Configuration Status Response 3405 message that caused the error. 3407 4.5.35. Session ID 3409 The Session ID message element value contains a randomly generated 3410 unsigned 32-bit integer. 3412 0 1 2 3 3413 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 3414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3415 | Session ID | 3416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3418 Type: 35 for Session ID 3420 Length: 16 3422 Session ID: A 32-bit unsigned integer used as a random session 3423 identifier 3425 4.5.36. Statistics Timer 3427 The Statistics Timer message element value is used by the AC to 3428 inform the WTP of the frequency with which it expects to receive 3429 updated statistics. 3431 0 1 3432 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3434 | Statistics Timer | 3435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3437 Type: 36 for Statistics Timer 3439 Length: 2 3441 Statistics Timer: A 16-bit unsigned integer indicating the time, in 3442 seconds. The default value for this timer is specified in 3443 Section 4.6.13. 3445 4.5.37. Vendor Specific Payload 3447 The Vendor Specific Payload message element is used to communicate 3448 vendor specific information between the WTP and the AC. The message 3449 element uses the following format: 3451 0 1 2 3 3452 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 3453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3454 | Vendor Identifier | 3455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3456 | Element ID | Value... | 3457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3459 Type: 37 for Vendor Specific 3461 Length: >= 7 3463 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 3464 Network Management Private Enterprise Codes" [16] 3466 Element ID: A 16-bit Element Identifier which is managed by the 3467 vendor. 3469 Value: The value associated with the vendor specific element. 3471 4.5.38. WTP Board Data 3473 The WTP Board Data message element is sent by the WTP to the AC and 3474 contains information about the hardware present. 3476 0 1 2 3 3477 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 3478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3479 | Vendor Identifier | 3480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3481 | Type=0 | Length | 3482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3483 | Value... 3484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3485 | Type=1 | Length | 3486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3487 | Value... 3488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3489 | Optional additional vendor specific WTP board data TLVs..... 3490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3492 Type: 38 for WTP Board Data 3494 Length: >=14 3496 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 3497 Network Management Private Enterprise Codes" 3499 Type: The following values are supported: 3501 0 - WTP Model Number: The WTP Model Number MUST be included in 3502 the WTP Board Data message element. 3504 1 - WTP Serial Number: The WTP Serial Number MUST be included in 3505 the WTP Board Data message element. 3507 2 - Board ID: A hardware identifier, which MAY be included in 3508 the WTP Board Data mesage element. 3510 3 - Board Revision A revision number of the board, which MAY be 3511 included in the WTP Board Data message element. 3513 4 - Base MAC Addres The WTP's Base MAC Address, which MAY be 3514 assigned to the primary Ethernet interface. 3516 4.5.39. WTP Descriptor 3518 The WTP Descriptor message element is used by a WTP to communicate 3519 its current hardware and software (firmware) configuration. The 3520 value contains the following fields. 3522 0 1 2 3 3523 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 3524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3525 | Max Radios | Radios in use | Encryption Capabilities | 3526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3527 | Vendor Identifier | 3528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3529 | Type=0 | Length | 3530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3531 | Value... 3532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3533 | Vendor Identifier | 3534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3535 | Type=1 | Length | 3536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3537 | Value... 3538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3539 | Vendor Identifier | 3540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3541 | Type=2 | Length | 3542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3543 | Value... 3544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3545 | Vendor Identifier | 3546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3547 | Type=3 | Length | 3548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3549 | Value... 3550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3552 Type: 39 for WTP Descriptor 3554 Length: >= 31 3556 Max Radios: An 8-bit value representing the number of radios (where 3557 each radio is identified via the Radio ID field) supported by the 3558 WTP. 3560 Radios in use: An 8-bit value representing the number of radios in 3561 use in the WTP. 3563 Encryption Capabilities: This 16-bit field is used by the WTP to 3564 communicate its capabilities to the AC. A WTP that does not have 3565 any encryption capabilities sets this field to zero (0). Refer to 3566 the specific wireless binding for further specification of the 3567 Encryption Capabilities field. 3569 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 3570 Network Management Private Enterprise Codes". 3572 Type: The following values are supported. The Hardware Version, 3573 Active Software Version, and Boot Version values MUST be included. 3574 Zero or more Other Software Version values MAY be included. 3576 0 - Hardware Version: The WTP hardware version number. 3578 1 - Active Software Version: The WTP running software version 3579 number. 3581 2 - Boot Version: The WTP boot loader version number. 3583 3 - Other Software Version: The WTP non-running software 3584 (firmware) version number. 3586 Length: Length of vendor specific encoding of WTP information. 3588 Value: Vendor specific data of WTP information encoded in the UTF-8 3589 format. 3591 4.5.40. WTP Fallback 3593 The WTP Fallback message element is sent by the AC to the WTP to 3594 enable or disable automatic CAPWAP fallback in the event that a WTP 3595 detects its preferred AC, and is not currently connected to it. 3597 0 3598 0 1 2 3 4 5 6 7 3599 +-+-+-+-+-+-+-+-+ 3600 | Mode | 3601 +-+-+-+-+-+-+-+-+ 3603 Type: 40 for WTP Fallback 3605 Length: 1 3607 Mode: The 8-bit value indicates the status of automatic CAPWAP 3608 fallback on the WTP. When enabled, if the WTP detects that its 3609 primary AC is available, and that the WTP is not connected to the 3610 primary AC, the WTP SHOULD automatically disconnect from its 3611 current AC and reconnect to its primary AC. If disabled, the WTP 3612 will only reconnect to its primary AC through manual intervention 3613 (e.g., through the Reset Request message). The default value for 3614 this field is specified in Section 4.7.10. The following values 3615 are supported: 3617 1 - Enabled 3619 2 - Disabled 3621 4.5.41. WTP Frame Tunnel Mode 3623 The WTP Frame Tunnel Mode message element allows the WTP to 3624 communicate the tunneling modes of operation which it supports to the 3625 AC. A WTP that advertises support for all types allows the AC to 3626 select which type will be used, based on its local policy. 3628 0 3629 0 1 2 3 4 5 6 7 3630 +-+-+-+-+-+-+-+-+ 3631 | Tunnel Mode | 3632 +-+-+-+-+-+-+-+-+ 3634 Type: 41 for WTP Frame Tunnel Mode 3636 Length: 1 3638 Frame Tunnel Mode: The Frame Tunnel mode specifies the tunneling 3639 modes for station data that are supported by the WTP. The 3640 following values are supported: 3642 1 - Local Bridging: When Local Bridging is used, the WTP does 3643 not tunnel user traffic to the AC; all user traffic is locally 3644 bridged. This value MUST NOT be used when the WTP MAC Type is 3645 set to Split-MAC. 3647 2 - 802.3 Frame Tunnel Mode: The 802.3 Frame Tunnel Mode 3648 requires the WTP and AC to encapsulate all user payload as 3649 native IEEE 802.3 frames (see Section 4.3). All user traffic 3650 is tunneled to the AC. This value MUST NOT be used when the 3651 WTP MAC Type is set to Split-MAC. 3653 4 - Native Frame Tunnel Mode: Native Frame Tunnel mode requires 3654 the WTP and AC to encapsulate all user payloads as native 3655 wireless frames, as defined by the wireless binding (see for 3656 example Section 4.3). 3658 7 - All: The WTP is capable of supporting all frame tunnel 3659 modes. 3661 4.5.42. WTP IPv4 IP Address 3663 The WTP IPv4 address is used to perform NAT detection. 3665 0 1 2 3 3666 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 3667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3668 | WTP IPv4 IP Address | 3669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3671 Type: 42 for WTP IPv4 IP Address 3673 Length: 4 3675 WTP IPv4 IP Address: The IPv4 address from which the WTP is sending 3676 packets. This field is used for NAT detection. 3678 4.5.43. WTP MAC Type 3680 The WTP MAC-Type message element allows the WTP to communicate its 3681 mode of operation to the AC. A WTP that advertises support for both 3682 modes allows the AC to select the mode to use, based on local policy. 3684 0 3685 0 1 2 3 4 5 6 7 3686 +-+-+-+-+-+-+-+-+ 3687 | MAC Type | 3688 +-+-+-+-+-+-+-+-+ 3690 Type: 43 for WTP MAC Type 3692 Length: 1 3694 MAC Type: The MAC mode of operation supported by the WTP. The 3695 following values are supported 3697 0 - Local-MAC: Local-MAC is the default mode that MUST be 3698 supported by all WTPs. 3700 1 - Split-MAC: Split-MAC support is optional, and allows the AC 3701 to receive and process native wireless frames. 3703 2 - Both: WTP is capable of supporting both Local-MAC and Split- 3704 MAC. 3706 4.5.44. WTP Name 3708 The WTP Name message element is a variable length byte UTF-8 encoded 3709 string. The string is not zero terminated. 3711 0 3712 0 1 2 3 4 5 6 7 3713 +-+-+-+-+-+-+-+-+- 3714 | WTP Name ... 3715 +-+-+-+-+-+-+-+-+- 3717 Type: 44 for WTP Name 3719 Length: variable 3721 WTP Name: A non-zero terminated UTF-8 encoded string containing the 3722 WTP name. 3724 4.5.45. WTP Operational Statistics 3726 The WTP Operational Statistics message element is sent by the WTP to 3727 the AC to provide statistics related to the operation of the WTP. 3729 0 1 2 3 3730 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 3731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3732 | Radio ID | Tx Queue Level | Wireless Link Frames per Sec | 3733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3735 Type: 45 for WTP Operational Statistics 3737 Length: 4 3739 Radio ID: The radio ID of the radio to which the statistics apply. 3741 Wireless Transmit Queue Level: The percentage of Wireless Transmit 3742 queue utilization, calculated as the sum of utilized transmit 3743 queue lengths divided by the sum of maximum transmit queue 3744 lengths, multiplied by 100. The Wireless Transmit Queue Level is 3745 representative of congestion conditions over wireless interfaces 3746 between the WTP and stations. 3748 Wireless Link Frames per Sec: The number of frames transmitted or 3749 received per second by the WTP over the air interface. 3751 4.5.46. WTP Radio Statistics 3753 The WTP Radio Statistics message element is sent by the WTP to the AC 3754 to communicate statistics on radio behavior and reasons why the WTP 3755 radio has been reset. 3757 0 1 2 3 3758 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 3759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3760 | Radio ID | Last Fail Type| Reset Count | 3761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3762 | SW Failure Count | HW Failure Count | 3763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3764 | Other Failure Count | Unknown Failure Count | 3765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3766 | Config Update Count | Channel Change Count | 3767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3768 | Band Change Count | Current Noise Floor | 3769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3771 Type: 46 for WTP Radio Statistics 3773 Length: 20 3775 Radio ID: The radio ID of the radio to which the statistics apply. 3777 Last Failure Type: The last WTP failure. The following values are 3778 supported: 3780 0 - Statistic Not Supported 3782 1 - Software Failure 3784 2 - Hardware Failure 3786 3 - Other Failure 3788 255 - Unknown (e.g., WTP doesn't keep track of info) 3790 Reset Count: The number of times that that the radio has been 3791 reset. 3793 SW Failure Count: The number of times that the radio has failed due 3794 to software related reasons. 3796 HW Failure Count: The number of times that the radio has failed due 3797 to hardware related reasons. 3799 Other Failure Count: The number of times that the radio has failed 3800 due to known reasons, other than software or hardware failure. 3802 Unknown Failure Count: The number of times that the radio has 3803 failed for unknown reasons. 3805 Config Update Count: The number of times that the radio 3806 configuration has been updated. 3808 Channel Change Count: The number of times that the radio channel 3809 has been changed. 3811 Band Change Count: The number of times that the radio has changed 3812 frequency bands. 3814 Current Noise Floor: A signed integer which indicates the noise 3815 floor of the radio receiver in units of dBm. 3817 4.5.47. WTP Reboot Statistics 3819 The WTP Reboot Statistics message element is sent by the WTP to the 3820 AC to communicate reasons why WTP reboots have occurred. 3822 0 1 2 3 3823 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 3824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3825 | Reboot Count | AC Initiated Count | 3826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3827 | Link Failure Count | SW Failure Count | 3828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3829 | HW Failure Count | Other Failure Count | 3830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3831 | Unknown Failure Count |Last Failure Type| 3832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3834 Type: 47 for WTP Reboot Statistics 3836 Length: 15 3838 Reboot Count: The number of reboots that have occurred due to a WTP 3839 crash. A value of 65535 implies that this information is not 3840 available on the WTP. 3842 AC Initiated Count: The number of reboots that have occurred at the 3843 request of a CAPWAP protocol message, such as a change in 3844 configuration that required a reboot or an explicit CAPWAP 3845 protocol reset request. A value of 65535 implies that this 3846 information is not available on the WTP. 3848 Link Failure Count: The number of times that a CAPWAP protocol 3849 connection with an AC has failed due to link failure. 3851 SW Failure Count: The number of times that a CAPWAP protocol 3852 connection with an AC has failed due to software related reasons. 3854 HW Failure Count: The number of times that a CAPWAP protocol 3855 connection with an AC has failed due to hardware related reasons. 3857 Other Failure Count: The number of times that a CAPWAP protocol 3858 connection with an AC has failed due to known reasons, other than 3859 AC initiated, link, SW or HW failure. 3861 Unknown Failure Count: The number of times that a CAPWAP protocol 3862 connection with an AC has failed for unknown reasons. 3864 Last Failure Type: The failure type of the most recent WTP failure. 3865 The following values are supported: 3867 0 - Not Supported 3869 1 - AC Initiated (see Section 9.2) 3871 2 - Link Failure 3873 3 - Software Failure 3875 4 - Hardware Failure 3877 5 - Other Failure 3879 255 - Unknown (e.g., WTP doesn't keep track of info) 3881 4.5.48. WTP Static IP Address Information 3883 The WTP Static IP Address Information message element is used by an 3884 AC to configure or clear a previously configured static IP address on 3885 a WTP. 3887 0 1 2 3 3888 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 3889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3890 | IP Address | 3891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3892 | Netmask | 3893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3894 | Gateway | 3895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3896 | Static | 3897 +-+-+-+-+-+-+-+-+ 3899 Type: 48 for WTP Static IP Address Information 3901 Length: 13 3903 IP Address: The IP Address to assign to the WTP. This field is 3904 only valid if the static field is set to one. 3906 Netmask: The IP Netmask. This field is only valid if the static 3907 field is set to one. 3909 Gateway: The IP address of the gateway. This field is only valid 3910 if the static field is set to one. 3912 Netmask: The IP Netmask. This field is only valid if the static 3913 field is set to one. 3915 Static: An 8-bit boolean stating whether the WTP should use a 3916 static IP address or not. A value of zero disables the static IP 3917 address, while a value of one enables it. 3919 4.6. CAPWAP Protocol Timers 3921 This section contains the CAPWAP timers. 3923 4.6.1. ChangeStatePendingTimer 3925 The maximum time, in seconds, the AC will wait for the Change State 3926 Event Request from the WTP after having transmitted a successful 3927 Configuration Status Response message. The default value is 25 3928 seconds. 3930 4.6.2. DataChannelDeadInterval 3932 The minimum time, in seconds, a WTP MUST wait without having received 3933 a Data Channel Keep Alive packet before the destination for the Data 3934 Channel Keep Alive packets may be considered dead. The value of this 3935 timer MUST be no less than 2*DataChannelKeepAlive seconds and no 3936 greater that 240 seconds. 3938 Default: 5 3940 4.6.3. DiscoveryInterval 3942 The minimum time, in seconds, that a WTP MUST wait after receiving a 3943 Discovery Response message, before initiating a DTLS handshake. 3945 Default: 5 3947 4.6.4. DTLSSessionDelete 3949 The minimum time, in seconds, a WTP MUST wait for DTLS session 3950 deletion. 3952 Default: 5 3954 4.6.5. EchoInterval 3956 The minimum time, in seconds, between sending Echo Request messages 3957 to the AC with which the WTP has joined. 3959 Default: 30 3961 4.6.6. KeyLifetime 3963 The maximum time, in seconds, which a CAPWAP DTLS session key is 3964 valid. 3966 Default: 28800 3968 4.6.7. MaxDiscoveryInterval 3970 The maximum time allowed between sending Discovery Request messages, 3971 in seconds. This value MUST be no less than 2 seconds and no greater 3972 than 180 seconds. 3974 Default: 20 seconds. 3976 4.6.8. MaxFailedDTLSSessionRetry 3978 The maximum number of failed DTLS session establishment attempts 3979 before the CAPWAP device enters a silent period. 3981 Default: 3. 3983 4.6.9. NeighborDeadInterval 3985 The minimum time, in seconds, a WTP MUST wait without having received 3986 an Echo Response message to its Echo Request message, before the 3987 destination for the Echo Request may be considered dead. This value 3988 MUST be no less than 2*EchoInterval seconds and no greater than 240 3989 seconds. 3991 Default: 60 3993 4.6.10. ResponseTimeout 3995 The minimum time, in seconds, in which the WTP or AC must respond to 3996 a CAPWAP Request message. 3998 Default: 1 4000 4.6.11. RetransmitInterval 4002 The minimum time, in seconds, in which a non-acknowledged CAPWAP 4003 packet will be retransmitted. 4005 Default: 3 4007 4.6.12. SilentInterval 4009 For a WTP, this is the minimum time, in seconds, a WTP MUST wait 4010 before it MAY again send Discovery Request messages or attempt to a 4011 establish DTLS session. For an AC, this is the minimum time, in 4012 seconds, during which the AC SHOULD ignore all CAPWAP and DTLS 4013 packets received from the WTP that is in the Sulking state. 4015 Default: 30 4017 4.6.13. StatisticsTimer 4019 The default Statistics Interval is 120 seconds. 4021 4.6.14. WaitDTLS 4023 The maximum time, in seconds, a WTP MUST wait without having received 4024 a DTLS Handshake message from an AC. This timer must be greater than 4025 30 seconds. 4027 Default: 60 4029 4.6.15. WaitJoin 4031 The maximum time, in seconds, after which the DTLS session has been 4032 established that the AC will wait before receiving a Join Request 4033 message. This timer must be greater than 30 seconds. 4035 Default: 60 4037 4.7. CAPWAP Protocol Variables 4039 A WTP or AC that implements the CAPWAP Discovery phase MUST allow for 4040 the following variables to be configured by system management; 4041 default values are specified, making explicit configuration 4042 unnecessary in many cases. If the default values are explicitly 4043 overriden by the AC, the WTP MUST save the values sent by the AC. 4045 4.7.1. AdminState 4047 The default Administrative State value is enabled (1). 4049 4.7.2. DiscoveryCount 4051 The number of Discovery Request messages transmitted by a WTP to a 4052 single AC. This is a monotonically increasing counter. 4054 4.7.3. FailedDTLSAuthFailCount 4056 The number of failed DTLS session establishment attempts due to 4057 authentication failures. 4059 4.7.4. FailedDTLSSessionCount 4061 The number of failed DTLS session establishment attempts. 4063 4.7.5. IdleTimeout 4065 The default Idle Timeout is 300 seconds. 4067 4.7.6. MaxDiscoveries 4069 The maximum number of Discovery Request messages that will be sent 4070 after a WTP boots. 4072 Default: 10 4074 4.7.7. MaxRetransmit 4076 The maximum number of retransmissions for a given CAPWAP packet 4077 before the link layer considers the peer dead. 4079 Default: 5 4081 4.7.8. ReportInterval 4083 The default Report Interval is 120 seconds. 4085 4.7.9. RetransmitCount 4087 The number of retransmissions for a given CAPWAP packet. This is a 4088 monotonically increasing counter. 4090 4.7.10. WTPFallBack 4092 The default WTP Fallback value is enabled (1). 4094 4.8. WTP Saved Variables 4096 In addition to the values defined in Section 4.7, the following 4097 values SHOULD be saved on the WTP in non-volatile memory. CAPWAP 4098 wireless bindings may define additional values that SHOULD be stored 4099 on the WTP. 4101 4.8.1. AdminRebootCount 4103 The number of times the WTP has rebooted administratively, defined in 4104 Section 4.5.47. 4106 4.8.2. FrameEncapType 4108 For WTPs that support multiple Frame Encapsulation Types, it is 4109 useful to save the value configured by the AC. The Frame 4110 Encapsulation Type is defined in Section 4.5.41. 4112 4.8.3. LastRebootReason 4114 The reason why the WTP last rebooted, defined in Section 4.5.47. 4116 4.8.4. MacType 4118 For WTPs that support multiple MAC Types, it is useful to save the 4119 value configured by the AC. The MACType is defined in 4120 Section 4.5.43. 4122 4.8.5. PreferredACs 4124 The preferred ACs, with the index, defined in Section 4.5.5. 4126 4.8.6. RebootCount 4128 The number of times the WTP has rebooted, defined in Section 4.5.47. 4130 4.8.7. Static ACL Table 4132 The static ACL table saved on the WTP, as configured by the Add 4133 Static MAC ACL Entry message element, see Section 4.5.9. 4135 4.8.8. Static IP Address 4137 The static IP Address assigned to the WTP, as configured by the WTP 4138 Static IP Address Information message element (see Section 4.5.48). 4140 4.8.9. WTPLinkFailureCount 4142 The number of times the link to the AC has failed, see 4143 Section 4.5.47. 4145 4.8.10. WTPLocation 4147 The WTP Location, defined in Section 4.5.28. 4149 4.8.11. WTPName 4151 The WTP Name, defined in Section 4.5.44. 4153 5. CAPWAP Discovery Operations 4155 The Discovery messages are used by a WTP to determine which ACs are 4156 available to provide service, and the capabilities and load of the 4157 ACs. 4159 5.1. Discovery Request Message 4161 The Discovery Request message is used by the WTP to automatically 4162 discover potential ACs available in the network. The Discovery 4163 Request message provides ACs with the primary capabilities of the 4164 WTP. A WTP must exchange this information to ensure subsequent 4165 exchanges with the ACs are consistent with the WTP's functional 4166 characteristics. 4168 Discovery Request messages MUST be sent by a WTP in the Discover 4169 state after waiting for a random delay less than 4170 MaxDiscoveryInterval, after a WTP first comes up or is 4171 (re)initialized. A WTP MUST send no more than the maximum of 4172 MaxDiscoveries Discovery Request messages, waiting for a random delay 4173 less than MaxDiscoveryInterval between each successive message. 4175 This is to prevent an explosion of WTP Discovery Request messages. 4176 An example of this occurring is when many WTPs are powered on at the 4177 same time. 4179 Discovery Request messages MUST be sent by a WTP when no Echo 4180 Response messages are received for NeighborDeadInterval and the WTP 4181 returns to the Idle state. Discovery Request messages are sent after 4182 NeighborDeadInterval. They MUST be sent after waiting for a random 4183 delay less than MaxDiscoveryInterval. A WTP MAY send up to a maximum 4184 of MaxDiscoveries Discovery Request messages, waiting for a random 4185 delay less than MaxDiscoveryInterval between each successive message. 4187 If a Discovery Response message is not received after sending the 4188 maximum number of Discovery Request messages, the WTP enters the 4189 Sulking state and MUST wait for an interval equal to SilentInterval 4190 before sending further Discovery Request messages. 4192 Upon receiving a Discovery Request message, the AC will respond with 4193 a Discovery Response message sent to the address in the source 4194 address of the received Discovery Request message. 4196 It is possible for the AC to receive a cleartext Discovery Request 4197 message while a DTLS session is already active with the WTP. This is 4198 most likely the case if the WTP has rebooted, perhaps due to a 4199 software or power failure, but could also be caused by a DoS attack. 4200 In such cases, any WTP state, including the state machine instance, 4201 MUST NOT be cleared until another DTLS session has been successfully 4202 established, communicated via the DTLSSessionEstablished DTLS 4203 notification (see Section 2.3.2.2). 4205 The binding specific WTP Radio Information message element (see 4206 Section 2.1) is included in the Discovery Request message to 4207 advertise WTP support for one or more CAPWAP bindings. 4209 The Discovery Request message is sent by the WTP when in the 4210 Discovery State. The AC does not transmit this message. 4212 The following message elements MUST be included in the Discovery 4213 Request message: 4215 o Discovery Type, see Section 4.5.20 4217 o WTP Board Data, see Section 4.5.38 4219 o WTP Descriptor, see Section 4.5.39 4221 o WTP Frame Tunnel Mode, see Section 4.5.41 4223 o WTP MAC Type, see Section 4.5.43 4225 o WTP Radio Information message element(s)that the WTP supports; 4226 These are defined by the individual link layer CAPWAP Binding 4227 Protocols (see Section 2.1). 4229 5.2. Discovery Response Message 4231 The Discovery Response message provides a mechanism for an AC to 4232 advertise its services to requesting WTPs. 4234 When a WTP receives a Discovery Response message, it MUST wait for an 4235 interval not less than DiscoveryInterval for receipt of additional 4236 Discovery Response messages. After the DiscoveryInterval elapses, 4237 the WTP enters the DTLS-Init state and selects one of the ACs that 4238 sent a Discovery Response message and send a DTLS Handshake to that 4239 AC. 4241 One or more binding specific WTP Radio Information message elements 4242 (see Section 2.1) are included in the Discovery Request message to 4243 advertise AC support for the CAPWAP bindings. The AC MAY include 4244 only the bindings it shares in common with the WTP, known through the 4245 WTP Radio Information message elements received in the Discovery 4246 Request message, or it MAY include all of the bindings supported. 4247 The WTP MAY use the supported bindings in its AC decision process. 4248 Note that if the WTP joins an AC that does not support a specific 4249 CAPWAP binding, service for that binding MUST NOT be provided by the 4250 WTP. 4252 The Discovery Response message is sent by the AC when in the Idle 4253 State. The WTP does not transmit this message. 4255 The following message elements MUST be included in the Discovery 4256 Response Message: 4258 o AC Descriptor, see Section 4.5.1 4260 o AC Name, see Section 4.5.4 4262 o WTP Radio Information message element(s)that the AC supports; 4263 These are defined by the individual link layer CAPWAP Binding 4264 Protocols (see Section 2.1 for more information). 4266 o One of the following message elements MUST be included in the 4267 Discovery Response Message: 4269 * CAPWAP Control IPv4 Address, see Section 4.5.10 4271 * CAPWAP Control IPv6 Address, see Section 4.5.11 4273 5.3. Primary Discovery Request Message 4275 The Primary Discovery Request message is sent by the WTP to determine 4276 whether its preferred (or primary) AC is available. 4278 A Primary Discovery Request message is sent by a WTP when it has a 4279 primary AC configured, and is connected to another AC. This 4280 generally occurs as a result of a failover, and is used by the WTP as 4281 a means to discover when its primary AC becomes available. Since the 4282 WTP only has a single instance of the CAPWAP state machine, the 4283 Primary Discovery Request is sent by the WTP when in the Run State. 4284 The AC does not transmit this message. 4286 The frequency of the Primary Discovery Request messages should be no 4287 more often than the sending of the Echo Request message. 4289 Upon receipt of a Primary Discovery Request message, the AC responds 4290 with a Primary Discovery Response message sent to the address in the 4291 source address of the received Primary Discovery Request message. 4293 The following message elements MUST be included in the Primary 4294 Discovery Request message. 4296 o Discovery Type, see Section 4.5.20 4298 o WTP Board Data, see Section 4.5.38 4300 o WTP Descriptor, see Section 4.5.39 4302 o WTP Frame Tunnel Mode, see Section 4.5.41 4304 o WTP MAC Type, see Section 4.5.43 4306 o WTP Radio Information message element(s)that the WTP supports; 4307 These are defined by the individual link layer CAPWAP Binding 4308 Protocols (see Section 2.1 for more information). 4310 5.4. Primary Discovery Response 4312 The Primary Discovery Response message enables an AC to advertise its 4313 availability and services to requesting WTPs that are configured to 4314 have the AC as its primary AC. 4316 The Primary Discovery Response message is sent by an AC after 4317 receiving a Primary Discovery Request message. 4319 When a WTP receives a Primary Discovery Response message, it may 4320 establish a CAPWAP protocol connection to its primary AC, based on 4321 the configuration of the WTP Fallback Status message element on the 4322 WTP. 4324 The Primary Discovery Response message is sent by the AC when in the 4325 Idle State. The WTP does not transmit this message. 4327 The following message elements MUST be included in the Primary 4328 Discovery Response message. 4330 o AC Descriptor, see Section 4.5.1 4332 o AC Name, see Section 4.5.4 4334 o WTP Radio Information message element(s)that the AC supports; 4335 These are defined by the individual link layer CAPWAP Binding 4336 Protocols (see Section 2.1 for more information). 4338 One of the following message elements MUST be included in the 4339 Discovery Response Message: 4341 o CAPWAP Control IPv4 Address, see Section 4.5.10 4342 o CAPWAP Control IPv6 Address, see Section 4.5.11 4344 6. CAPWAP Join Operations 4346 The Join Request message is used by a WTP to request service from an 4347 AC after a DTLS connection is established to that AC. The Join 4348 Response message is used by the the AC to indicate that it will or 4349 will not provide service. 4351 6.1. Join Request 4353 The Join Request message is used by a WTP to request service through 4354 the AC. A Join Request message is sent by a WTP after (optionally) 4355 receiving one or more Discovery Response messages, and completion of 4356 DTLS session establishment. When an AC receives a Join Request 4357 message it responds with a Join Response message. 4359 Upon completion of the DTLS handshake, and receiving the 4360 DTLSEstablished notification, the WTP sends the Join Request message 4361 to the AC. When the AC is notified of the DTLS session 4362 establishment, it does not clear the WaitDTLS timer until it has 4363 received the Join Request message, at which time it sends a Join 4364 Response message to the WTP, indicating success or failure. 4366 One or more WTP Radio Information message elements (see Section 2.1) 4367 are included in the Join Request to request service for the CAPWAP 4368 bindings by the AC. Including a binding that is unsupported by the 4369 AC will result in a failed Join Response. 4371 If the AC rejects the Join Request, it sends a Join Response message 4372 with a failure indication and initiates an abort of the DTLS session 4373 via the DTLSAbort command. 4375 If an invalid (i.e. malformed) Join Request message is received, the 4376 message MUST be silently discarded by the AC. No response is sent to 4377 the WTP. The AC SHOULD log this event. 4379 The Join Request is sent by the WTP when in the Join State. The AC 4380 does not transmit this message. 4382 The following message elements MUST be included in the Join Request 4383 message. 4385 o Location Data, see Section 4.5.28 4387 o WTP Board Data, see Section 4.5.38 4389 o WTP Descriptor, see Section 4.5.39 4390 o WTP IPv4 IP Address, see Section 4.5.42 4392 o WTP Name, see Section 4.5.44 4394 o Session ID, see Section 4.5.35 4396 o WTP Frame Tunnel Mode, see Section 4.5.41 4398 o WTP MAC Type, see Section 4.5.43 4400 o WTP Radio Information message element(s)that the WTP supports; 4401 These are defined by the individual link layer CAPWAP Binding 4402 Protocols (see Section 2.1 for more information). 4404 The following message element MAY be included in the Join Request 4405 message. 4407 o Maximum Message Length, see Section 4.5.29 4409 o WTP Reboot Statistics, see Section 4.5.47 4411 6.2. Join Response 4413 The Join Response message is sent by the AC to indicate to a WTP that 4414 it is capable and willing to provide service to the WTP. 4416 The WTP, receiving a Join Response message, checks for success or 4417 failure. If the message indicates success, the WTP clears the 4418 WaitDTLS timer for the session and proceeds to the Configure state. 4420 If the WaitDTLS Timer expires prior to reception of the Join Response 4421 message, the WTP MUST terminate the handshake, deallocate session 4422 state and initiate the DTLSAbort command. 4424 If an invalid (malformed) Join Response message is received, the WTP 4425 SHOULD log an informative message detailing the error. This error 4426 MUST be treated in the same manner as AC non-responsiveness. The 4427 WaitDTLS timer will eventually expire, and the WTP may (if it is so 4428 configured) attempts to join a new AC. 4430 If one of the WTP Radio Information message elements (see 4431 Section 2.1) in the Join Request message requested support for a 4432 CAPWAP binding which the AC does not support, the AC sets the Result 4433 Code message element to "Binding Not Supported". 4435 The AC includes the Image Identifier message element to indicate the 4436 software version it expects the WTP to run. This information is used 4437 to determine whether the WTP MUST either change its currently running 4438 firmware image, or download a new version (see Section 9.1.1). 4440 The Join Response message is sent by the AC when in the Join State. 4441 The WTP does not transmit this message. 4443 The following message elements MAY be included in the Join Response 4444 message. 4446 o AC IPv4 List, see Section 4.5.2 4448 o AC IPv6 List, see Section 4.5.3 4450 o Image Identifier, see Section 4.5.25 4452 o Maximum Message Length, see Section 4.5.29 4454 The following message elements MUST be included in the Join Response 4455 message. 4457 o Result Code, see Section 4.5.33 4459 o AC Descriptor, see Section 4.5.1 4461 o AC Name, see Section 4.5.4 4463 o WTP Radio Information message element(s)that the AC supports; 4464 These are defined by the individual link layer CAPWAP Binding 4465 Protocols (see Section 2.1). 4467 One of the following message elements MUST be included in the 4468 Discovery Response Message: 4470 o CAPWAP Control IPv4 Address, see Section 4.5.10 4472 o CAPWAP Control IPv6 Address, see Section 4.5.11 4474 7. Control Channel Management 4476 The Control Channel Management messages are used by the WTP and AC to 4477 maintain a control communication channel. CAPWAP control messages, 4478 such as the WTP Event Request message sent from the WTP to the AC 4479 indicate to the AC that the WTP is operational. When such control 4480 messages are not being sent, the Echo Request and Echo Response 4481 messages are used to maintain the control communication channel. 4483 7.1. Echo Request 4485 The Echo Request message is a keep-alive mechanism for CAPWAP control 4486 messages. 4488 Echo Request messages are sent periodically by a WTP in the Run state 4489 (see Section 2.3) to determine the state of the control connection 4490 between the WTP and the AC. The Echo Request message is sent by the 4491 WTP when the EchoInterval timer expires. The WTP MUST start its 4492 NeighborDeadInterval timer when the EchoInterval timer expires. 4494 The Echo Request message is sent by the WTP when in the Run State. 4495 The AC does not transmit this message. 4497 The Echo Request message carries no message elements. 4499 When an AC receives an Echo Request message it responds with an Echo 4500 Response message. 4502 7.2. Echo Response 4504 The Echo Response message acknowledges the Echo Request message. 4506 An Echo Response message is sent by an AC after receiving an 4507 EchoRequest message. After transmitting the Echo Response message, 4508 the AC SHOULD reset its EchoInterval timer. If another Echo Request 4509 message or other control message is not received by the AC when the 4510 timer expires, the AC SHOULD consider the WTP to be no longer 4511 reachable. 4513 The Echo Response message is sent by the AC when in the Run State. 4514 The WTP does not transmit this message. 4516 The Echo Response message carries no message elements. 4518 When a WTP receives an Echo Response message it stops the 4519 NeighborDeadInterval timer, and initializes the EchoInterval to the 4520 configured value. 4522 If the NeighborDeadInterval timer expires prior to receiving an Echo 4523 Response message, or other control message, the WTP enters the Idle 4524 state. 4526 8. WTP Configuration Management 4528 WTP Configuration messages are used to exchange configuration 4529 information between the AC and the WTP. 4531 8.1. Configuration Consistency 4533 The CAPWAP protocol provides flexibility in how WTP configuration is 4534 managed. A WTP has two options: 4536 1. The WTP retains no configuration and accepts the configuration 4537 provided by the AC. 4539 2. The WTP retains the configuration of parameters provided by the AC 4540 that are non-default values. 4542 If the WTP opts to save configuration locally, the CAPWAP protocol 4543 state machine defines the Configure state, which allows for 4544 configuration exchange. In the Configure state, the WTP sends its 4545 current configuration overrides to the AC via the Configuration 4546 Status message. A configuration override is a non-default parameter. 4547 As an example, in the CAPWAP protocol, the default antenna 4548 configuration is internal omni antenna. A WTP that either has no 4549 internal antennas, or has been explicitly configured by the AC to use 4550 external antennas, sends its antenna configuration during the 4551 configure phase, allowing the AC to become aware of the WTP's current 4552 configuration. 4554 Once the WTP has provided its configuration to the AC, the AC sends 4555 its configuration to the WTP. This allows the WTP to receive 4556 configuration and policies from the AC. 4558 The AC maintains a copy of each active WTP configuration. There is 4559 no need for versioning or other means to identify configuration 4560 changes. If a WTP becomes inactive, the AC MAY delete the inactive 4561 WTP configuration. If a WTP fails, and connects to a new AC, the WTP 4562 provides its overridden configuration parameters, allowing the new AC 4563 to be aware of the WTP configuration. 4565 This model allows for resiliency in case of an AC failure, ensuring 4566 another AC can provide service to the WTP. A new AC would be 4567 automatically updated with WTP configuration changes, eliminating the 4568 need for inter-AC communication and the need for all ACs to be aware 4569 of the configuration of all WTPs in the network. 4571 Once the CAPWAP protocol enters the Run state, the WTPs begin to 4572 provide service. It is common for administrators to require that 4573 configuration changes be made while the network is operational. 4575 Therefore, the Configuration Update Request is sent by the AC to the 4576 WTP to make these changes at run-time. 4578 8.1.1. Configuration Flexibility 4580 The CAPWAP protocol provides the flexibility to configure and manage 4581 WTPs of varying design and functional characteristics. When a WTP 4582 first discovers an AC, it provides primary functional information 4583 relating to its type of MAC and to the nature of frames to be 4584 exchanged. The AC configures the WTP appropriately. The AC also 4585 establishes corresponding internal state for the WTP. 4587 8.2. Configuration Status 4589 The Configuration Status message is sent by a WTP to deliver its 4590 current configuration to the AC. 4592 The Configuration Status message carries binding specific message 4593 elements. Refer to the appropriate binding for the definition of 4594 this structure. 4596 When an AC receives a Configuration Status message it acts upon the 4597 content of the message and responds to the WTP with a Configuration 4598 Status Response message. 4600 The Configuration Status message includes multiple Radio 4601 Administrative State message elements, one for the WTP, and one for 4602 each radio in the WTP. 4604 The Configuration Status message is sent by the WTP when in the 4605 Configure State. The AC does not transmit this message. 4607 The following message elements MUST be included in the Configuration 4608 Status message. 4610 o AC Name, see Section 4.5.4 4612 o AC Name with Index, see Section 4.5.5 4614 o Radio Administrative State, see Section 4.5.31 4616 o Statistics Timer, see Section 4.5.36 4618 o WTP Reboot Statistics, see Section 4.5.47 4620 The following message elements MAY be included in the Configuration 4621 Status message. 4623 o WTP Static IP Address Information, see Section 4.5.48 4625 8.3. Configuration Status Response 4627 The Configuration Status Response message is sent by an AC and 4628 provides a mechanism for the AC to override a WTP's requested 4629 configuration. 4631 A Configuration Status Response message is sent by an AC after 4632 receiving a Configuration Request message. 4634 The Configuration Status Response message carries binding specific 4635 message elements. Refer to the appropriate binding for the 4636 definition of this structure. 4638 When a WTP receives a Configuration Status Response message it acts 4639 upon the content of the message, as appropriate. If the 4640 Configuration Status Response message includes a Radio Operational 4641 State message element that causes a change in the operational state 4642 of one of the radios, the WTP transmits a Change State Event to the 4643 AC, as an acknowledgement of the change in state. 4645 The Configuration Status Response message is sent by the AC when in 4646 the Configure State. The WTP does not transmit this message. 4648 The following message elements MUST be included in the Configuration 4649 Status Response message. 4651 o AC IPv4 List, see Section 4.5.2 4653 o AC IPv6 List, see Section 4.5.3 4655 o CAPWAP Timers, see Section 4.5.12 4657 o Decryption Error Report Period, see Section 4.5.16 4659 o Idle Timeout, see Section 4.5.23 4661 o WTP Fallback, see Section 4.5.40 4663 The following message element MAY be included in the Configuration 4664 Status Response message. 4666 o WTP Static IP Address Information, see Section 4.5.48 4668 8.4. Configuration Update Request 4670 Configuration Update Request messages are sent by the AC to provision 4671 the WTP while in the Run state. This is used to modify the 4672 configuration of the WTP while it is operational. 4674 When a WTP receives a Configuration Update Request message, it 4675 responds with a Configuration Update Response message, with a Result 4676 Code message element indicating the result of the configuration 4677 request. 4679 The AC includes the Image Identifier and Initiate Download message 4680 elements to force the WTP to update its firmware while in the Run 4681 state. The WTP MAY proceed to download the requested firmware if it 4682 determines the version specified in the Image Identifier message 4683 element is not in its non-volatile storage (see Section 9.1.1). 4685 The Configuration Update Request is sent by the AC when in the Run 4686 State. The WTP does not transmit this message. 4688 One or more of the following message elements MAY be included in the 4689 Configuration Update message. 4691 o AC Name with Index, see Section 4.5.5 4693 o AC Timestamp, see Section 4.5.6 4695 o Add MAC ACL Entry, see Section 4.5.7 4697 o Add Static MAC ACL Entry, see Section 4.5.9 4699 o CAPWAP Timers, see Section 4.5.12 4701 o Decryption Error Report Period, see Section 4.5.16 4703 o Delete MAC ACL Entry, see Section 4.5.17 4705 o Delete Static MAC ACL Entry, see Section 4.5.19 4707 o Idle Timeout, see Section 4.5.23 4709 o Location Data, see Section 4.5.28 4711 o Radio Administrative State, see Section 4.5.31 4713 o Statistics Timer, see Section 4.5.36 4714 o WTP Fallback, see Section 4.5.40 4716 o WTP Name, see Section 4.5.44 4718 o WTP Static IP Address Information, see Section 4.5.48 4720 o Image Identifier, see Section 4.5.25 4722 o Initiate Download, see Section 4.5.27 4724 8.5. Configuration Update Response 4726 The Configuration Update Response message is the acknowledgement 4727 message for the Configuration Update Request message. 4729 The Configuration Update Response message is sent by a WTP after 4730 receiving a Configuration Update Request message. 4732 When an AC receives a Configuration Update Response message the 4733 result code indicates if the WTP successfully accepted the 4734 configuration. 4736 The Configuration Update Response message is sent by the WTP when in 4737 the Run State. The AC does not transmit this message. 4739 The following message element MUST be present in the Configuration 4740 Update message. 4742 Result Code, see Section 4.5.33 4744 The following message elements MAY be present in the Configuration 4745 Update Response message. 4747 o Radio Operational State, see Section 4.5.32 4749 8.6. Change State Event Request 4751 The Change State Event Request message is used by the WTP for two 4752 main purposes: 4754 o When sent by the WTP following the reception of a Configuration 4755 Status Response message from the AC, the WTP uses the Change State 4756 Event Request message to provide an update on the WTP radio's 4757 operational state and to confirm that the configuration provided 4758 by the AC was successfully applied. 4760 o When sent during the Run state, the WTP uses the Change State 4761 Event Request message to notify the AC of an unexpected change in 4762 the WTP's radio operational state. 4764 When an AC receives a Change State Event Request message it responds 4765 with a Change State Event Response message and modifies its data 4766 structures for the WTP as needed. The AC MAY decide not to provide 4767 service to the WTP if it receives an error, based on local policy, 4768 and to transition to the Reset state. 4770 The Change State Event Request message is sent by a WTP to 4771 acknowledge or report an error condition to the AC for a requested 4772 configuration in the Configuration Status Response message. The 4773 Change State Event Request message includes the Result Code message 4774 element, which indicates whether the configuration was successfully 4775 applied. If the WTP is unable to apply a specfic configuration 4776 request, it indicates the failure by including one or more Returned 4777 Message Element message elements (see Section 4.5.34). 4779 The Change State Event Request message is sent by the WTP in the 4780 Configure or Run State. The AC does not transmit this message. 4782 The WTP MAY save its configuration to persistent storage prior to 4783 transmitting the response. However, this is implementation specific 4784 and is not required. 4786 The following message elements MUST be present in the Change State 4787 Event Request message. 4789 o Radio Operational State, see Section 4.5.32 4791 o Result Code, see Section 4.5.33 4793 One or more of the following message elements MAY be present in the 4794 Change State Event Request message. 4796 o Returned Message Element(s), see Section 4.5.34 4798 8.7. Change State Event Response 4800 The Change State Event Response message acknowledges the Change State 4801 Event Request message. 4803 A Change State Event Response message is sent by an AC in response to 4804 a Change State Event Request message. 4806 The Change State Event Response message is sent by the AC when in the 4807 Configure or Run state. The WTP does not transmit this message. 4809 The Change State Event Response message carries no message elements. 4811 The WTP does not take any action upon receipt of the Change State 4812 Event Response message. 4814 8.8. Clear Configuration Request 4816 The Clear Configuration Request message is used to reset the WTP 4817 configuration. 4819 The Clear Configuration Request message is sent by an AC to request 4820 that a WTP reset its configuration to the manufacturing default 4821 configuration. The Clear Config Request message is sent while in the 4822 Run state. 4824 The Clear Configuration Request is sent by the AC when in the Run 4825 State. The WTP does not transmit this message. 4827 The Clear Configuration Request message carries no message elements. 4829 When a WTP receives a Clear Configuration Request message it resets 4830 its configuration to the manufacturing default configuration. 4832 8.9. Clear Configuration Response 4834 The Clear Configuration Response message is sent by the WTP after 4835 receiving a Clear Configuration Request message and resetting its 4836 configuration parameters to the manufacturing default values. 4838 The Clear Configuration Response is sent by the WTP when in the Run 4839 State. The AC does not transmit this message. 4841 The Clear Configuration Request message MUST include the following 4842 message element. 4844 o Result Code, see Section 4.5.33 4846 9. Device Management Operations 4848 This section defines CAPWAP operations responsible for debugging, 4849 gathering statistics, logging, and firmware management. 4851 9.1. Firmware Management 4853 This section describes the firmware download procedures used by the 4854 CAPWAP protocol. Firmware download can occur during the Image Data 4855 or Run state. 4857 Figure 4 provides an example of a WTP that performs a firmware 4858 upgrade while in the Image Data state. In this example, the WTP does 4859 not already have the requested firmware (Image Identifier = x), and 4860 downloads the image from the AC. 4862 WTP AC 4864 Join Request 4865 --------------------------------------------------------> 4867 Join Response (Image Identifier = x) 4868 <------------------------------------------------------ 4870 Image Data Request (Image Identifier = x) 4871 --------------------------------------------------------> 4873 Image Data Response (Result Code = Success, 4874 Image Information = {size,hash}, 4875 Initiate Download) 4876 <------------------------------------------------------ 4878 Image Data Request (Image Data = Data) 4879 <------------------------------------------------------ 4881 Image Data Response (Result Code = Success) 4882 --------------------------------------------------------> 4884 ..... 4886 Image Data Request (Image Data = EOF) 4887 <------------------------------------------------------ 4889 Image Data Response (Result Code = Success) 4890 --------------------------------------------------------> 4892 (WTP enters the Reset State) 4894 Figure 4: WTP Firmware Download Case 1 4896 Figure 5 provides an example in which the WTP has the image specified 4897 by the AC in its non-volative storage. The WTP opts to NOT download 4898 the firmware and immediately reset. 4900 WTP AC 4902 Join Request 4903 --------------------------------------------------------> 4905 Join Response (Image Identifier = x) 4906 <------------------------------------------------------ 4908 (WTP enters the Reset State) 4910 Figure 5: WTP Firmware Download Case 2 4912 Figure 6 provides an example of a WTP that performs a firmware 4913 upgrade while in the Run state. This mode of firmware upgrade allows 4914 the WTP to download its image while continuing to provide service. 4915 The WTP will not automatically reset until it is notified by the AC, 4916 with a Reset Request message. 4918 WTP AC 4920 Configuration Update Request (Image Identifier = x) 4921 <------------------------------------------------------ 4923 Configuration Update Response (Result Code = Success) 4924 --------------------------------------------------------> 4926 Image Data Request (Image Identifier = x) 4927 --------------------------------------------------------> 4929 Image Data Response (Result Code = Success, 4930 Image Information = {size,hash}, 4931 Initiate Download) 4932 <------------------------------------------------------ 4934 Image Data Request (Image Data = Data) 4935 <------------------------------------------------------ 4937 Image Data Response (Result Code = Success) 4938 --------------------------------------------------------> 4940 ..... 4942 Image Data Request (Image Data = EOF) 4943 <------------------------------------------------------ 4945 Image Data Response (Result Code = Success) 4946 --------------------------------------------------------> 4948 ..... 4950 (administratively requested reboot request) 4951 Reset Request (Image Identifier = x) 4952 <------------------------------------------------------ 4954 Reset Response (Result Code = Success) 4955 --------------------------------------------------------> 4957 Figure 6: WTP Firmware Download Case 3 4959 Figure 7 provides another example of the firmware download while in 4960 the Run state. In this example, the WTP already has the image 4961 specified by the AC in its non-volative storage. The WTP opts to NOT 4962 download the firmware. The WTP resets upon receipt of a Reset 4963 Request message from the AC. 4965 WTP AC 4967 Configuration Update Request (Image Identifier = x, 4968 Image Information = {size,hash}, 4969 Initiate Download) 4970 <------------------------------------------------------ 4972 Configuration Update Response (Result Code = Already Have Image) 4973 --------------------------------------------------------> 4975 ..... 4977 (administratively requested reboot request) 4978 Reset Request (Image Identifier = x) 4979 <------------------------------------------------------ 4981 Reset Response (Result Code = Success) 4982 --------------------------------------------------------> 4984 Figure 7: WTP Firmware Download Case 4 4986 9.1.1. Image Data Request 4988 The Image Data Request message is used to update firmware on the WTP. 4989 This message and its companion Response message are used by the AC to 4990 ensure that the image being run on each WTP is appropriate. 4992 Image Data Request messages are exchanged between the WTP and the AC 4993 to download a new firmware image to the WTP. When a WTP or AC 4994 receives an Image Data Request message it responds with an Image Data 4995 Response message. The message elements contained within the Image 4996 Data Request message are required to determine the intent of the 4997 request. 4999 The decision that new firmware is to be downloaded to the WTP can 5000 occur in one of two ways: 5002 When the WTP joins the AC, the Join Response message includes the 5003 Image Identifier message element, which informs the WTP of the 5004 firmware it is expected to run. if the WTP does not currently have 5005 the requested firmware version, it transmits an Image Data Request 5006 message, with the appropriate Image Identifier message element. 5007 If the WTP already has the requested firmware, it simply resets. 5009 Once the WTP is in the Run state, it is possible for the AC to 5010 cause the WTP to initiate a firmware download by sending a 5011 Configuration Update Request message with the Initiate Download 5012 and and Image Identifier message elements. The WTP then transmits 5013 the Image Data Request message, which includes the Image 5014 Identifier message element to start the download process. Note 5015 that when the firmware is downloaded in this way, the WTP does not 5016 automatically reset after the download is complete. The WTP will 5017 only reset when it receives a Reset Request message from the AC. 5018 If the WTP already had the requested firmware version in its non- 5019 volatile storage, the WTP does not transmit the Image Data Request 5020 message and responds with a Configuration Update Response message 5021 with the Result Code set to Image Already Present. 5023 Regardless of how the download was initiated, once the AC receives an 5024 Image Data Request message with the Image Identifier message element, 5025 it begins the transfer process by transmitting an Image Data Request 5026 message that includes the Image Data message element. This continues 5027 until the firmware image has been transfered. 5029 The Image Data Request message is sent by the WTP or the AC when in 5030 the Image Data or Run State. 5032 The following message elements MAY be included in the Image Data 5033 Request message. 5035 o Image Data, see Section 4.5.24 5037 o Image Identifier, see Section 4.5.25 5039 9.1.2. Image Data Response 5041 The Image Data Response message acknowledges the Image Data Request 5042 message. 5044 An Image Data Response message is sent in response to a received 5045 Image Data Request message. Its purpose is to acknowledge the 5046 receipt of the Image Data Request message. The Result Code is 5047 included to indicate whether a previously sent Image Data Request 5048 message was invalid. 5050 The Image Data Response message is sent by the WTP or the AC when in 5051 the Image Data or Run State. 5053 The following message element MUST be included in the Image Data 5054 Response message. 5056 o Result Code, see Section 4.5.33 5058 The following message elements MAY be included in the Image Data 5059 Response message. 5061 o Image Information, see Section 4.5.26 5063 o Initiate Download, see Section 4.5.27 5065 Upon receiving an Image Data Response message indicating an error, 5066 the WTP MAY retransmit a previous Image Data Reqest message, or 5067 abandon the firmware download to the WTP by transitioning to the 5068 Reset state. 5070 9.2. Reset Request 5072 The Reset Request message is used to cause a WTP to reboot. 5074 A Reset Request message is sent by an AC to cause a WTP to 5075 reinitialize its operation. 5077 The Reset Request is sent by the AC when in the Run State. The WTP 5078 does not transmit this message. 5080 The following message elements MUST be included in the Reset Request 5081 message. 5083 o Image Identifier, see Section 4.5.25 5085 When a WTP receives a Reset Request message, it responds with a Reset 5086 Response message indicating success and then reinitialize itself. If 5087 the WTP is unable to write to its non-volatile storage, to ensure 5088 that it runs the requested software version indicated in the Image 5089 Identifier message element, it MAY send the appropriate Result Code 5090 message element, but MUST reboot. If the WTP is unable to reset, 5091 including a hardware reset, it sends a Reset Response message to the 5092 AC with a Result Code message element indicating failure. The AC no 5093 longer provides service to the WTP. 5095 9.3. Reset Response 5097 The Reset Response message acknowledges the Reset Request message. 5099 A Reset Response message is sent by the WTP after receiving a Reset 5100 Request message. 5102 The Reset Response is sent by the WTP when in the Run State. The AC 5103 does not transmit this message. 5105 The following message element MAY be included in the Image Data 5106 Request message. 5108 o Result Code, see Section 4.5.33 5110 When an AC receives a successful Reset Response message, it is 5111 notified that the WTP will reinitialize its operation. An AC that 5112 receives a Reset Response message indicating failure may opt to no 5113 longer provide service to the WTP. 5115 9.4. WTP Event Request 5117 The WTP Event Request message is used by a WTP to send information to 5118 its AC. The WTP Event Request message may be sent periodically, or 5119 sent in response to an asynchronous event on the WTP. For example, a 5120 WTP MAY collect statistics and use the WTP Event Request message to 5121 transmit the statistics to the AC. 5123 When an AC receives a WTP Event Request message it will respond with 5124 a WTP Event Response message. 5126 The presence of the Delete Station message element is used by the WTP 5127 to inform the AC that it is no longer providing service to the 5128 station. This could be the result of an Idle Timeout (see 5129 Section 4.5.23), due to to resource shortages, or some other reason. 5131 The WTP Event Request message is sent by the WTP when in the Run 5132 State. The AC does not transmit this message. 5134 The WTP Event Request message MUST contain one of the message 5135 elements listed below, or a message element that is defined for a 5136 specific wireless technology. More than one of each messsage element 5137 listed may be included in the WTP Event Request message. 5139 o Decryption Error Report, see Section 4.5.15 5141 o Duplicate IPv4 Address, see Section 4.5.21 5143 o Duplicate IPv6 Address, see Section 4.5.22 5145 o WTP Operational Statistics, see Section 4.5.45 5147 o WTP Radio Statistics, see Section 4.5.46 5149 o WTP Reboot Statistics, see Section 4.5.47 5151 o Delete Station, see Section 4.5.18 5153 9.5. WTP Event Response 5155 The WTP Event Response message acknowledges receipt of the WTP Event 5156 Request message. 5158 A WTP Event Response message is sent by an AC after receiving a WTP 5159 Event Request message. 5161 The WTP Event Response message is sent by the AC when in the Run 5162 State. The WTP does not transmit this message. 5164 The WTP Event Response message carries no message elements. 5166 9.6. Data Transfer Request 5168 The Data Transfer Request message is used to deliver debug 5169 information from the WTP to the AC. 5171 Data Transfer Request messages are sent by the WTP to the AC when the 5172 WTP determines that it has important information to send to the AC. 5173 For instance, if the WTP detects that its previous reboot was caused 5174 by a system crash, it can send the crash file to the AC. The remote 5175 debugger function in the WTP also uses the Data Transfer Request 5176 message to send console output to the AC for debugging purposes. 5178 When the AC receives a Data Transfer Request message it responds to 5179 the WTP with a Data Transfer Response message. The AC MAY log the 5180 information received. 5182 The Data Transfer Request message is sent by the WTP when in the Run 5183 State. The AC does not transmit this message. 5185 The Data Transfer Request message MUST contain one of the message 5186 elements listed below. 5188 o Data Transfer Data, see Section 4.5.13 5190 o Data Transfer Mode, see Section 4.5.14 5192 9.7. Data Transfer Response 5194 The Data Transfer Response message acknowledges the Data Transfer 5195 Request message. 5197 A Data Transfer Response message is sent in response to a received 5198 Data Transfer Request message. Its purpose is to acknowledge receipt 5199 of the Data Transfer Request message. 5201 The Data Transfer Response message is sent by the AC when in the Run 5202 State. The WTP does not transmit this message. 5204 The Data Transfer Response message carries no message elements. 5206 Upon receipt of a Data Transfer Response message, the WTP transmits 5207 more information, if more information is available. 5209 10. Station Session Management 5211 Messages in this section are used by the AC to create, modify or 5212 delete station session state on the WTPs. 5214 10.1. Station Configuration Request 5216 The Station Configuration Request message is used to create, modify 5217 or delete station session state on a WTP. The message is sent by the 5218 AC to the WTP, and may contain one or more message elements. The 5219 message elements for this CAPWAP control message include information 5220 that is generally highly technology specific. Refer to the 5221 appropriate binding document for definitions of the messages elements 5222 that are included in this control message. 5224 The Station Configuration Request message is sent by the AC when in 5225 the Run State. The WTP does not transmit this message. 5227 The following CAPWAP Control message elements MAY be included in the 5228 Station Configuration Request message. More than one of each message 5229 element listed may be included in the Station Configuration Request 5230 message. 5232 o Add Station, see Section 4.5.8 5234 o Delete Station, see Section 4.5.18 5236 10.2. Station Configuration Response 5238 The Station Configuration Response message is used to acknowledge a 5239 previously received Station Configuration Request message. 5241 The Station Configuration Response message is sent by the WTP when in 5242 the Run State. The AC does not transmit this message. 5244 The following message element MUST be present in the Station 5245 Configuration Response message. 5247 o Result Code, see Section 4.5.33 5249 The Result Code message element indicates that the requested 5250 configuration was successfully applied, or that an error related to 5251 processing of the Station Configuration Request message occurred on 5252 the WTP. 5254 11. NAT Considerations 5256 There are three specific situations in which a NAT deployment may be 5257 used in conjunction with a CAPWAP-enabled deployment. The first 5258 consists of a configuration in which a single WTP is behind a NAT 5259 system. Since all communication is initiated by the WTP, and all 5260 communication is performed over IP using two UDP ports, the protocol 5261 easily traverses NAT systems in this configuration. 5263 In the second case, two or more WTPs are deployed behind the same NAT 5264 system. Here, the AC would receive multiple connection requests from 5265 the same IP address, and cannot differentiate the originating WTP of 5266 the connection requests. The CAPWAP Data Check state, which 5267 establishes the data plane connection and communicates the Data 5268 Keepalive, includes the Session Identifier message element, which is 5269 used to bind the control and data plane. Use of the Session 5270 Identifier message element enables the AC to match the control and 5271 data plane flows from multiple WTPs behind the same NAT system 5272 (multiple WTPs sharing the same IP address). 5274 In the third configuration, the AC is deployed behind a NAT. Two 5275 issues exist in this situation. First, an AC communicates its 5276 interfaces and corresponding WTP load using the CAPWAP Control 5277 IP(v4/v6) Address message element. This message element is currently 5278 mandatory, and if NAT compliance becomes an issue, it is possible to 5279 either: 5281 1. Make the CAPWAP Control IP (v4/v6) Address optional, allowing the 5282 WTP to use the known IP Address. Note that this approach 5283 eliminates the ability to perform load balancing of WTP across 5284 ACs, and therefore is not the recommended approach. 5286 2. Allow an AC to configure a NAT'ed address for every AC that would 5287 otherwise be communicated in the CAPWAP Control IP (v4/v6) Address 5288 message element. 5290 3. Require that if a WTP determines that the AC List message element 5291 contains a set of IP Addresses that are different from the AC IP 5292 Address the WTP is currently using, then assume that NAT is 5293 present, and require that the WTP communicate with the AC IP 5294 Address (and ignore the CAPWAP Control IP (v4/v6) Address message 5295 element(s)). 5297 The CAPWAP protocol allows for all of the AC identities supporting a 5298 group of WTPs to be communicated through the AC List message element. 5299 This feature must be disabled when the AC is behind a NAT and the IP 5300 Address that is embedded is invalid. 5302 The CAPWAP protocol allows an AC to configure a static IP address on 5303 a WTP using the WTP Static IP Address Information message element. 5304 This message element SHOULD NOT be used in NAT'ed environments, 5305 unless the administrator is familiar with the internal IP addressing 5306 scheme within the WTP's private network, and does not rely on the 5307 public address seen by the AC. 5309 When a WTP detects the duplicate address condition, it generates a 5310 message to the AC, which includes the Duplicate IP Address message 5311 element. The IP Address embedded within this message element is 5312 different from the public IP address seen by the AC. 5314 When CAPWAP is run over IPv6, NAT support can only be provided if the 5315 IPv6 NAT system is capable of performing address translation over the 5316 UDP-Lite 3828 protocol [13]. A protocol interoperability issues will 5317 exist if the NAT system is being utilized for IPv4/IPv6 address 5318 translation. 5320 12. Security Considerations 5322 This section describes security considerations for the CAPWAP 5323 protocol. It also provides security recommendations for protocols 5324 used in conjunction with CAPWAP. 5326 12.1. CAPWAP Security 5328 As it is currently specified, the CAPWAP protocol sits between the 5329 security mechanisms specified by the wireless link layer protocol 5330 (e.g.IEEE 802.11i) and AAA. One goal of CAPWAP is to bootstrap trust 5331 between the STA and WTP using a series of preestablished trust 5332 relationships: 5334 STA WTP AC AAA 5335 ============================================== 5337 DTLS Cred AAA Cred 5338 <------------><-------------> 5340 EAP Credential 5341 <------------------------------------------> 5343 wireless link layer 5344 (e.g.802.11 PTK) 5345 <--------------> or 5346 <---------------------------> 5347 (derived) 5349 Within CAPWAP, DTLS is used to secure the link between the WTP and 5350 AC. In addition to securing control messages, it's also a link in 5351 this chain of trust for establishing link layer keys. Consequently, 5352 much rests on the security of DTLS. 5354 In some CAPWAP deployment scenarios, there are two channels between 5355 the WTP and AC: the control channel, carrying CAPWAP control 5356 messages, and the data channel, over which client data packets are 5357 tunneled between the AC and WTP. Typically, the control channel is 5358 secured by DTLS, while the data channel is not. 5360 The use of parallel protected and unprotected channels deserves 5361 special consideration, but does not create a threat. There are two 5362 potential concerns: attempting to convert protected data into un- 5363 protected data and attempting to convert un-protected data into 5364 protected data. These concerns are addressed below. 5366 12.1.1. Converting Protected Data into Unprotected Data 5368 Since CAPWAP does not support authentication-only ciphers (i.e. all 5369 supported ciphersuites include encryption and authentication), it is 5370 not possible to convert protected data into unprotected data. Since 5371 encrypted data is (ideally) indistinguishable from random data, the 5372 probability of an encrypted packet passing for a well-formed packet 5373 is effectively zero. 5375 12.1.2. Converting Unprotected Data into Protected Data (Insertion) 5377 The use of message authentication makes it impossible for the 5378 attacker to forge protected records. This makes conversion of 5379 unprotected records to protected records impossible. 5381 12.1.3. Deletion of Protected Records 5383 An attacker could remove protected records from the stream, though 5384 not undetectably so, due the built-in reliability of the underlying 5385 CAPWAP protocol. In the worst case, the attacker would remove the 5386 same record repeatedly, resulting in a CAPWAP session timeout and 5387 restart. This is effectively a DoS attack, and could be accomplished 5388 by a man in the middle regardless of the CAPWAP protocol security 5389 mechanisms chosen. 5391 12.1.4. Insertion of Unprotected Records 5393 An attacker could inject packets into the unprotected channel, but 5394 this may become evident if sequence number desynchronization occurs 5395 as a result. Only if the attacker is a MiM can packets be inserted 5396 undetectably. This is a consequence of that channel's lack of 5397 protection, and not a new threat resulting from the CAPWAP security 5398 mechanism. 5400 12.2. Session ID Security 5402 Since DTLS does not export a unique session identifier, there can be 5403 no explicit protocol binding between the DTLS layer and CAPWAP layer. 5404 As a result, implementations MUST provide a mechanism for performing 5405 this binding. For example, an AC MUST NOT associate decrypted DTLS 5406 control packets with a particular WTP session based solely on the 5407 Session ID in the packet header. Instead, identification should be 5408 done based on which DTLS session decrypted the packet. Otherwise one 5409 authenticated WTP could spoof another authenticated WTP by altering 5410 the Session ID in the encrypted CAPWAP header. 5412 It should be noted that when the CAPWAP data channel is unencrypted, 5413 the WTP Session ID is exposed and possibly known to adversaries and 5414 other WTPs. This would allow the forgery of the source of data- 5415 channel traffic. This, however, should not be a surprise for 5416 unencrypted data channels. When the data channel is encrypted, the 5417 Session ID is not exposed, and therefore can safely be used to 5418 associate a data and control channel. The 64-bit length of the 5419 Session ID mitigates online guessing attacks where an adversarial, 5420 authenticated WTP tries to correlate his own data channel with 5421 another WTP's control channel. Note that for encrypted data 5422 channels, the Session ID should only be used for correlation for the 5423 first packet immediately after the initial DTLS handshake. Future 5424 correlation should instead be done via identification of a packet's 5425 DTLS session. 5427 12.3. Discovery Attacks 5429 Since the Discovery Request messages are sent in the clear, it is 5430 important that AC implementations NOT assume that receiving such a 5431 request from a WTP implies that it has rebooted, and consequently 5432 tear down any active DTLS sessions. Discovery Request messages can 5433 easily be spoofed by malicious devices, so it is important that the 5434 AC maintain two separate sets of states for the WTP until the 5435 DTLSSessionEstablished notification is received, indicating that the 5436 WTP was authenticated. Once a new DTLS session is successfully 5437 established, any state referring to the old session can be cleared. 5439 12.4. Interference with a DTLS Session 5441 If a WTP or AC repeatedly receives packets which fail DTLS 5442 authentication or decryption, this could indicate a DTLS 5443 desynchronization between the AC and WTP, a link prone to 5444 undetectable bit errors, or an attacker trying to disrupt a DTLS 5445 session. 5447 In the state machine (section 2.3), transitions to the DTLS tear down 5448 state can be triggered by frequently receiving DTLS packets with 5449 authentication or decryption errors. The threshold or technique for 5450 deciding when to move to the tear down state should be chosen 5451 carefully. Being able to easily transition to DTLS TD allows easy 5452 detection of malfunctioning devices, but allows for denial of service 5453 attacks. Making it difficult to transition to DTLS TD prevents 5454 denial of service attacks, but makes it more difficult to detect and 5455 reset a malfunctioning session. Implementers should set this policy 5456 with care. 5458 12.5. Use of Preshared Keys in CAPWAP 5460 While use of preshared keys may provide deployment and provisioning 5461 advantages not found in public key based deployments, it also 5462 introduces a number of operational and security concerns. In 5463 particular, because the keys must typically be entered manually, it 5464 is common for people to base them on memorable words or phrases. 5465 These are referred to as "low entropy passwords/passphrases". 5467 Use of low-entropy preshared keys, coupled with the fact that the 5468 keys are often not frequently updated, tends to significantly 5469 increase exposure. For these reasons, the following recommendations 5470 are made: 5472 o When DTLS is used with a preshared-key (PSK) ciphersuite, each WTP 5473 SHOULD have a unique PSK. Since WTPs will likely be widely 5474 deployed, their physical security is not guaranteed. If PSKs are 5475 not unique for each WTP, key reuse would allow the compromise of 5476 one WTP to result in the compromise of others 5478 o Generating PSKs from low entropy passwords is NOT RECOMMENDED. 5480 o It is RECOMMENDED that implementations that allow the 5481 administrator to manually configure the PSK also provide a 5482 capability for generation of new random PSKs, taking RFC 1750 [2] 5483 into account. 5485 o Preshared keys SHOULD be periodically updated. Implementations 5486 may facilitate this by providing an administrative interface for 5487 automatic key generation and periodic update, or it may be 5488 accomplished manually instead. 5490 Every pairwise combination of WTP and AC on the network SHOULD have a 5491 unqiue PSK. This prevents the domino effect (see Guidance for AAA 5492 Key Management [15]). If PSKs are tied to specific WTPs, then 5493 knowledge of the PSK implies a binding to a specified identity that 5494 can be authorized. 5496 If PSKs are shared, this binding between device and identity is no 5497 longer possible. Compromise of one WTP can yield compromise of 5498 another WTP, violating the CAPWAP security hierarchy. Consequently, 5499 sharing keys between WTPs is NOT RECOMMENDED. 5501 12.6. Use of Certificates in CAPWAP 5503 For public-key-based DTLS deployments, each device SHOULD have unique 5504 credentials, with an extended key usage authorizing the device to act 5505 as either a WTP or AC. If devices do not have unique credentials, it 5506 is possible that by compromising one device, any other device using 5507 the same credential may also be considered to be compromised. 5509 Certificate validation involves checking a large variety of things. 5511 Since the necessary things to validate are often environment- 5512 specific, many are beyond the scope of this document. In this 5513 section, we provide some basic guidance on certificate validation. 5515 Each device is responsible for authenticating and authorizing devices 5516 with which they communicate. Authentication entails validation of 5517 the chain of trust leading to the peer certificate, followed by the 5518 the peer certificate itself. At a minimum, devices SHOULD use SSH- 5519 style certificate caching to guarantee consistency. If devices have 5520 access to a certificate authority, they SHOULD properly validate the 5521 trust chain. Implementations SHOULD also provide a secure method for 5522 verifying that the credential in question has not been revoked. 5524 Note that if the WTP relies on the AC for network connectivity (e.g. 5525 the AC is a layer 2 switch to which the WTP is directly connected), 5526 the WTP may not be able to contact an OCSP server or otherwise obtain 5527 an up to date CRL if a compromised AC doesn't explicitly permit this. 5528 This cannot be avoided, except through effective physical security 5529 and monitoring measures at the AC. 5531 Proper validation of certificates typically requires checking to 5532 ensure the certificate has not yet expired. If devices have a real- 5533 time clock, they SHOULD verify the certificate validity dates. If no 5534 real-time clock is available, the device SHOULD make a best-effort 5535 attempt to validate the certificate validity dates through other 5536 means. Failure to check a certificate's temporal validity can make a 5537 device vulnerable to man-in-the-middle attacks launched using 5538 compromised, expired certificates, and therefore devices should make 5539 every effort to perform this validation. 5541 12.7. AAA Security 5543 The AAA protocol is used to distribute EAP keys to the ACs, and 5544 consequently its security is important to the overall system 5545 security. When used with TLS or IPsec, security guidelines specified 5546 in RFC 3539 [5] SHOULD be followed. 5548 In general, the link between the AC and AAA server SHOULD be secured 5549 using a strong ciphersuite keyed with mutually authenticated session 5550 keys. Implementations SHOULD NOT rely solely on Basic RADIUS shared 5551 secret authentication as it is often vulnerable to dictionary 5552 attacks, but rather SHOULD use stronger underlying security 5553 mechanisms. 5555 13. Management Considerations 5557 The CAPWAP protocol assumes that it is the only configuration 5558 interface to the WTP to configure parameters that are specified in 5559 the CAPWAP specifications. While the use of a separate management 5560 protocol MAY be used for the purposes of monitoring the WTP directly, 5561 configuring the WTP through a separate management interface is not 5562 recommended. Configuring the WTP through a separate protocol, such 5563 as via a CLI or SNMP, could lead to the AC state being out of sync 5564 with the WTP. 5566 14. IANA Considerations 5568 A separate UDP port for data channel communications is (currently) 5569 the selected demultiplexing mechanism, and a port must be assigned 5570 for this purpose in section Section 3.1. The UDP port numbers are 5571 listed by IANA at http://www.iana.org/assignments/port-numbers. 5573 IANA needs to assign a DHCP code point, currently identified as TBD 5574 in the Section 3.3. DHCP options are defined in RFC 1533 [10], and 5575 are listed by IANA at 5576 http://www.iana.org/assignments/bootp-dhcp-parameters. 5578 IANA needs to assign an organization local multicast address called 5579 the "All ACs multicast address" from the IPv6 multicast address 5580 registry in Section 3.3 5582 14.1. CAPWAP Message Types 5584 The Message Type field in the CAPWAP header (Section 4.4.1.1) is used 5585 to identify the operation performed by the message. There are 5586 multiple namespaces, which is identified via the first three octets 5587 of the field containing the IANA Enterprise Number [12]. When the 5588 Enterprise Number is set to zero, the message types are reserved for 5589 use by the base CAPWAP specification which are controlled and 5590 maintained by IANA. 5592 15. Acknowledgements 5594 The following individuals are acknowledged for their contributions to 5595 this protocol specification: Puneet Agarwal, Saravanan Govindan, 5596 Peter Nilsson, and David Perkins. 5598 Michael Vakulenko contributed text to describe how CAPWAP can be used 5599 over layer 3 (IP/UDP) networks. 5601 16. References 5603 16.1. Normative References 5605 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 5606 Levels", BCP 14, RFC 2119, March 1997. 5608 [2] Eastlake, D., Crocker, S., and J. Schiller, "Randomness 5609 Recommendations for Security", RFC 1750, December 1994. 5611 [3] Mills, D., "Network Time Protocol (Version 3) Specification, 5612 Implementation", RFC 1305, March 1992. 5614 [4] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 5615 Public Key Infrastructure Certificate and Certificate 5616 Revocation List (CRL) Profile", RFC 3280, April 2002. 5618 [5] Aboba, B. and J. Wood, "Authentication, Authorization and 5619 Accounting (AAA) Transport Profile", RFC 3539, June 2003. 5621 [6] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for 5622 Transport Layer Security (TLS)", RFC 4279, December 2005. 5624 [7] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 5625 Protocol Version 1.1", RFC 4346, April 2006. 5627 [8] Manner, J. and M. Kojo, "Mobility Related Terminology", 5628 RFC 3753, June 2004. 5630 [9] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 5631 Security", RFC 4347, April 2006. 5633 [10] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 5634 Extensions", RFC 1533, October 1993. 5636 [11] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 5637 RFC 2246, January 1999. 5639 [12] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 5640 Considerations Section in RFCs", BCP 26, RFC 2434, 5641 October 1998. 5643 [13] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. 5644 Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)", 5645 RFC 3828, July 2004. 5647 16.2. Informational References 5649 [14] "draft-ietf-capwap-protocol-binding-specification-ieee802dot11- 5650 02". 5652 16.3. Informational References 5654 [15] "draft-housley-aaa-key-mgmt-06". 5656 [16] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On- 5657 line Database", RFC 3232, January 2002. 5659 [17] Modadugu et al, N., "The Design and Implementation of Datagram 5660 TLS", Feb 2004. 5662 [18] IEEE, "Guidelines for use of a 48-bit Extended Unique 5663 Identifier", Dec 2005. 5665 [19] IEEE, "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) 5666 REGISTRATION AUTHORITY". 5668 Editors' Addresses 5670 Pat R. Calhoun 5671 Cisco Systems, Inc. 5672 170 West Tasman Drive 5673 San Jose, CA 95134 5675 Phone: +1 408-853-5269 5676 Email: pcalhoun@cisco.com 5678 Michael P. Montemurro 5679 Research In Motion 5680 5090 Commerce Blvd 5681 Mississauga, ON L4W 5M4 5682 Canada 5684 Phone: +1 905-629-4746 x4999 5685 Email: mmontemurro@rim.com 5687 Dorothy Stanley 5688 Aruba Networks 5689 1322 Crossman Ave 5690 Sunnyvale, CA 94089 5692 Phone: +1 630-363-1389 5693 Email: dstanley@arubanetworks.com 5695 Full Copyright Statement 5697 Copyright (C) The IETF Trust (2007). 5699 This document is subject to the rights, licenses and restrictions 5700 contained in BCP 78, and except as set forth therein, the authors 5701 retain all their rights. 5703 This document and the information contained herein are provided on an 5704 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 5705 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 5706 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 5707 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 5708 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 5709 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 5711 Intellectual Property 5713 The IETF takes no position regarding the validity or scope of any 5714 Intellectual Property Rights or other rights that might be claimed to 5715 pertain to the implementation or use of the technology described in 5716 this document or the extent to which any license under such rights 5717 might or might not be available; nor does it represent that it has 5718 made any independent effort to identify any such rights. Information 5719 on the procedures with respect to rights in RFC documents can be 5720 found in BCP 78 and BCP 79. 5722 Copies of IPR disclosures made to the IETF Secretariat and any 5723 assurances of licenses to be made available, or the result of an 5724 attempt made to obtain a general license or permission for the use of 5725 such proprietary rights by implementers or users of this 5726 specification can be obtained from the IETF on-line IPR repository at 5727 http://www.ietf.org/ipr. 5729 The IETF invites any interested party to bring to its attention any 5730 copyrights, patents or patent applications, or other proprietary 5731 rights that may cover technology that may be required to implement 5732 this standard. Please address the information to the IETF at 5733 ietf-ipr@ietf.org. 5735 Acknowledgment 5737 Funding for the RFC Editor function is provided by the IETF 5738 Administrative Support Activity (IASA).