idnits 2.17.1 draft-ietf-capwap-protocol-specification-04.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 4893. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4904. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4911. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4917. 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 12 instances of too long lines in the document, the longest one being 18 characters in excess of 72. ** The abstract seems to contain references ([12]), 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: Note that 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 order the message elements as convenient. Furthermore, unless specifically noted, any individual message element may exist one or more times within 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 (January 23, 2007) is 6303 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'ChangeCipherSpec' on line 1221 ** 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) -- Possible downref: Non-RFC (?) normative reference: ref. '11' Summary: 10 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: July 27, 2007 M. Montemurro, Editor 5 Research In Motion 6 D. Stanley, Editor 7 Aruba Networks 8 January 23, 2007 10 CAPWAP Protocol Specification 11 draft-ietf-capwap-protocol-specification-04 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 July 27, 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 [12]. 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 . . . . . . . . . . . . . . . . . . . . . . . . 6 57 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 1.2. Conventions used in this document . . . . . . . . . . . . 7 59 1.3. Contributing Authors . . . . . . . . . . . . . . . . . . 8 60 1.4. Acknowledgements . . . . . . . . . . . . . . . . . . . . 9 61 1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 9 62 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 10 63 2.1. Wireless Binding Definition . . . . . . . . . . . . . . . 11 64 2.2. CAPWAP Session Establishment Overview . . . . . . . . . . 11 65 2.3. CAPWAP State Machine Definition . . . . . . . . . . . . . 13 66 2.3.1. CAPWAP Protocol State Transitions . . . . . . . . . . 15 67 2.3.2. CAPWAP/DTLS Interface . . . . . . . . . . . . . . . . 24 68 2.4. Use of DTLS in the CAPWAP Protocol . . . . . . . . . . . 26 69 2.4.1. DTLS Handshake Processing . . . . . . . . . . . . . . 26 70 2.4.2. DTLS Session Establishment . . . . . . . . . . . . . 28 71 2.4.3. DTLS Error Handling . . . . . . . . . . . . . . . . . 28 72 2.4.4. DTLS EndPoint Authentication . . . . . . . . . . . . 29 73 3. CAPWAP Transport . . . . . . . . . . . . . . . . . . . . . . 33 74 3.1. UDP Transport . . . . . . . . . . . . . . . . . . . . . . 33 75 3.2. AC Discovery . . . . . . . . . . . . . . . . . . . . . . 33 76 3.3. Fragmentation/Reassembly . . . . . . . . . . . . . . . . 34 77 4. CAPWAP Packet Formats . . . . . . . . . . . . . . . . . . . . 35 78 4.1. CAPWAP preamble . . . . . . . . . . . . . . . . . . . . . 37 79 4.2. CAPWAP Header . . . . . . . . . . . . . . . . . . . . . . 37 80 4.3. CAPWAP Data Messages . . . . . . . . . . . . . . . . . . 41 81 4.3.1. CAPWAP Data Keepalive . . . . . . . . . . . . . . . . 41 82 4.3.2. Station Data Payloads . . . . . . . . . . . . . . . . 42 83 4.4. CAPWAP Control Messages . . . . . . . . . . . . . . . . . 43 84 4.4.1. Control Message Format . . . . . . . . . . . . . . . 43 85 4.4.2. Control Message Quality of Service . . . . . . . . . 46 86 4.5. CAPWAP Protocol Message Elements . . . . . . . . . . . . 46 87 4.5.1. AC Descriptor . . . . . . . . . . . . . . . . . . . . 49 88 4.5.2. AC IPv4 List . . . . . . . . . . . . . . . . . . . . 50 89 4.5.3. AC IPv6 List . . . . . . . . . . . . . . . . . . . . 51 90 4.5.4. AC Name . . . . . . . . . . . . . . . . . . . . . . . 51 91 4.5.5. AC Name with Index . . . . . . . . . . . . . . . . . 52 92 4.5.6. AC Timestamp . . . . . . . . . . . . . . . . . . . . 52 93 4.5.7. Add MAC ACL Entry . . . . . . . . . . . . . . . . . . 53 94 4.5.8. Add Station . . . . . . . . . . . . . . . . . . . . . 53 95 4.5.9. Add Static MAC ACL Entry . . . . . . . . . . . . . . 54 96 4.5.10. CAPWAP Control IPv4 Address . . . . . . . . . . . . . 55 97 4.5.11. CAPWAP Control IPv6 Address . . . . . . . . . . . . . 55 98 4.5.12. CAPWAP Timers . . . . . . . . . . . . . . . . . . . . 56 99 4.5.13. Data Transfer Data . . . . . . . . . . . . . . . . . 56 100 4.5.14. Data Transfer Mode . . . . . . . . . . . . . . . . . 57 101 4.5.15. Decryption Error Report . . . . . . . . . . . . . . . 57 102 4.5.16. Decryption Error Report Period . . . . . . . . . . . 58 103 4.5.17. Delete MAC ACL Entry . . . . . . . . . . . . . . . . 58 104 4.5.18. Delete Station . . . . . . . . . . . . . . . . . . . 59 105 4.5.19. Delete Static MAC ACL Entry . . . . . . . . . . . . . 59 106 4.5.20. Discovery Type . . . . . . . . . . . . . . . . . . . 60 107 4.5.21. Duplicate IPv4 Address . . . . . . . . . . . . . . . 61 108 4.5.22. Duplicate IPv6 Address . . . . . . . . . . . . . . . 61 109 4.5.23. Idle Timeout . . . . . . . . . . . . . . . . . . . . 62 110 4.5.24. Image Data . . . . . . . . . . . . . . . . . . . . . 63 111 4.5.25. Image Filename . . . . . . . . . . . . . . . . . . . 63 112 4.5.26. Initiate Download . . . . . . . . . . . . . . . . . . 64 113 4.5.27. Location Data . . . . . . . . . . . . . . . . . . . . 64 114 4.5.28. MTU Discovery Padding . . . . . . . . . . . . . . . . 65 115 4.5.29. Radio Administrative State . . . . . . . . . . . . . 65 116 4.5.30. Radio Operational State . . . . . . . . . . . . . . . 66 117 4.5.31. Result Code . . . . . . . . . . . . . . . . . . . . . 67 118 4.5.32. Returned Message Element . . . . . . . . . . . . . . 68 119 4.5.33. Session ID . . . . . . . . . . . . . . . . . . . . . 69 120 4.5.34. Statistics Timer . . . . . . . . . . . . . . . . . . 69 121 4.5.35. Vendor Specific Payload . . . . . . . . . . . . . . . 70 122 4.5.36. WTP Board Data . . . . . . . . . . . . . . . . . . . 70 123 4.5.37. WTP Descriptor . . . . . . . . . . . . . . . . . . . 71 124 4.5.38. WTP Fallback . . . . . . . . . . . . . . . . . . . . 73 125 4.5.39. WTP Frame Tunnel Mode . . . . . . . . . . . . . . . . 73 126 4.5.40. WTP IPv4 IP Address . . . . . . . . . . . . . . . . . 74 127 4.5.41. WTP MAC Type . . . . . . . . . . . . . . . . . . . . 75 128 4.5.42. WTP Name . . . . . . . . . . . . . . . . . . . . . . 75 129 4.5.43. WTP Operational Statistics . . . . . . . . . . . . . 76 130 4.5.44. WTP Radio Statistics . . . . . . . . . . . . . . . . 76 131 4.5.45. WTP Reboot Statistics . . . . . . . . . . . . . . . . 78 132 4.5.46. WTP Static IP Address Information . . . . . . . . . . 79 133 4.6. CAPWAP Protocol Timers . . . . . . . . . . . . . . . . . 80 134 4.6.1. DataChannelKeepAlive . . . . . . . . . . . . . . . . 80 135 4.6.2. DataChannelDeadInterval . . . . . . . . . . . . . . . 80 136 4.6.3. DiscoveryInterval . . . . . . . . . . . . . . . . . . 81 137 4.6.4. DTLSRehandshake . . . . . . . . . . . . . . . . . . . 81 138 4.6.5. DTLSSessionDelete . . . . . . . . . . . . . . . . . . 81 139 4.6.6. EchoInterval . . . . . . . . . . . . . . . . . . . . 81 140 4.6.7. KeyLifetime . . . . . . . . . . . . . . . . . . . . . 81 141 4.6.8. MaxDiscoveryInterval . . . . . . . . . . . . . . . . 81 142 4.6.9. MaxFailedDTLSSessionRetry . . . . . . . . . . . . . . 82 143 4.6.10. NeighborDeadInterval . . . . . . . . . . . . . . . . 82 144 4.6.11. ResponseTimeout . . . . . . . . . . . . . . . . . . . 82 145 4.6.12. RetransmitInterval . . . . . . . . . . . . . . . . . 82 146 4.6.13. SilentInterval . . . . . . . . . . . . . . . . . . . 82 147 4.6.14. StatisticsTimer . . . . . . . . . . . . . . . . . . . 82 148 4.6.15. WaitDTLS . . . . . . . . . . . . . . . . . . . . . . 82 149 4.7. CAPWAP Protocol Variables . . . . . . . . . . . . . . . . 83 150 4.7.1. AdminState . . . . . . . . . . . . . . . . . . . . . 83 151 4.7.2. DiscoveryCount . . . . . . . . . . . . . . . . . . . 83 152 4.7.3. FailedDTLSSessionCount . . . . . . . . . . . . . . . 83 153 4.7.4. IdleTimeout . . . . . . . . . . . . . . . . . . . . . 83 154 4.7.5. MaxDiscoveries . . . . . . . . . . . . . . . . . . . 83 155 4.7.6. MaxRetransmit . . . . . . . . . . . . . . . . . . . . 83 156 4.7.7. ReportInterval . . . . . . . . . . . . . . . . . . . 83 157 4.7.8. RetransmitCount . . . . . . . . . . . . . . . . . . . 84 158 4.7.9. WTPFallBack . . . . . . . . . . . . . . . . . . . . . 84 159 4.8. WTP Saved Variables . . . . . . . . . . . . . . . . . . . 84 160 4.8.1. AdminRebootCount . . . . . . . . . . . . . . . . . . 84 161 4.8.2. FrameEncapType . . . . . . . . . . . . . . . . . . . 84 162 4.8.3. LastRebootReason . . . . . . . . . . . . . . . . . . 84 163 4.8.4. MacType . . . . . . . . . . . . . . . . . . . . . . . 84 164 4.8.5. PreferredACs . . . . . . . . . . . . . . . . . . . . 84 165 4.8.6. RebootCount . . . . . . . . . . . . . . . . . . . . . 84 166 4.8.7. Static ACL Table . . . . . . . . . . . . . . . . . . 85 167 4.8.8. Static IP Address . . . . . . . . . . . . . . . . . . 85 168 4.8.9. WTPLinkFailureCount . . . . . . . . . . . . . . . . . 85 169 4.8.10. WTPLocation . . . . . . . . . . . . . . . . . . . . . 85 170 4.8.11. WTPName . . . . . . . . . . . . . . . . . . . . . . . 85 171 5. CAPWAP Discovery Operations . . . . . . . . . . . . . . . . . 86 172 5.1. Discovery Request Message . . . . . . . . . . . . . . . . 86 173 5.2. Discovery Response Message . . . . . . . . . . . . . . . 87 174 5.3. Primary Discovery Request Message . . . . . . . . . . . . 87 175 5.4. Primary Discovery Response . . . . . . . . . . . . . . . 88 176 6. CAPWAP Join Operations . . . . . . . . . . . . . . . . . . . 90 177 6.1. Join Request . . . . . . . . . . . . . . . . . . . . . . 90 178 6.2. Join Response . . . . . . . . . . . . . . . . . . . . . . 91 179 7. Control Channel Management . . . . . . . . . . . . . . . . . 92 180 7.1. Echo Request . . . . . . . . . . . . . . . . . . . . . . 92 181 7.2. Echo Response . . . . . . . . . . . . . . . . . . . . . . 92 182 8. WTP Configuration Management . . . . . . . . . . . . . . . . 93 183 8.1. Configuration Consistency . . . . . . . . . . . . . . . . 93 184 8.1.1. Configuration Flexibility . . . . . . . . . . . . . . 94 186 8.2. Configuration Status . . . . . . . . . . . . . . . . . . 94 187 8.3. Configuration Status Response . . . . . . . . . . . . . . 95 188 8.4. Configuration Status Acknowledge . . . . . . . . . . . . 96 189 8.5. Configuration Update Request . . . . . . . . . . . . . . 96 190 8.6. Configuration Update Response . . . . . . . . . . . . . . 97 191 8.7. Change State Event Request . . . . . . . . . . . . . . . 97 192 8.8. Change State Event Response . . . . . . . . . . . . . . . 98 193 8.9. Clear Configuration Request . . . . . . . . . . . . . . . 99 194 8.10. Clear Configuration Response . . . . . . . . . . . . . . 99 195 9. Device Management Operations . . . . . . . . . . . . . . . . 100 196 9.1. Image Data Request . . . . . . . . . . . . . . . . . . . 100 197 9.2. Image Data Response . . . . . . . . . . . . . . . . . . . 101 198 9.3. Reset Request . . . . . . . . . . . . . . . . . . . . . . 101 199 9.4. Reset Response . . . . . . . . . . . . . . . . . . . . . 101 200 9.5. WTP Event Request . . . . . . . . . . . . . . . . . . . . 102 201 9.6. WTP Event Response . . . . . . . . . . . . . . . . . . . 102 202 9.7. Data Transfer Request . . . . . . . . . . . . . . . . . . 103 203 9.8. Data Transfer Response . . . . . . . . . . . . . . . . . 103 204 10. Station Session Management . . . . . . . . . . . . . . . . . 104 205 10.1. Station Configuration Request . . . . . . . . . . . . . . 104 206 10.2. Station Configuration Response . . . . . . . . . . . . . 104 207 11. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 105 208 12. Security Considerations . . . . . . . . . . . . . . . . . . . 107 209 12.1. CAPWAP Security . . . . . . . . . . . . . . . . . . . . . 107 210 12.1.1. Converting Protected Data into Unprotected Data . . . 108 211 12.1.2. Converting Unprotected Data into Protected Data 212 (Insertion) . . . . . . . . . . . . . . . . . . . . . 108 213 12.1.3. Deletion of Protected Records . . . . . . . . . . . . 108 214 12.1.4. Insertion of Unprotected Records . . . . . . . . . . 108 215 12.2. Use of Preshared Keys in CAPWAP . . . . . . . . . . . . . 108 216 12.3. Use of Certificates in CAPWAP . . . . . . . . . . . . . . 109 217 12.4. AAA Security . . . . . . . . . . . . . . . . . . . . . . 110 218 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 111 219 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 112 220 14.1. Normative References . . . . . . . . . . . . . . . . . . 112 221 14.2. Informational References . . . . . . . . . . . . . . . . 112 222 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 114 223 Intellectual Property and Copyright Statements . . . . . . . . . 115 225 1. Introduction 227 This document describes the CAPWAP Protocol, a standard, 228 interoperable protocol which enables an Access Controller (AC) to 229 manage a collection of Wireless Termination Points (WTPs). The 230 CAPWAP protocol is defined to be independent of layer 2 technology. 232 The emergence of centralized IEEE 802.11 Wireless Local Area Network 233 (WLAN) architectures, in which simple IEEE 802.11 WTPs are managed by 234 an Access Controller (AC) suggested that a standards based, 235 interoperable protocol could radically simplify the deployment and 236 management of wireless networks. WTPs require a set of dynamic 237 management and control functions related to their primary task of 238 connecting the wireless and wired mediums. Traditional protocols for 239 managing WTPs are either manual static configuration via HTTP, 240 proprietary Layer 2 specific or non-existent (if the WTPs are self- 241 contained). An IEEE 802.11 binding is defined in [12] to support use 242 of the CAPWAP protocol with IEEE 802.11 WLAN networks. 244 CAPWAP assumes a network configuration consisting of multiple WTPs 245 communicating via the Internet Protocol (IP) to an AC. WTPs are 246 viewed as remote RF interfaces controlled by the AC. The CAPWAP 247 protocol supports two modes of operation: Split and Local MAC. In 248 Split MAC mode all L2 wireless data and management frames are 249 encapsulated via the CAPWAP protocol and exchanged between the AC and 250 the WTP. As shown in Figure 1, the wireless frames received from a 251 mobile device, which is referred to in this specification as a 252 Station (or STA for short), are directly encapsulated by the WTP and 253 forwarded to the AC. 255 +-+ wireless frames +-+ 256 | |--------------------------------| | 257 | | +-+ | | 258 | |--------------| |---------------| | 259 | |wireless PHY/ | | CAPWAP | | 260 | | MAC sublayer | | | | 261 +-+ +-+ +-+ 262 STA WTP AC 264 Figure 1: Representative CAPWAP Architecture for Split MAC 266 The Local MAC mode of operation allows for the data frames to be 267 either locally bridged, or tunneled as 802.3 frames. The latter 268 implies that the WTP performs the 802 bridging function. In either 269 case the L2 wireless management frames are processed locally by the 270 WTP, and then forwarded to the AC. Figure 2 shows the Local MAC 271 mode, in which a station transmits a wireless frame which is 272 encapsulated in an 802.3 frame and forwarded to the AC. 274 +-+wireless frames +-+ 802.3 frames +-+ 275 | |----------------| |--------------| | 276 | | | | | | 277 | |----------------| |--------------| | 278 | |wireless PHY/ | | CAPWAP | | 279 | | MAC sublayer | | | | 280 +-+ +-+ +-+ 281 STA WTP AC 283 Figure 2: Representative CAPWAP Architecture for Local MAC 285 Provisioning WTPs with security credentials, and managing which WTPs 286 are authorized to provide service are traditionally handled by 287 proprietary solutions. Allowing these functions to be performed from 288 a centralized AC in an interoperable fashion increases manageability 289 and allows network operators to more tightly control their wireless 290 network infrastructure. 292 1.1. Goals 294 The goals for the CAPWAP protocol are listed below: 296 1. To centralize the authentication and policy enforcement functions 297 for a wireless network. The AC may also provide centralized 298 bridging, forwarding, and encryption of user traffic. 299 Centralization of these functions will enable reduced cost and 300 higher efficiency by applying the capabilities of network 301 processing silicon to the wireless network, as in wired LANs. 303 2. To enable shifting of the higher level protocol processing from 304 the WTP. This leaves the time critical applications of wireless 305 control and access in the WTP, making efficient use of the 306 computing power available in WTPs which are the subject to severe 307 cost pressure. 309 3. To provide a generic encapsulation and transport mechanism, 310 enabling the CAPWAP protocol to be applied to many access point 311 types in the future, via a specific wireless binding. 313 The CAPWAP protocol concerns itself solely with the interface between 314 the WTP and the AC. Inter-AC, or station to AC communication is 315 strictly outside the scope of this document. 317 1.2. Conventions used in this document 319 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 320 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 321 document are to be interpreted as described in RFC 2119 [1]. 323 1.3. Contributing Authors 325 This section lists and acknowledges the authors of significant text 326 and concepts included in this specification. [Note: This section 327 needs work to accurately reflect the contribution of each author and 328 this work will be done a future revision of this document.] 330 The CAPWAP Working Group selected the Lightweight Access Point 331 Protocol (LWAPP) [add reference, when available]to be used as the 332 basis of the CAPWAP protocol specification. The following people are 333 authors of the LWAPP document: 335 Bob O'Hara, Cisco Systems, Inc.,170 West Tasman Drive, San Jose, CA 95134 336 Phone: +1 408-853-5513, Email: bob.ohara@cisco.com 338 Pat Calhoun, Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134 339 Phone: +1 408-853-5269, Email: pcalhoun@cisco.com 341 Rohit Suri, Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134 342 Phone: +1 408-853-5548, Email: rsuri@cisco.com 344 Nancy Cam Winget, Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134 345 Phone: +1 408-853-0532, Email: ncamwing@cisco.com 347 Scott Kelly, Aruba Networks, 1322 Crossman Ave, Sunnyvale, CA 94089 348 Phone: +1 408-754-8408, Email: skelly@arubanetworks.com 350 Michael Glenn Williams, Nokia, Inc., 313 Fairchild Drive, Mountain View, CA 94043 351 Phone: +1 650-714-7758, Email: Michael.G.Williams@Nokia.com 353 Sue Hares, Nexthop Technologies, Inc., 825 Victors Way, Suite 100, Ann Arbor, MI 48108 354 Phone: +1 734 222 1610, Email: shares@nexthop.com 356 DTLS is used as the security solution for the CAPWAP protocol. The 357 following people are authors of significant DTLS-related text 358 included in this document: 360 Scott Kelly, Aruba Networks, 1322 Crossman Ave, Sunnyvale, CA 94089 361 Phone: +1 408-754-8408, Email: skelly@arubanetworks.com 363 Eric Rescorla, Network Resonance, 2483 El Camino Real, #212,Palo Alto CA, 94303 364 Email: ekr@networkresonance.com 366 The concept of using DTLS to secure the CAPWAP protocol was part of 367 the Secure Light Access Point Protocol (SLAPP) proposal [add 368 reference when available]. The following people are authors of the 369 SLAPP proposal: 371 Partha Narasimhan, Aruba Networks, 1322 Crossman Ave, Sunnyvale, CA 94089 372 Phone: +1 408-480-4716, Email: partha@arubanetworks.com 374 Dan Harkins, Tropos Networks, 555 Del Rey Avenue, Sunnyvale, CA, 95085 375 Phone: +1 408 470 7372, Email: dharkins@tropos.com 377 Subbu Ponnuswamy, Aruba Networks, 1322 Crossman Ave, Sunnyvale, CA 94089 378 Phone: +1 408-754-1213, Email: subbu@arubanetworks.com 380 1.4. Acknowledgements 382 The authors thank Michael Vakulenko for contributing text that 383 describes how CAPWAP can be used over a layer 3 (IP/UDP) network. 385 The authors thank Russ Housley and Charles Clancy for their 386 assistance in provide a security review of the LWAPP specification. 387 Charles' review can be found at [11]. 389 1.5. Terminology 391 Access Controller (AC): The network entity that provides WTPs access 392 to the network infrastructure in the data plane, control plane, 393 management plane, or a combination therein. 395 Station (STA): A device that contains an IEEE 802.11 conformant 396 medium access control (MAC) and physical layer (PHY) interface to the 397 wireless medium (WM). 399 Wireless Termination Point (WTP): The physical or network entity that 400 contains an RF antenna and wireless PHY to transmit and receive 401 station traffic for wireless access networks. 403 This Document uses additional terminology defined in [8]. 405 2. Protocol Overview 407 The CAPWAP protocol is a generic protocol defining AC and WTP control 408 and data plane communication via a CAPWAP protocol transport 409 mechanism. CAPWAP control messages, and optionally CAPWAP data 410 messages, are secured using Datagram Transport Layer Security (DTLS) 411 [7]. DTLS is a standards-track IETF protocol based upon TLS. The 412 underlying security-related protocol mechanisms of TLS have been 413 successfully deployed for many years. 415 The CAPWAP protocol Transport layer carries two types of payload, 416 CAPWAP Data messages and CAPWAP Control messages. CAPWAP Data 417 messages encapsulate forwarded wireless frames. CAPWAP protocol 418 Control messages are management messages exchanged between a WTP and 419 an AC. The CAPWAP Data and Control packets are sent over separate 420 UDP ports. Since both data and control frames can exceed the PMTU, 421 the payload of a CAPWAP data or control message can be fragmented. 422 The fragmentation behavior is defined in Section 3. 424 The CAPWAP Protocol begins with a discovery phase. The WTPs send a 425 Discovery Request message, causing any Access Controller (AC) 426 receiving the message to respond with a Discovery Response message. 427 From the Discovery Response messages received, a WTP will select an 428 AC with which to establish a secure DTLS session. CAPWAP protocol 429 messages will be fragmented to the maximum length discovered to be 430 supported by the network. 432 Once the WTP and the AC have completed DTLS session establishment, a 433 configuration exchange occurs in which both devices to agree on 434 version information. During this exchange the WTP may receive 435 provisioning settings. The WTP is then enabled for operation. 437 When the WTP and AC have completed the version and provision exchange 438 and the WTP is enabled, the CAPWAP protocol is used to encapsulate 439 the wireless data frames sent between the WTP and AC. The CAPWAP 440 protocol will fragment the L2 frames if the size of the encapsulated 441 wireless user data (Data) or protocol control (Management) frames 442 causes the resulting CAPWAP protocol packet to exceed the MTU 443 supported between the WTP and AC. Fragmented CAPWAP packets are 444 reassembled to reconstitute the original encapsulated payload. 446 The CAPWAP protocol provides for the delivery of commands from the AC 447 to the WTP for the management of stations that are communicating with 448 the WTP. This may include the creation of local data structures in 449 the WTP for the stations and the collection of statistical 450 information about the communication between the WTP and the stations. 451 The CAPWAP protocol provides a mechanism for the AC to obtain 452 statistical information collected by the WTP. 454 The CAPWAP protocol provides for a keep alive feature that preserves 455 the communication channel between the WTP and AC. If the AC fails to 456 appear alive, the WTP will try to discover a new AC. 458 2.1. Wireless Binding Definition 460 The CAPWAP protocol is independent of a specific WTP radio 461 technology. Elements of the CAPWAP protocol are designed to 462 accommodate the specific needs of each wireless technology in a 463 standard way. Implementation of the CAPWAP protocol for a particular 464 wireless technology must follow the binding requirements defined for 465 that technology. 467 When defining a binding for wireless technologies, the authors MUST 468 include any necessary definitions for technology-specific messages 469 and all technology-specific message elements for those messages. At 470 a minimum, a binding MUST provide the definition for a binding- 471 specific Statistics message element, carried in the WTP Event Request 472 message, a message element carried in the Station Configure Request 473 to configure STA information on the WTP, and a WTP Radio Information 474 message element carried in the Discovery Request, Primary Discovery 475 Request and and Join Request messages, indicating the binding 476 specific radio types supported at the WTP. If technology specific 477 message elements are required for any of the existing CAPWAP messages 478 defined in this specification, they MUST also be defined in the 479 technology binding document. 481 The naming of binding-specific message elements MUST begin with the 482 name of the technology type, e.g., the binding for IEEE 802.11, 483 provided in [12], begins with "IEEE 802.11"." 485 2.2. CAPWAP Session Establishment Overview 487 This section describes the session establishment process message 488 exchanges in the ideal case. The annotated ladder diagram shows the 489 AC on the right, the WTP on the left, and assumes the use of 490 certificates for DTLS authentication. The CAPWAP Protocol State 491 Machine is described in detail in Section 2.3. 493 ============ ============ 494 WTP AC 495 ============ ============ 496 [----------- begin optional discovery ------------] 498 Discover Request ------> 499 <------ Discover Response 501 [----------- end optional discovery ------------] 502 (--- begin dtls handshake ---) 504 ClientHello ------> 505 <------ HelloVerifyRequest 506 (with cookie) 508 ClientHello ------> 509 (with cookie) 510 <------ ServerHello 511 <------ Certificate 512 <------ ServerHelloDone 514 (WTP callout for AC authorization) 516 Certificate* 517 ClientKeyExchange 518 CertificateVerify* 519 [ChangeCipherSpec] 520 Finished ------> 522 (AC callout for WTP 523 authorization) 525 [ChangeCipherSpec] 526 <------ Finished 528 (--- DTLS session is established now ---) 530 Join Request ------> 531 <------ Join Response 533 ( ---assume image is up to date ---) 535 Configure Request -------> 536 <------ Configure Response 538 (--- enter RUN state ---) 540 : 541 : 543 Echo Request -------> 544 <------ Echo Response 546 : 547 : 549 EventRequest -------> 550 <------ Event Response 552 : 553 : 555 At the end of the illustrated CAPWAP message exchange, the AC and WTP 556 are securely exchanging CAPWAP control messages. This is an 557 idealized illustration, provided to clarify protocol operation. 558 Section 2.3 provides a detailed description of the corresponding 559 state machine. 561 2.3. CAPWAP State Machine Definition 563 The following state diagram represents the lifecycle of a WTP-AC 564 session. Use of DTLS by the CAPWAP protocol results in the 565 juxtaposition of two nominally separate yet tightly bound state 566 machines. The DTLS and CAPWAP state machines are coupled through an 567 API consisting of commands (from CAPWAP to DTLS) and notifications 568 (from DTLS to CAPWAP). Certain transitions in the DTLS state machine 569 are triggered by commands from the CAPWAP state machine, while 570 certain transitions in the CAPWAP state machine are triggered by 571 notifications from the DTLS state machine. 573 /-------------------------\ 574 w| | 575 5+----------+ x +------------+ | 576 | Run |-->| Reset |-\| 577 +----------+ +------------+ || 578 u ^ ^ ^ y|| 579 +------------+--------/ | | || 580 | Data Check | /-------/ | || 581 +------------+<-------\ | | || 582 t| s| 4 o| || 583 +--------+ +-----------+ +------------+ || 584 | Join |---->| Configure |---->| Image Data | || 585 +--------+ q +-----------+ r +------------+ || 586 ^ p| || 587 | \------------------------------------\ || 588 \---------------------\ | || 589 /--------------<----------------+---------------\ | || 590 | /------------<-------------\ | | | || 591 | | m| |n z| v vv 592 | | +----------------+ +--------------+ +-----------+ 593 | | | DTLS Setup | | DTLS Connect | | DTLS TD | 594 | | +----------------+ +--------------+ +-----------+ 595 | | g| ^ ^ |h ^ ^ 596 v v | | | | | | 597 | | | | | \-------\ | /-----------/ 598 | | | | | | | | 599 | | v |e f| 2 v |j |k 600 | \->+------+ +------+ +-----------+ 601 | | Idle |-->| Disc | | Authorize | 602 \--->+------+ a +------+ +-----------+ 603 b| ^ |c 604 | | /----/ 605 v d| | 606 +---------+ | 607 | Sulking |<-/ 608 3 +---------+ 610 Figure 3: CAPWAP Integrated State Machine 612 The CAPWAP protocol state machine, depicted above, is used by both 613 the AC and the WTP. In cases where states are not shared (i.e. not 614 implemented in one or the other of the AC or WTP), this is explicitly 615 called out in the transition descriptions below. For every state 616 defined, only certain messages are permitted to be sent and received. 617 The CAPWAP control messages definitions specify the state(s) in which 618 each message is valid. 620 2.3.1. CAPWAP Protocol State Transitions 622 The following text discusses the various state transitions, and the 623 events that cause them. This section does not discuss interactions 624 between DTLS- and CAPWAP-specific states. Those interactions, as 625 well as DTLS-specific states and transitions, are discussed in 626 Section 2.3.2. 628 Idle to Discovery (a): This transition occurs once device 629 initialization is complete. 631 WTP: The WTP enters the Discovery state prior to transmitting the 632 first Discovery Request message (see Section 5.1). Upon 633 entering this state, the WTP sets the DiscoveryInterval timer 634 (see Section 4.6). The WTP resets the DiscoveryCount counter 635 to zero (0) (see Section 4.7). The WTP also clears all 636 information from ACs it may have received during a previous 637 Discovery phase. 639 AC: The AC does not maintain state information for the WTP upon 640 reception of the Discovery Request message, but it SHOULD 641 respond with a Discovery Response message (see Section 5.2). 642 This transition is a no-op for the AC. 644 Idle to Sulking (b): This transition occurs to force the WTP and AC 645 to enter a quiet period to avoid repeatedly attempting to 646 establish a connection. 648 WTP: The WTP enters this state when the FailedDTLSSessionCount 649 counter reaches MaxFailedDTLSSessionRetry variable (see 650 Section 4.7). Upon entering this state, the WTP shall start 651 the SilentInterval timer. While in the Sulking state, all 652 received CAPWAP and DTLS protocol messages received shall be 653 ignored. 655 AC: The AC enters this state with the specific WTP when the 656 FailedDTLSSessionCount counter reaches 657 MaxFailedDTLSSessionRetry variable (see Section 4.7). Upon 658 entering this state, the AC shall start the SilentInterval 659 timer. While in the Sulking state, all received CAPWAP and 660 DTLS protocol messages received from the WTP shall be ignored. 662 Discovery to Discovery (2): In the Discovery state, the WTP 663 determines which AC to connect to. 665 WTP: This transition occurs when the DiscoveryInterval timer 666 expires. If the WTP is configured with a list of ACs, it 667 transmits a Discovery Request message to every AC from which it 668 has not received a Discovery Response message. For every 669 transition to this event, the WTP increments the DiscoveryCount 670 counter. See Section 5.1 for more information on how the WTP 671 knows the ACs to which it should transmit the Discovery Request 672 messages. The WTP restarts the DiscoveryInterval timer 673 whenever it transmits Discovery Request messages. 675 AC: This is a no-op. 677 Discovery to Sulking (c): This transition occurs on a WTP when 678 Discovery or connectivity to the AC fails. 680 WTP: The WTP enters this state when the DiscoveryInterval timer 681 expires or the DiscoveryCount variable is equal to the 682 MaxDiscoveries variable (see Section 4.7). Upon entering this 683 state, the WTP shall start the SilentInterval timer. While in 684 the Sulking state, all received CAPWAP protocol messages 685 received shall be ignored. 687 AC: This is a no-op. 689 Sulking to Idle (d): This transition occurs on a WTP when it must 690 restart the discovery phase. 692 WTP: The WTP enters this state when the SilentInterval timer (see 693 Section 4.6) expires. The FailedDTLSSessionCount and 694 DiscoveryCount counters are reset to zero. 696 AC: The AC enters this state when the SilentInterval timer (see 697 Section 4.6) expires. The FailedDTLSSessionCount and 698 DiscoveryCount counters are reset to zero. 700 Sulking to Sulking (3): The Sulking state provides the silent 701 period, minimizing the possibility for Denial of service attacks. 703 WTP: All packets received from the AC while in the sulking state 704 are ignored. 706 AC: All packets receive from the WTP while in the sulking state 707 are ignored. 709 Idle to DTLS Setup (e): This transition occurs to establish a secure 710 DTLS session with the peer. 712 WTP: The WTP initiates this transition by invoking the DTLSStart 713 command, which starts the DTLS session establishment with the 714 chosen AC. This decision is performed via local configuration 715 of the AC. 717 AC: The AC initiates this transition by invoking the DTLSListen 718 command, which informs the DTLS stack that it is willing to 719 listen for an incoming session. The AC MAY provide optional 720 qualifiers in the DTLSListen to only accept session requests 721 from specific WTP. 723 Discovery to DTLS Setup (f): This transition occurs to establish a 724 secure DTLS session with the peer. 726 WTP: The WTP initiates this transition by invoking the DTLSStart 727 command (see Section 2.3.2.1), which starts the DTLS session 728 establishment with the chosen AC. The decision of which AC to 729 connect to is the result of the discovery phase, which is 730 described in Section 3.2. 732 AC: The AC initiates this transition by invoking the DTLSListen 733 command (see Section 2.3.2.1), which informs the DTLS stack 734 that it is willing to listen for an incoming session. The AC 735 MAY have maintained state information when it received the 736 Discovery Request in order to provide optional qualifiers in 737 the DTLSListen command to only accept session requests from 738 specific WTP. Note that maintaining state information based on 739 an unsecured discovery request MAY lead to a Denial of Service 740 attack. Therefore the AC SHOULD ensure that the state 741 information is freed after a period, which is implementation 742 specific. 744 DTLS Setup to Idle (g): This transition occurs when the DTLS Session 745 failed to be established. 747 WTP: The WTP initiates this state transition when it receives a 748 DTLSEstablishFail notification from DTLS (see Section 2.3.2.2). 749 This error notification aborts the secure DTLS session 750 establishment. When this transition occurs, the 751 FailedDTLSSessionCount counter is incremented. 753 AC: The WTP initiates this state transition when it receives a 754 DTLSEstablishFail notification from DTLS (see Section 2.3.2.2). 755 This error notification means a DTLS session was attempted with 756 a WTP, but failed. The notification should include information 757 such as the offending WTP, and the reason for the failure. 758 When this transition occurs, the FailedDTLSSessionCount counter 759 is incremented. 761 DTLS Setup to Authorize (h): This transition occurs an incoming DTLS 762 session is being established, and the DTLS stack needs 763 authorization to proceed with the session establishment. 765 WTP: This state transition occurs when the WTP receives the 766 DTLSPeerAuthorize notification (see Section 2.3.2.2). Upon 767 entering this state, the WTP MAY perform an authorization check 768 against the AC's credentials. The method by which this 769 authorization is performed is outside the scope of the CAPWAP 770 specification. 772 AC: This state transition occurs when the AC receives the 773 DTLSPeerAuthorize notification (see Section 2.3.2.2). Upon 774 entering this state, the AC MAY perform an authorization check 775 against the WTP's credentials. The method by which this 776 authorization is performed is outside the scope of the CAPWAP 777 specification. 779 Authorize to DTLS Connect (j): This transition occurs to notify the 780 DTLS stack that the session should be established. 782 WTP: This state transition occurs when the WTP has either opted 783 to forgo the authorization check of the AC's credentials, or 784 the credentials were successfully authorized. This is done by 785 invoking the DTLSAccept DTLS command (see Section 2.3.2.1). 787 AC: This state transition occurs when the AC has either opted to 788 forgo the authorization check of the WTP's credentials, or the 789 credentials were successfully authorized. This is done by 790 invoking the DTLSAccept DTLS command (see Section 2.3.2.1). 792 Authorize to DTLS Teardown (k): This transition occurs to notify the 793 DTLS stack that the session should be aborted. 795 WTP: This state transition occurs when the WTP was unable to 796 authorize the AC, via its credentials. The WTP then aborts the 797 DTLS session, which is done by invoking DTLSAbortSession (see 798 Section 2.3.2.1). 800 AC: This state transition occurs when the AC was unable to 801 authorize the WTP, via its credentials. The AC then aborts the 802 DTLS session, which is done by invoking DTLSAbortSession (see 803 Section 2.3.2.1). 805 DTLS Connect to Idle (m): This transition occurs when the DTLS 806 Session failed to be established. 808 WTP: This state transition occurs when the WTP receives the 809 DTLSAborted notification (see Section 2.3.2.2), indicating that 810 the DTLS session was not successfully established. When this 811 notification is received, the FailedDTLSSessionCount counter is 812 incremented. 814 AC: This state transition occurs when the AC receives the 815 DTLSAborted notification (see Section 2.3.2.2), indicating that 816 the DTLS session was not successfully established. When this 817 notification is received, the FailedDTLSSessionCount counter is 818 incremented. 820 DTLS Connect to Join (n): This transition occurs when the DTLS 821 Session is successfully established. 823 WTP: This state transition occurs when the WTP receives the 824 DTLSEstablished notification (see Section 2.3.2.2), indicating 825 that the DTLS session was successfully established. When this 826 notification is received, the FailedDTLSSessionCount counter is 827 set to zero. 829 AC: This state transition occurs when the AC receives the 830 DTLSEstablished notification (see Section 2.3.2.2), indicating 831 that the DTLS session was successfully established. When this 832 notification is received, the FailedDTLSSessionCount counter is 833 set to zero. 835 Join to DTLS Teardown (p): This transition occurs when the join 836 process failed. 838 WTP: This state transition occurs when the WTP receives a Join 839 Response with a Result Code message element containing an 840 error. This causes the WTP to initiate the DTLSShutdown 841 command (see Section 2.3.2.1). 843 AC: This state transition occurs when the AC transmits a Join 844 Response with a Result Code message element containing an 845 error. This causes the WTP to initiate the DTLSShutdown 846 command (see Section 2.3.2.1). 848 Join to Configure (g): This state transition is used by the WTP and 849 the AC to exchange configuration information. 851 WTP: The WTP enters the Configure state when it successfully 852 completes the Join operation. If it determines that its 853 version number and the version number advertised by the AC are 854 compatible, the WTP transmits the Configuration Status message 855 (see Section 8.2) to the AC with a snapshot of its current 856 configuration. The WTP also starts the ResponseTimeout timer 857 (see Section 4.6). If the version numbers are not compatible, 858 the WTP will immediately transition to Image Data state (see 859 transition (g)). If the AC determines that a new firmware 860 image should be installed on the WTP, the AC initiates a 861 firmware download by sending an Image Data Request Message with 862 an Initiate Download message element to the WTP 864 AC: This state transition occurs immediately after the AC 865 transmits the Join Response message to the WTP. If the AC 866 receives the Configuration Status message from the WTP, the AC 867 must transmit a Configuration Status Response message (see 868 Section 8.3) to the WTP, and may include specific message 869 elements to override the WTP's configuration. If the AC 870 instead receives the Image Data Request from the WTP, it 871 immediately transitions to the Image Data state (see transition 872 (g)). 874 Configure to Reset (s): This state transition is used to reset the 875 connection either due to an error during the configuration phase, 876 or when the WTP determines it needs to reset in order for the new 877 configuration to take effect. 879 WTP: The WTP enters the Reset state when it receives a 880 Configuration Status Response indicating an error or when it 881 determines that a reset of the WTP is required, due to the 882 characteristics of a new configuration. 884 AC: The AC transitions to the Reset state when it receives a 885 Change State Event message from the WTP that contains an error 886 for which the AC's policy does not permit the WTP providing 887 service. 889 Configure to Image Data (r): This state transition is used by the 890 WTP and the AC to download executable firmware. 892 WTP: The WTP enters the Image Data state when it successfully 893 comletes DTLS session establishment, and determines that its 894 version number and the version number advertised by the AC are 895 different. The WTP transmits the Image Data Request (see 896 Section 9.1) message requesting that a download of the AC's 897 latest firmware be initiated. 899 AC: This state transition occurs when the AC receives the Image 900 Data Request message from the WTP. The AC must transmit an 901 Image Data Response message (see Section 9.2) to the WTP, which 902 includes a portion of the firmware. 904 Image Data to Image Data (4): The Image Data state is used by WTP 905 and the AC during the firmware download phase. 907 WTP: The WTP enters the Image Data state when it receives an 908 Image Data Response message indicating that the AC has more 909 data to send. 911 AC: This state transition occurs when the AC receives the Image 912 Data Request message from the WTP while already in the Image 913 Data state, and it detects that the firmware download has not 914 completed. 916 Image Data to Reset (o): This state transition is used to reset the 917 DTLS connection prior to restarting the WTP after an image 918 download. 920 WTP: When an image download completes, the WTP enters the Reset 921 state. The WTP MAY also transition to this state upon 922 receiving an Image Data Response from the AC (see Section 9.2) 923 indicating a failure. 925 AC: The AC enters the Reset state when the image download is 926 complete, or if an error occurs during the image download 927 process. 929 Configure to Data Check (t): This state transition occurs when the 930 WTP and AC confirm the configuration. 932 WTP: The WTP enters this state when it receives a successful 933 Configuration Status Response message from the AC. The WTP 934 initializes the HeartBeat timer (see Section 4.6), and 935 transmits the Change State Event Request message (see 936 Section 8.7). 938 AC: This state transition occurs when the AC receives the Change 939 State Event Request message (see Section 8.7) from the WTP. 940 The AC responds with a Change State Event Response (see 941 Section 8.8) message. The AC must start the 942 NeighborDeadInterval timer (see Section 4.6). 944 Data Check to Run (u): This state transition occurs once the linkage 945 between the control and data channels has occured, which causes 946 the WTP and AC to enter their normal state of operation. 948 WTP: The WTP enters this state when it receives a successful 949 Change State Event Response from the AC. The WTP initiates the 950 data channel, which MAY require the establishment of a DTLS 951 session, starts the DataChannelKeepAlive timer (see 952 Section 4.6) and transmits a Data Channel Keep Alive (see 953 Section 4.3.1). The WTP then starts the 954 DataChannelDeadInterval timer (see Section 4.6). 956 AC: This state transition occurs when the AC receives the Data 957 Channel Keep Alive (see Section 4.3.1), whose Session ID 958 message element matches the one included by the WTP in the Join 959 Request. Note that if the AC's policy is to require the data 960 channel to be encrypted, this process would also require the 961 establishment of the data channel's DTLS session. Upon 962 receiving the Data Channel Keep Alive, the AC transmits its own 963 Data Channel Keep Alive. 965 Run to DTLS Teardown (u): This state transition occurs when an error 966 has occured in the DTLS stack, causing the DTLS session to be 967 torndown. 969 WTP: The WTP enters this state when it receives a one of the 970 following DTLS notifications: DTLSAborted, 971 DTLSReassemblyFailure, DTLSDecapFailure or DTLSPeerDisconnect 972 (see Section 2.3.2.2). 974 AC: The AC enters this state when it receives a one of the 975 following DTLS notifications: DTLSAborted, 976 DTLSReassemblyFailure, DTLSDecapFailure or DTLSPeerDisconnect 977 (see Section 2.3.2.2). 979 Run to Run (5): This is the normal state of operation. 981 WTP: This is the WTP's normal state of operation. There are many 982 events that result this state transition: 984 Configuration Update: The WTP receives a Configuration Update 985 Request message(see Section 8.5). The WTP MUST respond with 986 a Configuration Update Response message (see Section 8.6). 988 Change State Event: The WTP receives a Change State Event 989 Response message, or determines that it must initiate a 990 Change State Event Request message, as a result of a failure 991 or change in the state of a radio. 993 Echo Request: The WTP receives an Echo Request message (see 994 Section 7.1), to which it MUST respond with an Echo Response 995 message(see Section 7.2). 997 Clear Config Request: The WTP receives a Clear Configuration 998 Request message (see Section 8.9). The WTP MUST reset its 999 configuration back to manufacturer defaults. 1001 WTP Event: The WTP generates a WTP Event Request message to 1002 send information to the AC (see Section 9.5). The WTP 1003 receives a WTP Event Response message from the AC (see 1004 Section 9.6). 1006 Data Transfer: The WTP generates a Data Transfer Request 1007 message to the AC (see Section 9.7). The WTP receives a 1008 Data Transfer Response message from the AC (see 1009 Section 9.8). 1011 Station Configuration Request: The WTP receives a Station 1012 Config Request message (see Section 10.1), to which it MUST 1013 respond with a Station Config Response message (see 1014 Section 10.2). 1016 AC: This is the AC's normal state of operation: 1018 Configuration Update: The AC sends a Configuration Update 1019 Request message (see Section 8.5) to the WTP to update its 1020 configuration. The AC receives a Configuration Update 1021 Response message (see Section 8.6) from the WTP. 1023 Change State Event: The AC receives a Change State Event 1024 Request message (see Section 8.7), to which it MUST respond 1025 with the Change State Event Response message (see 1026 Section 8.8). 1028 Echo: The AC sends an Echo Request message Section 7.1 or 1029 receives the corresponding Echo Response message, see 1030 Section 7.2 from the WTP. 1032 Clear Config Response: The AC receives a Clear Configuration 1033 Response message (see Section 8.10). 1035 Station Config: The AC sends a Station Configuration Request 1036 message (see Section 10.1) or receives the corresponding 1037 Station Configuration Response message (see Section 10.2) 1038 from the WTP. 1040 Data Transfer: The AC receives a Data Transfer Request message 1041 from the AC (see Section 9.7) and MUST generate a 1042 corresponding Data Transfer Response message (see 1043 Section 9.8). 1045 WTP Event: The AC receives a WTP Event Request message from 1046 the AC (see Section 9.5) and MUST generate a corresponding 1047 WTP Event Response message (see Section 9.6). 1049 Run to Reset (x): This state transition is used when the AC or WTP 1050 wish to tear down the connection. This may occur as part of 1051 normal operation, or due to error conditions. 1053 WTP: The WTP enters the Reset state when it receives a Reset 1054 Request from the AC. 1056 AC: The AC enters the reset state when it transmits a Reset 1057 Request to the WTP. 1059 Reset to DTLS Teardown (y): This transition occurs when the CAPWAP 1060 reset is complete to terminate the DTLS session. 1062 WTP: This state transition occurs when the WTP receives a Reset 1063 Response. This causes the WTP to initiate the DTLSShutdown 1064 command (see Section 2.3.2.1). 1066 AC: This state transition occurs when the AC transmits a Reset 1067 Response. This causes the WTP to initiate the DTLSShutdown 1068 command (see Section 2.3.2.1). 1070 DTLS Teardown to Idle (z): This transition occurs when the DTLS 1071 session has been shutdown. 1073 WTP: This state transition occurs when the WTP receives a 1074 DTLSPeerDisconnect notification (see Section 2.3.2.2). 1076 AC: This state transition occurs when the AC receives a 1077 DTLSPeerDisconnect notification (see Section 2.3.2.2). 1079 2.3.2. CAPWAP/DTLS Interface 1081 This section describes the DTLS Commands used by CAPWAP, as well as 1082 the notifications received from DTLS to the CAPWAP protocol stack. 1084 2.3.2.1. CAPWAP to DTLS Commands 1086 Four commands are defined for the CAPWAP to DTLS API. These 1087 "commands" are conceptual, and may be implemented as one or more 1088 function calls. This API definition is provided to clarify 1089 interactions between the DTLS and CAPWAP components of the integrated 1090 CAPWAP state machine. 1092 Below is a list of the minimal command API: 1094 o DTLSStart is sent to the DTLS module to cause a DTLS session to be 1095 established. Upon invoking the DTLSStart command, the WaitDTLS 1096 timer is started. The WTP is the only CAPWAP device that 1097 initiates this DTLS command, as the AC does not initiate DTLS 1098 sessions. 1100 o DTLSListen is sent to the DTLS module to allow the DTLS to listen 1101 for incoming DTLS session requests. 1103 o DTLSAccept is sent to the DTLS module to allow the DTLS session 1104 establishment to continue successfully. 1106 o DTLSAbortSession is sent to the DTLS module to cause the session 1107 that is in the process of being established, to be aborted. This 1108 command is also sent when the WaitDTLS timer expires. When this 1109 command is executed, the FailedDTLSSessionCount counter is 1110 incremented. 1112 o DTLSShutdown is sent to the DTLS module to cause session teardown. 1114 2.3.2.2. DTLS to CAPWAP Notifications 1116 DTLS notifications are defined for the DTLS to CAPWAP API. These 1117 "notifications" are conceptual, and may be implemented in numerous 1118 ways (e.g. as function return values). This API definition is 1119 provided to clarify interactions between the DTLS and CAPWAP 1120 components of the integrated CAPWAP state machine. It is important 1121 to note that the notifications listed below MAY cause the CAPWAP 1122 state machine to jump from one state to another using a state 1123 transition not listed in section Section 2.3.1. When a notification 1124 listed below occurs, the target CAPWAP state shown in Figure 3 1125 becomes the current state. 1127 Below is a list of the API notifications: 1129 o DTLSIncomingSession is sent to the CAPWAP protocol stack during 1130 the DTLS session establishment once the peer's identity has been 1131 received. This notification MAY be used by the CAPWAP protocol 1132 stack in order to authorize the session, based on the peer's 1133 identity. The authorization process will lead to the CAPWAP 1134 protocol stack initiating either the DTLSAccept or 1135 DTLSAbortSession commands. 1137 o DTLSEstablished is sent to the CAPWAP module to indicate that that 1138 a secure channel now exists, using the parameters provided during 1139 the DTLS initialization process. When this notification is 1140 received, the FailedDTLSSessionCount counter is reset to zero. 1141 When this notification is received, the WaitDTLS is stopped. 1143 o DTLSEstablishFail is sent when the DTLS session establishment has 1144 failed, either due to a local error, or due to the peer rejecting 1145 the session establishment. When this notification is received, 1146 the FailedDTLSSessionCount counter is reset to zero. When this 1147 notification is received, the WaitDTLS is stopped. 1149 o DTLSAborted is sent to the CAPWAP module to indicate that session 1150 abort (as requested by CAPWAP) is complete; this occurs to confirm 1151 a DTLS session abort, or when the WaitDTLS timer expires. When 1152 this notification is received, the WaitDTLS is stopped. 1154 o DTLSReassemblyFailure may be sent to the CAPWAP module to indicate 1155 DTLS fragment reassembly failure. 1157 o DTLSDecapFailure may be sent to CAPWAP to indicate an 1158 decapsulation failure. DTLSDecapFailure may be sent to CAPWAP to 1159 indicate an encryption/authentication failure. 1161 o DTLSPeerDisconnect is sent to the CAPWAP module to indicate the 1162 DTLS session has been torn down. Note that this notification is 1163 only received if the DTLS session has been established. 1165 2.4. Use of DTLS in the CAPWAP Protocol 1167 DTLS is used as a tightly-integrated, secure wrapper for the CAPWAP 1168 protocol. In this document DTLS and CAPWAP are discussed as 1169 nominally distinct entitites; however they are very closely coupled, 1170 and may even be implemented inseparably. Since there are DTLS 1171 library implementations currently available, and since security 1172 protocols (e.g. IPsec, TLS) are often implemented in widely 1173 available acceleration hardware, it is both convenient and forward- 1174 looking to maintain a modular distinction in this document. 1176 This section describes a detailed walk-through of the interactions 1177 between the DTLS module and the CAPWAP module, via 'commands' (CAPWAP 1178 to DTLS) and 'notifications' (DTLS to CAPWAP) as they would be 1179 encountered during the normal course of operation. 1181 2.4.1. DTLS Handshake Processing 1183 Details of the DTLS handshake process are specified in [9]. This 1184 section describes the interactions between the DTLS session 1185 establishment process and the CAPWAP protocol. Note that the 1186 conceptual DTLS state is shown below to help understand the point at 1187 which the DTLS states transition. In the normal case, the DTLS 1188 handshake will proceed as follows (NOTE: this example uses 1189 certificates, but preshared keys are also supported): 1191 ============ ============ 1192 WTP AC 1193 ============ ============ 1194 1195 ClientHello ------> 1196 <------ HelloVerifyRequest 1197 (with cookie) 1199 1200 ClientHello ------> 1201 (with cookie) 1202 1203 <------ ServerHello 1204 <------ Certificate 1205 <------ ServerHelloDone 1207 (WTP callout for AC authorization 1208 occurs in CAPWAP Auth state) 1210 1211 Certificate* 1212 ClientKeyExchange 1213 CertificateVerify* 1214 [ChangeCipherSpec] 1215 Finished ------> 1217 (AC callout for WTP authorization 1218 occurs in CAPWAP Auth state) 1220 1221 [ChangeCipherSpec] 1222 <------ Finished 1224 DTLS, as specified, provides its own retransmit timers with an 1225 exponential back-off. However, it will never terminate the handshake 1226 due to non-responsiveness; rather, it will continue to increase its 1227 back-off timer period. Hence, timing out incomplete DTLS handshakes 1228 is entirely the responsiblity of the CAPWAP protocol. 1230 2.4.2. DTLS Session Establishment 1232 The WTP, either through the Discovery process, or through pre- 1233 configuration, determines the AC to connect to. The WTP uses the 1234 DTLSStart command to request that a secure connection be established 1235 to the selected AC. Prior to initiation of the DTLS handshake, the 1236 WTP sets the WaitDTLS timer. Upon receiving the DTLSIncomingSession 1237 DTLS notification, the AC sets the WaitDTLS timer. If the 1238 DTLSEstablished notification is not received prior to timer 1239 expiration, the DTLS session is aborted by issuing the 1240 DTLSAbortSession DTLS command. This notification causes the CAPWAP 1241 state to transition back to the Idle state. Upon receiving a 1242 DTLSEstablished notification, the WaitDTLS timer is deactivated. 1244 2.4.3. DTLS Error Handling 1246 If the AC does not respond to any DTLS messages sent by the WTP, the 1247 DTLS specification calls for the WTP to retransmit these messages. 1248 If the WaitDTLS timer expires, CAPWAP will issue the DTLSAbortSession 1249 command, causing DTLS to terminate the handshake and remove any 1250 allocated session context. Note that DTLS MAY send a single TLS 1251 Alert message to the AC to indicate session termination. 1253 If the WTP does not respond to any DTLS messages sent by the AC, the 1254 CAPWAP protocol allows for three possiblities, listed below. Note 1255 that DTLS MAY send a single TLS Alert message to the AC to indicate 1256 session termination. 1258 o The message was lost in transit; in this case, the WTP will re- 1259 transmit its last outstanding message, since it did not receive 1260 the reply. 1262 o The WTP sent a DTLS Alert, which was lost in transit; in this 1263 case, the AC's WaitDTLS timer will expire, and the session will be 1264 terminated. 1266 o Communication with the WTP has completely failed; in this case, 1267 the AC's WaitDTLS timer will expire, and the session will be 1268 terminated. 1270 The DTLS specification provides for retransmission of unacknowledged 1271 requests. If retransmissions remain unacknowledged, the WaitDTLS 1272 timer will eventually expire, at which time the CAPWAP module will 1273 terminate the session. 1275 If a cookie fails to validate, this could represent a WTP error, or 1276 it could represent a DoS attack. Hence, AC resource utilization 1277 SHOULD be minimized. The AC MAY log a message indicating the 1278 failure, but SHOULD NOT attempt to reply to the WTP. 1280 Since DTLS handshake messages are potentially larger than the maximum 1281 record size, DTLS supports fragmenting of handshake messages across 1282 multiple records. There are several potential causes of re-assembly 1283 errors, including overlapping and/or lost fragments. The DTLS module 1284 MUST send a DTLSReassemblyFailure notification to CAPWAP. Whether 1285 precise information is given along with notification is an 1286 implementation issue, and hence is beyond the scope of this document. 1287 Upon receipt of such an error, the CAPWAP protocol implementation 1288 SHOULD log an appropriate error message. Whether processing 1289 continues or the DTLS session is terminated is implementation 1290 dependent. 1292 DTLS decapsulation errors consist of three types: decryption errors, 1293 and authentication errors, and malformed DTLS record headers. Since 1294 DTLS authenticates the data prior to encapsulation, if decryption 1295 fails, it is difficult to detect this without first attempting to 1296 authenticate the packet. If authentication fails, a decryption error 1297 is also likely, but not guaranteed. Rather than attempt to derive 1298 (and require the implementation of) algorithms for detecting 1299 decryption failures, these are reported as authentication failures. 1300 The DTLS module MUST provide a DTLSDecapFailure notification to 1301 CAPWAP when such errors occur. If a malformed DTLS record header is 1302 detected, the packets SHOULD be silently discarded, and the receiver 1303 MAY log an error message. 1305 There is currently only one encapsulation error defined: MTU 1306 exceeeded. As part of DTLS session establishment, CAPWAP informs 1307 DTLS of the MTU size. This may be dynamically modified at any time 1308 when CAPWAP sends the DTLSMtuUpdate command to DTLS. DTLS returns 1309 this notification to CAPWAP whenever a transmission request will 1310 result in a packet which exceeds the MTU. 1312 2.4.4. DTLS EndPoint Authentication 1314 DTLS supports endpoint authentication with certificates or preshared 1315 keys. The TLS algorithm suites for each endpoint authentication 1316 method are described below. 1318 2.4.4.1. Authenticating with Certificates 1320 Note that only block ciphers are currently recommended for use with 1321 DTLS. To understand the reasoning behind this, see [14]. However, 1322 support for AES counter mode encryption is currently progressing in 1323 the TLS working group, and once protocol identifiers are available, 1324 they will be added below. At present, the following algorithms MUST 1325 be supported when using certificates for CAPWAP authentication: 1327 o TLS_RSA_WITH_AES_128_CBC_SHA 1329 o TLS_RSA_WITH_3DES_EDE_CBC_SHA 1331 The following algorithms SHOULD be supported when using certificates: 1333 o TLS_DH_RSA_WITH_AES_128_CBC_SHA 1335 o TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA 1337 The following algorithms MAY be supported when using certificates: 1339 o TLS_RSA_WITH_AES_256_CBC_SHA 1341 o TLS_DH_RSA_WITH_AES_256_CBC_SHA 1343 2.4.4.2. Authenticating with Preshared Keys 1345 Pre-shared keys present significant challenges from a security 1346 perspective, and for that reason, their use is strongly discouraged. 1347 However, [6] defines several different methods for authenticating 1348 with preshared keys, and we focus on the following two: 1350 o PSK key exchange algorithm - simplest method, ciphersuites use 1351 only symmetric key algorithms 1353 o DHE_PSK key exchange algorithm - use a PSK to authenticate a 1354 Diffie-Hellman exchange. These ciphersuites give some additional 1355 protection against dictionary attacks and also provide Perfect 1356 Forward Secrecy (PFS). 1358 The first approach (plain PSK) is susceptible to passive dictionary 1359 attacks; hence, while this alorithm MUST be supported, special care 1360 should be taken when choosing that method. In particular, user- 1361 readable passphrases SHOULD NOT be used, and use of short PSKs SHOULD 1362 be strongly discouraged. 1364 The following cryptographic algorithms MUST be supported when using 1365 preshared keys: 1367 o TLS_PSK_WITH_AES_128_CBC_SHA 1369 o TLS_PSK_WITH_3DES_EDE_CBC_SHA 1371 o TLS_DHE_PSK_WITH_AES_128_CBC_SHA 1373 o TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA 1374 The following algorithms MAY be supported when using preshared keys: 1376 o TLS_PSK_WITH_AES_256_CBC_SHA 1378 o TLS_DHE_PSK_WITH_AES_256_CBC_SHA 1380 2.4.4.3. Certificate Usage 1382 When using certificates, both authentication and authorization must 1383 be considered. Section 12.3 provides recommendations on how to 1384 authenticate a certificate and bind that to a CAPWAP entity. This 1385 section deals with certificate authorization. 1387 Certificate authorization by the AC and WTP is required so that only 1388 an AC may perform the functions of an AC and that only a WTP may 1389 perform the functions of a WTP. This restriction of functions to the 1390 AC or WTP requires that the certificates used by the AC MUST be 1391 distinguishable from the certificate used by the WTP. To accomplish 1392 this differentiation, the x.509 certificates MUST include the 1393 Extended Key Usage (EKU) certificate extension [4]. 1395 The EKU field indicates one or more purposes for which a certificate 1396 may be used. It is an essential part in authorization. Its syntax 1397 is as follows: 1399 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 1401 KeyPurposeId ::= OBJECT IDENTIFIER 1403 Here we define two KeyPurposeId values, one for the WTP and one for 1404 the AC. Inclusion of one of those two values indicates a certificate 1405 is authorized for use by a WTP or AC, respectively. These values are 1406 formatted as id-kp fields. 1408 id-kp OBJECT IDENTIFIER ::= 1409 { iso(1) identified-organization(3) dod(6) internet(1) 1410 security(5) mechanisms(5) pkix(7) 3 } 1412 id-kp-capwapWTP OBJECT IDENTIFIER ::= { id-kp 19 } 1414 id-kp-capwapAC OBJECT IDENTIFIER ::= { id-kp 18 } 1416 For an AC, the id-kp-capwapAC EKU MUST be present in the certificate. 1417 For a WTP, the id-kp-capwapWTP EKU MUST be present in the 1418 certificate. 1420 Part of the CAPWAP certificate validation process includes ensuring 1421 that the proper EKU is included and only allowing the CAPWAP session 1422 to be established if the extension properly represents the device. 1424 3. CAPWAP Transport 1426 The CAPWAP protocol uses UDP as a transport, and can be used with 1427 IPv4 or IPv6. This section details the specifics of how the CAPWAP 1428 protocol works in conjunction with IP. 1430 3.1. UDP Transport 1432 Communication between a WTP and an AC is established according to the 1433 standard UDP client/server model. One of the CAPWAP requirements is 1434 to allow a WTP to reside behind a firewall and/or Network Address 1435 Translation (NAT) device. Since the connection is initiated by the 1436 WTP (client) to the well-known UDP port of the AC (server), the use 1437 of UDP is a logical choice. 1439 CAPWAP protocol control packets sent between the WTP and the AC use 1440 well known UDP port [to be IANA assigned]. CAPWAP protocol data 1441 packets sent between the WTP and the AC use UDP port [to be IANA 1442 assigned]. 1444 3.2. AC Discovery 1446 A WTP and an AC will frequently not reside in the same IP subnet 1447 (broadcast domain). When this occurs, the WTP must be capable of 1448 discovering the AC, without requiring that multicast services are 1449 enabled in the network. This section describes how AC discovery is 1450 performed by WTPs. 1452 As the WTP attempts to establish communication with an AC, it sends 1453 the Discovery Request message and receives the corresponding response 1454 message from the AC(s). The WTP must send the Discovery Request 1455 message to either the limited broadcast IP address (255.255.255.255), 1456 a well known multicast address or to the unicast IP address of the 1457 AC. Upon receipt of the Discovery Request message, the AC issues a 1458 Discovery Response message to the unicast IP address of the WTP, 1459 regardless of whether the Discovery Request message was sent as a 1460 broadcast, multicast or unicast message. 1462 WTP use of a limited IP broadcast, multicast or unicast IP address is 1463 implementation dependent. 1465 When a WTP transmits a Discovery Request message to a unicast 1466 address, the WTP must first obtain the IP address of the AC. Any 1467 static configuration of an AC's IP address on the WTP non-volatile 1468 storage is implementation dependent. However, additional dynamic 1469 schemes are possible, for example: 1471 DHCP: A comma delimited ASCII encoded list of AC IP addresses is 1472 embedded in the DHCP code number TBD. An example of the actual 1473 format of the vendor specific payload for IPv4 is of the form 1474 "10.1.1.1, 10.1.1.2". 1476 DNS: The DNS name "CAPWAP-AC-Address" MAY be resolvable to one or 1477 more AC addresses. 1479 3.3. Fragmentation/Reassembly 1481 While fragmentation and reassembly services are provided by IP, the 1482 CAPWAP protocol also provides such services. Environments where the 1483 CAPWAP protocol is used involve firewall, Network Address Translation 1484 (NAT) and "middle box" devices, which tend to drop IP fragments in 1485 order to minimize possible Denial of Service attacks. By providing 1486 fragmentation and reassembly at the application layer, any 1487 fragmentation required due to the tunneling component of the CAPWAP 1488 protocol becomes transparent to these intermediate devices. 1489 Consequently, the CAPWAP protocol is not impacted by any network 1490 configurations. 1492 4. CAPWAP Packet Formats 1494 This section contains the CAPWAP protocol packet formats. A CAPWAP 1495 protocol packet consists of a CAPWAP Transport Layer packet header 1496 followed by a CAPWAP message. The CAPWAP message can be either of 1497 type Control or Data, where Control packets carry signaling, and Data 1498 packets carry user payloads. The CAPWAP frame formats for CAPWAP 1499 Data packets, and for DTLS encapsulated CAPWAP Data and Control 1500 packets. See section Section 3.1 for more information on the use of 1501 UDP. 1503 The CAPWAP Control protocol includes two messages that are never 1504 protected by DTLS. These messages, called the Discovery Request and 1505 Discovery Response, need to be in the clear in order for the CAPWAP 1506 protocol to properly identify and process them. The format of these 1507 packets are as follows: 1509 CAPWAP Control Packet (Discovery Request/Response): 1510 +---------------------------------------------------+ 1511 | IP | UDP | CAPWAP |CAPWAP | Control | Message | 1512 | Hdr | Hdr | p-amble|Header | Header | Element(s) | 1513 +---------------------------------------------------+ 1515 All other CAPWAP control protocol messages MUST be protected via the 1516 DTLS protocol, which ensures that the packets are both authenticated 1517 and encrypted. The format of these packets are as follows: 1519 CAPWAP Control Packet (DTLS Security Required): 1520 +------------------------------------------------------------------+ 1521 | IP | UDP | CAPWAP | DTLS | CAPWAP | Control | Message | DTLS | 1522 | Hdr | Hdr | p-amble| Hdr | Header | Header | Element(s) | Trlr | 1523 +------------------------------------------------------------------+ 1524 \----------- authenticated ------------/ 1525 \------------- encrypted -------------/ 1527 The CAPWAP protocol allows optional encryption of the data frames, 1528 once again using the DTLS protocol. Whether or not the data frames 1529 are encrypted is a matter of policy, which is described in a later 1530 section of this specification. The format of these packets is as 1531 follows: 1533 CAPWAP Plain Text Data Packet : 1534 +-----------------------------------------+ 1535 | IP | UDP | CAPWAP | CAPWAP | Wireless | 1536 | Hdr | Hdr | p-amble| Header | Payload | 1537 +-----------------------------------------+ 1539 DTLS Secured CAPWAP Data Packet: 1540 +------------------------------------------------------+ 1541 | IP | UDP | CAPWAP | DTLS | CAPWAP | Wireless | DTLS | 1542 | Hdr | Hdr | p-amble| Hdr | Hdr | Payload | Trlr | 1543 +------------------------------------------------------+ 1544 \----- authenticated -----/ 1545 \------- encrypted --------/ 1547 UDP: All CAPWAP packets are encapsulated within UDP. Section 1548 Section 3.1 defines the specific UDP usage. 1550 CAPWAP preamble: All CAPWAP protocol packets are prefixed with the 1551 preable header, which is used to identify the frame type that 1552 follows. This header, is defined in Section 4.1. 1554 DTLS Header: The DTLS header provides authentication and encrytion 1555 services to the CAPWAP payload it encapsulates. This protocol is 1556 defined in RFC 4347 [9]. 1558 CAPWAP Header: All CAPWAP protocol packets use a common header that 1559 immediately follows the UDP header. This header, is defined in 1560 Section 4.2. 1562 Wireless Payload: A CAPWAP protocol packet that contains a wireless 1563 payload is known as a data frame. The CAPWAP protocol does not 1564 dictate the format of the wireless payload, which is defined by 1565 the appropriate wireless standard. Additional information is in 1566 Section 4.3. 1568 Control Header: The CAPWAP protocol includes a signalling component, 1569 known as the CAPWAP control protocol. All CAPWAP control packets 1570 include a Control Header, which is defined in Section 4.4.1. 1572 Message Elements: A CAPWAP Control packet includes one or more 1573 message elements, which are found immediately following the 1574 control header. These message elements are in a Type/Length/value 1575 style header, defined in Section 4.5. 1577 4.1. CAPWAP preamble 1579 The CAPWAP preamble header is used to help identify the payload type 1580 that immediately follows. The reason for this header to is avoid 1581 needing the perform byte comparisons in order to guess whether the 1582 frame is DTLS encrypted or not. The format of the frame is as 1583 follows: 1585 0 1 2 3 1586 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 1587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1588 |Version| Type | Reserved | 1589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1591 Version: A 4 bit field which contains the version of CAPWAP used in 1592 this packet. The value for this draft is zero (0). 1594 Payload Type: A 4 bit field which specifies the payload type that 1595 follows the preamble header. The following values are supported: 1597 0 - Clear text. If the packet is received on the data UDP port, 1598 the CAPWAP stack MUST treat this as a clear text CAPWAP data 1599 packet. If received on the control UDP port, the CAPWAP stack 1600 MUST treat this as a clear text CAPWAP control packet. If the 1601 control packet is not a Discovery Request or Response packet, 1602 it is illegal and MUST be dropped. 1604 1 - DTLS Payload. The packet is either a DTLS packet and MAY be 1605 a data or control packet, based on the UDP port it was received 1606 on (see section Section 3.1). 1608 Reserved: The 24-bit field is reserved for future use. All 1609 implementations complying with this protocol MUST set to zero any 1610 bits that are reserved in the version of the protocol supported by 1611 that implementation. Receivers MUST ignore all bits not defined 1612 for the version of the protocol they support. 1614 4.2. CAPWAP Header 1616 All CAPWAP protocol messages are encapsulated using a common header 1617 format, regardless of the CAPWAP control or CAPWAP Data transport 1618 used to carry the messages. However, certain flags are not 1619 applicable for a given transport. Refer to the specific transport 1620 section in order to determine which flags are valid. 1622 Note that the optional fields defined in this section MUST be present 1623 in the precise order shown below. 1625 0 1 2 3 1626 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 1627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1628 |Version| RID | HLEN | WBID |T|F|L|W|M|K| Flags | 1629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1630 | Fragment ID | Frag Offset |Rsvd | 1631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1632 | (optional) Radio MAC Address | 1633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1634 | (optional) Wireless Specific Information | 1635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1636 | Payload .... | 1637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1639 Version: A 4 bit field which contains the version of CAPWAP used in 1640 this packet. The value of this field MUST match the version field 1641 set in the CAPWAP preamble header (see Section 4.1). The reason 1642 for this duplicate field is to avoid any possible tampering of the 1643 version field in the preamble header which is not encrypted or 1644 authenticated. 1646 RID: A 5 bit field which contains the Radio ID number for this 1647 packet. WTPs with multiple radios but a single MAC Address range 1648 use this field to indicate which radio is associated with the 1649 packet. 1651 HLEN: A 5 bit field containing the length of the CAPWAP transport 1652 header in 4 byte words (Similar to IP header length). This length 1653 includes the optional headers. 1655 WBID: A 5 bit field which is the wireless binding identifier. The 1656 identifier will indicate the type of wireless packet type 1657 associated with the radio. The following values are defined: 1659 1 - IEEE 802.11 1661 2 - IEEE 802.16 1663 3 - EPCGlobal 1665 T: The Type 'T' bit indicates the format of the frame being 1666 transported in the payload. When this bit is set to one (1), the 1667 payload has the native frame format indicated by the WBID field. 1668 When this bit is zero (0) the payload is an IEEE 802.3 frame. 1670 F: The Fragment 'F' bit indicates whether this packet is a fragment. 1671 When this bit is one (1), the packet is a fragment and MUST be 1672 combined with the other corresponding fragments to reassemble the 1673 complete information exchanged between the WTP and AC. 1675 L: The Last 'L' bit is valid only if the 'F' bit is set and indicates 1676 whether the packet contains the last fragment of a fragmented 1677 exchange between WTP and AC. When this bit is 1, the packet is 1678 the last fragment. When this bit is 0, the packet is not the last 1679 fragment. 1681 W: The Wireless 'W' bit is used to specify whether the optional 1682 wireless specific information field is present in the header. A 1683 value of one (1) is used to represent the fact that the optional 1684 header is present. 1686 M: The M bit is used to indicate that the Radio MAC Address optional 1687 header is present. This is used to communicate the MAC address of 1688 the receiving radio when the native wireless packet. This field 1689 MUST NOT be set to one in packets sent by the AC to the WTP. 1691 K: The 'Keep-alive' K bit indicates the packet is a data channel 1692 keep-alive packet. This packet is used to map the data channel to 1693 the control channel for the specified Session ID and to maintain 1694 freshness of the Data Channel. The K bit MUST NOT be set for data 1695 packets containing user data. 1697 Flags: A set of reserved bits for future flags in the CAPWAP header. 1698 All implementations complying with this protocol MUST set to zero 1699 any bits that are reserved in the version of the protocol 1700 supported by that implementation. Receivers MUST ignore all bits 1701 not defined for the version of the protocol they support. 1703 Fragment ID: An 16 bit field whose value is assigned to each group 1704 of fragments making up a complete set. The fragment ID space is 1705 managed individually for every WTP/AC pair. The value of Fragment 1706 ID is incremented with each new set of fragments. The Fragment ID 1707 wraps to zero after the maximum value has been used to identify a 1708 set of fragments. 1710 Fragment Offset: A 13 bit field that indicates where in the payload 1711 will this fragment belong during re-assembly. This field is valid 1712 when the 'F' bit is set to 1. The fragment offset is measured in 1713 units of 8 octets (64 bits). The first fragment has offset zero. 1714 Note the CAPWAP protocol does not allow for overlapping fragments. 1715 For instance, fragment 0 would include offset 0 with a payload 1716 length of 1000, while fragment 1 include offset 900 with a payload 1717 length of 600. 1719 Reserved: The 3-bit field is reserved for future use. All 1720 implementations complying with this protocol MUST set to zero any 1721 bits that are reserved in the version of the protocol supported by 1722 that implementation. Receivers MUST ignore all bits not defined 1723 for the version of the protocol they support. 1725 Radio MAC Address: This optional field contains the MAC address of 1726 the radio receiving the packet. This is useful in packets sent 1727 from the WTP to the AC, when the native wireless frame format is 1728 converted to 802.3 by the WTP. This field is only present if the 1729 'M' bit is set. Given the HLEN field assumes 4 byte alignment, 1730 this field MUST be padded with zeroes (0x00) if it is not 4 byte 1731 aligned. 1733 The field contains the basic format: 1735 0 1 2 3 1736 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 1737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1738 | Length | MAC Address 1739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1741 Length: The number of bytes in the MAC Address field. The length 1742 field is present since some technologies (e.g., IEEE 802.16) 1743 are now using 64 bit MAC addresses. 1745 MAC Address: The MAC Address of the receiving radio. 1747 Wireless Specific Information: This optional field contains 1748 technology specific information that may be used to carry per 1749 packet wireless information. This field is only present if the 1750 'W' bit is set. Given the HLEN field assumes 4 byte alignment, 1751 this field MUST be padded with zeroes (0x00) if it is not 4 byte 1752 aligned. 1754 The field contains the basic format: 1756 0 1 2 3 1757 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 1758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1759 | Wireless ID | Length | Data 1760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1762 Wireless ID: The wireless binding identifier. The following 1763 values are defined: 1765 1 - : IEEE 802.11 1767 IEEE 802.16 1769 EPCGlobal 1771 Length: The length of the data field 1773 Data: Wireless specific information, defined by the wireless 1774 specific binding. 1776 Payload: This field contains the header for a CAPWAP Data Message or 1777 CAPWAP Control Message, followed by the data associated with that 1778 message. 1780 4.3. CAPWAP Data Messages 1782 There are two different types of CAPWAP data messages; keepalive and 1783 user payload. The first is used by the WTP to synchronize the 1784 control and data channels, as well as to maintain freshness of the 1785 data channel. The second is used to transmit user payloads between 1786 the AC and WTP. This section will detail both types of CAPWAP data 1787 messages. 1789 Both CAPWAP data messages are transmitted on the data channel UDP 1790 port. 1792 4.3.1. CAPWAP Data Keepalive 1794 The CAPWAP data keepalive is used to bind the CAPWAP control channel 1795 with the data channel. The keep alive is also used to maintain 1796 freshness of the data channel, meaning ensuring the channel is still 1797 in functioning. The CAPWAP Data Keepalive is transmitted by the WTP 1798 when the DataChannelKeepAlive timer expires. When the CAPWAP Data 1799 Keepalive is transmitted, the WTP sets the DataChannelDeadInterval 1800 timer. 1802 All of the fields in the CAPWAP header, other than the HLEN and K 1803 bit, are set to zero upon transmission. Upon receiving a CAPWAP Data 1804 Keepalive, the AC transmits a CAPWAP Data Keepalive message back to 1805 the WTP. The contents of the CAPWAP message is assumed to be 1806 identical to the one received. 1808 Upon receiving a CAPWAP Data Keepalive, the WTP cancels the 1809 DataChannelDeadInterval timer and resets the DataChannelKeepAlive 1810 timer. The CAPWAP Data Keepalive is retranmitted by the WTP in the 1811 same manner as the CAPWAP control messages. If the 1812 DataChannelDeadInterval timer expires the WTP tears down the control 1813 DTLS session, as well as the data DTLS session if one existed. 1815 The CAPWAP Data Keepalive contains the following payload immediately 1816 following the CAPWAP Header (see Section 4.2) 1818 0 1 2 3 1819 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 1820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1821 | Msg Element Length | Msg Element [0..N] ... 1822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1824 Message Element Length: The Length field indicates the number of 1825 bytes following the CAPWAP Header. 1827 Message Element[0..N]: The message element(s) carry the information 1828 pertinent to each of the CAPWAP Data Keepalive message. The 1829 following message elements MUST be present in this CAPWAP message: 1831 Session ID, see Section 4.5.33 1833 4.3.2. Station Data Payloads 1835 A CAPWAP protocol data message encapsulates a forwarded wireless 1836 frame. The CAPWAP protocol defines two different modes of 1837 encapsulation; IEEE 802.3 and native wireless. IEEE 802.3 1838 encapsulation requires that the bridging function be performed in the 1839 WTP. An IEEE 802.3 encapsulated user payload frame has the following 1840 format: 1842 +------------------------------------------------------+ 1843 | IP Header | UDP Header | CAPWAP Header | 802.3 Frame | 1844 +------------------------------------------------------+ 1846 The CAPWAP protocol also defines the native wireless encapsulation 1847 mode. The actual format of the encapsulated CAPWAP data frame is 1848 subject to the rules defined under the specific wireless technology 1849 binding. As a consequence, each wireless technology binding MUST 1850 define a section entitled "Payload encapsulation", which defines the 1851 format of the wireless payload that is encapsulated within the CAPWAP 1852 Data messages. 1854 In the event that the encapsulated frame would exceed the transport 1855 layer's MTU, the sender is responsible for the fragmentation of the 1856 frame, as specified in Section 3.3. 1858 4.4. CAPWAP Control Messages 1860 The CAPWAP Control protocol provides a control channel between the 1861 WTP and the AC. Control messages are divided into the following 1862 distinct message types: 1864 Discovery: CAPWAP Discovery messages are used to identify potential 1865 ACs, their load and capabilities. 1867 Join: CAPWAP Join messages are used to for a WTP to request service 1868 from an AC, and for the AC to respond to the WTP. 1870 Control Channel Management: CAPWAP control channel management 1871 messages are used to maintain the control channel. 1873 WTP Configuration Management: The WTP Configuration messages are 1874 used by the AC to push a specific configuration to the WTP. 1875 Messages which provide retrieval of statistics from the WTP also 1876 fall in this category. 1878 Station Session Management: Station session management messages are 1879 used by the AC to push specific Station policies to the WTP. 1881 Device Management Operations: Device management operations are used 1882 to request and deliver a firmware image to the WTP. 1884 Binding Specific CAPWAP Management Frames: Messages in this category 1885 are used by the AC and the WTP to exchange protocol-specific 1886 CAPWAP management messages. These messages may or may not be used 1887 to change the link state of a station. 1889 Discovery, Join, Control Message Management, WTP Configuration 1890 Management and Station Session Management CAPWAP control messages 1891 MUST be implemented. Device Operations Management messages MAY be 1892 implemented. 1894 CAPWAP control messages sent from the WTP to the AC indicate that the 1895 WTP is operational, providing an implicit keep-alive mechanism for 1896 the WTP. The Control Channel Management Echo Request and Echo 1897 Response messages provide an explicit keep-alive mechanism when other 1898 CAPWAP control messages are not exchanged. 1900 4.4.1. Control Message Format 1902 All CAPWAP control messages are sent encapsulated within the CAPWAP 1903 header (see Section 4.2). Immediately following the CAPWAP header, 1904 is the control header, which has the following format: 1906 0 1 2 3 1907 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 1908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1909 | Message Type | 1910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1911 | Seq Num | Msg Element Length | Flags | 1912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1913 | Msg Element [0..N] ... 1914 +-+-+-+-+-+-+-+-+-+-+-+-+ 1916 4.4.1.1. Message Type 1918 The Message Type field identifies the function of the CAPWAP control 1919 message. The Message Type field is comprised of an IANA Enterprise 1920 Number and an enterprise specific message type number. The first 1921 three octets is the enterprise number in network byte order, with 1922 zero being used for CAPWAP generic message types and the IEEE 802.11 1923 IANA assigned enterprise number 13277 being used for IEEE 802.11 1924 technology specific message types. The last octet is the enterprise 1925 specific message type number, which has a range from 0 to 255. The 1926 message type field can be expressed as: 1928 Message Type = IANA Enterprise Number * 256 + enterprise specific message type number 1930 The valid values for base CAPWAP Message Types are given in the table 1931 below: 1933 CAPWAP Control Message Message Type 1934 Value 1935 Discovery Request 1 1936 Discovery Response 2 1937 Join Request 3 1938 Join Response 4 1939 Configuration Status 5 1940 Configuration Status Response 6 1941 Configuration Status Acknowledge ??? 1943 CAPWAP Control Message Message Type 1944 Value 1945 Discovery Request 1 1946 Discovery Response 2 1947 Join Request 3 1948 Join Response 4 1949 Configuration Status 5 1950 Configuration Status Response 6 1951 Configuration Status Acknowledge ??? 1953 4.4.1.2. Sequence Number 1955 The Sequence Number Field is an identifier value to match request and 1956 response packet exchanges. When a CAPWAP packet with a request 1957 message type is received, the value of the sequence number field is 1958 copied into the corresponding response packet. 1960 When a CAPWAP control message is sent, its internal sequence number 1961 counter is monotonically incremented, ensuring that no two requests 1962 pending have the same sequence number. This field will wrap back to 1963 zero. 1965 4.4.1.3. Message Element Length 1967 The Length field indicates the number of bytes following the Sequence 1968 Number field. 1970 4.4.1.4. Flags 1972 The Flags field MUST be set to zero. 1974 4.4.1.5. Message Element[0..N] 1976 The message element(s) carry the information pertinent to each of the 1977 control message types. Every control message in this specification 1978 specifies which message elements are permitted. 1980 4.4.2. Control Message Quality of Service 1982 It is recommended that CAPWAP control messages be sent by both the AC 1983 and the WTP with an appropriate Quality of Service precedence value, 1984 ensuring that congestion in the network minimizes occurrences of 1985 CAPWAP control channel disconnects. Therefore, a Quality of Service 1986 enabled CAPWAP device should use the following values: 1988 802.1P: The precedence value of 7 SHOULD be used. 1990 DSCP: The DSCP tag value of 46 SHOULD be used. 1992 4.5. CAPWAP Protocol Message Elements 1994 This section defines the CAPWAP Protocol message elements which are 1995 included in CAPWAP protocol control messages. 1997 Message elements are used to carry information needed in control 1998 messages. Every message element is identified by the Type field, 1999 whose numbering space is defined below. The total length of the 2000 message elements is indicated in the Message Element Length field. 2002 All of the message element definitions in this document use a diagram 2003 similar to the one below in order to depict its format. Note that in 2004 order to simplify this specification, these diagrams do not include 2005 the header fields (Type and Length). The header field values are 2006 defined in the Message element descriptions. 2008 Note that unless otherwise specified, a control message that lists a 2009 set of supported (or expected) message elements MUST not expect the 2010 message elements to be in any specific order. The sender may order 2011 the message elements as convenient. Furthermore, unless specifically 2012 noted, any individual message element may exist one or more times 2013 within a given control message. 2015 Additional message elements may be defined in separate IETF 2016 documents. 2018 The format of a message element uses the TLV format shown here: 2020 0 1 2 3 2021 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 2022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2023 | Type | Length | 2024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2025 | Value ... | 2026 +-+-+-+-+-+-+-+-+ 2028 Where Type (16 bit) identifies the character of the information 2029 carried in the Value field and Length (16 bits) indicates the number 2030 of bytes in the Value field. Type field values are allocated as 2031 follows: 2033 Usage Type Values 2035 CAPWAP Protocol Message Elements 1-1023 2036 IEEE 802.11 Message Elements 1024-2047 2037 IEEE 802.16 Message Elements 2048 - 3071 2038 EPCGlobal Message Elements 3072 - 4095 2039 Reserved for Future Use 4096 - 65024 2041 The table below lists the CAPWAP protocol Message Elements and their 2042 Type values. 2044 CAPWAP Message Element Type Value 2046 AC Descriptor 1 2047 AC IPv4 List 2 2048 AC IPv6 List 3 2049 AC Name 4 2050 AC Name with Index 5 2051 AC Timestamp 6 2052 Add MAC ACL Entry 7 2053 Add Station 8 2054 Add Static MAC ACL Entry 9 2055 CAPWAP Control IPV4 Address 10 2056 CAPWAP Control IPV6 Address 11 2057 CAPWAP Timers 12 2058 Data Transfer Data 13 2059 Data Transfer Mode 14 2060 Decryption Error Report 15 2061 Decryption Error Report Period 16 2062 Delete MAC ACL Entry 17 2063 Delete Station 18 2064 Delete Static MAC ACL Entry 19 2065 Discovery Type 20 2066 Duplicate IPv4 Address 21 2067 Duplicate IPv6 Address 22 2068 Idle Timeout 23 2069 Image Data 24 2070 Image Filename 25 2071 Initiate Download 26 2072 Location Data 27 2073 MTU Discovery Padding 28 2074 Radio Administrative State 29 2075 Radio Operational State 30 2076 Result Code 31 2077 Returned Message Element 46 2078 Session ID 32 2079 Statistics Timer 33 2080 Vendor Specific Payload 34 2081 WTP Board Data 35 2082 WTP Descriptor 36 2083 WTP Fallback 37 2084 WTP Frame Tunnel Mode 38 2085 WTP IPv4 IP Address 39 2086 WTP MAC Type 40 2087 WTP Name 41 2088 WTP Operational Statistics 42 2089 WTP Radio Statistics 43 2090 WTP Reboot Statistics 44 2091 WTP Static IP Address Information 45 2093 4.5.1. AC Descriptor 2095 The AC payload message element is used by the AC to communicate it's 2096 current state. The value contains the following fields. 2098 0 1 2 3 2099 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 2100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2101 | Stations | Limit | 2102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2103 | Active WTPs | Max WTPs | 2104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2105 | Security | R-MAC Field |Wireless Field | DTLS Policy | 2106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2107 | Vendor Identifier | 2108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2109 | Type=4 | Length | 2110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2111 | Value... 2112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2113 | Vendor Identifier | 2114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2115 | Type=5 | Length | 2116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2117 | Value... 2118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2120 Type: 1 for AC Descriptor 2122 Length: >= 12 2124 Stations: The number of stations currently associated with the AC 2126 Limit: The maximum number of stations supported by the AC 2128 Active WTPs: The number of WTPs currently attached to the AC 2130 Max WTPs: The maximum number of WTPs supported by the AC 2132 Security: A 8 bit bit mask specifying the authentication credential 2133 type supported by the AC. The following values are supported (see 2134 Section 2.4.4): 2136 1 - X.509 Certificate Based 2137 2 - Pre-Shared Secret 2139 R-MAC Field: The AC supports the optional Radio MAC Address field 2140 in the CAPWAP transport Header (see Section 4.2). 2142 Wireless Field: The AC supports the optional Wireless Specific 2143 Information field in the CAPWAP Header (see Section 4.2). 2145 DTLS Policy: The AC communicates its policy on the use of DTLS for 2146 the CAPWAP data channel. The AC MAY communicate more than one 2147 supported option, represented by the bit field below. The WTP 2148 MUST abide by one of the options communicated by AC. The 2149 following bit field values are supported: 2151 1 - Clear Text Data Channel Supported 2153 2 - DTLS Enabled Data Channel Supported 2155 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 2156 Network Management Private Enterprise Codes" 2158 Type: Vendor specific encoding of AC information. The following 2159 values are supported. The Hardware and Software Version values 2160 MUST be included. 2162 4 - Hardware Version: The AC's hardware version number. 2164 5 - Software Version: The AC's Firmware version number. 2166 Length: Length of vendor specific encoding of AC information. 2168 Value: Vendor specific encoding of AC information. 2170 4.5.2. AC IPv4 List 2172 The AC IPv4 List message element is used to configure a WTP with the 2173 latest list of ACs available for the WTP to join. 2175 0 1 2 3 2176 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 2177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2178 | AC IP Address[] | 2179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2181 Type: 2 for AC List 2183 Length: 4 2185 The AC IP Address: An array of 32-bit integers containing an AC's 2186 IPv4 Address. 2188 4.5.3. AC IPv6 List 2190 The AC IPv6 List message element is used to configure a WTP with the 2191 latest list of ACs available for the WTP to join. 2193 0 1 2 3 2194 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 2195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2196 | AC IP Address[] | 2197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2198 | AC IP Address[] | 2199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2200 | AC IP Address[] | 2201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2202 | AC IP Address[] | 2203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2205 Type: 3 for AC IPV6 List 2207 Length: 16 2209 The AC IP Address: An array of 32-bit integers containing an AC's 2210 IPv6 Address. 2212 4.5.4. AC Name 2214 The AC name message element contains an UTF-8 representation of the 2215 AC's identity. The value is a variable length byte string. The 2216 string is NOT zero terminated. 2218 0 2219 0 1 2 3 4 5 6 7 2220 +-+-+-+-+-+-+-+-+ 2221 | Name ... 2222 +-+-+-+-+-+-+-+-+ 2224 Type: 4 for AC Name 2226 Length: > 0 2228 Name: A variable length UTF-8 encoded string containing the AC's 2229 name 2231 4.5.5. AC Name with Index 2233 The AC Name with Index message element is sent by the AC to the WTP 2234 to configure preferred ACs. The number of instances where this 2235 message element would be present is equal to the number of ACs 2236 configured on the WTP. 2238 0 1 2239 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2241 | Index | AC Name... 2242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2244 Type: 5 for AC Name with Index 2246 Length: > 2 2248 Index: The index of the preferred server (e.g., 1=primary, 2249 2=secondary). 2251 AC Name: A variable length UTF-8 encoded string containing the AC's 2252 name. 2254 4.5.6. AC Timestamp 2256 The AC Timestamp message element is sent by the AC to synchronize the 2257 WTP's clock. 2259 0 1 2 3 2260 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 2261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2262 | Timestamp | 2263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2265 Type: 6 for AC Timestamp 2267 Length: 4 2268 Timestamp: The AC's current time, allowing all of the WTPs to be 2269 time synchronized in the format defined by Network Time Protocol 2270 (NTP) in RFC 1305 [3]. 2272 4.5.7. Add MAC ACL Entry 2274 The Add MAC Access Control List (ACL) Entry message element is used 2275 by an AC to add a MAC ACL list entry on a WTP, ensuring that the WTP 2276 no longer provides any service to the MAC addresses provided in the 2277 message. The MAC Addresses provided in this message element are not 2278 expected to be saved in non-volatile memory on the WTP. 2280 0 1 2 3 2281 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 2282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2283 | Num of Entries| MAC Address[] | 2284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2285 | MAC Address[] | 2286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2288 Type: 7 for Add MAC ACL Entry 2290 Length: >= 7 2292 Num of Entries: The number of MAC Addresses in the array. 2294 MAC Address: An array of MAC Addresses to add to the ACL. 2296 4.5.8. Add Station 2298 The Add Station message element is used by the AC to inform a WTP 2299 that it should forward traffic for a particular station. The Add 2300 Station message element will be accompanied by technology specific 2301 binding information element which may include security parameters. 2302 Consequently, the security parameters must be applied by the WTP for 2303 the particular station. 2305 Once a station's policy has been pushed to the WTP through this 2306 message element, an AC may change any policies by simply sending a 2307 modified Add Station message element. When a WTP receives an Add 2308 Station message element for an existing station, it must override any 2309 existing state it may have for the station in question. The latest 2310 Add Station message element data overrides any previously received 2311 messages. 2313 0 1 2 3 2314 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 2315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2316 | Radio ID | MAC Address | 2317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2318 | MAC Address | VLAN Name... 2319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2321 Type: 8 for Add Station 2323 Length: >= 7 2325 Radio ID: An 8-bit value representing the radio 2327 MAC Address: The station's MAC Address 2329 VLAN Name: An optional variable length UTF-8 encoded string 2330 containing the VLAN Name on which the WTP is to locally bridge 2331 user data. Note this field is only valid with WTPs configured in 2332 Local MAC mode. 2334 4.5.9. Add Static MAC ACL Entry 2336 The Add Static MAC ACL Entry message element is used by an AC to add 2337 a permanent ACL entry on a WTP, ensuring that the WTP no longer 2338 provides any service to the MAC addresses provided in the message. 2339 The MAC Addresses provided in this message element are expected to be 2340 saved in non-volative memory on the WTP. 2342 0 1 2 3 2343 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 2344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2345 | Num of Entries| MAC Address[] | 2346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2347 | MAC Address[] | 2348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2350 Type: 9 for Add Static MAC ACL Entry 2352 Length: >= 7 2354 Num of Entries: The number of MAC Addresses in the array. 2356 MAC Address: An array of MAC Addresses to add to the permanent ACL. 2358 4.5.10. CAPWAP Control IPv4 Address 2360 The CAPWAP Control IPv4 Address message element is sent by the AC to 2361 the WTP during the discovery process and is used by the AC to provide 2362 the interfaces available on the AC, and the current number of WTPs 2363 connected. In the event that multiple CAPWAP Control IPV4 Address 2364 message elements are returned, the WTP is expected to perform load 2365 balancing across the multiple interfaces. 2367 0 1 2 3 2368 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 2369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2370 | IP Address | 2371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2372 | WTP Count | 2373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2375 Type: 10 for CAPWAP Control IPv4 Address 2377 Length: 6 2379 IP Address: The IP Address of an interface. 2381 WTP Count: The number of WTPs currently connected to the interface. 2383 4.5.11. CAPWAP Control IPv6 Address 2385 The CAPWAP Control IPv6 Address message element is sent by the AC to 2386 the WTP during the discovery process and is used by the AC to provide 2387 the interfaces available on the AC, and the current number of WTPs 2388 connected. This message element is useful for the WTP to perform 2389 load balancing across multiple interfaces. 2391 0 1 2 3 2392 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 2393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2394 | IP Address | 2395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2396 | IP Address | 2397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2398 | IP Address | 2399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2400 | IP Address | 2401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2402 | WTP Count | 2403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2405 Type: 11 for CAPWAP Control IPv6 Address 2407 Length: 18 2409 IP Address: The IP Address of an interface. 2411 WTP Count: The number of WTPs currently connected to the interface. 2413 4.5.12. CAPWAP Timers 2415 The CAPWAP Timers message element is used by an AC to configure 2416 CAPWAP timers on a WTP. 2418 0 1 2419 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2421 | Discovery | Echo Request | 2422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2424 Type: 12 for CAPWAP Timers 2426 Length: 2 2428 Discovery: The number of seconds between CAPWAP Discovery packets, 2429 when the WTP is in the discovery mode. 2431 Echo Request: The number of seconds between WTP Echo Request CAPWAP 2432 messages. The default value for this message element can be found 2433 in Section 4.6.6. 2435 4.5.13. Data Transfer Data 2437 The Data Transfer Data message element is used by the WTP to provide 2438 information to the AC for debugging purposes. 2440 0 1 2 2441 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2443 | Data Type | Data Length | Data .... 2444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2446 Type: 13 for Data Transfer Data 2448 Length: >= 3 2449 Data Type: An 8-bit value the type of information being sent. The 2450 following values are supported: 2452 1 - WTP Crash Data 2454 2 - WTP Memory Dump 2456 Data Length: Length of data field. 2458 Data: Debug information. 2460 4.5.14. Data Transfer Mode 2462 The Data Transfer Mode message element is used by the WTP to indicate 2463 the type of data transfer information it is sending to the AC for 2464 debugging purposes. 2466 0 2467 0 1 2 3 4 5 6 7 2468 +-+-+-+-+-+-+-+-+ 2469 | Data Type | 2470 +-+-+-+-+-+-+-+-+ 2472 Type: 14 for Data Transfer Mode 2474 Length: 1 2476 Data Type: An 8-bit value the type of information being requested. 2477 The following values are supported: 2479 1 - WTP Crash Data 2481 2 - WTP Memory Dump 2483 4.5.15. Decryption Error Report 2485 The Decryption Error Report message element value is used by the WTP 2486 to inform the AC of decryption errors that have occurred since the 2487 last report. Note that this error reporting mechanism is not used if 2488 encryption and decryption services are provided via the AC. 2490 0 1 2 2491 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2493 | Radio ID |Num Of Entries | Station MAC Address | 2494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2495 | Station MAC Address[] | 2496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2498 Type: 15 for Decryption Error Report 2500 Length: >= 8 2502 Radio ID: The Radio Identifier, which typically refers to an 2503 interface index on the WTP 2505 Num Of Entries: An 8-bit unsigned integer indicating the number of 2506 station MAC addresses. 2508 Station MAC Address: An array of station MAC addresses that have 2509 caused decryption errors. 2511 4.5.16. Decryption Error Report Period 2513 The Decryption Error Report Period message element value is used by 2514 the AC to inform the WTP how frequently it should send decryption 2515 error report messages. 2517 0 1 2 2518 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2520 | Radio ID | Report Interval | 2521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2523 Type: 16 for Decryption Error Report Period 2525 Length: 3 2527 Radio ID: The Radio Identifier, typically refers to some interface 2528 index on the WTP 2530 Report Interval: A 16-bit unsigned integer indicating the time, in 2531 seconds. The default value for this message element can be found 2532 in Section 4.7.7. 2534 4.5.17. Delete MAC ACL Entry 2536 The Delete MAC ACL Entry message element is used by an AC to delete a 2537 MAC ACL entry on a WTP, ensuring that the WTP provides service to the 2538 MAC addresses provided in the message. 2540 0 1 2 3 2541 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 2542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2543 | Num of Entries| MAC Address[] | 2544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2545 | MAC Address[] | 2546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2548 Type: 17 for Delete MAC ACL Entry 2550 Length: >= 7 2552 Num of Entries: The number of MAC Addresses in the array. 2554 MAC Address: An array of MAC Addresses to delete from the ACL. 2556 4.5.18. Delete Station 2558 The Delete Station message element is used by the AC to inform an WTP 2559 that it should no longer provide service to a particular station. 2560 The WTP must terminate service immediately upon receiving this 2561 message element. 2563 The transmission of a Delete Station message element could occur for 2564 various reasons, including for administrative reasons, as a result of 2565 the fact that the station has roamed to another WTP, etc. 2567 The Delete Station message element MAY be sent by the WTP, through 2568 the WTP Event Request, to inform the AC that a particular station is 2569 no longer being provided service. This could occur as a result of an 2570 Idle Timeout (see section 4.4.43), due to internal resource shortages 2571 or for some other reason. 2573 0 1 2 3 2574 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 2575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2576 | Radio ID | MAC Address | 2577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2578 | MAC Address | 2579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2581 Type: 18 for Delete Station 2583 Length: 7 2585 Radio ID: An 8-bit value representing the radio 2587 MAC Address: The station's MAC Address 2589 4.5.19. Delete Static MAC ACL Entry 2591 The Delete Static MAC ACL Entry message element is used by an AC to 2592 delete a previously added static MAC ACL entry on a WTP, ensuring 2593 that the WTP provides service to the MAC addresses provided in the 2594 message. 2596 0 1 2 3 2597 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 2598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2599 | Num of Entries| MAC Address[] | 2600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2601 | MAC Address[] | 2602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2604 Type: 19 for Delete Static MAC ACL Entry 2606 Length: >= 7 2608 Num of Entries: The number of MAC Addresses in the array. 2610 MAC Address: An array of MAC Addresses to delete from the static 2611 MAC ACL entry. 2613 4.5.20. Discovery Type 2615 The Discovery Type message element is used by the WTP to indicate how 2616 it has come to know about the existence of the AC, to which it is 2617 sending the Discovery Request message. 2619 0 2620 0 1 2 3 4 5 6 7 2621 +-+-+-+-+-+-+-+-+ 2622 | Discovery Type| 2623 +-+-+-+-+-+-+-+-+ 2625 Type: 20 for Discovery Type 2627 Length: 1 2629 Discovery Type: An 8-bit value indicating how the WTP discovered 2630 the AC . The following values are supported: 2632 0 - Unknown 2634 1 - Static Configuration 2636 2 - DHCP 2638 3 - DNS 2639 4 - AC Referral 2641 4.5.21. Duplicate IPv4 Address 2643 The Duplicate IPv4 Address message element is used by a WTP to inform 2644 an AC that it has detected another IP device using the same IP 2645 address it is currently using. 2647 The WTP shall transmit this message element after it has detected a 2648 duplicate IP address. The WTP will consider the condition cleared 2649 once it has successfully received a frame from the AC. 2651 0 1 2 3 2652 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 2653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2654 | IP Address | 2655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2656 | MAC Address | 2657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2658 | MAC Address | 2659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2661 Type: 21 for Duplicate IPv4 Address 2663 Length: 10 2665 IP Address: The IP Address currently used by the WTP. 2667 MAC Address: The MAC Address of the offending device. 2669 4.5.22. Duplicate IPv6 Address 2671 The Duplicate IPv6 Address message element is used by a WTP to inform 2672 an AC that it has detected another host using the same IP address it 2673 is currently using. 2675 The WTP shall transmit this message element after it has detected a 2676 duplicate IP address. The WTP will consider the condition cleared 2677 once it has successfully received a frame from the AC. 2679 0 1 2 3 2680 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 2681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2682 | IP Address | 2683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2684 | IP Address | 2685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2686 | IP Address | 2687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2688 | IP Address | 2689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2690 | MAC Address | 2691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2692 | MAC Address | 2693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2695 Type: 22 for Duplicate IPv6 Address 2697 Length: 22 2699 IP Address: The IP Address currently used by the WTP. 2701 MAC Address: The MAC Address of the offending device. 2703 4.5.23. Idle Timeout 2705 The Idle Timeout message element is sent by the AC to the WTP to 2706 provide it with the idle timeout that it should enforce on its active 2707 station entries. The value applies for all radios on the WTP. 2709 0 1 2 3 2710 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 2711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2712 | Timeout | 2713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2715 Type: 23 for Idle Timeout 2717 Length: 4 2719 Timeout: The current idle timeout to be enforced by the WTP. The 2720 default value for this message element can be found in 2721 Section 4.7.4. 2723 4.5.24. Image Data 2725 The image data message element is present in the Image Data Request 2726 message sent by the AC and contains the following fields. 2728 0 1 2 3 2729 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 2730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2731 | Opcode | Checksum | Image Data | 2732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2733 | Image Data ... | 2734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2736 Type: 24 for Image Data 2738 Length: >= 4 (allows 0 length element if last data unit is 1024 2739 bytes) 2741 Opcode: An 8-bit value representing the transfer opcode. The 2742 following values are supported: 2744 3 - Image data is included 2746 5 - An error occurred. Transfer is aborted 2748 Checksum: A 16-bit value containing a checksum of the image data 2749 that follows. The checksum field is the 16 bit one's complement 2750 of the one's complement sum of all 16 bit words in the header. 2751 For purposes of computing the checksum, the value of the checksum 2752 field is zero. 2754 Image Data: The Image Data field contains 1024 characters, unless 2755 the payload being sent is the last one (end of file). If the last 2756 block was 1024 in length, an Image Data with a zero length payload 2757 is sent. 2759 4.5.25. Image Filename 2761 The image filename message element is sent by the WTP to the AC and 2762 is used to initiate the firmware download process. This message 2763 element contains the image filename, which the AC subsequently 2764 transfers to the WTP via the Image Data message element. The value 2765 is a variable length UTF-8 encoded string, which is NOT zero 2766 terminated. 2768 0 1 2 3 2769 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 2770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2771 | Filename ... | 2772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2774 Type: 25 for Image Filename 2776 Length: >= 1 2778 Filename: A variable length UTF-8 encoded string containing the 2779 filename to download. 2781 4.5.26. Initiate Download 2783 The Initiate Download message element is used by the AC to inform the 2784 WTP that it should initiate a firmware upgrade. This is performed by 2785 having the WTP initiate its own Image Data Request, with the Image 2786 Download message element. This message element does not contain any 2787 data. 2789 Type: 24 for Initiate Download 2791 Length: 0 2793 4.5.27. Location Data 2795 The Location Data message element is a variable length byte UTF-8 2796 encoded string containing user defined location information (e.g. 2797 "Next to Fridge"). This information is configurable by the network 2798 administrator, and allows for the WTP location to be determined 2799 through this field. The string is not zero terminated. 2801 0 2802 0 1 2 3 4 5 6 7 2803 +-+-+-+-+-+-+-+-+- 2804 | Location ... 2805 +-+-+-+-+-+-+-+-+- 2807 Type: 27 for Location Data 2809 Length: > 0 2811 Location: A non-zero terminated UTF-8 encoded string containing the 2812 WTP location. 2814 4.5.28. MTU Discovery Padding 2816 The MTU Discovery Padding message element is used as padding to 2817 perform MTU discovery, and MUST contain octets of value 0xFF, of any 2818 length 2820 0 2821 0 1 2 3 4 5 6 7 2822 +-+-+-+-+-+-+-+-+ 2823 | Padding... 2824 +-+-+-+-+-+-+-+- 2826 Type: 28 for MTU Discovery Padding 2828 Length: variable 2830 Pad: A variable length pad. 2832 4.5.29. Radio Administrative State 2834 The radio administrative state message element is used to communicate 2835 the state of a particular radio. The configuration of the Radio 2836 Administrative State is sent by the AC to change the state of the 2837 WTP, which saves the value to ensure its effect remains across WTP 2838 resets. The WTP communicates this message element during the 2839 configuration phase to ensure that AC has the WTP radio's current 2840 administrative state settings. The value contains the following 2841 fields. 2843 0 1 2 2844 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2846 | Radio ID | Admin State | Cause | 2847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2849 Type: 29 for Administrative State 2851 Length: 2 2853 Radio ID: An 8-bit value representing the radio to configure. The 2854 Radio ID field may also include the value of 0xff, which is used 2855 to identify the WTP itself. Therefore, if an AC wishes to change 2856 the administrative state of a WTP, it would include 0xff in the 2857 Radio ID field. 2859 Admin State: An 8-bit value representing the administrative state 2860 of the radio. The default value for the Admin State field is 2861 listed in section Section 4.7.1. The following values are 2862 supported: 2864 1 - Enabled 2866 2 - Disabled 2868 Cause: In the event of a radio being inoperable, the cause field 2869 would contain the reason the radio is out of service. The 2870 following values are supported: 2872 0 - Normal 2874 1 - Radio Failure 2876 2 - Software Failure 2878 3 - Radar Detection 2880 4.5.30. Radio Operational State 2882 The Radio Operational State message element is sent by the WTP to the 2883 AC to communicate a change in the operational state of a radio. For 2884 instance, if the WTP were to detect that a hardware failure existed 2885 with a radio, which caused the radio to be taken offline, the WTP 2886 would indicate this event to the AC via the message element. The AC 2887 MAY also send this message element to change the operational state of 2888 a specific radio. Note that the operational state setting is not 2889 saved on the WTP, and therefore does not remain across WTP resets. 2890 The value contains two fields, as shown. 2892 0 1 2 2893 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2895 | Radio ID | State | Cause | 2896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2898 Type: 30 for Radio Operational State 2900 Length: 3 2902 Radio ID: The Radio Identifier, typically refers to some interface 2903 index on the WTP. A value of 0xFF is invalid, as it is not 2904 possible to change the WTP's operational state. 2906 State: An 8-bit boolean value representing the state of the radio. 2907 A value of one disables the radio, while a value of two enables 2908 it. 2910 Cause: In the event of a radio being inoperable, the cause field 2911 would contain the reason the radio is out of service. The 2912 following values are supported: 2914 0 - Normal 2916 1 - Radio Failure 2918 2 - Software Failure 2920 3 - Administratively Set 2922 4.5.31. Result Code 2924 The Result Code message element value is a 32-bit integer value, 2925 indicating the result of the request operation corresponding to the 2926 sequence number in the message. 2928 0 1 2 3 2929 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 2930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2931 | Result Code | 2932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2934 Type: 31 for Result Code 2936 Length: 4 2938 Result Code: The following values are defined: 2940 0 Success 2942 1 Failure (AC List message element MUST be present) 2944 2 Success (NAT detected) 2946 3 Failure (unspecified) 2948 4 Failure (Join Failure, Resource Depletion) 2950 5 Failure (Join Failure, Unknown Source) 2951 6 Failure (Join Failure, Incorrect Data) 2953 7 Failure (Join Failure, Session ID already in use) 2955 8 Failure (Join Failure, WTP Hardware not supported) 2957 9 Failure (Unable to Reset) 2959 10 Failure (Unable to Apply Requested Configuration - Service 2960 Provided Anyhow) 2962 11 Failure (Unable to Apply Requested Configuration - Service Not 2963 Provided) 2965 12 Image Data Error (Invalid Checksum) 2967 13 Image Data Error (Invalid Data Length) 2969 14 Image Data Error (Other Error) 2971 4.5.32. Returned Message Element 2973 The Returned Message Element is sent by the WTP within the Change 2974 State Event Request in order to communicate to the AC which message 2975 elements in the Configuration Status Response it was unable to apply 2976 locally. The Returned Message Element contains a result code that is 2977 used to indicate the reason why the configuration could not be 2978 applied, and encapsulates the offending message element. 2980 0 1 2 2981 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2983 | Reason | Message Element... 2984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2986 Reason: The reason why the configuration in the offending message 2987 element could not be applied by the WTP 2989 1 - Unknown Message Element 2991 2 - Unsupported Message Element 2993 3 - Unknown Message Element Value 2995 4 - Unsupported Message Element Value 2997 Message Element: The Message Element field encapsulates the message 2998 element sent by the AC in the Configuration Status Response 2999 message that caused the error. 3001 4.5.33. Session ID 3003 The session ID message element value contains a randomly generated 3004 unsigned 32-bit integer. 3006 0 1 2 3 3007 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3009 | Session ID | 3010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3011 | Session ID | 3012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3013 | Session ID | 3014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3015 | Session ID | 3016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3018 Type: 32 for Session ID 3020 Length: 16 3022 Session ID: A 16 octet random session identifier 3024 4.5.34. Statistics Timer 3026 The statistics timer message element value is used by the AC to 3027 inform the WTP of the frequency which it expects to receive updated 3028 statistics. 3030 0 1 3031 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3033 | Statistics Timer | 3034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3036 Type: 33 for Statistics Timer 3038 Length: 2 3040 Statistics Timer: A 16-bit unsigned integer indicating the time, in 3041 seconds. The default value for this timer can be found in section 3042 Section 4.6.14. 3044 4.5.35. Vendor Specific Payload 3046 The Vendor Specific Payload is used to communicate vendor specific 3047 information between the WTP and the AC. The value contains the 3048 following format: 3050 0 1 2 3 3051 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 3052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3053 | Vendor Identifier | 3054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3055 | Element ID | Value... | 3056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3058 Type: 34 for Vendor Specific 3060 Length: >= 7 3062 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 3063 Network Management Private Enterprise Codes" [13] 3065 Element ID: A 16-bit Element Identifier which is managed by the 3066 vendor. 3068 Value: The value associated with the vendor specific element. 3070 4.5.36. WTP Board Data 3072 The WTP Board Data message element is sent by the WTP to the AC and 3073 contains information about the hardware present. 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 | Vendor Identifier | 3079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3080 | Type=0 | Length | 3081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3082 | Value... 3083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3084 | Type=1 | Length | 3085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3086 | Value... 3087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3088 | Optional additional vendor specific WTP board data TLVs 3090 Type: 35 for WTP Board Data 3092 Length: >=14 3094 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 3095 Network Management Private Enterprise Codes" 3097 Type: The following values are supported: 3099 0 - WTP Model Number: The WTP Model Number MUST be included in 3100 the WTP Board Data message element. 3102 1 - WTP Serial Number: The WTP Serial Number MUST be included in 3103 the WTP Board Data message element. 3105 2 - Board ID: A hardware identifier, which MAY be included in 3106 the WTP Board Data mesage element. 3108 3 - Board Revision A revision number of the board, which MAY be 3109 included in the WTP Board Data message element. 3111 4.5.37. WTP Descriptor 3113 The WTP descriptor message element is used by a WTP to communicate 3114 it's current hardware/firmware configuration. The value contains the 3115 following fields. 3117 0 1 2 3 3118 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 3119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3120 | Max Radios | Radios in use | Encryption Capabilities | 3121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3122 | Vendor Identifier | 3123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3124 | Type=0 | Length | 3125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3126 | Value... 3127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3128 | Vendor Identifier | 3129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3130 | Type=1 | Length | 3131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3132 | Value... 3133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3134 | Vendor Identifier | 3135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3136 | Type=2 | Length | 3137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3138 | Value... 3139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3141 Type: 36 for WTP Descriptor 3143 Length: >= 31 3145 Max Radios: An 8-bit value representing the number of radios (where 3146 each radio is identified via the Radio ID, or RID, field) 3147 supported by the WTP 3149 Radios in use: An 8-bit value representing the number of radios 3150 present in the WTP 3152 Encryption Capabilities: This 16-bit field is used by the WTP to 3153 communicate it's capabilities to the AC. A WTP that does not have 3154 any encryption capabilities sets this field to zero (0). Refer to 3155 the specific wireless binding for further specification of the 3156 Encryption Capabilities field. 3158 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 3159 Network Management Private Enterprise Codes" 3161 Type: The following values are supported. The Hardware Version, 3162 Software Version, and Boot Version values MUST be included. 3164 0 - Hardware Version: The WTP's hardware version number. 3166 1 - Software Version: The WTP's Firmware version number. 3168 2 - Boot Version: The WTP's boot loader's version number. 3170 Length: Length of vendor specific encoding of WTP information. 3172 Value: Vendor specific data of WTP information encoded in the UTF-8 3173 format. 3175 4.5.38. WTP Fallback 3177 The WTP Fallback message element is sent by the AC to the WTP to 3178 enable or disable automatic CAPWAP fallback in the event that a WTP 3179 detects its preferred AC, and is not currently connected to it. 3181 0 3182 0 1 2 3 4 5 6 7 3183 +-+-+-+-+-+-+-+-+ 3184 | Mode | 3185 +-+-+-+-+-+-+-+-+ 3187 Type: 37 for WTP Fallback 3189 Length: 1 3191 Mode: The 8-bit value indicates the status of automatic CAPWAP 3192 fallback on the WTP. When enabled, if the WTP detects that its 3193 primary AC is available, and it is not connected to it, it SHOULD 3194 automatically disconnect from its current AC and reconnect to its 3195 primary. If disabled, the WTP will only reconnect to its primary 3196 through manual intervention (e.g., through the Reset Request 3197 command). The default value for this field can be found in 3198 section Section 4.7.9. The following values are supported: 3200 1 - Enabled 3202 2 - Disabled 3204 4.5.39. WTP Frame Tunnel Mode 3206 The WTP Frame Tunnel Mode message element allows the WTP to 3207 communicate the tunneling modes of operation which it supports to the 3208 AC. A WTP that advertises support for all types allows the AC to 3209 select which type will be used, based on its local policy. 3211 0 3212 0 1 2 3 4 5 6 7 3213 +-+-+-+-+-+-+-+-+ 3214 | Tunnel Mode | 3215 +-+-+-+-+-+-+-+-+ 3217 Type: 38 for WTP Frame Tunnel Mode 3219 Length: 1 3221 Frame Tunnel Mode: The Frame Tunnel mode specifies the tunneling 3222 modes for station data which are supported by the WTP. The 3223 following values are supported: 3225 1 - Local Bridging: When Local Bridging is used, the WTP does 3226 not tunnel user traffic to the AC; all user traffic is locally 3227 bridged. This value MUST NOT be used when the WTP MAC Type is 3228 set to Split-MAC. 3230 2 - 802.3 Frame Tunnel Mode: The 802.3 Frame Tunnel Mode 3231 requires the WTP and AC to encapsulate all user payload as 3232 native IEEE 802.3 frames (see Section 4.3). All user traffic 3233 is tunneled to the AC. This value MUST NOT be used when the 3234 WTP MAC Type is set to Split-MAC. 3236 4 - Native Frame Tunnel Mode: Native Frame Tunnel mode requires 3237 the WTP and AC to encapsulate all user payloads as native 3238 wireless frames, as defined by the wireless binding (see for 3239 example Section 4.3). 3241 7 - All: The WTP is capable of supporting all frame tunnel 3242 modes. 3244 4.5.40. WTP IPv4 IP Address 3246 The WTP IPv4 address is used to perform NAT detection. 3248 0 1 2 3 3249 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 3250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3251 | WTP IPv4 IP Address | 3252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3254 Type: 39 for WTP IPv4 IP Address 3256 Length: 4 3258 WTP IPv4 IP Address: The IPv4 address from which the WTP is sending 3259 packets. This field is used for NAT detection. 3261 4.5.41. WTP MAC Type 3263 The WTP MAC-Type message element allows the WTP to communicate its 3264 mode of operation to the AC. A WTP that advertises support for both 3265 modes allows the AC to select the mode to use, based on local policy. 3267 0 3268 0 1 2 3 4 5 6 7 3269 +-+-+-+-+-+-+-+-+ 3270 | MAC Type | 3271 +-+-+-+-+-+-+-+-+ 3273 Type: 40 for WTP MAC Type 3275 Length: 1 3277 MAC Type: The MAC mode of operation supported by the WTP. The 3278 following values are supported 3280 0 - Local-MAC: Local-MAC is the default mode that MUST be 3281 supported by all WTPs. 3283 1 - Split-MAC: Split-MAC support is optional, and allows the AC 3284 to receive and process native wireless frames. 3286 2 - Both: WTP is capable of supporting both Local-MAC and Split- 3287 MAC. 3289 4.5.42. WTP Name 3291 The WTP Name message element is a variable length byte UTF-8 encoded 3292 string. The string is not zero terminated. 3294 0 3295 0 1 2 3 4 5 6 7 3296 +-+-+-+-+-+-+-+-+- 3297 | WTP Name ... 3298 +-+-+-+-+-+-+-+-+- 3300 Type: 41 for WTP Name 3302 Length: variable 3304 WTP Name: A non-zero terminated UTF-8 encoded string containing the 3305 WTP name. 3307 4.5.43. WTP Operational Statistics 3309 The WTP Operational Statistics message element is sent by the WTP to 3310 the AC to provide statistics related to the operation of the WTP. 3312 0 1 2 3 3313 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 3314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3315 | Radio ID | Tx Queue Level | Wireless Link Frames per Sec | 3316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3318 Type: 42 for WTP Operational Statistics 3320 Length: 4 3322 Radio ID: The radio ID of the radio to which the statistics apply. 3324 Wireless Transmit Queue Level: The percentage of Wireless Transmit 3325 queue utilization, calaculated as the sum of utilized transmit 3326 queue lengths divided by the sum of maximum transmit queue 3327 lengths, multiplied by 100. The Wireless Transmit Queue Level is 3328 representative of congestion conditions over wireless interfaces 3329 between the WTP and wireless terminals. 3331 Wireless Link Frames per Sec: The number of frames transmitted or 3332 received per second by the WTP over the air interface. 3334 4.5.44. WTP Radio Statistics 3336 The WTP Radio Statistics message element is sent by the WTP to the AC 3337 to communicate statistics on radio behavior and reasons why the WTP 3338 radio has been reset. 3340 0 1 2 3 3341 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 3342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3343 | Radio ID | Last Fail Type| Reset Count | 3344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3345 | SW Failure Count | HW Failure Count | 3346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3347 | Other Failure Count | Unknown Failure Count | 3348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3349 | Config Update Count | Channel Change Count | 3350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3351 | Band Change Count | Current Noise Floor | 3352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3354 Type: 43 for WTP Radio Statistics 3356 Length: 20 3358 Radio ID: The radio ID of the radio to which the statistics apply. 3360 Last Failure Type: The last WTP failure. The following values are 3361 supported: 3363 0 - Statistic Not Supported 3365 1 - Software Failure 3367 2 - Hardware Failure 3369 3 - Other Failure 3371 255 - Unknown (e.g., WTP doesn't keep track of info) 3373 Reset Count: The number of times that that the radio has been 3374 reset. 3376 SW Failure Count: The number of times that the radio has failed due 3377 to software related reasons. 3379 HW Failure Count: The number of times that the radio has failed due 3380 to hardware related reasons. 3382 Other Failure Count: The number of times that the radio has failed 3383 due to known reasons, other than software or hardware failure. 3385 Unknown Failure Count: The number of times that the radio has 3386 failed for unknown reasons. 3388 Config Update Count: The number of times that the radio 3389 configuration has been updated. 3391 Channel Change Count: The number of times that the radio channel 3392 has been changed. 3394 Band Change Count: The number of times that the radio has changed 3395 frequency bands. 3397 Current Noise Floor: A signed integer which indicates the noise 3398 floor of the radio receiver in units of dBm. 3400 4.5.45. WTP Reboot Statistics 3402 The WTP Reboot Statistics message element is sent by the WTP to the 3403 AC to communicate reasons why WTP reboots have occurred. 3405 0 1 2 3 3406 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 3407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3408 | Reboot Count | AC Initiated Count | 3409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3410 | Link Failure Count | SW Failure Count | 3411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3412 | HW Failure Count | Other Failure Count | 3413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3414 | Unknown Failure Count |Last Failure Type| 3415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3417 Type: 44 for WTP Reboot Statistics 3419 Length: 15 3421 Reboot Count: The number of reboots that have occurred due to a WTP 3422 crash. A value of 65535 implies that this information is not 3423 available on the WTP. 3425 AC Initiated Count: The number of reboots that have occurred at the 3426 request of a CAPWAP protocol message, such as a change in 3427 configuration that required a reboot or an explicit CAPWAP 3428 protocol reset request. A value of 65535 implies that this 3429 information is not available on the WTP. 3431 Link Failure Count: The number of times that a CAPWAP protocol 3432 connection with an AC has failed due to link failure. 3434 SW Failure Count: The number of times that a CAPWAP protocol 3435 connection with an AC has failed due to software related reasons. 3437 HW Failure Count: The number of times that a CAPWAP protocol 3438 connection with an AC has failed due to hardware related reasons. 3440 Other Failure Count: The number of times that a CAPWAP protocol 3441 connection with an AC has failed due to known reasons, other than 3442 AC initiated, link, SW or HW failure. 3444 Unknown Failure Count: The number of times that a CAPWAP protocol 3445 connection with an AC has failed for unknown reasons. 3447 Last Failure Type: The failure type of the most recent WTP failure. 3448 The following values are supported: 3450 0 - Not Supported 3452 1 - AC Initiated (see Section 9.3) 3454 2 - Link Failure 3456 3 - Software Failure 3458 4 - Hardware Failure 3460 5 - Other Failure 3462 255 - Unknown (e.g., WTP doesn't keep track of info) 3464 4.5.46. WTP Static IP Address Information 3466 The WTP Static IP Address Information message element is used by an 3467 AC to configure or clear a previously configured static IP address on 3468 a WTP. 3470 0 1 2 3 3471 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 3472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3473 | IP Address | 3474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3475 | Netmask | 3476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3477 | Gateway | 3478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3479 | Static | 3480 +-+-+-+-+-+-+-+-+ 3482 Type: 45 for WTP Static IP Address Information 3484 Length: 13 3486 IP Address: The IP Address to assign to the WTP. This field is 3487 only valid if the static field is set to one. 3489 Netmask: The IP Netmask. This field is only valid if the static 3490 field is set to one. 3492 Gateway: The IP address of the gateway. This field is only valid 3493 if the static field is set to one. 3495 Netmask: The IP Netmask. This field is only valid if the static 3496 field is set to one. 3498 Static: An 8-bit boolean stating whether the WTP should use a 3499 static IP address or not. A value of zero disables the static IP 3500 address, while a value of one enables it. 3502 4.6. CAPWAP Protocol Timers 3504 A WTP or AC that implements CAPWAP discovery MUST implement the 3505 following timers. 3507 4.6.1. DataChannelKeepAlive 3509 The minimum time, in seconds, between sending data channel keep-alive 3510 packets to the AC with which the WTP has joined. The default value 3511 is 30 seconds. 3513 4.6.2. DataChannelDeadInterval 3515 The minimum time, in seconds, a WTP MUST wait without having received 3516 data channel keep-alive packets before the destination for the data 3517 channel keep-alive packets may be considered dead. Must be no less 3518 than 2*DataChannelKeepAlive seconds and no greater that 240 seconds. 3520 Default: 5 3522 4.6.3. DiscoveryInterval 3524 The minimum time, in seconds, that a WTP MUST wait after receiving a 3525 Discovery Response, before initiating a DTLS handshake. 3527 Default: 5 3529 4.6.4. DTLSRehandshake 3531 The minimum time, in seconds, a WTP MUST wait for DTLS rehandshake to 3532 complete. 3534 Default: 10 3536 4.6.5. DTLSSessionDelete 3538 The minimum time, in seconds, a WTP MUST wait for DTLS session 3539 deletion. 3541 Default: 5 3543 4.6.6. EchoInterval 3545 The minimum time, in seconds, between sending echo requests to the AC 3546 with which the WTP has joined. 3548 Default: 30 3550 4.6.7. KeyLifetime 3552 The maximum time, in seconds, which a CAPWAP DTLS session key is 3553 valid. 3555 Default: 28800 3557 4.6.8. MaxDiscoveryInterval 3559 The maximum time allowed between sending discovery requests from the 3560 interface, in seconds. Must be no less than 2 seconds and no greater 3561 than 180 seconds. 3563 Default: 20 seconds. 3565 4.6.9. MaxFailedDTLSSessionRetry 3567 The maximum number of failed DTLS session establishment attempts 3568 before the CAPWAP device enters a silent period. 3570 Default: 3. 3572 4.6.10. NeighborDeadInterval 3574 The minimum time, in seconds, a WTP MUST wait without having received 3575 Echo Responses to its Echo Requests, before the destination for the 3576 Echo Request may be considered dead. Must be no less than 3577 2*EchoInterval seconds and no greater than 240 seconds. 3579 Default: 60 3581 4.6.11. ResponseTimeout 3583 The minimum time, in seconds, which the WTP or AC must respond to a 3584 CAPWAP Request message. 3586 Default: 1 3588 4.6.12. RetransmitInterval 3590 The minimum time, in seconds, which a non-acknowledged CAPWAP packet 3591 will be retransmitted. 3593 Default: 3 3595 4.6.13. SilentInterval 3597 For a WTP, this is the minimum time, in seconds, a WTP MUST wait 3598 before it MAY again send discovery requests or attempt to a establish 3599 DTLS session. For an AC, this is the minimum time, in seconds, which 3600 the AC should ignore all CAPWAP and DTLS packets received from the 3601 WTP that is in the sulking state. 3603 Default: 30 3605 4.6.14. StatisticsTimer 3607 The default Statistics Interval is 120 seconds. 3609 4.6.15. WaitDTLS 3611 The maximum time, in seconds, a WTP MUST wait without having received 3612 a DTLS Handshake message from an AC. This timer must be greater than 3613 30 seconds. 3615 Default: 60 3617 4.7. CAPWAP Protocol Variables 3619 A WTP or AC that implements CAPWAP discovery MUST allow for the 3620 following variables to be configured by system management; default 3621 values are specified, making explicit configuration unnecessary in 3622 many cases. If the default values are explicitly overriden by the 3623 AC, t he WTP MUST save the values sent by the AC. 3625 4.7.1. AdminState 3627 The default Administrative State value is enabled (1). 3629 4.7.2. DiscoveryCount 3631 The number of discoveries transmitted by a WTP to a single AC. This 3632 is a monotonically increasing counter. 3634 4.7.3. FailedDTLSSessionCount 3636 The number of failed DTLS session establishment attempts. 3638 4.7.4. IdleTimeout 3640 The default Idle Timeout is 300 seconds. 3642 4.7.5. MaxDiscoveries 3644 The maximum number of discovery requests that will be sent after a 3645 WTP boots. 3647 Default: 10 3649 4.7.6. MaxRetransmit 3651 The maximum number of retransmissions for a given CAPWAP packet 3652 before the link layer considers the peer dead. 3654 Default: 5 3656 4.7.7. ReportInterval 3658 The default Report Interval is 120 seconds.. 3660 4.7.8. RetransmitCount 3662 The number of retransmissions for a given CAPWAP packet. This is a 3663 monotonically increasing counter. 3665 4.7.9. WTPFallBack 3667 The default WTP Fallback value is enabled (1). 3669 4.8. WTP Saved Variables 3671 In addition to the values defined in Section 4.7, the following 3672 values SHOULD be saved on the WTP in non-volatile memory. CAPWAP 3673 wireless bindings may define additional values that SHOULD be stored 3674 on the WTP. 3676 4.8.1. AdminRebootCount 3678 The number of times the WTP has rebooted administratively, defined in 3679 Section 4.5.45. 3681 4.8.2. FrameEncapType 3683 For WTPs that support multiple Frame Encapsulation Types, it is 3684 useful to save the value configured by the AC. The Frame 3685 Encapsulation Type is defined in Section 4.5.39. 3687 4.8.3. LastRebootReason 3689 The reason why the WTP last rebooted, defined in Section 4.5.45. 3691 4.8.4. MacType 3693 For WTPs that support multiple MAC Types, it is usefule to save the 3694 value configured by the AC. The MAC Type is defined in 3695 Section 4.5.41. 3697 4.8.5. PreferredACs 3699 The preferred ACs, with the index, defined in Section 4.5.5. 3701 4.8.6. RebootCount 3703 The number of times the WTP has rebooted, defined in Section 4.5.45. 3705 4.8.7. Static ACL Table 3707 The static ACL table saved on the WTP, as configured by the Add 3708 Static MAC ACL Entry message element, see Section 4.5.9. 3710 4.8.8. Static IP Address 3712 The static IP Address assigned to the WTP, as configured by the 3713 message element, see Section 4.5.46. 3715 4.8.9. WTPLinkFailureCount 3717 The number of times the link to the AC has failed, see 3718 Section 4.5.45. 3720 4.8.10. WTPLocation 3722 The WTP Location, defined in Section 4.5.27. 3724 4.8.11. WTPName 3726 The WTP Name, defined in Section 4.5.42. 3728 5. CAPWAP Discovery Operations 3730 The Discovery messages are used by a WTP to determine which ACs are 3731 available to provide service, and the capabilities and load of the 3732 ACs. 3734 5.1. Discovery Request Message 3736 The Discovery Request message is used by the WTP to automatically 3737 discover potential ACs available in the network. The Discovery 3738 Request message provides ACs with the primary capabilities of the 3739 WTP. A WTP must exchange this information to ensure subsequent 3740 exchanges with the ACs are consistent with the WTP's functional 3741 characteristics. A WTP must transmit this command even if it has a 3742 statically configured AC. 3744 Discovery Request messages MUST be sent by a WTP in the Discover 3745 state after waiting for a random delay less than 3746 MaxDiscoveryInterval, after a WTP first comes up or is 3747 (re)initialized. A WTP MUST send no more than the maximum of 3748 MaxDiscoveries Discovery Request messages, waiting for a random delay 3749 less than MaxDiscoveryInterval between each successive message. 3751 This is to prevent an explosion of WTP Discovery Request messages. 3752 An example of this occurring is when many WTPs are powered on at the 3753 same time. 3755 Discovery Request messages MUST be sent by a WTP when no Echo 3756 Response messages are received for NeighborDeadInterval and the WTP 3757 returns to the Idle state. Discovery Request messages are sent after 3758 NeighborDeadInterval. They MUST be sent after waiting for a random 3759 delay less than MaxDiscoveryInterval. A WTP MAY send up to a maximum 3760 of MaxDiscoveries Discovery Request messages, waiting for a random 3761 delay less than MaxDiscoveryInterval between each successive message. 3763 If a Discovery Response message is not received after sending the 3764 maximum number of Discovery Request messages, the WTP enters the 3765 Sulking state and MUST wait for an interval equal to SilentInterval 3766 before sending further Discovery Request messages. 3768 Upon receiving a Discovery Request message, the AC will respond with 3769 a Discovery Response message sent to the address in the source 3770 address of the received discovery request message. 3772 The following message elements MUST be included in the Discovery 3773 Request message: 3775 o Discovery Type, see Section 4.5.20 3777 o WTP Board Data, see Section 4.5.36 3779 o WTP Descriptor, see Section 4.5.37 3781 o WTP Frame Tunnel Mode, see Section 4.5.39 3783 o WTP MAC Type, see Section 4.5.41 3785 5.2. Discovery Response Message 3787 The Discovery Response message provides a mechanism for an AC to 3788 advertise its services to requesting WTPs. 3790 The Discovery Response message is sent by an AC after receiving a 3791 Discovery Request message from a WTP. As with the Discovery Request, 3792 the Session ID field in the CAPWAP header MUST be set to zero. 3794 When a WTP receives a Discovery Response message, it MUST wait for an 3795 interval not less than DiscoveryInterval for receipt of additional 3796 Discovery Response messages. After the DiscoveryInterval elapses, 3797 the WTP enters the DTLS-Init state and selects one of the ACs that 3798 sent a Discovery Response message and send a DTLS Handshake to that 3799 AC. 3801 The following message elements MUST be included in the Discovery 3802 Response Message: 3804 o AC Descriptor, see Section 4.5.1 3806 o AC Name, see Section 4.5.4 3808 o CAPWAP Control IPv4 Address, see Section 4.5.10 3810 o CAPWAP Control IPv6 Address, see Section 4.5.11 3812 5.3. Primary Discovery Request Message 3814 The Primary Discovery Request message is sent by the WTP to determine 3815 whether its preferred (or primary) AC is available. 3817 A Primary Discovery Request message is sent by a WTP when it has a 3818 primary AC configured, and is connected to another AC. This 3819 generally occurs as a result of a failover, and is used by the WTP as 3820 a means to discover when its primary AC becomes available. As a 3821 consequence, this message is only sent by a WTP when it is in the Run 3822 state. 3824 The frequency of the Primary Discovery Request messages should be no 3825 more often than the sending of the Echo Request message. 3827 Upon receipt of a Discovery Request message, the AC responds with a 3828 Primary Discovery Response message sent to the address in the source 3829 address of the received Primary Discovery Request message. 3831 The following message elements MUST be included in the Primary 3832 Discovery Request message. 3834 o Discovery Type, see Section 4.5.20 3836 o WTP Board Data, see Section 4.5.36 3838 o WTP Descriptor, see Section 4.5.37 3840 o WTP Frame Tunnel Mode, see Section 4.5.39 3842 o WTP MAC Type, see Section 4.5.41 3844 o WTP Radio Information Element(s)that the AC supports; These are 3845 defined by the individual link layer CAPWAP Binding Protocols. 3847 5.4. Primary Discovery Response 3849 The Primary Discovery Response message enables an AC to advertise its 3850 availability and services to requesting WTPs that are configured to 3851 have the AC as its primary AC. 3853 The Primary Discovery Response message is sent by an AC after 3854 receiving a Primary Discovery Request message. 3856 When a WTP receives a Primary Discovery Response message, it may 3857 establish a CAPWAP protocol connection to its primary AC, based on 3858 the configuration of the WTP Fallback Status message element on the 3859 WTP. 3861 The following message elements MUST be included in the Primary 3862 Discovery Response message. 3864 o AC Descriptor, see Section 4.5.1 3866 o AC Name, see Section 4.5.4 3868 o CAPWAP Control IPv4 Address, see Section 4.5.10 3870 o CAPWAP Control IPv6 Address, see Section 4.5.11 3871 o WTP Radio Information Element(s)that the AC supports; These are 3872 defined by the individual link layer CAPWAP Binding Protocols. 3874 6. CAPWAP Join Operations 3876 The Join Request message is used by a WTP to request service from an 3877 AC after a DTLS connection is established to that AC. The Join 3878 Response message is used by the the AC to indicate that it will or 3879 will not provide service. 3881 6.1. Join Request 3883 The Join Request message is used by a WTP to inform an AC that it 3884 wishes to provide services through the AC. A Join Request message is 3885 sent by a WTP after (optionally) receiving one or more Discovery 3886 Responses, and completion of DTLS session establishment. When an AC 3887 receives a Join Request message it responds with a Join Response 3888 message. 3890 Upon completion of the DTLS handshake, which the WTP is notified via 3891 the DTLSEstablished notification, sends the Join Request message to 3892 the AC. When the AC is notified of the DTLS session establishment, 3893 it does not clear the WaitDTLS timer until it has received the Join 3894 Request message, at which time it generates a Join Response message 3895 and sends it to the WTP, indicating success or failure. 3897 If the AC rejects the Join Request, it sends a Join Response message 3898 with a failure indication and initiates an abort of the DTLS session 3899 via the DTLSAbort command. 3901 If an invalid (i.e. malformed) Join Request message is received, the 3902 message MUST be silently discarded by the AC. No response is sent to 3903 the WTP. The AC SHOULD log this event. 3905 The following message elements MUST be included in the Join Request 3906 message. 3908 o Location Data, see Section 4.5.27 3910 o WTP Board Data, see Section 4.5.36 3912 o WTP Descriptor, see Section 4.5.37 3914 o WTP IPv4 IP Address, see Section 4.5.40 3916 o WTP Name, see Section 4.5.42 3918 o Session ID, see Section 4.5.33 3920 The following message element MAY be included in the Join Request 3921 message. 3923 o WTP Reboot Statistics, see Section 4.5.45 3925 6.2. Join Response 3927 The Join Response message is sent by the AC to indicate to a WTP that 3928 it is capable and willing to provide service to it. 3930 The WTP, receiving a Join Response message, checks for success or 3931 failure. If the message indicates success, the WTP clears the 3932 WaitDTLS timer for the session and proceeds to the Configure state. 3934 If the WaitDTLS Timer expires prior to reception of the Join Response 3935 message, the WTP MUST terminate the handshake, deallocate associated 3936 session state and initiate the DTLSAbort command. 3938 If an invalid (malformed) Join Response message is received, the WTP 3939 SHOULD log an informative message detailing the error. This error 3940 MUST be treated in the same manner as AC non-responsiveness. In this 3941 way, the WaitDTLS timer will eventually expire, in which case the WTP 3942 may (if it is so configured) attempt to join with an alternative AC. 3944 The following message elements MAY be included in the Join Response 3945 message. 3947 o AC IPv4 List, see Section 4.5.2 3949 o AC IPv6 List, see Section 4.5.3 3951 o Result Code, see Section 4.5.31 3953 o WTP Radio Information Element(s)that the AC supports; These are 3954 defined by the individual link layer CAPWAP Binding Protocols. 3956 The following message element MUST be included in the Join Response 3957 message. 3959 o AC Descriptor, see Section 4.5.1 3961 7. Control Channel Management 3963 The Control Channel Management messages are used by the WTP and AC to 3964 maintain a control communication channel. CAPWAP control messages, 3965 such as the WTP Event Request message sent from the WTP to the AC 3966 indicate to the AC that the WTP is operational. When such control 3967 messages are not being sent, the Echo Request and Echo Response 3968 messages are used to maintain the control communication channel. 3970 7.1. Echo Request 3972 The Echo Request message is a keep alive mechanism for CAPWAP control 3973 messages. 3975 Echo Request messages are sent periodically by a WTP in the Run state 3976 (see Section 2.3) to determine the state of the connection between 3977 the WTP and the AC. The Echo Request message is sent by the WTP when 3978 the Heartbeat timer expires. The WTP MUST start its 3979 NeighborDeadInterval timer when the Heartbeat timer expires. 3981 The Echo Request message carries no message elements. 3983 When an AC receives an Echo Request message it responds with an Echo 3984 Response message. 3986 7.2. Echo Response 3988 The Echo Response message acknowledges the Echo Request message, and 3989 is only processed while in the Run state (see Section 2.3). 3991 An Echo Response message is sent by an AC after receiving an Echo 3992 Request message. After transmitting the Echo Response message, the 3993 AC SHOULD reset its Heartbeat timer to expire in the value configured 3994 for EchoInterval. If another Echo Request message or other control 3995 message is not received by the AC when the timer expires, the AC 3996 SHOULD consider the WTP to be no longer be reachable. 3998 The Echo Response message carries no message elements. 4000 When a WTP receives an Echo Response message it stops the 4001 NeighborDeadInterval timer, and initializes the Heartbeat timer to 4002 the EchoInterval. 4004 If the NeighborDeadInterval timer expires prior to receiving an Echo 4005 Response message, or other control message, the WTP enters the Idle 4006 state. 4008 8. WTP Configuration Management 4010 Wireless Termination Point Configuration messages are used to 4011 exchange configuration information between the AC and the WTP. 4013 8.1. Configuration Consistency 4015 The CAPWAP protocol provides flexibility in how WTP configuration is 4016 managed. A WTP has two options: 4018 1. The WTP retains no configuration and accepts the configuration 4019 provided by the AC. 4021 2. The WTP retains the configuration of parameters provided by the AC 4022 that are non-default values. 4024 If the WTP opts to save configuration locally, the CAPWAP protocol 4025 state machine defines the Configure state, which allows for 4026 configuration exchange. In the Configure state, the WTP sends its 4027 current configuration overrides to the AC via the Configuration 4028 Status message. A configuration override is a parameter that is non- 4029 default. One example is that in the CAPWAP protocol, the default 4030 antenna configuration is internal omni antenna. A WTP that either 4031 has no internal antennas, or has been explicitly configured by the AC 4032 to use external antennas, sends its antenna configuration during the 4033 configure phase, allowing the AC to become aware of the WTP's current 4034 configuration. 4036 Once the WTP has provided its configuration to the AC, the AC sends 4037 its own configuration. This allows the WTP to inherit the 4038 configuration and policies from the AC. 4040 An AC maintains a copy of each active WTP's configuration. There is 4041 no need for versioning or other means to identify configuration 4042 changes. If a WTP becomes inactive, the AC MAY delete the 4043 configuration associated with it. If a WTP fails, and connects to a 4044 new AC, it provides its overridden configuration parameters, allowing 4045 the new AC to be aware of the WTP's configuration. 4047 This model allows for resiliency in case of an AC failure, that 4048 another AC can provide service to the WTP. In this scenario, the new 4049 AC would be automatically updated with WTP configuration changes, 4050 eliminating the need for inter-AC communication or the need for all 4051 ACs to be aware of the configuration of all WTPs in the network. 4053 Once the CAPWAP protocol enters the Run state, the WTPs begin to 4054 provide service. It is quite common for administrators to require 4055 that configuration changes be made while the network is operational. 4057 Therefore, the Configuration Update Request is sent by the AC to the 4058 WTP to make these changes at run-time. 4060 8.1.1. Configuration Flexibility 4062 The CAPWAP protocol provides the flexibility to configure and manage 4063 WTPs of varying design and functional characteristics. When a WTP 4064 first discovers an AC, it provides primary functional information 4065 relating to its type of MAC and to the nature of frames to be 4066 exchanged. The AC configures the WTP appropriately. The AC also 4067 establishes corresponding internal operations to deal with the WTP 4068 according to its functionalities. 4070 8.2. Configuration Status 4072 The Configuration Status message is sent by a WTP to deliver its 4073 current configuration to its AC. 4075 Configuration Status messages are sent by a WTP while in the 4076 Configure state. 4078 The Configuration Status message carries binding specific message 4079 elements. Refer to the appropriate binding for the definition of 4080 this structure. 4082 When an AC receives a Configuration Status message it will act upon 4083 the content of the packet and respond to the WTP with a Configuration 4084 Status Response message. 4086 The Configuration Status message includes multiple Radio 4087 Administrative State message Elements. There is one such message 4088 element for the WTP, and one message element per radio in the WTP. 4090 The following message elements MUST be included in the Configuration 4091 Status message. 4093 o AC Name, see Section 4.5.4 4095 o AC Name with Index, see Section 4.5.5 4097 o Radio Administrative State, see Section 4.5.29 4099 o Statistics Timer, see Section 4.5.34 4101 o WTP Reboot Statistics, see Section 4.5.45 4103 The following message elements MAY be included in the Configuration 4104 Status message. 4106 o WTP Static IP Address Information, see Section 4.5.46 4108 8.3. Configuration Status Response 4110 The Configuration Status Response message is sent by an AC and 4111 provides a mechanism for the AC to override a WTP's requested 4112 configuration. 4114 Configuration Status Response messages are sent by an AC after 4115 receiving a Configure Request message. 4117 The Configuration Status Response message carries binding specific 4118 message elements. Refer to the appropriate binding for the 4119 definition of this structure. 4121 When a WTP receives a Configuration Status Response message it acts 4122 upon the content of the message, as appropriate. If the 4123 Configuration Status Response message includes a Radio Operational 4124 State message element that causes a change in the operational state 4125 of one of the Radio, the WTP will transmit a Change State Event to 4126 the AC, as an acknowledgement of the change in state. 4128 The following message elements MUST be included in the Configuration 4129 Status Response message. 4131 o AC IPv4 List, see Section 4.5.2 4133 o AC IPv6 List, see Section 4.5.3 4135 o CAPWAP Timers, see Section 4.5.12 4137 o Radio Operational Event, see Section 4.5.30 4139 o Decryption Error Report Period, see Section 4.5.16 4141 o Idle Timeout, see Section 4.5.23 4143 o WTP Fallback, see Section 4.5.38 4145 The following message element MAY be included in the Configuration 4146 Status Response message. 4148 o WTP Static IP Address Information, see Section 4.5.46 4150 8.4. Configuration Status Acknowledge 4152 The Configuration Status Acknowledge message is sent by a WTP and 4153 provides a mechanism for the WTP to acknowledge or report an error 4154 condition to the AC for a requested configuration. 4156 Configuration Status Acknowledge messages are sent by a WTP after 4157 receiving a Configure Response message. 4159 The Configuration Status Acknowledge message carries a status code 4160 and may contain any specific binding message elements that could not 4161 be set as requested by the AC. If the WTP successfully applies the 4162 configuration, it shall set the return code value to "Success". If 4163 the WTP is unable to apply any part of the configuration, it shall 4164 set the return code value to "Unable to Apply Requested 4165 Configuration" Refer to the appropriate binding for the definition of 4166 this structure. 4168 When a AC receives a Configuration Status Acknowledge message it acts 4169 upon the content of the message, as appropriate. If the 4170 Configuration Status Response message includes a Radio Operational 4171 State message element that causes a change in the operational state 4172 of one of the Radio, the WTP will transmit a Change State Event to 4173 the AC, as an acknowledgement of the change in state. 4175 The following message elements MUST be included in the Configuration 4176 Status Acknowledge message. 4178 o Result Code, see Section 4.5.31 4180 8.5. Configuration Update Request 4182 Configuration Update Request messages are sent by the AC to provision 4183 the WTP while in the Run state. This is used to modify the 4184 configuration of the WTP while it is operational. 4186 When an AC receives a Configuration Update Request message it will 4187 respond with a Configuration Update Response message, with the 4188 appropriate Result Code. 4190 One or more of the following message elements MAY be included in the 4191 Configuration Update message. 4193 o AC Name with Index, see Section 4.5.5 4195 o AC Timestamp, see Section 4.5.6 4196 o Add MAC ACL Entry, see Section 4.5.7 4198 o Add Static MAC ACL Entry, see Section 4.5.9 4200 o CAPWAP Timers, see Section 4.5.12 4202 o Decryption Error Report Period, see Section 4.5.16 4204 o Delete MAC ACL Entry, see Section 4.5.17 4206 o Delete Static MAC ACL Entry, see Section 4.5.19 4208 o Idle Timeout, see Section 4.5.23 4210 o Location Data, see Section 4.5.27 4212 o Radio Operational State, see Section 4.5.30 4214 o Statistics Timer, see Section 4.5.34 4216 o WTP Fallback, see Section 4.5.38 4218 o WTP Name, see Section 4.5.42 4220 o WTP Static IP Address Information, see Section 4.5.46 4222 8.6. Configuration Update Response 4224 The Configuration Update Response message is the acknowledgement 4225 message for the Configuration Update Request message. 4227 The Configuration Update Response message is sent by a WTP after 4228 receiving a Configuration Update Request message. 4230 When an AC receives a Configuration Update Response message the 4231 result code indicates if the WTP successfully accepted the 4232 configuration. 4234 The following message element MUST be present in the Configuration 4235 Update message. 4237 Result Code, see Section 4.5.31 4239 8.7. Change State Event Request 4241 The Change State Event Request message is used by the WTP for two 4242 main purposes: 4244 o When sent by the WTP following the reception Configuration Status 4245 Response from the AC, the WTP uses the Change State Event to 4246 provide an update on the WTP radio's operational state as well as 4247 to confirm that the configuration provided by the AC was 4248 successfully applied. 4250 o When sent during the Run state, the WTP uses the Change State 4251 Event to notify the AC of an unexpected change in the WTP's radio 4252 operational state. 4254 When an AC receives a Change State Event Request message it will 4255 respond with a Change State Event Response message and make any 4256 necessary modifications to internal WTP data structures. The AC MAY 4257 decide not to provide service to the WTP if it receives an error, 4258 based on local policy, which is done by transitioning to the CAPWAP 4259 Reset state. 4261 The Change State Event Request is sent by a WTP to acknowledge or 4262 report an error condition to the AC for a requested configuration 4263 through the Configuration Status Response. The Change State Event 4264 Request includes the Result Code message element, which indicates 4265 whether the configuration was successfully applied. If the WTP is 4266 unable to apply a specfic configuration request, it indicates the 4267 failure by including one or more Returned Message Element message 4268 elements (see Section 4.5.32). 4270 The following message elements MUST be present in the Change State 4271 Event Request message. 4273 o Radio Operational State, see Section 4.5.30 4275 o Result Code, see Section 4.5.31 4277 One or more of the following message elements MAY be present in the 4278 Change State Event Request message. 4280 o Returned Message Element, see Section 4.5.32 4282 8.8. Change State Event Response 4284 The Change State Event Response message acknowledges the Change State 4285 Event Request message. 4287 A Change State Event Response message is sent by an AC in response to 4288 a Change State Event Request message. 4290 The Change State Event Response message carries no message elements. 4291 Its purpose is to acknowledge the receipt of the Change State Event 4292 Request message. 4294 The WTP does not need to perform any special processing of the Change 4295 State Event Response message. 4297 8.9. Clear Configuration Request 4299 The Clear Configuration Request message is used to reset a WTP's 4300 configuration. 4302 The Clear Configuration Request message is sent by an AC to request 4303 that a WTP reset its configuration to the manufacturing default 4304 configuration. The Clear Config Request message is sent while in the 4305 Run CAPWAP state. 4307 The Clear Configuration Request message carries no message elements. 4309 When a WTP receives a Clear Configuration Request message it resets 4310 its configuration to the manufacturing default configuration. 4312 8.10. Clear Configuration Response 4314 The Clear Configuration Response message is sent by the WTP after 4315 receiving a Clear Configuration Request message and resetting its 4316 configuration parameters back to the manufacturing default values. 4318 The Clear Configuration Request message carries the message elements. 4320 o Result Code, see Section 4.5.31 4322 9. Device Management Operations 4324 This section defines CAPWAP operations responsible for debugging, 4325 gathering statistics, logging, and firmware management. 4327 9.1. Image Data Request 4329 The Image Data Request message is used to update firmware on the WTP. 4330 This message and its companion response message are used by the AC to 4331 ensure that the image being run on each WTP is appropriate. 4333 Image Data Request messages are exchanged between the WTP and the AC 4334 to download a new firmware image to the WTP. When a WTP or AC 4335 receives an Image Data Request message it will respond with an Image 4336 Data Response message. The message elements contained within the 4337 Image Data Request message are required to determine the intent of 4338 the request. 4340 The decision that new firmware is to be downloaded to the WTP can 4341 occur in one of two methods: 4343 When the WTP joins the AC, and each exchange their software 4344 revision, the WTP may opt to initiate a firmware download by 4345 sending an Image Data Request, which contains an Image Filename 4346 message element. 4348 Once the WTP is in the Configure state, it is possible for the AC 4349 to cause the WTP to initiate a firmware download by sending an 4350 Image Data Request message, with the Initiate Download and and 4351 Image Filename message elements. The WTP then transmits the Image 4352 Data Request message,which includes the Image Filename message 4353 element to start the download process. 4355 Regardless of how the download was initiated, once the AC receives an 4356 Image Data Request with the Image Filename message element, it begins 4357 the transfer process by transmitting its own request with the Image 4358 Data message element. This continues until the firmware image has 4359 been transfered. 4361 The following message elements MAY be included in the Image Data 4362 Request message. 4364 o Image Data, see Section 4.5.24 4366 o Image Filename, see Section 4.5.25 4368 o Initiate Download, see Section 4.5.26 4370 9.2. Image Data Response 4372 The Image Data Response message acknowledges the Image Data Request 4373 message. 4375 An Image Data Response message is sent in response to a received 4376 Image Data Request message. Its purpose is to acknowledge the 4377 receipt of the Image Data Request message. The Result Code is 4378 included to indicate whether a previously sent Image Data Request 4379 message was invalid. 4381 The following message elements MUST be included in the Image Data 4382 Response message. 4384 o Result Code, see Section 4.5.31 4386 Upon receiving an error, the WTP MAY decide to retransmit a previous 4387 Image Data Reqest, or abandon the firmware download to the WTP by 4388 transitioning to the Reset state machine. 4390 9.3. Reset Request 4392 The Reset Request message is used to cause a WTP to reboot. 4394 A Reset Request message is sent by an AC to cause a WTP to 4395 reinitialize its operation. 4397 The Reset Request carries no message elements. 4399 When a WTP receives a Reset Request it will respond with a Reset 4400 Response indicating success and then reinitialize itself. In the 4401 event the WTP is unable to reset, including a hardware reset, it can 4402 respond with a Reset Response whose Result-Code message element 4403 indicates failure. 4405 9.4. Reset Response 4407 The Reset Response message acknowledges the Reset Request message. 4409 A Reset Response message is sent by the WTP after receiving a Reset 4410 Request message. 4412 The following message elements MAY be included in the Image Data 4413 Request Message. 4415 o Result Code, see Section 4.5.31 4417 When an AC receives a successful Reset Response message, it is 4418 notified that the WTP will reinitialize its operation. An AC that 4419 receives a Reset Response indicating failure may opt to no longer 4420 provide service to the WTP in question. 4422 9.5. WTP Event Request 4424 WTP Event Request message is used by a WTP to send information to its 4425 AC. The WTP Event Request message may be sent periodically, or sent 4426 in response to an asynchronous event on the WTP. For example, a WTP 4427 MAY collect statistics and use the WTP Event Request message to 4428 transmit the statistics to the AC. 4430 When an AC receives a WTP Event Request message it will respond with 4431 a WTP Event Response message. 4433 The presence of the Delete Station message element is used by the WTP 4434 to inform the AC that it is no longer providing service to the 4435 station. This could be the result of an Idle Timeout (see 4436 Section 4.5.23), due to to resource shortages, or some other reason. 4438 The WTP Event Request message MUST contain one of the message 4439 elements listed below, or a message element that is defined for a 4440 specific wireless technology. 4442 o Decryption Error Report, see Section 4.5.15 4444 o Duplicate IPv4 Address, see Section 4.5.21 4446 o Duplicate IPv6 Address, see Section 4.5.22 4448 o WTP Operational Statistics, see Section 4.5.43 4450 o WTP Radio Statistics, see Section 4.5.44 4452 o WTP Reboot Statistics, see Section 4.5.45 4454 o Delete Station, see Section 4.5.18 4456 9.6. WTP Event Response 4458 The WTP Event Response message acknowledges receipt of the WTP Event 4459 Request message. 4461 A WTP Event Response message issent by an AC after receiving a WTP 4462 Event Request message. 4464 The WTP Event Response message carries no message elements. 4466 9.7. Data Transfer Request 4468 The Data Transfer Request message is used to deliver debug 4469 information from the WTP to the AC. 4471 Data Transfer Request messages are sent by the WTP to the AC when the 4472 WTP determines that it has important information to send to the AC. 4473 For instance, if the WTP detects that its previous reboot was caused 4474 by a system crash, it can send the crash file to the AC. The remote 4475 debugger function in the WTP also uses the Data Transfer Request 4476 message to send console output to the AC for debugging purposes. 4478 When the AC receives a Data Transfer Request message it responds to 4479 the WTP ith a Data Transfer Response message. The AC MAY log the 4480 information received. 4482 The Data Transfer Request message MUST contain one of the message 4483 elements listed below. 4485 o Data Transfer Data, see Section 4.5.13 4487 o Data Transfer Mode, see Section 4.5.14 4489 9.8. Data Transfer Response 4491 The Data Transfer Response message acknowledges the Data Transfer 4492 Request message. 4494 A Data Transfer Response message is sent in response to a received 4495 Data Transfer Request message. Its purpose is to acknowledge receipt 4496 of the Data Transfer Request message. 4498 The Data Transfer Response message carries no message elements. 4500 Upon receipt of a Data Transfer Response message, the WTP transmits 4501 more information, if more information is available. 4503 10. Station Session Management 4505 Messages in this section are used by the AC to create, modify or 4506 delete station session state on the WTPs. 4508 10.1. Station Configuration Request 4510 The Station Configuration Request message is used to create, modify 4511 or delete station session state on a WTP. The message is sent by the 4512 AC to the WTP, and may contain one or more message elements. The 4513 message elements for this CAPWAP control message include information 4514 that is generally highly technology specific. Refer to the 4515 appropriate binding section or document for the definitions of the 4516 messages elements that may be used in this control message. 4518 The following CAPWAP Control message elements MAY be included in the 4519 Station Configuration Request message. 4521 o Add Station, see Section 4.5.8 4523 o Delete Station, see Section 4.5.18 4525 10.2. Station Configuration Response 4527 The Station Configuration Response message is used to acknowledge a 4528 previously received Station Configuration Request message. The 4529 following message element MUST be present in the Station 4530 Configuration Response message. 4532 o Result Code, see Section 4.5.31 4534 The Result Code message element indicates that the requested 4535 configuration was successfully applied, or that an error related to 4536 processing of the Station Configuration Request message occurred on 4537 the WTP. 4539 11. NAT Considerations 4541 There are two specific situations in which a NAT system may be used 4542 in conjunction with a CAPWAP-enabled system. The first consists of a 4543 configuration where the WTP is behind a NAT system. Given that all 4544 communication is initiated by the WTP, and all communication is 4545 performed over IP using two UDP ports, the protocol easily traverses 4546 NAT systems in this configuration. 4548 It is, however, possible for two or more WTPs to reside behind the 4549 same NAT system. In this instance, the AC would receive multiple 4550 connection requests from the same IP address, and could end up 4551 thinking all of the connection requests come from the same WTP. It 4552 is important that the AC not disconnect another WTP's session as a 4553 result of this situation occuring. Therefore, the AC should consider 4554 the WTP's identity, which is communicated within the DTLS exchange 4555 used to secure the CAPWAP control channel. The CAPWAP header 4556 includes a Session Identifier field, which is used to match the 4557 control and data plane. This allows the AC to match the control and 4558 data plane flows from multiple WTPs behind the same NAT system 4559 (therefore all sharing the same IP address). 4561 The second configuration is one where the AC sits behind a NAT. Two 4562 issues exist in this situation. First, an AC communicates its 4563 interfaces, and associated WTP load on these interfaces, through the 4564 WTP Manager Control IP Address. This message element is currently 4565 mandatory, and if NAT compliance became an issue, it would be 4566 possible to either: 4568 1. Make the WTP Manager Control IP Address optional, allowing the WTP 4569 to simply use the known IP Address. However, note that this 4570 approach would eliminate the ability to perform load balancing of 4571 WTP across ACs, and therefore is not the recommended approach. 4573 2. Allow an AC to be able to configure a NAT'ed address for every 4574 associated AC that would generally be communicated in the WTP 4575 Manager Control IP Address message element. 4577 3. Require that if a WTP determines that the AC List message element 4578 consists of a set of IP Addresses that are different from the AC's 4579 IP Address it is currently communicating with, then assume that 4580 NAT is being enforced, and require that the WTP communicate with 4581 the original AC's IP Address (and ignore the WTP Manager Control 4582 IP Address message element(s)). 4584 Another issue related to having an AC behind a NAT system is CAPWAP's 4585 support for the CAPWAP Objective to allow the control and data plane 4586 to be separated. In order to support this requirement, the CAPWAP 4587 protocol defines the WTP Manager Data IP Address message element, 4588 which allows the AC to inform the WTP that the CAPWAP data frames are 4589 to be forwarded to a separate IP Address. This feature MUST be 4590 disabled when an AC is behind a NAT. However, there is no easy way 4591 to provide some default mechanism that satisfies both the data/ 4592 control separation and NAT objectives, as they directly conflict with 4593 each other. As a consequence, user intervention will be required to 4594 support such networks. 4596 The CAPWAP protocol allows for all of the ACs identities supporting a 4597 group of WTPs to be communicated through the AC List message element. 4598 This feature must be disabled when the AC is behind a NAT and the IP 4599 Address that is embedded would be invalid. 4601 The CAPWAP protocol has a feature that allows an AC to configure a 4602 static IP address on a WTP. The WTP Static IP Address Information 4603 message element provides such a function, however this feature SHOULD 4604 NOT be used in NAT'ed environments, unless the administrator is 4605 familiar with the internal IP addressing scheme within the WTP's 4606 private network, and does not rely on the public address seen by the 4607 AC. 4609 When a WTP detects the duplicate address condition, it generates a 4610 message to the AC, which includes the Duplicate IP Address message 4611 element. The IP Address embedded within this message element is 4612 different from the public IP address seen by the AC. 4614 12. Security Considerations 4616 This section describes security considerations for the CAPWAP 4617 protocol. It also provides security recommendations for protocols 4618 used in conjunction with CAPWAP. 4620 12.1. CAPWAP Security 4622 As it is currently specified, the CAPWAP protocol sits between the 4623 security mechanisms specified by the wireless link layer protocol 4624 (e.g.IEEE 802.11i) and AAA. One goal of CAPWAP is to bootstrap trust 4625 between the STA and WTP using a series of preestablished trust 4626 relationships: 4628 STA WTP AC AAA 4629 ============================================== 4631 DTLS Cred AAA Cred 4632 <------------><-------------> 4634 EAP Credential 4635 <------------------------------------------> 4637 wireless link layer 4638 (e.g.802.11 PTK) 4639 <--------------> or 4640 <---------------------------> 4641 (derived) 4643 Within CAPWAP, DTLS is used to secure the link between the WTP and 4644 AC. In addition to securing control messages, it's also a link in 4645 this chain of trust for establishing link layer keys. Consequently, 4646 much rests on the security of DTLS. 4648 In some CAPWAP deployment scenarios, there are two channels between 4649 the WTP and AC: the control channel, carrying CAPWAP control 4650 messages, and the data channel, over which client data packets are 4651 tunneled between the AC and WTP. Typically, the control channel is 4652 secured by DTLS, while the data channel is not. 4654 The use of parallel protected and unprotected channels deserves 4655 special consideration, but does not create a threat. There are two 4656 potential concerns: attempting to convert protected data into un- 4657 protected data and attempting to convert un-protected data into 4658 protected data. These concerns are addressed below. 4660 12.1.1. Converting Protected Data into Unprotected Data 4662 Since CAPWAP does not support authentication-only ciphers (i.e. all 4663 supported ciphersuites include encryption and authentication), it is 4664 not possible to convert protected data into unprotected data. Since 4665 encrypted data is (ideally) indistinguishable from random data, the 4666 probability of an encrypted packet passing for a well-formed packet 4667 is effectively zero. 4669 12.1.2. Converting Unprotected Data into Protected Data (Insertion) 4671 The use of message authentication makes it impossible for the 4672 attacker to forge protected records. This makes conversion of 4673 unprotected records to protected records impossible. 4675 12.1.3. Deletion of Protected Records 4677 An attacker could remove protected records from the stream, though 4678 not undetectably so, due the built-in reliability of the underlying 4679 CAPWAP protocol. In the worst case, the attacker would remove the 4680 same record repeatedly, resulting in a CAPWAP session timeout and 4681 restart. This is effectively a DoS attack, and could be accomplished 4682 by a man in the middle regardless of the CAPWAP protocol security 4683 mechanisms chosen. 4685 12.1.4. Insertion of Unprotected Records 4687 An attacker could inject packets into the unprotected channel, but 4688 this may become evident if sequence number desynchronization occurs 4689 as a result. Only if the attacker is a MiM can packets be inserted 4690 undetectably. This is a consequence of that channel's lack of 4691 protection, and not a new threat resulting from the CAPWAP security 4692 mechanism. 4694 12.2. Use of Preshared Keys in CAPWAP 4696 While use of preshared keys may provide deployment and provisioning 4697 advantages not found in public key based deployments, it also 4698 introduces a number of operational and security concerns. In 4699 particular, because the keys must typically be entered manually, it 4700 is common for people to base them on memorable words or phrases. 4701 These are referred to as "low entropy passwords/passphrases". 4703 Use of low-entropy preshared keys, coupled with the fact that the 4704 keys are often not frequently updated, tends to significantly 4705 increase exposure. For these reasons, we make the following 4706 recommendations: 4708 o When DTLS is used with a preshared-key (PSK) ciphersuite, each WTP 4709 SHOULD have a unique PSK. Since WTPs will likely be widely 4710 deployed, their physical security is not guaranteed. If PSKs are 4711 not unique for each WTP, key reuse would allow the compromise of 4712 one WTP to result in the compromise of others 4714 o Generating PSKs from low entropy passwords is NOT RECOMMENDED. 4716 o It is RECOMMENDED that implementations that allow the 4717 administrator to manually configure the PSK also provide a 4718 capability for generation of new random PSKs, taking RFC 1750 [2] 4719 into account. 4721 o Preshared keys SHOULD be periodically updated. Implementations 4722 may facilitate this by providing an administrative interface for 4723 automatic key generation and periodic update, or it may be 4724 accomplished manually instead. 4726 12.3. Use of Certificates in CAPWAP 4728 For public-key-based DTLS deployments, each device SHOULD have unique 4729 credentials, with an extended key usage authorizing them to act as 4730 either a WTP or AC. If devices do not have unique credentials, it is 4731 possible that by compromising one, any other one using the same 4732 credential may also be considered to be compromised. 4734 Certificate validation involves checking a large variety of things. 4735 Since the necessary things to validate are often environment- 4736 specific, many are beyond the scope of this document. In this 4737 section, we provide some basic guidance on certificate validation. 4739 Each device is responsible for authenticating and authorizing devices 4740 with which they communicate. Authentication entails validation of 4741 the chain of trust leading to the peer certificate, followed by the 4742 the peer certificate itself. At a minimum, devices SHOULD use SSH- 4743 style certificate caching to guarantee consistency. If devices have 4744 access to a certificate authority, they SHOULD properly validate the 4745 trust chain. Implementations SHOULD also provide a secure method for 4746 verifying that the credential in question has not been revoked. 4748 Note that if the WTP relies on the AC for network connectivity (e.g. 4749 the AC is a layer 2 switch to which the WTP is directly connected), 4750 there is a chicken and egg problem, in that the WTP may not be able 4751 to contact an OCSP server or otherwise obtain an up to date CRL if a 4752 compromised AC doesn't explicitly permit this. This cannot be 4753 avoided, except through effective physical security and monitoring 4754 measures at the AC. 4756 Proper validation of certificates typically requires checking to 4757 ensure the certificate has not yet expired. If devices have a real- 4758 time clock, they SHOULD verify the certificate validity dates. If no 4759 real-time clock is available, the device SHOULD make a best-effort 4760 attempt to validate the certificate validity dates through other 4761 means. Failure to check a certificate's temporal validity can make a 4762 device vulnerable to man-in-the-middle attacks launched using 4763 compromised, expired certificates, and therefore devices should make 4764 every effort to perform this validation. 4766 Another important part of certificate authentication is binding a 4767 certificate to a particular device. There are many ways to 4768 accomplish this. Specification of the certificate common name (CN) 4769 as the WTP or AC MAC address formatted as ASCII HEX, for example, 01: 4770 23:45:67:89:ab is REQUIRED for use with the CAPWAP protocol. During 4771 authentication, devices SHOULD ensure that the MAC address matches 4772 the MAC address specified in the CAPWAP header. If this mechanism is 4773 used, the ACs SHOULD maintain list of all authorized WTP MAC 4774 addresses and the WTP SHOULD save the AC credential or credential 4775 identifier. 4777 12.4. AAA Security 4779 The AAA protocol is used to distribute EAP keys to the ACs, and 4780 consequently its security is important to the overall system 4781 security. When used with TLS or IPsec, security guidelines specified 4782 in RFC 3539 [5] SHOULD be followed. 4784 In general, the link between the AC and AAA server SHOULD be secured 4785 using a strong ciphersuite keyed with mutually authenticated session 4786 keys. Implementations SHOULD NOT rely solely on Basic RADIUS shared 4787 secret authentication as it is often vulnerable to dictionary 4788 attacks, but rather SHOULD use stronger underlying security 4789 mechanisms. 4791 13. IANA Considerations 4793 A separate UDP port for data channel communications is (currently) 4794 the selected demultiplexing mechanism, and a port must be assigned 4795 for this purpose. 4797 IANA needs to assign a DHCP code point, currently identified as TBD 4798 in the section Section 3.2. DHCP options are defined in RFC 1533 4799 [10], and are listed by IANA at 4800 http://www.iana.org/assignments/bootp-dhcp-parameters. 4802 14. References 4804 14.1. Normative References 4806 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 4807 Levels", BCP 14, RFC 2119, March 1997. 4809 [2] Eastlake, D., Crocker, S., and J. Schiller, "Randomness 4810 Recommendations for Security", RFC 1750, December 1994. 4812 [3] Mills, D., "Network Time Protocol (Version 3) Specification, 4813 Implementation", RFC 1305, March 1992. 4815 [4] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 4816 Public Key Infrastructure Certificate and Certificate 4817 Revocation List (CRL) Profile", RFC 3280, April 2002. 4819 [5] Aboba, B. and J. Wood, "Authentication, Authorization and 4820 Accounting (AAA) Transport Profile", RFC 3539, June 2003. 4822 [6] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for 4823 Transport Layer Security (TLS)", RFC 4279, December 2005. 4825 [7] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 4826 Protocol Version 1.1", RFC 4346, April 2006. 4828 [8] Manner, J. and M. Kojo, "Mobility Related Terminology", 4829 RFC 3753, June 2004. 4831 [9] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 4832 Security", RFC 4347, April 2006. 4834 [10] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 4835 Extensions", RFC 1533, October 1993. 4837 [11] Clancy, C., "Security Review of the Light Weight Access Point 4838 Protocol", May 2005, 4839 . 4841 14.2. Informational References 4843 [12] "draft-ietf-capwap-protocol-binding-specification-ieee802dot11- 4844 00". 4846 [13] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On- 4847 line Database", RFC 3232, January 2002. 4849 [14] Modadugu et al, N., "The Design and Implementation of Datagram 4850 TLS", Feb 2004. 4852 Authors' Addresses 4854 Pat R. Calhoun 4855 Cisco Systems, Inc. 4856 170 West Tasman Drive 4857 San Jose, CA 95134 4859 Phone: +1 408-853-5269 4860 Email: pcalhoun@cisco.com 4862 Michael P. Montemurro 4863 Research In Motion 4864 5090 Commerce Blvd 4865 Mississauga, ON L4W 5M4 4866 Canada 4868 Phone: +1 905-629-4746 x4999 4869 Email: mmontemurro@rim.com 4871 Dorothy Stanley 4872 Aruba Networks 4873 1322 Crossman Ave 4874 Sunnyvale, CA 94089 4876 Phone: +1 630-363-1389 4877 Email: dstanley@arubanetworks.com 4879 Full Copyright Statement 4881 Copyright (C) The IETF Trust (2007). 4883 This document is subject to the rights, licenses and restrictions 4884 contained in BCP 78, and except as set forth therein, the authors 4885 retain all their rights. 4887 This document and the information contained herein are provided on an 4888 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 4889 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 4890 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 4891 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 4892 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4893 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4895 Intellectual Property 4897 The IETF takes no position regarding the validity or scope of any 4898 Intellectual Property Rights or other rights that might be claimed to 4899 pertain to the implementation or use of the technology described in 4900 this document or the extent to which any license under such rights 4901 might or might not be available; nor does it represent that it has 4902 made any independent effort to identify any such rights. Information 4903 on the procedures with respect to rights in RFC documents can be 4904 found in BCP 78 and BCP 79. 4906 Copies of IPR disclosures made to the IETF Secretariat and any 4907 assurances of licenses to be made available, or the result of an 4908 attempt made to obtain a general license or permission for the use of 4909 such proprietary rights by implementers or users of this 4910 specification can be obtained from the IETF on-line IPR repository at 4911 http://www.ietf.org/ipr. 4913 The IETF invites any interested party to bring to its attention any 4914 copyrights, patents or patent applications, or other proprietary 4915 rights that may cover technology that may be required to implement 4916 this standard. Please address the information to the IETF at 4917 ietf-ipr@ietf.org. 4919 Acknowledgment 4921 Funding for the RFC Editor function is provided by the IETF 4922 Administrative Support Activity (IASA).