idnits 2.17.1 draft-ietf-capwap-protocol-specification-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 4673. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4684. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4691. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4697. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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 ([11]), 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 RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == 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 (October 13, 2006) is 6404 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'ChangeCipherSpec' on line 1169 -- Looks like a reference, but probably isn't: 'DTLS' on line 1138 == Unused Reference: '10' is defined on line 4618, but no explicit reference was found in the text ** 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) Summary: 9 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 Intended status: Informational M. Montemurro, Editor 5 Expires: April 16, 2007 Research In Motion 6 D. Stanley, Editor 7 Aruba Networks 8 October 13, 2006 10 CAPWAP Protocol Specification 11 draft-ietf-capwap-protocol-specification-03 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 April 16, 2007. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 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 [11]. 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 to DTLS Commands . . . . . . . . . . . . . . . 21 68 2.3.3. DTLS to CAPWAP Notifications . . . . . . . . . . . . 21 69 2.3.4. DTLS State Transitions . . . . . . . . . . . . . . . 22 70 2.4. Use of DTLS in the CAPWAP Protocol . . . . . . . . . . . 25 71 2.4.1. DTLS Handshake Processing . . . . . . . . . . . . . . 26 72 2.4.2. DTLS Error Handling . . . . . . . . . . . . . . . . . 27 73 2.4.3. DTLS Rehandshake Behavior . . . . . . . . . . . . . . 28 74 2.4.4. DTLS EndPoint Authentication . . . . . . . . . . . . 31 75 3. CAPWAP Transport . . . . . . . . . . . . . . . . . . . . . . 34 76 3.1. UDP Transport . . . . . . . . . . . . . . . . . . . . . . 34 77 3.2. AC Discovery . . . . . . . . . . . . . . . . . . . . . . 34 78 3.3. Fragmentation/Reassembly . . . . . . . . . . . . . . . . 35 79 4. CAPWAP Packet Formats . . . . . . . . . . . . . . . . . . . . 36 80 4.1. CAPWAP Header . . . . . . . . . . . . . . . . . . . . . . 37 81 4.2. CAPWAP Data Messages . . . . . . . . . . . . . . . . . . 40 82 4.3. CAPWAP Control Messages . . . . . . . . . . . . . . . . . 41 83 4.3.1. Control Message Format . . . . . . . . . . . . . . . 41 84 4.3.2. Control Message Quality of Service . . . . . . . . . 44 85 4.4. CAPWAP Protocol Message Elements . . . . . . . . . . . . 44 86 4.4.1. AC Descriptor . . . . . . . . . . . . . . . . . . . . 47 87 4.4.2. AC IPv4 List . . . . . . . . . . . . . . . . . . . . 48 88 4.4.3. AC IPv6 List . . . . . . . . . . . . . . . . . . . . 49 89 4.4.4. AC Name . . . . . . . . . . . . . . . . . . . . . . . 49 90 4.4.5. AC Name with Index . . . . . . . . . . . . . . . . . 50 91 4.4.6. AC Timestamp . . . . . . . . . . . . . . . . . . . . 50 92 4.4.7. Add MAC ACL Entry . . . . . . . . . . . . . . . . . . 50 93 4.4.8. Add Station . . . . . . . . . . . . . . . . . . . . . 51 94 4.4.9. Add Static MAC ACL Entry . . . . . . . . . . . . . . 52 95 4.4.10. CAPWAP Control IPv4 Address . . . . . . . . . . . . . 52 96 4.4.11. CAPWAP Control IPv6 Address . . . . . . . . . . . . . 53 97 4.4.12. CAPWAP Timers . . . . . . . . . . . . . . . . . . . . 54 98 4.4.13. Data Transfer Data . . . . . . . . . . . . . . . . . 54 99 4.4.14. Data Transfer Mode . . . . . . . . . . . . . . . . . 55 100 4.4.15. Decryption Error Report . . . . . . . . . . . . . . . 55 101 4.4.16. Decryption Error Report Period . . . . . . . . . . . 56 102 4.4.17. Delete MAC ACL Entry . . . . . . . . . . . . . . . . 56 103 4.4.18. Delete Station . . . . . . . . . . . . . . . . . . . 57 104 4.4.19. Delete Static MAC ACL Entry . . . . . . . . . . . . . 57 105 4.4.20. Discovery Type . . . . . . . . . . . . . . . . . . . 58 106 4.4.21. Duplicate IPv4 Address . . . . . . . . . . . . . . . 58 107 4.4.22. Duplicate IPv6 Address . . . . . . . . . . . . . . . 59 108 4.4.23. Idle Timeout . . . . . . . . . . . . . . . . . . . . 60 109 4.4.24. Image Data . . . . . . . . . . . . . . . . . . . . . 60 110 4.4.25. Image Filename . . . . . . . . . . . . . . . . . . . 61 111 4.4.26. Initiate Download . . . . . . . . . . . . . . . . . . 61 112 4.4.27. Location Data . . . . . . . . . . . . . . . . . . . . 62 113 4.4.28. MTU Discovery Padding . . . . . . . . . . . . . . . . 62 114 4.4.29. Radio Administrative State . . . . . . . . . . . . . 62 115 4.4.30. Radio Operational State . . . . . . . . . . . . . . . 63 116 4.4.31. Result Code . . . . . . . . . . . . . . . . . . . . . 64 117 4.4.32. Session ID . . . . . . . . . . . . . . . . . . . . . 65 118 4.4.33. Statistics Timer . . . . . . . . . . . . . . . . . . 65 119 4.4.34. Vendor Specific Payload . . . . . . . . . . . . . . . 66 120 4.4.35. WTP Board Data . . . . . . . . . . . . . . . . . . . 66 121 4.4.36. WTP Descriptor . . . . . . . . . . . . . . . . . . . 67 122 4.4.37. WTP Fallback . . . . . . . . . . . . . . . . . . . . 69 123 4.4.38. WTP Frame Tunnel Mode . . . . . . . . . . . . . . . . 70 124 4.4.39. WTP IPv4 IP Address . . . . . . . . . . . . . . . . . 71 125 4.4.40. WTP MAC Type . . . . . . . . . . . . . . . . . . . . 71 126 4.4.41. WTP Name . . . . . . . . . . . . . . . . . . . . . . 72 127 4.4.42. WTP Operational Statistics . . . . . . . . . . . . . 72 128 4.4.43. WTP Radio Statistics . . . . . . . . . . . . . . . . 73 129 4.4.44. WTP Reboot Statistics . . . . . . . . . . . . . . . . 74 130 4.4.45. WTP Static IP Address Information . . . . . . . . . . 75 131 4.5. CAPWAP Protocol Timers . . . . . . . . . . . . . . . . . 76 132 4.5.1. DiscoveryInterval . . . . . . . . . . . . . . . . . . 76 133 4.5.2. DTLSRehandshake . . . . . . . . . . . . . . . . . . . 76 134 4.5.3. DTLSSessionDelete . . . . . . . . . . . . . . . . . . 77 135 4.5.4. EchoInterval . . . . . . . . . . . . . . . . . . . . 77 136 4.5.5. KeyLifetime . . . . . . . . . . . . . . . . . . . . . 77 137 4.5.6. MaxDiscoveryInterval . . . . . . . . . . . . . . . . 77 138 4.5.7. NeighborDeadInterval . . . . . . . . . . . . . . . . 77 139 4.5.8. ResponseTimeout . . . . . . . . . . . . . . . . . . . 77 140 4.5.9. RetransmitInterval . . . . . . . . . . . . . . . . . 78 141 4.5.10. SilentInterval . . . . . . . . . . . . . . . . . . . 78 142 4.5.11. WaitJoin . . . . . . . . . . . . . . . . . . . . . . 78 143 4.6. CAPWAP Protocol Variables . . . . . . . . . . . . . . . . 78 144 4.6.1. AdminState . . . . . . . . . . . . . . . . . . . . . 78 145 4.6.2. DiscoveryCount . . . . . . . . . . . . . . . . . . . 78 146 4.6.3. IdleTimeout . . . . . . . . . . . . . . . . . . . . . 78 147 4.6.4. MaxDiscoveries . . . . . . . . . . . . . . . . . . . 78 148 4.6.5. MaxRetransmit . . . . . . . . . . . . . . . . . . . . 79 149 4.6.6. ReportInterval . . . . . . . . . . . . . . . . . . . 79 150 4.6.7. RetransmitCount . . . . . . . . . . . . . . . . . . . 79 151 4.6.8. StatisticsTimer . . . . . . . . . . . . . . . . . . . 79 152 4.6.9. WTPFallBack . . . . . . . . . . . . . . . . . . . . . 79 153 4.7. WTP Saved Variables . . . . . . . . . . . . . . . . . . . 79 154 4.7.1. AdminRebootCount . . . . . . . . . . . . . . . . . . 79 155 4.7.2. FrameEncapType . . . . . . . . . . . . . . . . . . . 79 156 4.7.3. LastRebootReason . . . . . . . . . . . . . . . . . . 79 157 4.7.4. MacType . . . . . . . . . . . . . . . . . . . . . . . 80 158 4.7.5. PreferredACs . . . . . . . . . . . . . . . . . . . . 80 159 4.7.6. RebootCount . . . . . . . . . . . . . . . . . . . . . 80 160 4.7.7. Static ACL Table . . . . . . . . . . . . . . . . . . 80 161 4.7.8. Static IP Address . . . . . . . . . . . . . . . . . . 80 162 4.7.9. WTPLinkFailureCount . . . . . . . . . . . . . . . . . 80 163 4.7.10. WTPLocation . . . . . . . . . . . . . . . . . . . . . 80 164 4.7.11. WTPName . . . . . . . . . . . . . . . . . . . . . . . 80 165 5. CAPWAP Discovery Operations . . . . . . . . . . . . . . . . . 81 166 5.1. Discovery Request Message . . . . . . . . . . . . . . . . 81 167 5.2. Discovery Response Message . . . . . . . . . . . . . . . 82 168 5.3. Primary Discovery Request Message . . . . . . . . . . . . 82 169 5.4. Primary Discovery Response . . . . . . . . . . . . . . . 83 170 6. CAPWAP Join Operations . . . . . . . . . . . . . . . . . . . 84 171 6.1. Join Request . . . . . . . . . . . . . . . . . . . . . . 84 172 6.2. Join Response . . . . . . . . . . . . . . . . . . . . . . 84 173 7. Control Channel Management . . . . . . . . . . . . . . . . . 86 174 7.1. Echo Request . . . . . . . . . . . . . . . . . . . . . . 86 175 7.2. Echo Response . . . . . . . . . . . . . . . . . . . . . . 86 176 8. WTP Configuration Management . . . . . . . . . . . . . . . . 87 177 8.1. Configuration Consistency . . . . . . . . . . . . . . . . 87 178 8.1.1. Configuration Flexibility . . . . . . . . . . . . . . 88 179 8.2. Configuration Status . . . . . . . . . . . . . . . . . . 88 180 8.3. Configuration Status Response . . . . . . . . . . . . . . 89 181 8.4. Configuration Update Request . . . . . . . . . . . . . . 89 182 8.5. Configuration Update Response . . . . . . . . . . . . . . 90 183 8.6. Change State Event Request . . . . . . . . . . . . . . . 91 184 8.7. Change State Event Response . . . . . . . . . . . . . . . 91 185 8.8. Clear Configuration Request . . . . . . . . . . . . . . . 91 186 8.9. Clear Configuration Response . . . . . . . . . . . . . . 92 187 9. Device Management Operations . . . . . . . . . . . . . . . . 93 188 9.1. Image Data Request . . . . . . . . . . . . . . . . . . . 93 189 9.2. Image Data Response . . . . . . . . . . . . . . . . . . . 94 190 9.3. Reset Request . . . . . . . . . . . . . . . . . . . . . . 94 191 9.4. Reset Response . . . . . . . . . . . . . . . . . . . . . 94 192 9.5. WTP Event Request . . . . . . . . . . . . . . . . . . . . 95 193 9.6. WTP Event Response . . . . . . . . . . . . . . . . . . . 95 194 9.7. Data Transfer Request . . . . . . . . . . . . . . . . . . 95 195 9.8. Data Transfer Response . . . . . . . . . . . . . . . . . 96 196 10. Station Session Management . . . . . . . . . . . . . . . . . 97 197 10.1. Station Configuration Request . . . . . . . . . . . . . . 97 198 10.2. Station Configuration Response . . . . . . . . . . . . . 97 199 11. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 98 200 12. Security Considerations . . . . . . . . . . . . . . . . . . . 100 201 12.1. CAPWAP Security . . . . . . . . . . . . . . . . . . . . . 100 202 12.1.1. Converting Protected Data into Unprotected Data . . . 101 203 12.1.2. Converting Unprotected Data into Protected Data 204 (Insertion) . . . . . . . . . . . . . . . . . . . . . 101 205 12.1.3. Deletion of Protected Records . . . . . . . . . . . . 101 206 12.1.4. Insertion of Unprotected Records . . . . . . . . . . 101 207 12.2. Use of Preshared Keys in CAPWAP . . . . . . . . . . . . . 101 208 12.3. Use of Certificates in CAPWAP . . . . . . . . . . . . . . 102 209 12.4. AAA Security . . . . . . . . . . . . . . . . . . . . . . 103 210 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 104 211 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 105 212 14.1. Normative References . . . . . . . . . . . . . . . . . . 105 213 14.2. Informational References . . . . . . . . . . . . . . . . 105 214 Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 106 215 Intellectual Property and Copyright Statements . . . . . . . . . 107 217 1. Introduction 219 This document describes the CAPWAP Protocol, a standard, 220 interoperable protocol which enables an Access Controller (AC) to 221 manage a collection of Wireless Termination Points (WTPs). The 222 CAPWAP protocol is defined to be independent of layer 2 technology. 224 The emergence of centralized IEEE 802.11 Wireless Local Area Network 225 (WLAN) architectures, in which simple IEEE 802.11 WTPs are managed by 226 an Access Controller (AC) suggested that a standards based, 227 interoperable protocol could radically simplify the deployment and 228 management of wireless networks. WTPs require a set of dynamic 229 management and control functions related to their primary task of 230 connecting the wireless and wired mediums. Traditional protocols for 231 managing WTPs are either manual static configuration via HTTP, 232 proprietary Layer 2 specific or non-existent (if the WTPs are self- 233 contained). An IEEE 802.11 binding is defined in [11] to support use 234 of the CAPWAP protocol with IEEE 802.11 WLAN networks. 236 CAPWAP assumes a network configuration consisting of multiple WTPs 237 communicating via the Internet Protocol (IP) to an AC. WTPs are 238 viewed as remote RF interfaces controlled by the AC. The CAPWAP 239 protocol supports two modes of operation: Split and Local MAC. In 240 Split MAC mode all L2 wireless data and management frames are 241 encapsulated via the CAPWAP protocol and exchanged between the AC and 242 the WTP. As shown in Figure 1, the wireless frames received from a 243 mobile device, which is referred to in this specification as a 244 Station (or STA for short), are directly encapsulated by the WTP and 245 forwarded to the AC. 247 +-+ wireless frames +-+ 248 | |--------------------------------| | 249 | | +-+ | | 250 | |--------------| |---------------| | 251 | |wireless PHY/ | | CAPWAP | | 252 | | MAC sublayer | | | | 253 +-+ +-+ +-+ 254 STA WTP AC 256 Figure 1: Representative CAPWAP Architecture for Split MAC 258 The Local MAC mode of operation allows for the data frames to be 259 either locally bridged, or tunneled as 802.3 frames. The latter 260 implies that the WTP performs the 802 bridging function. In either 261 case the L2 wireless management frames are processed locally by the 262 WTP, and then forwarded to the AC. Figure 2 shows the Local MAC 263 mode, in which a station transmits a wireless frame which is 264 encapsulated in an 802.3 frame and forwarded to the AC. 266 +-+wireless frames +-+ 802.3 frames +-+ 267 | |----------------| |--------------| | 268 | | | | | | 269 | |----------------| |--------------| | 270 | |wireless PHY/ | | CAPWAP | | 271 | | MAC sublayer | | | | 272 +-+ +-+ +-+ 273 STA WTP AC 275 Figure 2: Representative CAPWAP Architecture for Local MAC 277 Provisioning WTPs with security credentials, and managing which WTPs 278 are authorized to provide service are traditionally handled by 279 proprietary solutions. Allowing these functions to be performed from 280 a centralized AC in an interoperable fashion increases manageability 281 and allows network operators to more tightly control their wireless 282 network infrastructure. 284 1.1. Goals 286 The goals for the CAPWAP protocol are listed below: 288 1. To centralize the authentication and policy enforcement functions 289 for a wireless network. The AC may also provide centralized 290 bridging, forwarding, and encryption of user traffic. 291 Centralization of these functions will enable reduced cost and 292 higher efficiency by applying the capabilities of network 293 processing silicon to the wireless network, as in wired LANs. 295 2. To enable shifting of the higher level protocol processing from 296 the WTP. This leaves the time critical applications of wireless 297 control and access in the WTP, making efficient use of the 298 computing power available in WTPs which are the subject to severe 299 cost pressure. 301 3. To provide a generic encapsulation and transport mechanism, 302 enabling the CAPWAP protocol to be applied to many access point 303 types in the future, via a specific wireless binding. 305 The CAPWAP protocol concerns itself solely with the interface between 306 the WTP and the AC. Inter-AC, or station to AC communication is 307 strictly outside the scope of this document. 309 1.2. Conventions used in this document 311 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 312 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 313 document are to be interpreted as described in RFC 2119 [1]. 315 1.3. Contributing Authors 317 This section lists and acknowledges the authors of significant text 318 and concepts included in this specification. [Note: This section 319 needs work to accurately reflect the contribution of each author and 320 this work will be done a future revision of this document.] 322 The CAPWAP Working Group selected the Lightweight Access Point 323 Protocol (LWAPP) [add reference, when available]to be used as the 324 basis of the CAPWAP protocol specification. The following people are 325 authors of the LWAPP document: 327 Bob O'Hara, Cisco Systems, Inc.,170 West Tasman Drive, San Jose, CA 95134 328 Phone: +1 408-853-5513, Email: bob.ohara@cisco.com 330 Pat Calhoun, Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134 331 Phone: +1 408-853-5269, Email: pcalhoun@cisco.com 333 Rohit Suri, Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134 334 Phone: +1 408-853-5548, Email: rsuri@cisco.com 336 Nancy Cam Winget, Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134 337 Phone: +1 408-853-0532, Email: ncamwing@cisco.com 339 Scott Kelly, Aruba Networks, 1322 Crossman Ave, Sunnyvale, CA 94089 340 Phone: +1 408-754-8408, Email: skelly@arubanetworks.com 342 Michael Glenn Williams, Nokia, Inc., 313 Fairchild Drive, Mountain View, CA 94043 343 Phone: +1 650-714-7758, Email: Michael.G.Williams@Nokia.com 345 Sue Hares, Nexthop Technologies, Inc., 825 Victors Way, Suite 100, Ann Arbor, MI 48108 346 Phone: +1 734 222 1610, Email: shares@nexthop.com 348 DTLS is used as the security solution for the CAPWAP protocol. The 349 following people are authors of significant DTLS-related text 350 included in this document: 352 Scott Kelly, Aruba Networks, 1322 Crossman Ave, Sunnyvale, CA 94089 353 Phone: +1 408-754-8408, Email: skelly@arubanetworks.com 355 Eric Rescorla, Network Resonance, 2483 El Camino Real, #212,Palo Alto CA, 94303 356 Email: ekr@networkresonance.com 358 The concept of using DTLS to secure the CAPWAP protocol was part of 359 the Secure Light Access Point Protocol (SLAPP) proposal [add 360 reference when available]. The following people are authors of the 361 SLAPP proposal: 363 Partha Narasimhan, Aruba Networks, 1322 Crossman Ave, Sunnyvale, CA 94089 364 Phone: +1 408-480-4716, Email: partha@arubanetworks.com 366 Dan Harkins, Tropos Networks, 555 Del Rey Avenue, Sunnyvale, CA, 95085 367 Phone: +1 408 470 7372, Email: dharkins@tropos.com 369 Subbu Ponnuswamy, Aruba Networks, 1322 Crossman Ave, Sunnyvale, CA 94089 370 Phone: +1 408-754-1213, Email: subbu@arubanetworks.com 372 1.4. Acknowledgements 374 The authors thank Michael Vakulenko for contributing text that 375 describes how CAPWAP can be used over a layer 3 (IP/UDP) network. 377 The authors thank Russ Housley and Charles Clancy for their 378 assistance in provide a security review of the LWAPP specification. 379 Charles' review can be found at [9]. 381 1.5. Terminology 383 Access Controller (AC): The network entity that provides WTP access 384 to the network infrastructure in the data plane, control plane, 385 management plane, or a combination therein. 387 Station (STA): A device that contains an IEEE 802.11 conformant 388 medium access control (MAC) and physical layer (PHY) interface to the 389 wireless medium (WM). 391 Wireless Termination Point (WTP): The physical or network entity that 392 contains an RF antenna and wireless PHY to transmit and receive 393 station traffic for wireless access networks. 395 This Document uses additional terminology defined in [8]. 397 2. Protocol Overview 399 The CAPWAP protocol is a generic protocol defining AC and WTP control 400 and data plane communication via a CAPWAP protocol transport 401 mechanism. CAPWAP control messages, and optionally CAPWAP data 402 messages, are secured using Datagram Transport Layer Security (DTLS) 403 [7]. DTLS is a standards-track IETF protocol based upon TLS. The 404 underlying security-related protocol mechanisms of TLS have been 405 successfully deployed for many years. 407 The CAPWAP protocol Transport layer carries two types of payload, 408 CAPWAP Data messages and CAPWAP Control messages. CAPWAP Data 409 messages encapsulate forwarded wireless frames. CAPWAP protocol 410 Control messages are management messages exchanged between a WTP and 411 an AC. The CAPWAP Data and Control packets are sent over separate 412 UDP ports. Since both data and control frames can exceed the PMTU, 413 the payload of a CAPWAP data or control message can be fragmented. 414 The fragmentation behavior is defined in Section 3. 416 The CAPWAP Protocol begins with a discovery phase. The WTPs send a 417 Discovery Request message, causing any Access Controller (AC) 418 receiving the message to respond with a Discovery Response message. 419 From the Discovery Response messages received, a WTP will select an 420 AC with which to establish a secure DTLS session. CAPWAP protocol 421 messages will be fragmented to the maximum length discovered to be 422 supported by the network. 424 Once the WTP and the AC have completed DTLS session establishment, a 425 configuration exchange occurs in which both devices to agree on 426 version information. During this exchange the WTP may receive 427 provisioning settings. The WTP is then enabled for operation. 429 When the WTP and AC have completed the version and provision exchange 430 and the WTP is enabled, the CAPWAP protocol is used to encapsulate 431 the wireless data frames sent between the WTP and AC. The CAPWAP 432 protocol will fragment the L2 frames if the size of the encapsulated 433 wireless user data (Data) or protocol control (Management) frames 434 causes the resulting CAPWAP protocol packet to exceed the MTU 435 supported between the WTP and AC. Fragmented CAPWAP packets are 436 reassembled to reconstitute the original encapsulated payload. 438 The CAPWAP protocol provides for the delivery of commands from the AC 439 to the WTP for the management of stations that are communicating with 440 the WTP. This may include the creation of local data structures in 441 the WTP for the stations and the collection of statistical 442 information about the communication between the WTP and the stations. 443 The CAPWAP protocol provides a mechanism for the AC to obtain 444 statistical information collected by the WTP. 446 The CAPWAP protocol provides for a keep alive feature that preserves 447 the communication channel between the WTP and AC. If the AC fails to 448 appear alive, the WTP will try to discover a new AC. 450 2.1. Wireless Binding Definition 452 The CAPWAP protocol is independent of a specific WTP radio 453 technology. Elements of the CAPWAP protocol are designed to 454 accommodate the specific needs of each wireless technology in a 455 standard way. Implementation of the CAPWAP protocol for a particular 456 wireless technology must follow the binding requirements defined for 457 that technology. 459 When defining a binding for wireless technologies, the authors MUST 460 include any necessary definitions for technology-specific messages 461 and all technology-specific message elements for those messages. At 462 a minimum, a binding MUST provide the definition for a binding- 463 specific Statistics message element, carried in the WTP Event Request 464 message, a message element carried in the Station Configure Request 465 to configure STA information on the WTP, and a WTP Radio Information 466 message element carried in the Discovery Request, Primary Discovery 467 Request and and Join Request messages, indicating the binding 468 specific radio types supported at the WTP. If technology specific 469 message elements are required for any of the existing CAPWAP messages 470 defined in this specification, they MUST also be defined in the 471 technology binding document. 473 The naming of binding-specific message elements MUST begin with the 474 name of the technology type, e.g., the binding for IEEE 802.11, 475 provided in [11], begins with "IEEE 802.11"." 477 2.2. CAPWAP Session Establishment Overview 479 This section describes the session establishment process message 480 exchanges in the ideal case. The annotated ladder diagram shows the 481 AC on the right, the WTP on the left, and assumes the use of 482 certificates for DTLS authentication. The CAPWAP Protocol State 483 Machine is described in detail in Section 2.3. 485 ============ ============ 486 WTP AC 487 ============ ============ 488 [----------- begin optional discovery ------------] 490 Discover Request ------> 491 <------ Discover Response 493 [----------- end optional discovery ------------] 494 (--- begin dtls handshake ---) 496 ClientHello ------> 497 <------ HelloVerifyRequest 498 (with cookie) 500 ClientHello ------> 501 (with cookie) 502 <------ ServerHello 503 <------ Certificate 504 <------ ServerHelloDone 506 (WTP callout for AC authorization) 508 Certificate* 509 ClientKeyExchange 510 CertificateVerify* 511 [ChangeCipherSpec] 512 Finished ------> 514 (AC callout for WTP 515 authorization) 517 [ChangeCipherSpec] 518 <------ Finished 520 (--- DTLS session is established now ---) 522 Join Request ------> 523 <------ Join Response 525 ( ---assume image is up to date ---) 527 Configure Request -------> 528 <------ Configure Response 530 (--- enter RUN state ---) 532 : 533 : 535 Echo Request -------> 536 <------ Echo Response 538 : 539 : 541 EventRequest -------> 542 <------ Event Response 544 : 545 : 547 At the end of the illustrated CAPWAP message exchange, the AC and WTP 548 are securely exchanging CAPWAP control messages. This is an 549 idealized illustration, provided to clarify protocol operation. 550 Section 2.3 provides a detailed description of the corresponding 551 state machine. 553 2.3. CAPWAP State Machine Definition 555 The following state diagram represents the lifecycle of a WTP-AC 556 session. Use of DTLS by the CAPWAP protocol results in the 557 juxtaposition of two nominally separate yet tightly bound state 558 machines. The DTLS and CAPWAP state machines are coupled through an 559 API consisting of commands (from CAPWAP to DTLS) and notifications 560 (from (DTLS to CAPWAP). Certain transitions in the DTLS state 561 machine are triggered by commands from the CAPWAP state machine, 562 while certain transitions in the CAPWAP state machine are triggered 563 by notifications from the DTLS state machine. 565 This section defines the CAPWAP Integrated State Machine. In the 566 figure below, single lines (denoted with '-' and '|') are used to 567 illustrate state transitions. Double lines (denoted with '=' and 568 '"') are used to illustrate commands and notifications between DTLS 569 and CAPWAP. A line composed of '~' characters is used to delineate 570 the boundary between nominal CAPWAP and DTLS state machine 571 components. 573 /-------------<----------------+--------------------\ 574 v |d | 575 +------+ b+-----------+ +----------+ | 576 | Idle |-->| Discovery |--->| Sulking | | 577 +------+ a +-----------+ c +----------+ | 578 ^ |aa ^ |e /----------------------\ | 579 | V f| v k| | | 580 h +--------------+ +------------+ i +------------+j | | 581 /--| Join |->| Configure |-->| Image Data | | | 582 | +--------------+ g+------------+ +------------+ | | 583 | "c1, ^ ^ ^ m| ^ |l | | 584 | "c4 " " " | /-------/ | /----/ | 585 | " " " " V |s v V | 586 | " " " " +------------+ o+------------+ | 587 | " " " " | Run |->| Reset |-------/ 588 | " " " " n+------------+ +------------+ p 589 | " " " " "c2 ^ ^ c3" ^ 590 \---"-----"--"---"--------"----"-------/ " " CAPWAP 591 ~~~~~~~"~~~~~"~~"~~~"~~~~~~~~"~~~~"~~~~~~~~~~~~"~~~"~~~~~~~~~~~~ 592 " " " " " " " " DTLS 593 v " "n2 \"""""\ " " v "n6,n7 594 /-->+------+ " W+------+ " " " +------------+ 595 | /-| Idle | " C| Auth |--"~-"----"----->| Shutdown |-------\P 596 | | +------+ " +------+V " " " /--->| |<----\ | 597 | |X Z| " ^ U| " " n4 " | +------------+ | | 598 | | | " | | " " n5," | ^ | | 599 | | v "n1 |Y | n3" v n8" |R |Q | | 600 | | +--------+ | +------------+ S+------------+ | | 601 | | | Init | \->| Run |<--| Rekey | | | 602 | | +--------+ | |-->| | | | 603 | | +------------+T +------------+ | | 604 | \---------------------------------------------------------/ | 605 \-------------------------------------------------------------/ 607 Figure 3: CAPWAP Integrated State Machine 609 The CAPWAP protocol state machine, depicted above, is used by both 610 the AC and the WTP. In cases where states are not shared (i.e. not 611 implemented in one or the other of the AC or WTP), this is explicitly 612 called out in the transition descriptions below. For every state 613 defined, only certain messages are permitted to be sent and received. 614 The CAPWAP control messages definitions specify the state(s) in which 615 each message is valid. 617 2.3.1. CAPWAP Protocol State Transitions 619 The following text discusses the various state transitions, and the 620 events that cause them. This section does not discuss interactions 621 between DTLS- and CAPWAP-specific states. Those interactions, as 622 well as DTLS-specific states and transitions, are discussed in 623 subsequent sections. 625 Idle to Discovery (a): This transition occurs once device 626 initialization is complete. 628 WTP: The WTP enters the Discovery state prior to transmitting the 629 first Discovery Request message (see Section 5.1). Upon 630 entering this state, the WTP sets the DiscoveryInterval timer 631 (see Section 4.5). The WTP resets the DiscoveryCount counter 632 to zero (0) (see Section 4.6). The WTP also clears all 633 information from ACs it may have received during a previous 634 Discovery phase. 636 AC: The AC does not maintain state information for the WTP upon 637 reception of the Discovery Request message, but it SHOULD 638 respond with a Discovery Response message (see Section 5.2). 639 This transition is a no-op for the AC. 641 Idle to Join (aa): This transition occurs when the WTP presents a 642 DTLS ClientHello message containing a valid cookie to the AC. 644 WTP: This transition is a no-op for the WTP. 646 AC: The AC does not maintain state information until the WTP 647 presents a DTLS ClientHello message containing a valid cookie. 648 Upon receipt of a DTLS ClientHello message containing a valid 649 cookie, the AC creates session state and transitions to the 650 Join state. 652 Discovery to Discovery (b): In the Discovery state, the WTP 653 determines which AC to connect to. 655 WTP: This transition occurs when the DiscoveryInterval timer 656 expires. If the WTP is configured with a list of ACs, it 657 transmits a Discovery Request message to every AC from which it 658 has not received a Discovery Response message. For every 659 transition to this event, the WTP increments the DiscoveryCount 660 counter. See Section 5.1 for more information on how the WTP 661 knows the ACs to which it should transmit the Discovery Request 662 messages. The WTP restarts the DiscoveryInterval timer 663 whenever it transmits Discovery Request messages. 665 AC: This is a no-op. 667 Discovery to Sulking (c): This transition occurs on a WTP when 668 Discovery or connectivity to the AC fails. 670 WTP: The WTP enters this state when the DiscoveryInterval timer 671 expires and the DiscoveryCount variable is equal to the 672 MaxDiscoveries variable (see Section 4.6). Upon entering this 673 state, the WTP shall start the SilentInterval timer. While in 674 the Sulking state, all received CAPWAP protocol messages 675 received shall be ignored. 677 AC: This is a no-op. 679 Sulking to Idle (d): This transition occurs on a WTP when it must 680 restart the discovery phase. 682 WTP: The WTP enters this state when the SilentInterval timer (see 683 Section 4.5) expires. 685 AC: This is a no-op. 687 Discovery to Join (e): This transition occurs when the WTP sends a 688 ClientHello message to the AC, confirming that it wishes to be 689 provided services by the AC. 691 WTP: The WTP selects the best AC based either on information 692 it gathered during the Discovery Phase or on its configuration. 693 It then sends a JoinRequest message to its preferred AC, sets 694 the WaitJoin timer, and awaits the Join Response Message. 696 AC: This is a no-op for the AC. 698 Join to Discovery (f): This state transition is used to return the 699 WTP to the Discovery state when an unresponsive AC is encountered. 701 WTP: The WTP re-enters the Discovery state when the WaitJoin 702 timer expires. 704 AC: This is a no-op. 706 Join to Configure (g): This state transition is used by the WTP and 707 the AC to exchange configuration information. 709 WTP: The WTP enters the Configure state when it successfully 710 completes the Join operation. If it determines that its 711 version number and the version number advertised by the AC are 712 compatible, the WTP transmits the Configuration Status message 713 (see Section 8.2) to the AC with a snapshot of its current 714 configuration. The WTP also starts the ResponseTimeout timer 715 (see Section 4.5). If the version numbers are not compatible, 716 the WTP will immediately transition to Image Data state (see 717 transition (i)). If the AC determines that a new firmware 718 image should be installed on the WTP, the AC initiates a 719 firmware download by sending an Image Data Request Message with 720 an Initiate Download message element to the WTP 722 AC: This state transition occurs immediately after the AC 723 transmits the Join Response message to the WTP. If the AC 724 receives the Configuration Status message from the WTP, the AC 725 must transmit a Configuration Status Response message(see 726 Section 8.3) to the WTP, and may include specific message 727 elements to override the WTP's configuration. If the AC 728 instead receives the Image Data Request from the WTP, it 729 immediately transitions to the Image Data state (see transition 730 (i)). 732 Join to Reset (h): This state transition occurs when the WaitJoin 733 Timer expires. 735 WTP: The state transition occurs when the WTP WaitJoin timer 736 expires, or upon DTLS negotiation failure. 738 AC: Thise state transition occurs when the AC WaitJoin timer 739 expires, or or upon DTLS negotiation failure. 741 Configure to Image Data (i): This state transition is used by the 742 WTP and the AC to download executable firmware. 744 WTP: The WTP enters the Image Data state when it successfully 745 comletes DTLS session establishment, and determines that its 746 version number and the version number advertised by the AC are 747 different. The WTP transmits the Image Data Request (see 748 Section 9.1) message requesting that a download of the AC's 749 latest firmware be initiated. 751 AC: This state transition occurs when the AC receives the Image 752 Data Request message from the WTP. The AC must transmit an 753 Image Data Response message (see Section 9.2) to the WTP, which 754 includes a portion of the firmware. 756 Image Data to Image Data (j): The Image Data state is used by WTP 757 and the AC during the firmware download phase. 759 WTP: The WTP enters the Image Data state when it receives an 760 Image Data Response message indicating that the AC has more 761 data to send. 763 AC: This state transition occurs when the AC receives the Image 764 Data Request message from the WTP while already in the Image 765 Data state, and it detects that the firmware download has not 766 completed. 768 Configure to Reset (k): This state transition is used to reset the 769 connection to the AC prior to restarting the WTP with a new 770 configuration. 772 WTP: The WTP enters the Reset state when it determines that a 773 reset of the WTP is required, due to the characteristics of a 774 new configuration. 776 AC: The AC transitions to the Reset state when it receives the 777 DTLSPeerDisconnect (n7) notification. 779 Image Data to Reset (l): This state transition is used to reset the 780 DTLS connection prior to restarting the WTP after an image 781 download. 783 WTP: When an image download completes, the WTP enters the Reset 784 state, and terminates the DTLS connection, sending a 785 DTLSShutdown command to the DTLS state machine. 787 AC: The AC enters the Reset state upon receipt of a DTLSIdle (n6) 788 notification. 790 Configure to Run (m): This state transition occurs when the WTP and 791 AC enter their normal state of operation. 793 WTP: The WTP enters this state when it receives a successful 794 Configuration Status Response message from the AC. The WTP 795 initializes the HeartBeat timer (see Section 4.5), and 796 transmits the Change State Event Request message (see 797 Section 8.6). 799 AC: This state transition occurs when the AC receives the Change 800 State Event Request message (see Section 8.6) from the WTP. 801 The AC responds with a Change State Event Response (see 802 Section 8.7) message. The AC must start the 803 NeighborDeadInterval timer (see Section 4.5). 805 Run to Run (n): This is the normal state of operation. 807 WTP: This is the WTP's normal state of operation. There are many 808 events that result this state transition: 810 Configuration Update: The WTP receives a Configuration Update 811 Request message(see Section 8.4). The WTP MUST respond with 812 a Configuration Update Response message (see Section 8.5). 814 Change State Event: The WTP receives a Change State Event 815 Response message, or determines that it must initiate a 816 Change State Event Request message, as a result of a failure 817 or change in the state of a radio. 819 Echo Request: The WTP receives an Echo Request message (see 820 Section 7.1), to which it MUST respond with an Echo Response 821 message(see Section 7.2). 823 Clear Config Request: The WTP receives a Clear Configuration 824 Request message (see Section 8.8). The WTP MUST reset its 825 configuration back to manufacturer defaults. 827 WTP Event: The WTP generates a WTP Event Request message to 828 send information to the AC (see Section 9.5). The WTP 829 receives a WTP Event Response message from the AC (see 830 Section 9.6). 832 Data Transfer: The WTP generates a Data Transfer Request 833 message to the AC (see Section 9.7). The WTP receives a 834 Data Transfer Response message from the AC (see 835 Section 9.8). 837 Station Configuration Request: The WTP receives a Station 838 Config Request message (see Section 10.1), to which it MUST 839 respond with a Station Config Response message (see 840 Section 10.2). 842 AC: This is the AC's normal state of operation: 844 Configuration Update: The AC sends a Configuration Update 845 Request message (see Section 8.4) to the WTP to update its 846 configuration. The AC receives a Configuration Update 847 Response message (see Section 8.5) from the WTP. 849 Change State Event: The AC receives a Change State Event 850 Request message (see Section 8.6), to which it MUST respond 851 with the Change State Event Response message (see 852 Section 8.7). 854 Echo: The AC sends an Echo Request message Section 7.1 or 855 receives the corresponding Echo Response message, see 856 Section 7.2 from the WTP. 858 Clear Config Response: The AC receives a Clear Configuration 859 Response message (see Section 8.9). 861 Station Config: The AC sends a Station Configuration Request 862 message (see Section 10.1) or receives the corresponding 863 Station Configuration Response message (see Section 10.2) 864 from the WTP. 866 Data Transfer: The AC receives a Data Transfer Request message 867 from the AC (see Section 9.7) and MUST generate a 868 corresponding Data Transfer Response message (see 869 Section 9.8). 871 WTP Event: The AC receives a WTP Event Request message from 872 the AC (see Section 9.5) and MUST generate a corresponding 873 WTP Event Response message (see Section 9.6). 875 Run to Reset(o): This state transition is used when the AC or WTP 876 wish to tear down the connection. This may occur as part of 877 normal operation, or due to error conditions. 879 WTP: The WTP enters the Reset state when it initiates orderly 880 termination of the DTLS connection, or when the underlying 881 reliable transport is unable to transmit a message within the 882 RetransmitInterval timer, see Section 4.5. The WTP also enters 883 the Reset state upon receiving a DTLS session termination 884 message (DTLS alert) from the AC. The WTP sends a DTLSShutdown 885 command to the DTLS state machine. 887 AC: The AC enters the Idle state when it initiates orderly 888 termination of the DTLS connection, or when the underlying 889 reliable transport is unable to transmit a message within the 890 RetransmitInterval timer (see Section 4.5), and the maximum 891 number of RetransmitCount counter has reached the MaxRetransmit 892 variable (see Section 4.6). The AC also enters the Reset state 893 upon receiving a DTLS session termination message from the WTP. 895 Reset to Idle (p): This state transition occurs when the state 896 machine is restarted following a system restart, an unrecoverable 897 error on the AC-WTP connection, or orderly session teardown. 899 WTP: The WTP clears any state associated with any AC and enters 900 the Idle state. 902 AC: The AC clears any state associated with the WTP and enters 903 the idle state. 905 Run to Image Data (s): This state transition occurs when the AC 906 transmits an Image Data Request to the WTP, with the Initiate 907 Download message element. The means by which the AC decides to 908 download firmware is undefined, but could occur through an 909 administrative action. 911 WTP: The WTP enters this state when it receives an an Image Data 912 Request to the WTP, with the Initiate Download message element. 913 The WTP responds by transmitting an Image Data Request with the 914 Image Filename message element included.. 916 AC: This state transition occurs when the AC decides that an WTP 917 is to update its firmware by sending an Image Data Request to 918 the WTP, with the Initiate Download message element. 920 2.3.2. CAPWAP to DTLS Commands 922 Four commands are defined for the CAPWAP to DTLS API. These 923 "commands" are conceptual, and may be implemented as one or more 924 function calls. This API definition is provided to clarify 925 interactions between the DTLS and CAPWAP components of the integrated 926 CAPWAP state machine. 928 Below is a list of the minimal command API: 930 o c1: DTLSStart is sent to the DTLS module to cause a DTLS session 931 to be established. 933 o c2: DTLSRehandshake is sent to the DTLS module to cause initiation 934 of a rehandshake (DTLS rekey). 936 o c3: DTLSShutdown is sent to the DTLS module to cause session 937 teardown. 939 o c4: DTLSAbort is sent to the DTLS module to cause session teardown 940 when the WaitJoin timer expires. 942 2.3.3. DTLS to CAPWAP Notifications 944 Eight notifications are defined for the DTLS to CAPWAP API. These 945 "notifications" are conceptual, and may be implemented in numerous 946 ways (e.g. as function return values). This API definition is 947 provided to clarify interactions between the DTLS and CAPWAP 948 components of the integrated CAPWAP state machine. 950 Below is a list of the API notifications: 952 o n1: DTLSInitFailure is sent to the CAPWAP module to indicate an 953 initialization failure, which may be due to out of memory or other 954 internal error condition. 956 o n2: DTLSAuthenticateFail or DTLSAuthorizeFail is sent to the 957 CAPWAP module to indicate peer authentication or authorization 958 failures, respectively. 960 o n3: DTLSEstablished is sent to the CAPWAP module to indicate that 961 that a secure channel now exists. 963 o n4: DTLSEncapFailure may be sent to CAPWAP to indicate an 964 encapsulation failure. DTLSDecapFailure may be sent to CAPWAP to 965 indicate an encryption/authentication failure 967 o n5: DTLSRehandshake is sent to the CAPWAP module to indicate DTLS 968 rehandshake initiation by peer. 970 o n6: DTLSIdle is sent to the CAPWAP module to indicate that session 971 abort (as requested by CAPWAP) is complete; this occurs when the 972 WaitJoin timer expires, or when CAPWAP is executing an orderly 973 session shutdown. 975 o n7: DTLSPeerDisconnect is sent to the CAPWAP module to indicate 976 DTLS session teardown by peer. Note that the n7 notification, can 977 be received while in the Join, Configure, Image Data, Run and 978 Reset states, and always causes a transition to the Reset state. 980 o n8: DTLSReassemblyFailure may be sent to the CAPWAP module to 981 indicate DTLS fragment reassembly failure. 983 2.3.4. DTLS State Transitions 985 This section describes the transitions in the DTLS-specific portion 986 of the state machine. 988 Idle to Init (Z): This transition indicates the begining of a DTLS 989 session. 991 WTP: The state ransition is triggered by receipt of the DTLSStart 992 command from the CAPWAP state machine, and causes the WTP to 993 send a DTLS ClientHello to the AC. 995 AC: The state transition is triggered by receipt of the DTLSStart 996 command from the CAPWAP state machine. The AC starts the 997 WaitJoin timer and awaits reception of a DTLS ClientHello 998 message 1000 Init to Authenticate/Authorize (Y) This transition indicates that 1001 the DTLS handshake is in progress. 1003 WTP: The WTP executes this state transition upon receipt of a 1004 valid ServerHello. 1006 AC: The AC executes this transition upon receipt of a certificate 1007 payload (if configured for public key authentication) or upon 1008 receipt of the ClientKeyExchange payload if configured for 1009 preshared keys. 1011 Init to Idle(X) This state transition occurs upon timeout of the 1012 WaitJoin Timer. 1014 WTP: Upon receiving a DTLSAbort command from the CAPWAP state 1015 machine, the WTP DTLS state machine transitions to Idle state. 1017 AC: Upon receiving a DTLSAbort command from the CAPWAP state 1018 machine, the AC DTLS state machine transitions to Idle state. 1020 Authenticate/Authorize to Authenticate/Authorize (W) This state 1021 transition is a Loopback state, representing execution of the TLS 1022 handshake protocol, including authorization callbacks to the 1023 CAPWAP architecture. 1025 WTP: Upon receiving AC credential, attempt to execute associated 1026 validation, authentication, and authorization callbacks. Note 1027 that credentials may span protocol messages, in which case the 1028 WTP will remain in this state pending receipt of all credential 1029 payloads. 1031 AC: Upon receipt of the WTP credential, attempt to execute 1032 associated validation, authentication, and authorization 1033 callbacks. Note that credentials may span protocol messages, 1034 in which case the AC will remain in this state pending receipt 1035 of all credential payloads. 1037 Authenticate/Authorize to Shutdown (V) This state transition 1038 indicates a failure of the DTLS handshake. 1040 WTP: Send a DTLSAuthenticateFail or DTLSAuthorizeFail to the 1041 CAPWAP state machine, depending on the exact cause of the 1042 error. May send a DTLS notification to the AC to indicate 1043 failure. 1045 AC: Send a DTLSAuthenticateFail or DTLSAuthorizeFail to the 1046 CAPWAP state machine, depending on the exact cause of the 1047 error. May send a DTLS Notification to the AC to indicate 1048 failure. 1050 Authenticate/Authorize to Run (U) This state transition occurs upon 1051 successful completion of the DTLS handshake. 1053 WTP: Send a DTLSEstablished notification to the CAPWAP state 1054 machine. 1056 AC: Send a DTLSEstablished notification to the CAPWAP state 1057 machine. 1059 Run to Rekey (T) This state transition occurs when a DTLS 1060 rehandshake is in progress; this is initiated when either (a) the 1061 DTLS state machine receives the DTLSRehandshake command from 1062 CAPWAP, or (b) a DTLS rehandshake message is received from the 1063 peer.. 1065 WTP: If CAPWAP issued a DTLSRehandshake command, initiate 1066 rehandshake with the peer; note that control traffic may 1067 continue to flow using existing secure association. If the 1068 rehandshake is initiated by the peer, send a DTLSRehandshake 1069 notification to CAPWAP. 1071 AC: If CAPWAP issued a DTLSRehandshake command, initiate 1072 rehandshake with the peer; note that control traffic may 1073 continue to flow using existing secure association. If the 1074 rehandshake is initiated by the peer, send a DTLSRehandshake 1075 notification to CAPWAP. 1077 Run to Shutdown (S) This state transition indicates a shutdown of 1078 the DTLS channel. 1080 WTP: This state transition occurs when the CAPWAP state machine 1081 sends a DTLSShutdown command, or when the the AC terminates the 1082 DTLS session. 1084 AC: This state transition occurs when CAPWAP state machine sends 1085 a DTLSShutdown command, or when the WTP terminates the DTLS 1086 session. 1088 Rekey to Run (R) This state transition indicates the successful 1089 completion of a DTLS rehandshake. 1091 WTP: This state transition occurs when the WTP receives the DTLS 1092 Finished message from the AC, completing the DTLS re-handshake. 1094 AC: This state transition occurs when the AC sends a DTLS 1095 Finished message to the WTP, completing the DTLS re-handshake. 1097 Rekey to Shutdown (Q) This state transition indicates the failure of 1098 the DTLS rekey operation. 1100 WTP: This state transition occurs when there is a failure in the 1101 rehandshake negotiation with the AC. 1103 AC: This state transition occurs when there is a failure in the 1104 rehandshake negotiation with the WTP. 1106 Shutdown to Idle (P) This state transition occurs upon transmission 1107 of a DTLS Session termination message, or upon receipt of a DTLS 1108 session termination message. 1110 WTP: This state transition occurs after the WTP transmits the 1111 DTLS session termination message. If the WTP receives a DTLS 1112 session termination message, it sends the DTLSPeerDisconnect 1113 notification to CAPWAP and moves to the Idle state. 1115 AC: This state transition occurs after the AC transmits the DTLS 1116 session termination message. If the AC receives a DTLS session 1117 termination message, it sends the DTLSPeerDisconnect 1118 notification to CAPWAP and moves to the Idle state. 1120 2.4. Use of DTLS in the CAPWAP Protocol 1122 DTLS is used as a tightly-integrated, secure wrapper for the CAPWAP 1123 protocol. In this document DTLS and CAPWAP are discussed as 1124 nominally distinct entitites; however they are very closely coupled, 1125 and may even be implemented inseparably. Since there are DTLS 1126 library implementations currently available, and since security 1127 protocols (e.g. IPsec, TLS) are often implemented in widely 1128 available acceleration hardware, it is both convenient and forward- 1129 looking to maintain a modular distinction in this document. 1131 This section describes a detailed walk-through of the interactions 1132 between the DTLS module and the CAPWAP module, via 'commands' (CAPWAP 1133 to DTLS) and 'notifications' (DTLS to CAPWAP) as they would be 1134 encountered during the normal course of operation. 1136 2.4.1. DTLS Handshake Processing 1138 Details of the DTLS handshake process are specified in [DTLS]. This 1139 section describes the interactions between the DTLS session 1140 establishment process and the CAPWAP protocol. In the normal case, 1141 the DTLS handshake will proceed as follows (NOTE: this example uses 1142 certificates, but preshared keys are also supported): 1144 ============ ============ 1145 WTP AC 1146 ============ ============ 1148 ClientHello ------> 1149 <------ HelloVerifyRequest 1150 (with cookie) 1152 ClientHello ------> 1153 (with cookie) 1154 <------ ServerHello 1155 <------ Certificate 1156 <------ ServerHelloDone 1158 (WTP callout for AC authorization) 1160 Certificate* 1161 ClientKeyExchange 1162 CertificateVerify* 1163 [ChangeCipherSpec] 1164 Finished ------> 1166 (AC callout for WTP 1167 authorization) 1169 [ChangeCipherSpec] 1170 <------ Finished 1172 DTLS, as specified, provides its own retransmit timers with an 1173 exponential back-off. However, it will never terminate the handshake 1174 due to non-responsiveness; rather, it will continue to increase its 1175 back-off timer period. Hence, timing out incomplete DTLS handshakes 1176 is entirely the responsiblity of the CAPWAP protocol. 1178 2.4.1.1. Join Operations 1180 The WTP, either through the Discovery process, or through pre- 1181 configuration, determines the AC to connect to. The WTP uses DTLS to 1182 establish a secure connection to the selected AC. Prior to 1183 initiation of the DTLS handshake, the WTP sets the WaitJoin timer. 1184 Upon receipt of a ClientHello message containing a valid cookie, the 1185 AC sets the WaitJoin timer. If the Join operation has not completed 1186 prior to timer expiration, the Join process is aborted, the WTP 1187 transitions back to Discovery state, and the AC transitions back to 1188 Idle state. Upon successful completion of the Join process the 1189 WaitJoin timer is deactivated. 1191 2.4.2. DTLS Error Handling 1193 If the AC does not respond to any DTLS messages sent by the WTP, the 1194 DTLS specification calls for the WTP to retransmit these messages. 1195 If the WaitJoin timer expires, CAPWAP will issue the DTLSAbort 1196 command, causing DTLS to terminate the handshake and remove any 1197 allocated session context. Note that DTLS MAY send a single TLS 1198 Alert message to the AC to indicate session termination. 1200 If the WTP does not respond to any DTLS messages sent by the AC, the 1201 CAPWAP protocol allows for three possiblities, listed below. Note 1202 that DTLS MAY send a single TLS Alert message to the AC to indicate 1203 session termination. 1205 o The message was lost in transit; in this case, the WTP will re- 1206 transmit its last outstanding message, since it did not receive 1207 the reply. 1209 o The WTP sent a DTLS Alert, which was lost in transit; in this 1210 case, the AC's WaitJoin timer will expire, and the session will be 1211 terminated. 1213 o Communication with the WTP has completely failed; in this case, 1214 the AC's WaitJoin timer will expire, and the session will be 1215 terminated. 1217 The DTLS specification provides for retransmission of unacknowledged 1218 requests. If retransmissions remain unacknowledged, the WaitJoin 1219 timer will eventually expire, at which time the CAPWAP module will 1220 terminate the session. 1222 If a cookie fails to validate, this could represent a WTP error, or 1223 it could represent a DoS attack. Hence, AC resource utilization 1224 SHOULD be minimized. The AC MAY log a message indicating the 1225 failure, but SHOULD NOT attempt to reply to the WTP. 1227 Since DTLS handshake messages are potentially larger than the maximum 1228 record size, DTLS supports fragmenting of handshake messages across 1229 multiple records. There are several potential causes of re-assembly 1230 errors, including overlapping and/or lost fragments. The DTLS module 1231 MUST send a DTLSReassemblyFailure notification to CAPWAP. Whether 1232 precise information is given along with notification is an 1233 implementation issue, and hence is beyond the scope of this document. 1234 Upon receipt of such an error, the CAPWAP protocol implementation 1235 SHOULD log an appropriate error message. Whether processing 1236 continues or the DTLS session is terminated is implementation 1237 dependent. 1239 DTLS decapsulation errors consist of three types: decryption errors, 1240 and authentication errors, and malformed DTLS record headers. Since 1241 DTLS authenticates the data prior to encapsulation, if decryption 1242 fails, it is difficult to detect this without first attempting to 1243 authenticate the packet. If authentication fails, a decryption error 1244 is also likely, but not guaranteed. Rather than attempt to derive 1245 (and require the implementation of) algorithms for detecting 1246 decryption failures, these are reported as authentication failures. 1247 The DTLS module MUST provide a DTLSDecapFailure notification to 1248 CAPWAP when such errors occur. If a malformed DTLS record header is 1249 detected, the packets SHOULD be silently discarded, and the receiver 1250 MAY log an error message. 1252 There is currently only one encapsulation error defined: MTU 1253 exceeeded. As part of DTLS session establishment, CAPWAP informs 1254 DTLS of the MTU size. This may be dynamically modified at any time 1255 when CAPWAP sends the DTLSMtuUpdate command to DTLS. DTLS returns 1256 this notification to CAPWAP whenever a transmission request will 1257 result in a packet which exceeds the MTU. 1259 2.4.3. DTLS Rehandshake Behavior 1261 DTLS rekeying (known in DTLS as "rehandshake") requires special 1262 attention, as the DTLS specification provides no rehandshake 1263 triggering mechanism. Rather, the application (in this case, CAPWAP) 1264 is expected to manage this for itself. This section addressed 1265 various aspects of rehandshake behavior. 1267 One simple way to think of a DTLS session is as a pair of 1268 unidirectional channels which are tightly bound together. A useful 1269 analogy is the twisted pair used for phone wiring, with one line per 1270 pair. Then, the rehandshake process can be thought of using the call 1271 over the existing pair to establish a call over a new pair - that is, 1272 an entirely new session is negotiated under the protection of the 1273 existing session. 1275 This sounds simple enough, yet there is operational complexity in 1276 changing over to the new session. In particular, how does each end 1277 know when it is safe to delete the "old" session, and switch over to 1278 the new one? If DTLS were not a datagram protocol, this would be 1279 simpler, but the fact that message delivery is unreliable 1280 significantly complicates things: when the AC (the "server") 1281 transmits its Finished message, it cannot be sure that the WTP 1282 received it until the WTP transmits data on the new channel. 1284 This fact constrains the way in which we transition to the new 1285 session, and delete the old one. The WTP, upon receipt of the AC's 1286 Finished message for the new session, immediately makes the new 1287 session active, and transmits no further data (e.g. echo requests, 1288 statistics, etc) on the old channel, and sends a TLS "user_cancelled" 1289 alert message on the old channel, after which the old session is 1290 immediately deleted. 1292 The AC, sets a DTLSSessionDelete timer, (see Section 4.5) and 1293 immediately makes the new session active, and transmits no further 1294 data (e.g. echo requests, statistics, etc) on the old channel. 1296 If a TLS "user_cancelled" alert message is received on the old 1297 channel, the session delete timer is deactivated, and the session is 1298 deleted. 1300 if the dtls-session-delete timer expires, a TLS "user_cancelled" 1301 alert message is transmitted on the old channel, and the session is 1302 deleted. 1304 Note that there is a slight possibility that some packets may be in 1305 flight when the session is deleted. However, since CAPWAP provides 1306 reliable delivery, these packets will be retransmitted over the new 1307 channel. 1309 2.4.3.1. Peer Initiated Rehandshake Triggers 1311 Since key lifetimes are not negotiable in DTLS, it is possible that a 1312 rehandshake from a peer may occur at any time, and implementations 1313 must be prepared for this eventuality. Presumably, communicating 1314 devices will be within the same domain of control. This being the 1315 case, overly-aggressive rekeying may be detected by simply monitoring 1316 logs, assuming such activity is indeed logged. Hence, 1317 implementations MUST log rekey attempts as they occur, reporting the 1318 time and identifying information for the peer. 1320 CAPWAP implementations MUST provide an administrative interface which 1321 permits specification of key lifetimes in seconds. Also, 1322 implementations which wait until this interval has expired to begin 1323 the rehandshake process are liable to encounter temporary service 1324 lapses on heavily loaded networks, so implementations SHOULD begin 1325 the rehandshake before the actual lifetime has elapsed. 1327 Given the relatively low bandwidth we might reasonably expect over a 1328 CAPWAP control channel and the strength of modern cryptographic 1329 algorithms (e.g. AES-128, 3DES, etc), it is reasonable to assume 1330 that lifetimes will typically be more than 8 hours. Given this 1331 assumption, a good rule of thumb for deciding when to rekey is this: 1332 deduct a random number of seconds from the lifetime (say, between 1% 1333 and 5% of the lifetime), and begin the rehandshake process at that 1334 point. Using a random value helps avert collisions, when both sides 1335 initiate a rehandshake at the same time (discussed further below). 1337 2.4.3.2. Time Based Rehandshake Triggers 1339 CAPWAP implementations MUST provide an administrative interface which 1340 permits specification of key lifetimes in seconds. Also, 1341 implementations which wait until this interval has expired to begin 1342 the rehandshake process are liable to encounter temporary service 1343 lapses on heavily loaded networks, so implementations SHOULD begin 1344 the rehandshake before the actual lifetime has elapsed. 1346 Given the relatively low bandwidth we might reasonably expect over a 1347 CAPWAP control channel and the strength of modern cryptographic 1348 algorithms (e.g. AES-128, 3DES, etc), it is reasonable to assume 1349 that key lifetimes will typically be more than 8 hours. Given this 1350 assumption, a good rule of thumb for deciding when to rekey is this: 1351 deduct a random number of seconds from the lifetime (say, between 1% 1352 and 5% of the lifetime), and begin the rehandshake process at that 1353 point. Using a random value helps avert collisions, when both sides 1354 initiate a rehandshake at the same time. 1356 2.4.3.3. Volume Based Rehandshake Triggers 1358 CAPWAP implementations MUST provide an administrative interface which 1359 permits specification of key lifetimes in packet count. Like time- 1360 based, lifetimes, implementations which wait until this interval has 1361 expired to begin the rehandshake process may encounter temporary 1362 service lapses on heavily loaded networks, so implementations SHOULD 1363 begin the rehandshake before the actual lifetime has elapsed. 1365 Volume-based lifetime estimation for purposes of rehandshake 1366 initiation is considerably more complex than time-based lifetime. In 1367 addition to avoiding collisions, the maximum burst rate must be 1368 known, and an extimate made, assuming rehandshake packets are lost, 1369 etc. Hence, we do not specify a one-size-fits-all approach here, and 1370 the specific algorithm used is implementation dependent. 1372 2.4.3.4. Rehandshake Collisions 1374 A collision occurs when both sides initiate a rehandshake 1375 simultaneously. No matter how much care is taken, rehandshake 1376 collisions are a distinct possibility. Hence, a contention 1377 resolution strategy is specified. 1379 A rehandshake collision is detected when a system receives a 1380 rehandshake initiation when it has one outstanding with the same 1381 peer. 1383 When this occurs, each side will compare its own address with that of 1384 its peer (in network byte order). 1386 The one with the lower of the two addresses will ignore the peer's 1387 rehandshake message, and continue with its own rehandshake process. 1389 The one with the higher message will immediately abort its current 1390 rehandshake, and set the DTLSRehandshake timer (see Section 4.5); if 1391 the peer with the lower address does not complete the rehandshake 1392 before the timer expires, the peer with the higher address will re- 1393 initiate. 1395 2.4.4. DTLS EndPoint Authentication 1397 DTLS supports endpoint authentication with certificates or preshared 1398 keys. The TLS algorithm suites for each endpoint authentication 1399 method are described below. 1401 2.4.4.1. Authenticating with Certificates 1403 Note that only block ciphers are currently recommended for use with 1404 DTLS. To understand the reasoning behind this, see [13]. However, 1405 support for AES counter mode encryption is currently progressing in 1406 the TLS working group, and once protocol identifiers are available, 1407 they will be added below. At present, the following algorithms MUST 1408 be supported when using certificates for CAPWAP authentication: 1410 o TLS_RSA_WITH_AES_128_CBC_SHA 1412 o TLS_RSA_WITH_3DES_EDE_CBC_SHA 1414 The following algorithms SHOULD be supported when using certificates: 1416 o TLS_DH_RSA_WITH_AES_128_CBC_SHA 1418 o TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA 1419 The following algorithms MAY be supported when using certificates: 1421 o TLS_RSA_WITH_AES_256_CBC_SHA 1423 o TLS_DH_RSA_WITH_AES_256_CBC_SHA 1425 2.4.4.2. Authenticating with Preshared Keys 1427 Pre-shared keys present significant challenges from a security 1428 perspective, and for that reason, their use is strongly discouraged. 1429 However, [6] defines several different methods for authenticating 1430 with preshared keys, and we focus on the following two: 1432 o PSK key exchange algorithm - simplest method, ciphersuites use 1433 only symmetric key algorithms 1435 o DHE_PSK key exchange algorithm - use a PSK to authenticate a 1436 Diffie-Hellman exchange. These ciphersuites give some additional 1437 protection against dictionary attacks and also provide Perfect 1438 Forward Secrecy (PFS). 1440 The first approach (plain PSK) is susceptible to passive dictionary 1441 attacks; hence, while this alorithm MUST be supported, special care 1442 should be taken when choosing that method. In particular, user- 1443 readable passphrases SHOULD NOT be used, and use of short PSKs SHOULD 1444 be strongly discouraged. 1446 The following cryptographic algorithms MUST be supported when using 1447 preshared keys: 1449 o TLS_PSK_WITH_AES_128_CBC_SHA 1451 o TLS_PSK_WITH_3DES_EDE_CBC_SHA 1453 o TLS_DHE_PSK_WITH_AES_128_CBC_SHA 1455 o TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA 1457 The following algorithms MAY be supported when using preshared keys: 1459 o TLS_PSK_WITH_AES_256_CBC_SHA 1461 o TLS_DHE_PSK_WITH_AES_256_CBC_SHA 1463 2.4.4.3. Certificate Usage 1465 When using certificates, both authentication and authorization must 1466 be considered. Section 12.3 provides recommendations on how to 1467 authenticate a certificate and bind that to a CAPWAP entity. This 1468 section deals with certificate authorization. 1470 Certificate authorization by the AC and WTP is required so that only 1471 an AC may perform the functions of an AC and that only a WTP may 1472 perform the functions of a WTP. This restriction of functions to the 1473 AC or WTP requires that the certificates used by the AC MUST be 1474 distinguishable from the certificate used by the WTP. To accomplish 1475 this differentiation, the x.509 certificates MUST include the 1476 Extended Key Usage (EKU)certificate extension [4]. 1478 The EKU field indicates one or more purposes for which a certificate 1479 may be used. It is an essential part in authorization. Its syntax 1480 is as follows: 1482 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 1484 KeyPurposeId ::= OBJECT IDENTIFIER 1486 Here we define two KeyPurposeId values, one for the WTP and one for 1487 the AC. Inclusion of one of those two values indicates a certificate 1488 is authorized for use by a WTP or AC, respectively. These values are 1489 formatted as id-kp fields. 1491 id-kp OBJECT IDENTIFIER ::= 1492 { iso(1) identified-organization(3) dod(6) internet(1) 1493 security(5) mechanisms(5) pkix(7) 3 } 1495 id-kp-capwapWTP OBJECT IDENTIFIER ::= { id-kp 19 } 1497 id-kp-capwapAC OBJECT IDENTIFIER ::= { id-kp 18 } 1499 For an AC, the id-kp-capwapAC EKU MUST be present in the certificate. 1500 For a WTP, the id-kp-capwapWTP EKU MUST be present in the 1501 certificate. 1503 Part of the CAPWAP certificate validation process includes ensuring 1504 that the proper EKU is included and only allowing the CAPWAP session 1505 to be established if the extension properly represents the device. 1507 3. CAPWAP Transport 1509 The CAPWAP protocol uses UDP as a transport, and can be used with 1510 IPv4 or IPv6. This section details the specifics of how the CAPWAP 1511 protocol works in conjunction with IP. 1513 3.1. UDP Transport 1515 Communication between a WTP and an AC is established according to the 1516 standard UDP client/server model. One of the CAPWAP requirements is 1517 to allow a WTP to reside behind a firewall and/or Network Address 1518 Translation (NAT) device. Since the connection is initiated by the 1519 WTP (client) to the well-known UDP port of the AC (server), the use 1520 of UDP is a logical choice. 1522 CAPWAP protocol control packets sent between the WTP and the AC use 1523 well known UDP port [to be IANA assigned]. CAPWAP protocol data 1524 packets sent between the WTP and the AC use UDP port [to be IANA 1525 assigned]. 1527 3.2. AC Discovery 1529 A WTP and an AC will frequently not reside in the same IP subnet 1530 (broadcast domain). When this occurs, the WTP must be capable of 1531 discovering the AC, without requiring that multicast services are 1532 enabled in the network. This section describes how AC discovery is 1533 performed by WTPs. 1535 As the WTP attempts to establish communication with an AC, it sends 1536 the Discovery Request message and receives the corresponding response 1537 message from the AC(s). The WTP must send the Discovery Request 1538 message to either the limited broadcast IP address (255.255.255.255), 1539 a well known multicast address or to the unicast IP address of the 1540 AC. Upon receipt of the Discovery Request message, the AC issues a 1541 Discovery Response message to the unicast IP address of the WTP, 1542 regardless of whether the Discovery Request message was sent as a 1543 broadcast, multicast or unicast message. 1545 WTP use of a limited IP broadcast, multicast or unicast IP address is 1546 implementation dependent. 1548 When a WTP transmits a Discovery Request message to a unicast 1549 address, the WTP must first obtain the IP address of the AC. Any 1550 static configuration of an AC's IP address on the WTP non-volatile 1551 storage is implementation dependent. However, additional dynamic 1552 schemes are possible, for example: 1554 DHCP: A comma delimited ASCII encoded list of AC IP addresses is 1555 embedded in the DHCP vendor specific option 43 extension. An 1556 example of the actual format of the vendor specific payload for 1557 IPv4 is of the form "10.1.1.1, 10.1.1.2". 1559 DNS: The DNS name "CAPWAP-AC-Address" MAY be resolvable to one or 1560 more AC addresses. 1562 3.3. Fragmentation/Reassembly 1564 While fragmentation and reassembly services are provided by IP, the 1565 CAPWAP protocol also provides such services. Environments where the 1566 CAPWAP protocol is used involve firewall, Network Address Translation 1567 (NAT) and "middle box" devices, which tend to drop IP fragments in 1568 order to minimize possible Denial of Service attacks. By providing 1569 fragmentation and reassembly at the application layer, any 1570 fragmentation required due to the tunneling component of the CAPWAP 1571 protocol becomes transparent to these intermediate devices. 1572 Consequently, the CAPWAP protocol is not impacted by any network 1573 configurations. 1575 4. CAPWAP Packet Formats 1577 This section contains the CAPWAP protocol packet formats. A CAPWAP 1578 protocol packet consists of a CAPWAP Transport Layer packet header 1579 followed by a CAPWAP message. The CAPWAP message can be either of 1580 type Control or Data, where Control packets carry signaling, and Data 1581 packets carry user payloads. The CAPWAP frame formats for CAPWAP 1582 Data packets, and for DTLS encapsulated CAPWAP Data and Control 1583 packets. are as shown below: 1585 CAPWAP Data Packet : 1586 +--------------------------------+ 1587 | IP |UDP | CAPWAP | Wireless | 1588 | Hdr |Hdr | Header | Payload | 1589 +--------------------------------+ 1591 CAPWAP + Optional DTLS Data Packet Security: 1592 +------------------------------------------------+ 1593 | IP |UDP | DTLS | CAPWAP | Wireless | DTLS | 1594 | Hdr |Hdr | Hdr | Hdr | Payload | Trailer| 1595 +------------------------------------------------+ 1596 \--authenticated-----------/ 1597 \--- encrypted-----------/ 1599 CAPWAP Control Packet (DTLS Security Required): 1600 +-----------------------------------------------------------+ 1601 | IP |UDP | DTLS | CAPWAP | Control | Message | DTLS | 1602 | Hdr |Hdr | Hdr | Header | Header | Element(s) | Trailer | 1603 +-----------------------------------------------------------+ 1604 \-------authenticated-----------------/ 1605 \------------encrypted-------------------/ 1607 UDP: All CAPWAP packets are encapsulated within UDP. Section 1608 Section 3.1 defines the specific UDP usage. 1610 CAPWAP Header: All CAPWAP protocol packets use a common header that 1611 immediately follows the UDP header. This header, is defined in 1612 Section 4.1. 1614 Wireless Payload: A CAPWAP protocol packet that contains a wireless 1615 payload is known as a data frame. The CAPWAP protocol does not 1616 dictate the format of the wireless payload, which is defined by 1617 the appropriate wireless standard. Additional information is in 1618 Section 4.2. 1620 Control Header: The CAPWAP protocol includes a signalling component, 1621 known as the CAPWAP control protocol. All CAPWAP control packets 1622 include a Control Header, which is defined in Section 4.3.1. 1624 Message Elements: A CAPWAP Control packet includes one or more 1625 message elements, which are found immediately following the 1626 control header. These message elements are in a Type/Length/value 1627 style header, defined in Section 4.4. 1629 4.1. CAPWAP Header 1631 All CAPWAP protocol messages are encapsulated using a common header 1632 format, regardless of the CAPWAP control or CAPWAP Data transport 1633 used to carry the messages. However, certain flags are not 1634 applicable for a given transport. Refer to the specific transport 1635 section in order to determine which flags are valid. 1637 Note that the optional fields defined in this section MUST be present 1638 in the precise order shown below. 1640 0 1 2 3 1641 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 1642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1643 |Version| RID | HLEN | WBID |T|F|L|W|M| Flags | 1644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1645 | Fragment ID | Frag Offset |Rsvd | 1646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1647 | (optional) Radio MAC Address | 1648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1649 | (optional) Wireless Specific Information | 1650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1651 | Payload .... | 1652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1654 Version: A 4 bit field which contains the version of CAPWAP used in 1655 this packet. The value for this draft is 0. 1657 RID: A 5 bit field which contains the Radio ID number for this 1658 packet. WTPs with multiple radios but a single MAC Address range 1659 use this field to indicate which radio is associated with the 1660 packet. 1662 HLEN: A 5 bit field containing the length of the CAPWAP transport 1663 header in 4 byte words (Similar to IP header length). This length 1664 includes the optional headers. 1666 WBID: A 5 bit field which is the wireless binding identifier. The 1667 identifier will indicate the type of wireless packet type 1668 associated with the radio. The following values are defined: 1670 1 - IEEE 802.11 1672 2 - IEEE 802.16 1674 3 - EPCGlobal 1676 T: The Type 'T' bit indicates the format of the frame being 1677 transported in the payload. When this bit is set to one (1), the 1678 payload has the native frame format indicated by the WBID field. 1679 When this bit is zero (0) the payload is an IEEE 802.3 frame. 1681 F: The Fragment 'F' bit indicates whether this packet is a fragment. 1682 When this bit is one (1), the packet is a fragment and MUST be 1683 combined with the other corresponding fragments to reassemble the 1684 complete information exchanged between the WTP and AC. 1686 L: The Last 'L' bit is valid only if the 'F' bit is set and indicates 1687 whether the packet contains the last fragment of a fragmented 1688 exchange between WTP and AC. When this bit is 1, the packet is 1689 the last fragment. When this bit is 0, the packet is not the last 1690 fragment. 1692 W: The Wireless 'W' bit is used to specify whether the optional 1693 wireless specific information field is present in the header. A 1694 value of one (1) is used to represent the fact that the optional 1695 header is present. 1697 M: The M bit is used to indicate that the Radio MAC Address optional 1698 header is present. This is used to communicate the MAC address of 1699 the receiving radio when the native wireless packet. This field 1700 MUST NOT be set to one in packets sent by the AC to the WTP. 1702 Flags: A set of reserved bits for future flags in the CAPWAP header. 1703 All implementations complying with this protocol MUST set to zero 1704 any bits that are reserved in the version of the protocol 1705 supported by that implementation. Receivers MUST ignore all bits 1706 not defined for the version of the protocol they support. 1708 Fragment ID: An 16 bit field whose value is assigned to each group 1709 of fragments making up a complete set. The fragment ID space is 1710 managed individually for every WTP/AC pair. The value of Fragment 1711 ID is incremented with each new set of fragments. The Fragment ID 1712 wraps to zero after the maximum value has been used to identify a 1713 set of fragments. 1715 Fragment Offset: A 13 bit field that indicates where in the payload 1716 will this fragment belong during re-assembly. This field is valid 1717 when the 'F' bit is set to 1. The fragment offset is measured in 1718 units of 8 octets (64 bits). The first fragment has offset zero. 1719 Note the CAPWAP protocol does not allow for overlapping fragments. 1720 For instance, fragment 0 would include offset 0 with a payload 1721 length of 1000, while fragment 1 include offset 900 with a payload 1722 length of 600. 1724 Reserved: The 3-bit field is reserved for future use. All 1725 implementations complying with this protocol MUST set to zero any 1726 bits that are reserved in the version of the protocol supported by 1727 that implementation. Receivers MUST ignore all bits not defined 1728 for the version of the protocol they support. 1730 Radio MAC Address: This optional field contains the MAC address of 1731 the radio receiving the packet. This is useful in packets sent 1732 from the WTP to the AC, when the native wireless frame format is 1733 converted to 802.3 by the WTP. This field is only present if the 1734 'M' bit is set. Given the HLEN field assumes 4 byte alignment, 1735 this field MUST be padded with zeroes (0x00) if it is not 4 byte 1736 aligned. 1738 The field contains the basic format: 1740 0 1 2 3 1741 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 1742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1743 | Length | MAC Address 1744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1746 Length: The number of bytes in the MAC Address field. The length 1747 field is present since some technologies (e.g., IEEE 802.16) 1748 are now using 64 bit MAC addresses. 1750 MAC Address: The MAC Address of the receiving radio. 1752 Wireless Specific Information: This optional field contains 1753 technology specific information that may be used to carry per 1754 packet wireless information. This field is only present if the 1755 'W' bit is set. Given the HLEN field assumes 4 byte alignment, 1756 this field MUST be padded with zeroes (0x00) if it is not 4 byte 1757 aligned. 1759 The field contains the basic format: 1761 0 1 2 3 1762 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 1763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1764 | Wireless ID | Length | Data 1765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1767 Wireless ID: The wireless binding identifier. The following 1768 values are defined: 1770 1 - IEEE 802.11 1772 2 - IEEE 802.16 1774 3 - EPCGlobal 1776 Length: The length of the data field 1778 Data: Wireless specific information, defined by the wireless 1779 specific binding. 1781 Payload: This field contains the header for a CAPWAP Data Message or 1782 CAPWAP Control Message, followed by the data associated with that 1783 message. 1785 4.2. CAPWAP Data Messages 1787 A CAPWAP protocol data message encapsulates a forwarded wireless 1788 frame. The CAPWAP protocol defines two different modes of 1789 encapsulation; IEEE 802.3 and native wireless. IEEE 802.3 1790 encapsulation requires that the bridging function be performed in the 1791 WTP. An IEEE 802.3 encapsulated user payload frame has the following 1792 format: 1794 +------------------------------------------------------+ 1795 | IP Header | UDP Header | CAPWAP Header | 802.3 Frame | 1796 +------------------------------------------------------+ 1798 The CAPWAP protocol also defines the native wireless encapsulation 1799 mode. The actual format of the encapsulated CAPWAP data frame is 1800 subject to the rules defined under the specific wireless technology 1801 binding. As a consequence, each wireless technology binding MUST 1802 define a section entitled "Payload encapsulation", which defines the 1803 format of the wireless payload that is encapsulated within the CAPWAP 1804 Data messages. 1806 In the event that the encapsulated frame would exceed the transport 1807 layer's MTU, the sender is responsible for the fragmentation of the 1808 frame, as specified in Section 3.3. 1810 4.3. CAPWAP Control Messages 1812 The CAPWAP Control protocol provides a control channel between the 1813 WTP and the AC. Control messages are divided into the following 1814 distinct message types: 1816 Discovery: CAPWAP Discovery messages are used to identify potential 1817 ACs, their load and capabilities. 1819 Join: CAPWAP Join messages are used to for a WTP to request service 1820 from an AC, and for the AC to respond to the WTP. 1822 Control Channel Management: CAPWAP control channel management 1823 messages are used to maintain the control channel. 1825 WTP Configuration Management: The WTP Configuration messages are 1826 used by the AC to push a specific configuration to the WTP. 1827 Messages which provide retrieval of statistics from the WTP also 1828 fall in this category. 1830 Station Session Management: Station session management messages are 1831 used by the AC to push specific Station policies to the WTP. 1833 Device Management Operations: Device management operations are used 1834 to request and deliver a firmware image to the WTP. 1836 Binding Specific CAPWAP Management Frames: Messages in this category 1837 are used by the AC and the WTP to exchange protocol-specific 1838 CAPWAP management messages. These messages may or may not be used 1839 to change the link state of a station. 1841 Discovery, Join, Control Message Management, WTP Configuration 1842 Management and Station Session Management CAPWAP control messages 1843 MUST be implemented. Device Operations Management messages MAY be 1844 implemented. 1846 CAPWAP control messages sent from the WTP to the AC indicate that the 1847 WTP is operational, providing an implicit keep-alive mechanism for 1848 the WTP. The Control Channel Management Echo Request and Echo 1849 Response messages provide an explicit keep-alive mechanism when other 1850 CAPWAP control messages are not exchanged. 1852 4.3.1. Control Message Format 1854 All CAPWAP control messages are sent encapsulated within the CAPWAP 1855 header (see Section 4.1). Immediately following the CAPWAP header, 1856 is the control header, which has the following format: 1858 0 1 2 3 1859 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 1860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1861 | Message Type | 1862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1863 | Seq Num | Msg Element Length | Flags | 1864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1865 | Time Stamp | 1866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1867 | Msg Element [0..N] ... 1868 +-+-+-+-+-+-+-+-+-+-+-+-+ 1870 4.3.1.1. Message Type 1872 The Message Type field identifies the function of the CAPWAP control 1873 message. The Message Type field is comprised of an IANA Enterprise 1874 Number and an enterprise specific message type number. The first 1875 three octets is the enterprise number in network byte order, with 1876 zero being used for CAPWAP generic message types and the IEEE 802.11 1877 IANA assigned enterprise number 13277 being used for IEEE 802.11 1878 technology specific message types. The last octet is the enterprise 1879 specific message type number, which has a range from 0 to 255. The 1880 message type field can be expressed as: 1882 Message Type = IANA Enterprise Number * 256 + enterprise specific message type number 1884 The valid values for base CAPWAP Message Types are given in the table 1885 below: 1887 CAPWAP Control Message Message Type 1888 Value 1889 Discovery Request 1 1890 Discovery Response 2 1891 Join Request 3 1892 Join Response 4 1893 Configuration Status 5 1894 Configuration Status Response 6 1895 Configuration Update Request 7 1896 Configuration Update Response 8 1897 WTP Event Request 9 1898 WTP Event Response 10 1899 Change State Event Request 11 1900 Change State Event Response 12 1901 Echo Request 13 1902 Echo Response 14 1903 Image Data Request 15 1904 Image Data Response 16 1905 Reset Request 17 1906 Reset Response 18 1907 Primary Discovery Request 19 1908 Primary Discovery Response 20 1909 Data Transfer Request 21 1910 Data Transfer Response 22 1911 Clear Configuration Request 23 1912 Clear Configuration Response 24 1913 Station Configuration Request 25 1914 Station Configuration Response 26 1916 4.3.1.2. Sequence Number 1918 The Sequence Number Field is an identifier value to match request and 1919 response packet exchanges. When a CAPWAP packet with a request 1920 message type is received, the value of the sequence number field is 1921 copied into the corresponding response packet. 1923 When a CAPWAP control message is sent, its internal sequence number 1924 counter is monotonically incremented, ensuring that no two requests 1925 pending have the same sequence number. This field will wrap back to 1926 zero. 1928 4.3.1.3. Message Element Length 1930 The Length field indicates the number of bytes following the Sequence 1931 Num field. 1933 4.3.1.4. Flags 1935 The Flags field MUST be set to zero. 1937 4.3.1.5. Time Stamp 1939 The Timestamp contains the timestamp. PRC-TODO: Details need to be 1940 added here, and I am waiting for info from Dave Perkins. 1942 4.3.1.6. Message Element[0..N] 1944 The message element(s) carry the information pertinent to each of the 1945 control message types. Every control message in this specification 1946 specifies which message elements are permitted. 1948 4.3.2. Control Message Quality of Service 1950 It is recommended that CAPWAP control messages be sent by both the AC 1951 and the WTP with an appropriate Quality of Service precedence value, 1952 ensuring that congestion in the network minimizes occurrences of 1953 CAPWAP control channel disconnects. Therefore, a Quality of Service 1954 enabled CAPWAP device should use the following values: 1956 802.1P: The precedence value of 7 SHOULD be used. 1958 DSCP: The DSCP tag value of 46 SHOULD be used. 1960 4.4. CAPWAP Protocol Message Elements 1962 This section defines the CAPWAP Protocol message elements which are 1963 included in CAPWAP protocol control messages. 1965 Message elements are used to carry information needed in control 1966 messages. Every message element is identified by the Type field, 1967 whose numbering space is defined below. The total length of the 1968 message elements is indicated in the Message Element Length field. 1970 All of the message element definitions in this document use a diagram 1971 similar to the one below in order to depict its format. Note that in 1972 order to simplify this specification, these diagrams do not include 1973 the header fields (Type and Length). The header field values are 1974 defined in the Message element descriptions. 1976 Note that unless otherwise specified, a control message that lists a 1977 set of supported (or expected) message elements MUST not expect the 1978 message elements to be in any specific order. The sender may order 1979 the message elements as convenient. Furthermore, unless specifically 1980 noted, any individual message element may exist one or more times 1981 within a given control message. 1983 Additional message elements may be defined in separate IETF 1984 documents. 1986 The format of a message element uses the TLV format shown here: 1988 0 1 2 3 1989 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 1990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1991 | Type | Length | 1992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1993 | Value ... | 1994 +-+-+-+-+-+-+-+-+ 1996 Where Type (16 bit) identifies the character of the information 1997 carried in the Value field and Length (16 bits) indicates the number 1998 of bytes in the Value field. Type field values are allocated as 1999 follows: 2001 Usage Type Values 2003 CAPWAP Protocol Message Elements 1-1023 2004 IEEE 802.11 Message Elements 1024-2047 2005 IEEE 802.16 Message Elements 2048 - 3071 2006 EPCGlobal Message Elements 3072 - 4095 2007 Reserved for Future Use 4096 - 65024 2009 The table below lists the CAPWAP protocol Message Elements and their 2010 Type values. 2012 CAPWAP Message Element Type Value 2014 AC Descriptor 1 2015 AC IPv4 List 2 2016 AC IPv6 List 3 2017 AC Name 4 2018 AC Name with Index 5 2019 AC Timestamp 6 2020 Add MAC ACL Entry 7 2021 Add Station 8 2022 Add Static MAC ACL Entry 9 2023 CAPWAP Control IPV4 Address 10 2024 CAPWAP Control IPV6 Address 11 2025 CAPWAP Timers 12 2026 Data Transfer Data 13 2027 Data Transfer Mode 14 2028 Decryption Error Report 15 2029 Decryption Error Report Period 16 2030 Delete MAC ACL Entry 17 2031 Delete Station 18 2032 Delete Static MAC ACL Entry 19 2033 Discovery Type 20 2034 Duplicate IPv4 Address 21 2035 Duplicate IPv6 Address 22 2036 Idle Timeout 23 2037 Image Data 24 2038 Image Filename 25 2039 Initiate Download 26 2040 Location Data 27 2041 MTU Discovery Padding 28 2042 Radio Administrative State 29 2043 Radio Operational State 30 2044 Result Code 31 2045 Session ID 32 2046 Statistics Timer 33 2047 Vendor Specific Payload 34 2048 WTP Board Data 35 2049 WTP Descriptor 36 2050 WTP Fallback 37 2051 WTP Frame Tunnel Mode 38 2052 WTP IPv4 IP Address 39 2053 WTP MAC Type 40 2054 WTP Name 41 2055 WTP Operational Statistics 42 2056 WTP Radio Statistics 43 2057 WTP Reboot Statistics 44 2058 WTP Static IP Address Information 45 2060 4.4.1. AC Descriptor 2062 The AC payload message element is used by the AC to communicate it's 2063 current state. The value contains the following fields. 2065 0 1 2 3 2066 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 2067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2068 | Stations | Limit | 2069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2070 | Active WTPs | Max WTPs | 2071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2072 | Security | R-MAC Field |Wireless Field | Reserved | 2073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2074 | Vendor Identifier | 2075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2076 | Type=4 | Length | 2077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2078 | Value... 2079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2080 | Vendor Identifier | 2081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2082 | Type=5 | Length | 2083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2084 | Value... 2085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2087 Type: 1 for AC Descriptor 2089 Length: >= 12 2091 Stations: The number of stations currently associated with the AC 2093 Limit: The maximum number of stations supported by the AC 2095 Active WTPs: The number of WTPs currently attached to the AC 2097 Max WTPs: The maximum number of WTPs supported by the AC 2099 Security: A 8 bit bit mask specifying the authentication credential 2100 type supported by the AC. The following values are supported (see 2101 Section 2.4.4): 2103 1 - X.509 Certificate Based 2104 2 - Pre-Shared Secret 2106 R-MAC Field: The AC supports the optional Radio MAC Address field 2107 in the CAPWAP transport Header (see Section 4.1). 2109 Wireless Field: The AC supports the optional Wireless Specific 2110 Information field in the CAPWAP Header (see Section 4.1). 2112 Reserved: All implementations complying with this protocol MUST set 2113 to zero any bits that are reserved in the version of the protocol 2114 supported by that implementation. Receivers MUST ignore all bits 2115 not defined for the version of the protocol they support. 2117 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 2118 Network Management Private Enterprise Codes" 2120 Type: Vendor specific encoding of AC information. The following 2121 values are supported. The Hardware and Software Version values 2122 MUST be included. 2124 4 - Hardware Version: The AC's hardware version number. 2126 5 - Software Version: The AC's Firmware version number. 2128 Length: Length of vendor specific encoding of AC information. 2130 Value: Vendor specific encoding of AC information. 2132 4.4.2. AC IPv4 List 2134 The AC IPv4 List message element is used to configure a WTP with the 2135 latest list of ACs available for the WTP to join. 2137 0 1 2 3 2138 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 2139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2140 | AC IP Address[] | 2141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2143 Type: 2 for AC List 2145 Length: 4 2147 The AC IP Address: An array of 32-bit integers containing an AC's 2148 IPv4 Address. 2150 4.4.3. AC IPv6 List 2152 The AC IPv6 List message element is used to configure a WTP with the 2153 latest list of ACs available for the WTP to join. 2155 0 1 2 3 2156 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 2157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2158 | AC IP Address[] | 2159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2160 | AC IP Address[] | 2161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2162 | AC IP Address[] | 2163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2164 | AC IP Address[] | 2165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2167 Type: 3 for AC IPV6 List 2169 Length: 16 2171 The AC IP Address: An array of 32-bit integers containing an AC's 2172 IPv6 Address. 2174 4.4.4. AC Name 2176 The AC name message element contains an UTF-8 representation of the 2177 AC's identity. The value is a variable length byte string. The 2178 string is NOT zero terminated. 2180 0 2181 0 1 2 3 4 5 6 7 2182 +-+-+-+-+-+-+-+-+ 2183 | Name ... 2184 +-+-+-+-+-+-+-+-+ 2186 Type: 4 for AC Name 2188 Length: > 0 2190 Name: A variable length UTF-8 encoded string containing the AC's 2191 name 2193 4.4.5. AC Name with Index 2195 The AC Name with Index message element is sent by the AC to the WTP 2196 to configure preferred ACs. The number of instances where this 2197 message element would be present is equal to the number of ACs 2198 configured on the WTP. 2200 0 1 2201 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2203 | Index | AC Name... 2204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2206 Type: 5 for AC Name with Index 2208 Length: > 2 2210 Index: The index of the preferred server (e.g., 1=primary, 2211 2=secondary). 2213 AC Name: A variable length UTF-8 encoded string containing the AC's 2214 name. 2216 4.4.6. AC Timestamp 2218 The AC Timestamp message element is sent by the AC to synchronize the 2219 WTP's clock. 2221 0 1 2 3 2222 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 2223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2224 | Timestamp | 2225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2227 Type: 6 for AC Timestamp 2229 Length: 4 2231 Timestamp: The AC's current time, allowing all of the WTPs to be 2232 time synchronized in the format defined by Network Time Protocol 2233 (NTP) in RFC 1305 [3]. 2235 4.4.7. Add MAC ACL Entry 2237 The Add MAC Access Control List (ACL) Entry message element is used 2238 by an AC to add a MAC ACL list entry on a WTP, ensuring that the WTP 2239 no longer provides any service to the MAC addresses provided in the 2240 message. The MAC Addresses provided in this message element are not 2241 expected to be saved in non-volatile memory on the WTP. 2243 0 1 2 3 2244 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 2245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2246 | Num of Entries| MAC Address[] | 2247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2248 | MAC Address[] | 2249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2251 Type: 7 for Add MAC ACL Entry 2253 Length: >= 7 2255 Num of Entries: The number of MAC Addresses in the array. 2257 MAC Address: An array of MAC Addresses to add to the ACL. 2259 4.4.8. Add Station 2261 The Add Station message element is used by the AC to inform a WTP 2262 that it should forward traffic for a particular station. The Add 2263 Station message element will be accompanied by technology specific 2264 binding information element which may include security parameters. 2265 Consequently, the security parameters must be applied by the WTP for 2266 the particular station. 2268 Once a station's policy has been pushed to the WTP through this 2269 message element, an AC may change any policies by simply sending a 2270 modified Add Station message element. When a WTP receives an Add 2271 Station message element for an existing station, it must override any 2272 existing state it may have for the station in question. The latest 2273 Add Station message element data overrides any previously received 2274 messages. 2276 0 1 2 3 2277 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 2278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2279 | Radio ID | MAC Address | 2280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2281 | MAC Address | VLAN Name... 2282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2284 Type: 8 for Add Station 2285 Length: >= 7 2287 Radio ID: An 8-bit value representing the radio 2289 MAC Address: The station's MAC Address 2291 VLAN Name: An optional variable length UTF-8 encoded string 2292 containing the VLAN Name on which the WTP is to locally bridge 2293 user data. Note this field is only valid with WTPs configured in 2294 Local MAC mode. 2296 4.4.9. Add Static MAC ACL Entry 2298 The Add Static MAC ACL Entry message element is used by an AC to add 2299 a permanent ACL entry on a WTP, ensuring that the WTP no longer 2300 provides any service to the MAC addresses provided in the message. 2301 The MAC Addresses provided in this message element are expected to be 2302 saved in non-volative memory on the WTP. 2304 0 1 2 3 2305 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 2306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2307 | Num of Entries| MAC Address[] | 2308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2309 | MAC Address[] | 2310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2312 Type: 9 for Add Static MAC ACL Entry 2314 Length: >= 7 2316 Num of Entries: The number of MAC Addresses in the array. 2318 MAC Address: An array of MAC Addresses to add to the permanent ACL. 2320 4.4.10. CAPWAP Control IPv4 Address 2322 The CAPWAP Control IPv4 Address message element is sent by the AC to 2323 the WTP during the discovery process and is used by the AC to provide 2324 the interfaces available on the AC, and the current number of WTPs 2325 connected. In the event that multiple CAPWAP Control IPV4 Address 2326 message elements are returned, the WTP is expected to perform load 2327 balancing across the multiple interfaces. 2329 0 1 2 3 2330 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 2331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2332 | IP Address | 2333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2334 | WTP Count | 2335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2337 Type: 10 for CAPWAP Control IPv4 Address 2339 Length: 6 2341 IP Address: The IP Address of an interface. 2343 WTP Count: The number of WTPs currently connected to the interface. 2345 4.4.11. CAPWAP Control IPv6 Address 2347 The CAPWAP Control IPv6 Address message element is sent by the AC to 2348 the WTP during the discovery process and is used by the AC to provide 2349 the interfaces available on the AC, and the current number of WTPs 2350 connected. This message element is useful for the WTP to perform 2351 load balancing across multiple interfaces. 2353 0 1 2 3 2354 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 2355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2356 | IP Address | 2357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2358 | IP Address | 2359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2360 | IP Address | 2361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2362 | IP Address | 2363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2364 | WTP Count | 2365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2367 Type: 11 for CAPWAP Control IPv6 Address 2369 Length: 18 2371 IP Address: The IP Address of an interface. 2373 WTP Count: The number of WTPs currently connected to the interface. 2375 4.4.12. CAPWAP Timers 2377 The CAPWAP Timers message element is used by an AC to configure 2378 CAPWAP timers on a WTP. 2380 0 1 2381 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2383 | Discovery | Echo Request | 2384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2386 Type: 12 for CAPWAP Timers 2388 Length: 2 2390 Discovery: The number of seconds between CAPWAP Discovery packets, 2391 when the WTP is in the discovery mode. 2393 Echo Request: The number of seconds between WTP Echo Request CAPWAP 2394 messages. The default value for this message element can be found 2395 in Section 4.5.4. 2397 4.4.13. Data Transfer Data 2399 The Data Transfer Data message element is used by the WTP to provide 2400 information to the AC for debugging purposes. 2402 0 1 2 2403 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2405 | Data Type | Data Length | Data .... 2406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2408 Type: 13 for Data Transfer Data 2410 Length: >= 3 2412 Data Type: An 8-bit value the type of information being sent. The 2413 following values are supported: 2415 1 - WTP Crash Data 2417 2 - WTP Memory Dump 2419 Data Length: Length of data field. 2421 Data: Debug information. 2423 4.4.14. Data Transfer Mode 2425 The Data Transfer Mode message element is used by the WTP to indicate 2426 the type of data transfer information it is sending to the AC for 2427 debugging purposes. 2429 0 2430 0 1 2 3 4 5 6 7 2431 +-+-+-+-+-+-+-+-+ 2432 | Data Type | 2433 +-+-+-+-+-+-+-+-+ 2435 Type: 14 for Data Transfer Mode 2437 Length: 1 2439 Data Type: An 8-bit value the type of information being requested. 2440 The following values are supported: 2442 1 - WTP Crash Data 2444 2 - WTP Memory Dump 2446 4.4.15. Decryption Error Report 2448 The Decryption Error Report message element value is used by the WTP 2449 to inform the AC of decryption errors that have occurred since the 2450 last report. Note that this error reporting mechanism is not used if 2451 encryption and decryption services are provided via the AC. 2453 0 1 2 2454 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2456 | Radio ID |Num Of Entries | Station MAC Address | 2457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2458 | Station MAC Address[] | 2459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2461 Type: 15 for Decryption Error Report 2463 Length: >= 8 2464 Radio ID: The Radio Identifier, which typically refers to an 2465 interface index on the WTP 2467 Num Of Entries: An 8-bit unsigned integer indicating the number of 2468 station MAC addresses. 2470 Station MAC Address: An array of station MAC addresses that have 2471 caused decryption errors. 2473 4.4.16. Decryption Error Report Period 2475 The Decryption Error Report Period message element value is used by 2476 the AC to inform the WTP how frequently it should send decryption 2477 error report messages. 2479 0 1 2 2480 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2482 | Radio ID | Report Interval | 2483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2485 Type: 16 for Decryption Error Report Period 2487 Length: 3 2489 Radio ID: The Radio Identifier, typically refers to some interface 2490 index on the WTP 2492 Report Interval: A 16-bit unsigned integer indicating the time, in 2493 seconds. The default value for this message element can be found 2494 in Section 4.6.6. 2496 4.4.17. Delete MAC ACL Entry 2498 The Delete MAC ACL Entry message element is used by an AC to delete a 2499 MAC ACL entry on a WTP, ensuring that the WTP provides service to the 2500 MAC addresses provided in the message. 2502 0 1 2 3 2503 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 2504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2505 | Num of Entries| MAC Address[] | 2506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2507 | MAC Address[] | 2508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2510 Type: 17 for Delete MAC ACL Entry 2512 Length: >= 7 2514 Num of Entries: The number of MAC Addresses in the array. 2516 MAC Address: An array of MAC Addresses to delete from the ACL. 2518 4.4.18. Delete Station 2520 The Delete Station message element is used by the AC to inform an WTP 2521 that it should no longer provide service to a particular station. 2522 The WTP must terminate service immediately upon receiving this 2523 message element. 2525 The transmission of a Delete Station message element could occur for 2526 various reasons, including for administrative reasons, as a result of 2527 the fact that the station has roamed to another WTP, etc. 2529 0 1 2 3 2530 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2532 | Radio ID | MAC Address | 2533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2534 | MAC Address | 2535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2537 Type: 18 for Delete Station 2539 Length: 7 2541 Radio ID: An 8-bit value representing the radio 2543 MAC Address: The station's MAC Address 2545 4.4.19. Delete Static MAC ACL Entry 2547 The Delete Static MAC ACL Entry message element is used by an AC to 2548 delete a previously added static MAC ACL entry on a WTP, ensuring 2549 that the WTP provides service to the MAC addresses provided in the 2550 message. 2552 0 1 2 3 2553 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 2554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2555 | Num of Entries| MAC Address[] | 2556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2557 | MAC Address[] | 2558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2560 Type: 19 for Delete Static MAC ACL Entry 2562 Length: >= 7 2564 Num of Entries: The number of MAC Addresses in the array. 2566 MAC Address: An array of MAC Addresses to delete from the static 2567 MAC ACL entry. 2569 4.4.20. Discovery Type 2571 The Discovery Type message element is used by the WTP to indicate how 2572 it has come to know about the existence of the AC, to which it is 2573 sending the Discovery Request message. 2575 0 2576 0 1 2 3 4 5 6 7 2577 +-+-+-+-+-+-+-+-+ 2578 | Discovery Type| 2579 +-+-+-+-+-+-+-+-+ 2581 Type: 20 for Discovery Type 2583 Length: 1 2585 Discovery Type: An 8-bit value indicating how the WTP discovered 2586 the AC . The following values are supported: 2588 0 - Unknown 2590 1 - Static Configuration 2592 2 - DHCP 2594 3 - DNS 2596 4 - AC Referral 2598 4.4.21. Duplicate IPv4 Address 2600 The Duplicate IPv4 Address message element is used by a WTP to inform 2601 an AC that it has detected another IP device using the same IP 2602 address it is currently using. 2604 0 1 2 3 2605 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 2606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2607 | IP Address | 2608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2609 | MAC Address | 2610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2611 | MAC Address | 2612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2614 Type: 21 for Duplicate IPv4 Address 2616 Length: 10 2618 IP Address: The IP Address currently used by the WTP. 2620 MAC Address: The MAC Address of the offending device. 2622 4.4.22. Duplicate IPv6 Address 2624 The Duplicate IPv6 Address message element is used by a WTP to inform 2625 an AC that it has detected another host using the same IP address it 2626 is currently using. 2628 0 1 2 3 2629 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 2630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2631 | IP Address | 2632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2633 | IP Address | 2634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2635 | IP Address | 2636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2637 | IP Address | 2638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2639 | MAC Address | 2640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2641 | MAC Address | 2642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2644 Type: 22 for Duplicate IPv6 Address 2646 Length: 22 2648 IP Address: The IP Address currently used by the WTP. 2650 MAC Address: The MAC Address of the offending device. 2652 4.4.23. Idle Timeout 2654 The Idle Timeout message element is sent by the AC to the WTP to 2655 provide it with the idle timeout that it should enforce on its active 2656 station entries. The value applies for all radios on the WTP. 2658 0 1 2 3 2659 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 2660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2661 | Timeout | 2662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2664 Type: 23 for Idle Timeout 2666 Length: 4 2668 Timeout: The current idle timeout to be enforced by the WTP. The 2669 default value for this message element can be found in 2670 Section 4.6.3. 2672 4.4.24. Image Data 2674 The image data message element is present in the Image Data Request 2675 message sent by the AC and contains the following fields. 2677 0 1 2 3 2678 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2680 | Opcode | Checksum | Image Data | 2681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2682 | Image Data ... | 2683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2685 Type: 24 for Image Data 2687 Length: >= 4 (allows 0 length element if last data unit is 1024 2688 bytes) 2690 Opcode: An 8-bit value representing the transfer opcode. The 2691 following values are supported: 2693 3 - Image data is included 2694 5 - An error occurred. Transfer is aborted 2696 Checksum: A 16-bit value containing a checksum of the image data 2697 that follows 2699 Image Data: The Image Data field contains 1024 characters, unless 2700 the payload being sent is the last one (end of file). If the last 2701 block was 1024 in length, an Image Data with a zero length payload 2702 is sent. 2704 4.4.25. Image Filename 2706 The image filename message element is sent by the WTP to the AC and 2707 is used to initiate the firmware download process. This message 2708 element contains the image filename, which the AC subsequently 2709 transfers to the WTP via the Image Data message element. The value 2710 is a variable length UTF-8 encoded string, which is NOT zero 2711 terminated. 2713 0 1 2 3 2714 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 2715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2716 | Filename ... | 2717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2719 Type: 25 for Image Filename 2721 Length: >= 1 2723 Filename: A variable length UTF-8 encoded string containing the 2724 filename to download. 2726 4.4.26. Initiate Download 2728 The Initiate Download message element is used by the AC to inform the 2729 WTP that it should initiate a firmware upgrade. This is performed by 2730 having the WTP initiate its own Image Data Request, with the Image 2731 Download message element. This message element does not contain any 2732 data. 2734 Type: 24 for Initiate Download 2736 Length: 0 2738 4.4.27. Location Data 2740 The Location Data message element is a variable length byte UTF-8 2741 encoded string containing user defined location information (e.g. 2742 "Next to Fridge"). This information is configurable by the network 2743 administrator, and allows for the WTP location to be determined 2744 through this field. The string is not zero terminated. 2746 0 2747 0 1 2 3 4 5 6 7 2748 +-+-+-+-+-+-+-+-+- 2749 | Location ... 2750 +-+-+-+-+-+-+-+-+- 2752 Type: 27 for Location Data 2754 Length: > 0 2756 Location: A non-zero terminated UTF-8 encoded string containing the 2757 WTP location. 2759 4.4.28. MTU Discovery Padding 2761 The MTU Discovery Padding message element is used as padding to 2762 perform MTU discovery, and MUST contain octets of value 0xFF, of any 2763 length 2765 0 2766 0 1 2 3 4 5 6 7 2767 +-+-+-+-+-+-+-+-+ 2768 | Padding... 2769 +-+-+-+-+-+-+-+- 2771 Type: 28 for MTU Discovery Padding 2773 Length: variable 2775 Pad: A variable length pad. 2777 4.4.29. Radio Administrative State 2779 The radio administrative state message element is used to communicate 2780 the state of a particular radio. The configuration of the Radio 2781 Administrative State is sent by the AC to change the state of the 2782 WTP, which saves the value to ensure its effect remains across WTP 2783 resets. The WTP communicates this message element during the 2784 configuration phase to ensure that AC has the WTP radio's current 2785 administrative state settings. The value contains the following 2786 fields. 2788 0 1 2 2789 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2791 | Radio ID | Admin State | Cause | 2792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2794 Type: 29 for Administrative State 2796 Length: 2 2798 Radio ID: An 8-bit value representing the radio to configure. The 2799 Radio ID field may also include the value of 0xff, which is used 2800 to identify the WTP itself. Therefore, if an AC wishes to change 2801 the administrative state of a WTP, it would include 0xff in the 2802 Radio ID field. 2804 Admin State: An 8-bit value representing the administrative state 2805 of the radio. The default value for the Admin State field is 2806 listed in section Section 4.6.1. The following values are 2807 supported: 2809 1 - Enabled 2811 2 - Disabled 2813 Cause: In the event of a radio being inoperable, the cause field 2814 would contain the reason the radio is out of service. The 2815 following values are supported: 2817 0 - Normal 2819 1 - Radio Failure 2821 2 - Software Failure 2823 3 - Radar Detection 2825 4.4.30. Radio Operational State 2827 The Radio Operational State message element is sent by the WTP to the 2828 AC to communicate a change in the operational state of a radio. For 2829 instance, if the WTP were to detect that a hardware failure existed 2830 with a radio, which caused the radio to be taken offline, the WTP 2831 would indicate this event to the AC via the message element. The AC 2832 MAY also send this message element to change the operational state of 2833 a specific radio. Note that the operational state setting is not 2834 saved on the WTP, and therefore does not remain across WTP resets. 2835 The value contains two fields, as shown. 2837 0 1 2 2838 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2840 | Radio ID | State | Cause | 2841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2843 Type: 30 for Radio Operational State 2845 Length: 3 2847 Radio ID: The Radio Identifier, typically refers to some interface 2848 index on the WTP. A value of 0xFF is invalid, as it is not 2849 possible to change the WTP's operational state. 2851 State: An 8-bit boolean value representing the state of the radio. 2852 A value of one disables the radio, while a value of two enables 2853 it. 2855 Cause: In the event of a radio being inoperable, the cause field 2856 would contain the reason the radio is out of service. The 2857 following values are supported: 2859 0 - Normal 2861 1 - Radio Failure 2863 2 - Software Failure 2865 3 - Administratively Set 2867 4.4.31. Result Code 2869 The Result Code message element value is a 32-bit integer value, 2870 indicating the result of the request operation corresponding to the 2871 sequence number in the message. 2873 0 1 2 3 2874 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 2875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2876 | Result Code | 2877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2879 Type: 31 for Result Code 2881 Length: 4 2883 Result Code: The following values are defined: 2885 0 Success 2887 1 Failure (AC List message element MUST be present) 2889 2 Success (NAT detected) 2891 3 Failure (unspecified) 2893 4 Failure (Join Failure, Resource Depletion) 2895 5 Failure (Join Failure, Unknown Source) 2897 6 Failure (Join Failure, Incorrect Data) 2899 7 Failure (Join Failure, Session ID already in use) 2901 8 Failure (Join Failure, WTP Hardware not supported) 2903 9 Failure (Unable to Reset) 2905 4.4.32. Session ID 2907 The session ID message element value contains a randomly generated 2908 unsigned 32-bit integer. 2910 0 1 2 3 2911 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 2912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2913 | Session ID | 2914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2916 Type: 32 for Session ID 2918 Length: 4 2920 Session ID: A 32-bit random session identifier 2922 4.4.33. Statistics Timer 2924 The statistics timer message element value is used by the AC to 2925 inform the WTP of the frequency which it expects to receive updated 2926 statistics. 2928 0 1 2929 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2931 | Statistics Timer | 2932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2934 Type: 33 for Statistics Timer 2936 Length: 2 2938 Statistics Timer: A 16-bit unsigned integer indicating the time, in 2939 seconds. The default value for this timer can be found in section 2940 Section 4.6.8. 2942 4.4.34. Vendor Specific Payload 2944 The Vendor Specific Payload is used to communicate vendor specific 2945 information between the WTP and the AC. The value contains the 2946 following format: 2948 0 1 2 3 2949 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 2950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2951 | Vendor Identifier | 2952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2953 | Element ID | Value... | 2954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2956 Type: 34 for Vendor Specific 2958 Length: >= 7 2960 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 2961 Network Management Private Enterprise Codes" [12] 2963 Element ID: A 16-bit Element Identifier which is managed by the 2964 vendor. 2966 Value: The value associated with the vendor specific element. 2968 4.4.35. WTP Board Data 2970 The WTP Board Data message element is sent by the WTP to the AC and 2971 contains information about the hardware present. 2973 0 1 2 3 2974 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 2975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2976 | Vendor Identifier | 2977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2978 | Type=0 | Length | 2979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2980 | Value... 2981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2982 | Type=1 | Length | 2983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2984 | Value... 2985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2986 | Optional additional vendor specific WTP board data TLVs 2988 Type: 35 for WTP Board Data 2990 Length: >=14 2992 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 2993 Network Management Private Enterprise Codes" 2995 Type: The following values are supported: 2997 0 - WTP Model Number: The WTP Model Number MUST be included in 2998 the WTP Board Data message element. 3000 1 - WTP Serial Number: The WTP Serial Number MUST be included in 3001 the WTP Board Data message element. 3003 2 - Board ID: A hardware identifier, which MAY be included in 3004 the WTP Board Data mesage element. 3006 3 - Board Revision A revision number of the board, which MAY be 3007 included in the WTP Board Data message element. 3009 4.4.36. WTP Descriptor 3011 The WTP descriptor message element is used by a WTP to communicate 3012 it's current hardware/firmware configuration. The value contains the 3013 following fields. 3015 0 1 2 3 3016 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 3017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3018 | Max Radios | Radios in use | Encryption Capabilities | 3019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3020 | Vendor Identifier | 3021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3022 | Type=0 | Length | 3023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3024 | Value... 3025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3026 | Vendor Identifier | 3027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3028 | Type=1 | Length | 3029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3030 | Value... 3031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3032 | Vendor Identifier | 3033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3034 | Type=0 | Length | 3035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3036 | Value... 3037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3039 Type: 36 for WTP Descriptor 3041 Length: >= 31 3043 Max Radios: An 8-bit value representing the number of radios (where 3044 each radio is identified via the Radio ID, or RID, field) 3045 supported by the WTP 3047 Radios in use: An 8-bit value representing the number of radios 3048 present in the WTP 3050 Encryption Capabilities: This 16-bit field is used by the WTP to 3051 communicate it's capabilities to the AC. A WTP that does not have 3052 any encryption capabilities sets this field to zero (0). Refer to 3053 the specific wireless binding for further specification of the 3054 Encryption Capabilities field. 3056 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 3057 Network Management Private Enterprise Codes" 3059 Type: The following values are supported. The Hardware Version, 3060 Software Version, and Boot Version values MUST be included. 3062 0 - WTP Model Number: The WTP Model Number MUST be included in 3063 the WTP Board Data message element. 3065 1 - WTP Serial Number: The WTP Serial Number MUST be included in 3066 the WTP Board Data message element. 3068 2 - Board ID: A hardware identifier, which MAY be included in 3069 the WTP Board Data mesage element. 3071 3 - Board Revision A revision number of the board, which MAY be 3072 included in the WTP Board Data message element. 3074 4 - Hardware Version: The WTP's hardware version number. 3076 5 - Software Version: The WTP's Firmware version number. 3078 6 - Boot Version: The WTP's boot loader's version number. 3080 Length: Length of vendor specific encoding of WTP information. 3082 Value: Vendor specific data of WTP information encoded in the UTF-8 3083 format. 3085 4.4.37. WTP Fallback 3087 The WTP Fallback message element is sent by the AC to the WTP to 3088 enable or disable automatic CAPWAP fallback in the event that a WTP 3089 detects its preferred AC, and is not currently connected to it. 3091 0 3092 0 1 2 3 4 5 6 7 3093 +-+-+-+-+-+-+-+-+ 3094 | Mode | 3095 +-+-+-+-+-+-+-+-+ 3097 Type: 37 for WTP Fallback 3099 Length: 1 3101 Mode: The 8-bit value indicates the status of automatic CAPWAP 3102 fallback on the WTP. When enabled, if the WTP detects that its 3103 primary AC is available, and it is not connected to it, it SHOULD 3104 automatically disconnect from its current AC and reconnect to its 3105 primary. If disabled, the WTP will only reconnect to its primary 3106 through manual intervention (e.g., through the Reset Request 3107 command). The default value for this field can be found in 3108 section Section 4.6.9. The following values are supported: 3110 1 - Enabled 3112 2 - Disabled 3114 4.4.38. WTP Frame Tunnel Mode 3116 The WTP Frame Tunnel Mode message element allows the WTP to 3117 communicate the tunneling modes of operation which it supports to the 3118 AC. A WTP that advertises support for all types allows the AC to 3119 select which type will be used, based on its local policy. 3121 0 3122 0 1 2 3 4 5 6 7 3123 +-+-+-+-+-+-+-+-+ 3124 | Tunnel Mode | 3125 +-+-+-+-+-+-+-+-+ 3127 Type: 38 for WTP Frame Tunnel Mode 3129 Length: 1 3131 Frame Tunnel Mode: The Frame Tunnel mode specifies the tunneling 3132 modes for station data which are supported by the WTP. The 3133 following values are supported: 3135 1 - Local Bridging: When Local Bridging is used, the WTP does 3136 not tunnel user traffic to the AC; all user traffic is locally 3137 bridged. This value MUST NOT be used when the WTP MAC Type is 3138 set to Split-MAC. 3140 2 - 802.3 Frame Tunnel Mode: The 802.3 Frame Tunnel Mode 3141 requires the WTP and AC to encapsulate all user payload as 3142 native IEEE 802.3 frames (see Section 4.2). All user traffic 3143 is tunneled to the AC. This value MUST NOT be used when the 3144 WTP MAC Type is set to Split-MAC. 3146 4 - Native Frame Tunnel Mode: Native Frame Tunnel mode requires 3147 the WTP and AC to encapsulate all user payloads as native 3148 wireless frames, as defined by the wireless binding (see for 3149 example Section 4.2). 3151 7 - All: The WTP is capable of supporting all frame tunnel 3152 modes. 3154 4.4.39. WTP IPv4 IP Address 3156 The WTP IPv4 address is used to perform NAT detection. 3158 0 1 2 3 3159 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 3160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3161 | WTP IPv4 IP Address | 3162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3164 Type: 39 for WTP IPv4 IP Address 3166 Length: 4 3168 WTP IPv4 IP Address: The IPv4 address from which the WTP is sending 3169 packets. This field is used for NAT detection. 3171 4.4.40. WTP MAC Type 3173 The WTP MAC-Type message element allows the WTP to communicate its 3174 mode of operation to the AC. A WTP that advertises support for both 3175 modes allows the AC to select the mode to use, based on local policy. 3177 0 3178 0 1 2 3 4 5 6 7 3179 +-+-+-+-+-+-+-+-+ 3180 | MAC Type | 3181 +-+-+-+-+-+-+-+-+ 3183 Type: 40 for WTP MAC Type 3185 Length: 1 3187 MAC Type: The MAC mode of operation supported by the WTP. The 3188 following values are supported 3190 0 - Local-MAC: Local-MAC is the default mode that MUST be 3191 supported by all WTPs. 3193 1 - Split-MAC: Split-MAC support is optional, and allows the AC 3194 to receive and process native wireless frames. 3196 2 - Both: WTP is capable of supporting both Local-MAC and Split- 3197 MAC. 3199 4.4.41. WTP Name 3201 The WTP Name message element is a variable length byte UTF-8 encoded 3202 string. The string is not zero terminated. 3204 0 3205 0 1 2 3 4 5 6 7 3206 +-+-+-+-+-+-+-+-+- 3207 | WTP Name ... 3208 +-+-+-+-+-+-+-+-+- 3210 Type: 41 for WTP Name 3212 Length: variable 3214 WTP Name: A non-zero terminated UTF-8 encoded string containing the 3215 WTP name. 3217 4.4.42. WTP Operational Statistics 3219 The WTP Operational Statistics message element is sent by the WTP to 3220 the AC to provide statistics related to the operation of the WTP. 3222 0 1 2 3 3223 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 3224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3225 | Radio ID | Tx Queue Level | Wireless Link Frames per Sec | 3226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3228 Type: 42 for WTP Operational Statistics 3230 Length: 4 3232 Radio ID: The radio ID of the radio to which the statistics apply. 3234 Wireless Transmit Queue Level: The percentage of Wireless Transmit 3235 queue utilization, calaculated as the sum of utilized transmit 3236 queue lengths divided by the sum of maximum transmit queue 3237 lengths, multiplied by 100. The Wireless Transmit Queue Level is 3238 representative of congestion conditions over wireless interfaces 3239 between the WTP and wireless terminals. 3241 Wireless Link Frames per Sec: The number of frames transmitted or 3242 received per second by the WTP over the air interface. 3244 4.4.43. WTP Radio Statistics 3246 The WTP Radio Statistics message element is sent by the WTP to the AC 3247 to communicate statistics on radio behavior and reasons why the WTP 3248 radio has been reset. 3250 0 1 2 3 3251 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 3252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3253 | Radio ID | Last Fail Type| Reset Count | 3254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3255 | SW Failure Count | HW Failure Count | 3256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3257 | Other Failure Count | Unknown Failure Count | 3258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3259 | Config Update Count | Channel Change Count | 3260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3261 | Band Change Count | Current Noise Floor | 3262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3264 Type: 43 for WTP Radio Statistics 3266 Length: 20 3268 Radio ID: The radio ID of the radio to which the statistics apply. 3270 Last Failure Type: The last WTP failure. The following values are 3271 supported: 3273 0 - Statistic Not Supported 3275 1 - Software Failure 3277 2 - Hardware Failure 3279 3 - Other Failure 3281 255 - Unknown (e.g., WTP doesn't keep track of info) 3283 Reset Count: The number of times that that the radio has been 3284 reset. 3286 SW Failure Count: The number of times that the radio has failed due 3287 to software related reasons. 3289 HW Failure Count: The number of times that the radio has failed due 3290 to hardware related reasons. 3292 Other Failure Count: The number of times that the radio has failed 3293 due to known reasons, other than software or hardware failure. 3295 Unknown Failure Count: The number of times that the radio has 3296 failed for unknown reasons. 3298 Config Update Count: The number of times that the radio 3299 configuration has been updated. 3301 Channel Change Count: The number of times that the radio channel 3302 has been changed. 3304 Band Change Count: The number of times that the radio has changed 3305 frequency bands. 3307 Current Noise Floor: A signed integer which indicates the noise 3308 floor of the radio receiver in units of dBm. 3310 4.4.44. WTP Reboot Statistics 3312 The WTP Reboot Statistics message element is sent by the WTP to the 3313 AC to communicate reasons why WTP reboots have occurred. 3315 0 1 2 3 3316 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 3317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3318 | Reboot Count | AC Initiated Count | 3319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3320 | Link Failure Count | SW Failure Count | 3321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3322 | HW Failure Count | Other Failure Count | 3323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3324 | Unknown Failure Count |Last Failure Type| 3325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3327 Type: 44 for WTP Reboot Statistics 3329 Length: 15 3331 Reboot Count: The number of reboots that have occurred due to a WTP 3332 crash. A value of 65535 implies that this information is not 3333 available on the WTP. 3335 AC Initiated Count: The number of reboots that have occurred at the 3336 request of a CAPWAP protocol message, such as a change in 3337 configuration that required a reboot or an explicit CAPWAP 3338 protocol reset request. A value of 65535 implies that this 3339 information is not available on the WTP. 3341 Link Failure Count: The number of times that a CAPWAP protocol 3342 connection with an AC has failed due to link failure. 3344 SW Failure Count: The number of times that a CAPWAP protocol 3345 connection with an AC has failed due to software related reasons. 3347 HW Failure Count: The number of times that a CAPWAP protocol 3348 connection with an AC has failed due to hardware related reasons. 3350 Other Failure Count: The number of times that a CAPWAP protocol 3351 connection with an AC has failed due to known reasons, other than 3352 AC initiated, link, SW or HW failure. 3354 Unknown Failure Count: The number of times that a CAPWAP protocol 3355 connection with an AC has failed for unknown reasons. 3357 Last Failure Type: The failure type of the most recent WTP failure. 3358 The following values are supported: 3360 0 - Not Supported 3362 1 - AC Initiated (see Section 9.3) 3364 2 - Link Failure 3366 3 - Software Failure 3368 4 - Hardware Failure 3370 5 - Other Failure 3372 255 - Unknown (e.g., WTP doesn't keep track of info) 3374 4.4.45. WTP Static IP Address Information 3376 The WTP Static IP Address Information message element is used by an 3377 AC to configure or clear a previously configured static IP address on 3378 a WTP. 3380 0 1 2 3 3381 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 3382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3383 | IP Address | 3384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3385 | Netmask | 3386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3387 | Gateway | 3388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3389 | Static | 3390 +-+-+-+-+-+-+-+-+ 3392 Type: 45 for WTP Static IP Address Information 3394 Length: 13 3396 IP Address: The IP Address to assign to the WTP. This field is 3397 only valid if the static field is set to one. 3399 Netmask: The IP Netmask. This field is only valid if the static 3400 field is set to one. 3402 Gateway: The IP address of the gateway. This field is only valid 3403 if the static field is set to one. 3405 Netmask: The IP Netmask. This field is only valid if the static 3406 field is set to one. 3408 Static: An 8-bit boolean stating whether the WTP should use a 3409 static IP address or not. A value of zero disables the static IP 3410 address, while a value of one enables it. 3412 4.5. CAPWAP Protocol Timers 3414 A WTP or AC that implements CAPWAP discovery MUST implement the 3415 following timers. 3417 4.5.1. DiscoveryInterval 3419 The minimum time, in seconds, that a WTP MUST wait after receiving a 3420 Discovery Response, before initiating a DTLS handshake. 3422 Default: 5 3424 4.5.2. DTLSRehandshake 3426 The minimum time, in seconds, a WTP MUST wait for DTLS rehandshake to 3427 complete. 3429 Default: 10 3431 4.5.3. DTLSSessionDelete 3433 The minimum time, in seconds, a WTP MUST wait for DTLS session 3434 deletion. 3436 Default: 5 3438 4.5.4. EchoInterval 3440 The minimum time, in seconds, between sending echo requests to the AC 3441 with which the WTP has joined. 3443 Default: 30 3445 4.5.5. KeyLifetime 3447 The maximum time, in seconds, which a CAPWAP DTLS session key is 3448 valid. 3450 Default: 28800 3452 4.5.6. MaxDiscoveryInterval 3454 The maximum time allowed between sending discovery requests from the 3455 interface, in seconds. Must be no less than 2 seconds and no greater 3456 than 180 seconds. 3458 Default: 20 seconds. 3460 4.5.7. NeighborDeadInterval 3462 The minimum time, in seconds, a WTP MUST wait without having received 3463 Echo Responses to its Echo Requests, before the destination for the 3464 Echo Request may be considered dead. Must be no less than 3465 2*EchoInterval seconds and no greater than 240 seconds. 3467 Default: 60 3469 4.5.8. ResponseTimeout 3471 The minimum time, in seconds, which the WTP or AC must respond to a 3472 CAPWAP Request message. 3474 Default: 1 3476 4.5.9. RetransmitInterval 3478 The minimum time, in seconds, which a non-acknowledged CAPWAP packet 3479 will be retransmitted. 3481 Default: 3 3483 4.5.10. SilentInterval 3485 The minimum time, in seconds, a WTP MUST wait after failing to 3486 receive any responses to its discovery requests, before it MAY again 3487 send discovery requests. 3489 Default: 30 3491 4.5.11. WaitJoin 3493 The maximum time, in seconds, a WTP MUST wait without having received 3494 a DTLS Handshake message from an AC. This timer must be greater than 3495 30 seconds. 3497 Default: 60 3499 4.6. CAPWAP Protocol Variables 3501 A WTP or AC that implements CAPWAP discovery MUST allow for the 3502 following variables to be configured by system management; default 3503 values are specified, making explicit configuration unnecessary in 3504 many cases. If the default values are explicitly overriden by the 3505 AC, the WTP MUST save the values sent by the AC. 3507 4.6.1. AdminState 3509 The default Administrative State value is enabled (1). 3511 4.6.2. DiscoveryCount 3513 The number of discoveries transmitted by a WTP to a single AC. This 3514 is a monotonically increasing counter. 3516 4.6.3. IdleTimeout 3518 The default Idle Timeout is 300 seconds. 3520 4.6.4. MaxDiscoveries 3522 The maximum number of discovery requests that will be sent after a 3523 WTP boots. 3525 Default: 10 3527 4.6.5. MaxRetransmit 3529 The maximum number of retransmissions for a given CAPWAP packet 3530 before the link layer considers the peer dead. 3532 Default: 5 3534 4.6.6. ReportInterval 3536 The default Report Interval is 120 seconds. 3538 4.6.7. RetransmitCount 3540 The number of retransmissions for a given CAPWAP packet. This is a 3541 monotonically increasing counter. 3543 4.6.8. StatisticsTimer 3545 The default Statistics Interval is 120 seconds. 3547 4.6.9. WTPFallBack 3549 The default WTP Fallback value is enabled (1). 3551 4.7. WTP Saved Variables 3553 In addition to the values defined in Section 4.6, the following 3554 values SHOULD be saved on the WTP in non-volatile memory. CAPWAP 3555 wireless bindings may define additional values that SHOULD be stored 3556 on the WTP. 3558 4.7.1. AdminRebootCount 3560 The number of times the WTP has rebooted administratively, defined in 3561 Section 4.4.44. 3563 4.7.2. FrameEncapType 3565 For WTPs that support multiple Frame Encapsulation Types, it is 3566 useful to save the value configured by the AC. The Frame 3567 Encapsulation Type is defined in Section 4.4.38. 3569 4.7.3. LastRebootReason 3571 The reason why the WTP last rebooted, defined in Section 4.4.44. 3573 4.7.4. MacType 3575 For WTPs that support multiple MAC Types, it is usefule to save the 3576 value configured by the AC. The MAC Type is defined in 3577 Section 4.4.40. 3579 4.7.5. PreferredACs 3581 The preferred ACs, with the index, defined in Section 4.4.5. 3583 4.7.6. RebootCount 3585 The number of times the WTP has rebooted, defined in Section 4.4.44. 3587 4.7.7. Static ACL Table 3589 The static ACL table saved on the WTP, as configured by the Add 3590 Static MAC ACL Entry message element, see Section 4.4.9. 3592 4.7.8. Static IP Address 3594 The static IP Address assigned to the WTP, as configured by the 3595 message element, see Section 4.4.45. 3597 4.7.9. WTPLinkFailureCount 3599 The number of times the link to the AC has failed, see 3600 Section 4.4.44. 3602 4.7.10. WTPLocation 3604 The WTP Location, defined in Section 4.4.27. 3606 4.7.11. WTPName 3608 The WTP Name, defined in Section 4.4.41. 3610 5. CAPWAP Discovery Operations 3612 The Discovery messages are used by a WTP to determine which ACs are 3613 available to provide service, and the capabilities and load of the 3614 ACs. 3616 5.1. Discovery Request Message 3618 The Discovery Request message is used by the WTP to automatically 3619 discover potential ACs available in the network. The Discovery 3620 Request message provides ACs with the primary capabilities of the 3621 WTP. A WTP must exchange this information to ensure subsequent 3622 exchanges with the ACs are consistent with the WTP's functional 3623 characteristics. A WTP must transmit this command even if it has a 3624 statically configured AC. 3626 Discovery Request messages MUST be sent by a WTP in the Discover 3627 state after waiting for a random delay less than 3628 MaxDiscoveryInterval, after a WTP first comes up or is 3629 (re)initialized. A WTP MUST send no more than the maximum of 3630 MaxDiscoveries Discovery Request messages, waiting for a random delay 3631 less than MaxDiscoveryInterval between each successive message. 3633 This is to prevent an explosion of WTP Discovery Request messages. 3634 An example of this occurring is when many WTPs are powered on at the 3635 same time. 3637 Discovery Request messages MUST be sent by a WTP when no Echo 3638 Response messages are received for NeighborDeadInterval and the WTP 3639 returns to the Idle state. Discovery Request messages are sent after 3640 NeighborDeadInterval. They MUST be sent after waiting for a random 3641 delay less than MaxDiscoveryInterval. A WTP MAY send up to a maximum 3642 of MaxDiscoveries Discovery Request messages, waiting for a random 3643 delay less than MaxDiscoveryInterval between each successive message. 3645 If a Discovery Response message is not received after sending the 3646 maximum number of Discovery Request messages, the WTP enters the 3647 Sulking state and MUST wait for an interval equal to SilentInterval 3648 before sending further Discovery Request messages. 3650 The Discovery Request message may be sent as a unicast, broadcast or 3651 multicast message. 3653 Upon receiving a Discovery Request message, the AC will respond with 3654 a Discovery Response message sent to the address in the source 3655 address of the received discovery request message. 3657 The following message elements MUST be included in the Discovery 3658 Request message: 3660 o Discovery Type, see Section 4.4.20 3662 o WTP Descriptor, see Section 4.4.36 3664 o WTP Frame Tunnel Mode, see Section 4.4.38 3666 o WTP MAC Type, see Section 4.4.40 3668 5.2. Discovery Response Message 3670 The Discovery Response message provides a mechanism for an AC to 3671 advertise its services to requesting WTPs. 3673 The Discovery Response message is sent by an AC after receiving a 3674 Discovery Request message from a WTP. 3676 When a WTP receives a Discovery Response message, it MUST wait for an 3677 interval not less than DiscoveryInterval for receipt of additional 3678 Discovery Response messages. After the DiscoveryInterval elapses, 3679 the WTP enters the DTLS-Init state and selects one of the ACs that 3680 sent a Discovery Response message and send a DTLS Handshake to that 3681 AC. 3683 The following message elements MUST be included in the Discovery 3684 Response Message: 3686 o AC Descriptor, see Section 4.4.1 3688 o AC Name, see Section 4.4.4 3690 o CAPWAP Control IPv4 Address, see Section 4.4.10 3692 o CAPWAP Control IPv6 Address, see Section 4.4.11 3694 5.3. Primary Discovery Request Message 3696 The Primary Discovery Request message is sent by the WTP to determine 3697 whether its preferred (or primary) AC is available. 3699 A Primary Discovery Request message is sent by a WTP when it has a 3700 primary AC configured, and is connected to another AC. This 3701 generally occurs as a result of a failover, and is used by the WTP as 3702 a means to discover when its primary AC becomes available. As a 3703 consequence, this message is only sent by a WTP when it is in the Run 3704 state. 3706 The frequency of the Primary Discovery Request messages should be no 3707 more often than the sending of the Echo Request message. 3709 Upon receipt of a Discovery Request message, the AC responds with a 3710 Primary Discovery Response message sent to the address in the source 3711 address of the received Primary Discovery Request message. 3713 The following message elements MUST be included in the Primary 3714 Discovery Request message. 3716 o Discovery Type, see Section 4.4.20 3718 o WTP Descriptor, see Section 4.4.36 3720 o WTP Frame Tunnel Mode, see Section 4.4.38 3722 o WTP MAC Type, see Section 4.4.40 3724 5.4. Primary Discovery Response 3726 The Primary Discovery Response message enables an AC to advertise its 3727 availability and services to requesting WTPs that are configured to 3728 have the AC as its primary AC. 3730 The Primary Discovery Response message is sent by an AC after 3731 receiving a Primary Discovery Request message. 3733 When a WTP receives a Primary Discovery Response message, it may 3734 establish a CAPWAP protocol connection to its primary AC, based on 3735 the configuration of the WTP Fallback Status message element on the 3736 WTP. 3738 The following message elements MUST be included in the Primary 3739 Discovery Response message. 3741 o AC Descriptor, see Section 4.4.1 3743 o AC Name, see Section 4.4.4 3745 o CAPWAP Control IPv4 Address, see Section 4.4.10 3747 o CAPWAP Control IPv6 Address, see Section 4.4.11 3749 6. CAPWAP Join Operations 3751 The Join Request message is used by a WTP to request service from an 3752 AC after a DTLS connection is established to that AC. The Join 3753 Response message is used by the the AC to indicate that it will or 3754 will not provide service. 3756 6.1. Join Request 3758 The Join Request message is used by a WTP to inform an AC that it 3759 wishes to provide services through the AC. A Join Request message is 3760 sent by a WTP after (optionally) receiving one or more Discovery 3761 Responses, and completion of DTLS session establishment. When an AC 3762 receives a Join Request message it responds with a Join Response 3763 message. 3765 Upon completion of the DTLS handshake (synonymous with DTLS "session 3766 establishment"), the WTP sends the Join Request message to the AC. 3767 Upon receipt of the Join Request Message, the AC generates a Join 3768 Response message and sends it to the WTP, indicating success or 3769 failure. 3771 If the AC rejects the Join Request, it sends a Join Response message 3772 with a failure indication then enters the CAPWAP reset state, 3773 resulting in shutdown of the DTLS session. 3775 If an invalid (i.e. malformed) Join Request message is received, the 3776 message MUST be silently discarded by the AC. No response is sent to 3777 the WTP. The AC SHOULD log this event. 3779 The following message elements MUST be included in the Join Request 3780 message. 3782 o Location Data, see Section 4.4.27 3784 o Session ID, see Section 4.4.32 3786 o WTP Descriptor, see Section 4.4.36 3788 o WTP IPv4 IP Address, see Section 4.4.39 3790 o WTP Name, see Section 4.4.41 3792 6.2. Join Response 3794 The Join Response message is sent by the AC to indicate to a WTP that 3795 it is capable and willing to provide service to it. 3797 Upon receipt of the DTLSClientHello, the AC creates session state 3798 containing the WTP address, port and session ID, sets the WaitJoin 3799 timer for the session, sends the Join Response message to the WTP. 3801 The WTP, receiving a Join Response message checks for success or 3802 failure. If the message indicates success, the WTP clears the 3803 WaitJoin timer for the session and proceeds to the Configure state. 3804 Otherwise, the WTP enters the CAPWAP reset state, resulting in 3805 shutdown of the DTLS session. 3807 If the WaitJoin Timer expires prior to reception of the Join Response 3808 message, the WTP MUST terminate the handshake, deallocate associated 3809 session state and transition to the Discover state. 3811 If an invalid (malformed) Join Response message is received, the WTP 3812 SHOULD log an informative message detailing the error. This error 3813 MUST be treated in the same manner as AC non-responsiveness. In this 3814 way, the WaitJoin timer will eventually expire, in which case the WTP 3815 may (if it is so configured) attempt to join with an alternative AC. 3817 The following message elements MAY be included in the Join Response 3818 message. 3820 o AC IPv4 List, see Section 4.4.2 3822 o AC IPv6 List, see Section 4.4.3 3824 o Result Code, see Section 4.4.31 3826 o Session ID, see Section 4.4.32 3828 The following message element MUST be included in the Join Response 3829 message. 3831 o AC Descriptor, see Section 4.4.1 3833 7. Control Channel Management 3835 The Control Channel Management messages are used by the WTP and AC to 3836 maintain a control communication channel. CAPWAP control messages, 3837 such as the WTP Event Request message sent from the WTP to the AC 3838 indicate to the AC that the WTP is operational. When such control 3839 messages are not being sent, the Echo Request and Echo Response 3840 messages are used to maintain the control communication channel. 3842 7.1. Echo Request 3844 The Echo Request message is a keep alive mechanism for CAPWAP control 3845 messages. 3847 Echo Request messages are sent periodically by a WTP in the Run state 3848 (see Section 2.3) to determine the state of the connection between 3849 the WTP and the AC. The Echo Request message is sent by the WTP when 3850 the Heartbeat timer expires. The WTP MUST start its 3851 NeighborDeadInterval timer when the Heartbeat timer expires. 3853 The Echo Request message carries no message elements. 3855 When an AC receives an Echo Request message it responds with an Echo 3856 Response message. 3858 7.2. Echo Response 3860 The Echo Response message acknowledges the Echo Request message, and 3861 is only processed while in the Run state (see Section 2.3). 3863 An Echo Response message is sent by an AC after receiving an Echo 3864 Request message. After transmitting the Echo Response message, the 3865 AC SHOULD reset its Heartbeat timer to expire in the value configured 3866 for EchoInterval. If another Echo Request message or other control 3867 message is not received by the AC when the timer expires, the AC 3868 SHOULD consider the WTP to be no longer be reachable. 3870 The Echo Response message carries no message elements. 3872 When a WTP receives an Echo Response message it stops the 3873 NeighborDeadInterval timer, and initializes the Heartbeat timer to 3874 the EchoInterval. 3876 If the NeighborDeadInterval timer expires prior to receiving an Echo 3877 Response message, or other control message, the WTP enters the Idle 3878 state. 3880 8. WTP Configuration Management 3882 Wireless Termination Point Configuration messages are used to 3883 exchange configuration information between the AC and the WTP. 3885 8.1. Configuration Consistency 3887 The CAPWAP protocol provides flexibility in how WTP configuration is 3888 managed. A WTP has two options: 3890 1. The WTP retains no configuration and accepts the configuration 3891 provided by the AC. 3893 2. The WTP retains the configuration of parameters provided by the AC 3894 that are non-default values. 3896 If the WTP opts to save configuration locally, the CAPWAP protocol 3897 state machine defines the Configure state, which allows for 3898 configuration exchange. In the Configure state, the WTP sends its 3899 current configuration overrides to the AC via the Configuration 3900 Status message. A configuration override is a parameter that is non- 3901 default. One example is that in the CAPWAP protocol, the default 3902 antenna configuration is internal omni antenna. A WTP that either 3903 has no internal antennas, or has been explicitly configured by the AC 3904 to use external antennas, sends its antenna configuration during the 3905 configure phase, allowing the AC to become aware of the WTP's current 3906 configuration. 3908 Once the WTP has provided its configuration to the AC, the AC sends 3909 its own configuration. This allows the WTP to inherit the 3910 configuration and policies from the AC. 3912 An AC maintains a copy of each active WTP's configuration. There is 3913 no need for versioning or other means to identify configuration 3914 changes. If a WTP becomes inactive, the AC MAY delete the 3915 configuration associated with it. If a WTP fails, and connects to a 3916 new AC, it provides its overridden configuration parameters, allowing 3917 the new AC to be aware of the WTP's configuration. 3919 This model allows for resiliency in case of an AC failure, that 3920 another AC can provide service to the WTP. In this scenario, the new 3921 AC would be automatically updated with WTP configuration changes, 3922 eliminating the need for inter-AC communication or the need for all 3923 ACs to be aware of the configuration of all WTPs in the network. 3925 Once the CAPWAP protocol enters the Run state, the WTPs begin to 3926 provide service. It is quite common for administrators to require 3927 that configuration changes be made while the network is operational. 3929 Therefore, the Configuration Update Request is sent by the AC to the 3930 WTP to make these changes at run-time. 3932 8.1.1. Configuration Flexibility 3934 The CAPWAP protocol provides the flexibility to configure and manage 3935 WTPs of varying design and functional characteristics. When a WTP 3936 first discovers an AC, it provides primary functional information 3937 relating to its type of MAC and to the nature of frames to be 3938 exchanged. The AC configures the WTP appropriately. The AC also 3939 establishes corresponding internal operations to deal with the WTP 3940 according to its functionalities. 3942 8.2. Configuration Status 3944 The Configuration Status message is sent by a WTP to deliver its 3945 current configuration to its AC. 3947 Configuration Status messages are sent by a WTP while in the 3948 Configure state. 3950 The Configuration Status message carries binding specific message 3951 elements. Refer to the appropriate binding for the definition of 3952 this structure. 3954 When an AC receives a Configuration Status message it will act upon 3955 the content of the packet and respond to the WTP with a Configuration 3956 Status Response message. 3958 The Configuration Status message includes multiple Radio 3959 Administrative State message Elements. There is one such message 3960 element for the WTP, and one message element per radio in the WTP. 3962 The following message elements MUST be included in the Configuration 3963 Status message. 3965 o AC Name, see Section 4.4.4 3967 o AC Name with Index, see Section 4.4.5 3969 o Radio Administrative State, see Section 4.4.29 3971 o Statistics Timer, see Section 4.4.33 3973 o WTP Board Data, see Section 4.4.35 3975 o WTP Reboot Statistics, see Section 4.4.44 3976 The following message elements MAY be included in the Configuration 3977 Status message. 3979 o WTP Static IP Address Information, see Section 4.4.45 3981 8.3. Configuration Status Response 3983 The Configuration Status Response message is sent by an AC and 3984 provides a mechanism for the AC to override a WTP's requested 3985 configuration. 3987 Configuration Status Response messages are sent by an AC after 3988 receiving a Configure Request message. 3990 The Configuration Status Response message carries binding specific 3991 message elements. Refer to the appropriate binding for the 3992 definition of this structure. 3994 When a WTP receives a Configuration Status Response message it acts 3995 upon the content of the message, as appropriate. If the 3996 Configuration Status Response message includes a Radio Operational 3997 State message element that causes a change in the operational state 3998 of one of the Radio, the WTP will transmit a Change State Event to 3999 the AC, as an acknowledgement of the change in state. 4001 The following message elements MUST be included in the Configuration 4002 Status Response message. 4004 o AC IPv4 List, see Section 4.4.2 4006 o AC IPv6 List, see Section 4.4.3 4008 o CAPWAP Timers, see Section 4.4.12 4010 o Radio Operational Event, see Section 4.4.30 4012 o Decryption Error Report Period, see Section 4.4.16 4014 o Idle Timeout, see Section 4.4.23 4016 o WTP Fallback, see Section 4.4.37 4018 8.4. Configuration Update Request 4020 Configuration Update Request messages are sent by the AC to provision 4021 the WTP while in the Run state. This is used to modify the 4022 configuration of the WTP while it is operational. 4024 When an AC receives a Configuration Update Request message it will 4025 respond with a Configuration Update Response message, with the 4026 appropriate Result Code. 4028 One or more of the following message elements MAY be included in the 4029 Configuration Update message. 4031 o AC Name with Index, see Section 4.4.5 4033 o AC Timestamp, see Section 4.4.6 4035 o Add MAC ACL Entry, see Section 4.4.7 4037 o Add Static MAC ACL Entry, see Section 4.4.9 4039 o CAPWAP Timers, see Section 4.4.12 4041 o Decryption Error Report Period, see Section 4.4.16 4043 o Delete MAC ACL Entry, see Section 4.4.17 4045 o Delete Static MAC ACL Entry, see Section 4.4.19 4047 o Idle Timeout, see Section 4.4.23 4049 o Location Data, see Section 4.4.27 4051 o Radio Operational State, see Section 4.4.30 4053 o Statistics Timer, see Section 4.4.33 4055 o WTP Fallback, see Section 4.4.37 4057 o WTP Name, see Section 4.4.41 4059 8.5. Configuration Update Response 4061 The Configuration Update Response message is the acknowledgement 4062 message for the Configuration Update Request message. 4064 The Configuration Update Response message is sent by a WTP after 4065 receiving a Configuration Update Request message. 4067 When an AC receives a Configuration Update Response message the 4068 result code indicates if the WTP successfully accepted the 4069 configuration. 4071 The following message element MUST be present in the Configuration 4072 Update message. 4074 Result Code, see Section 4.4.31 4076 8.6. Change State Event Request 4078 The Change State Event Request message is used by the WTP to inform 4079 the AC of a change in the one of the WTP radio's operational state. 4081 The Change State Event Request message MUST sent by the WTP when it 4082 receives a Configuration Response message that includes a Radio 4083 Operational State message element. It is also sent when the WTP 4084 detects an operational failure with a radio. The Change State Event 4085 Request message may be sent in either the Configure or Run state (see 4086 Section 2.3. 4088 When an AC receives a Change State Event Request message it will 4089 respond with a Change State Event Response message and make any 4090 necessary modifications to internal WTP data structures. 4092 The following message elements MUST be present in the Change State 4093 Event Request message. 4095 o Radio Operational State message element, see Section 4.4.30 4097 8.7. Change State Event Response 4099 The Change State Event Response message acknowledges the Change State 4100 Event Request message. 4102 A Change State Event Response message is sent by an AC in response to 4103 a Change State Event Request message. 4105 The Change State Event Response message carries no message elements. 4106 Its purpose is to acknowledge the receipt of the Change State Event 4107 Request message. 4109 The WTP does not need to perform any special processing of the Change 4110 State Event Response message. 4112 8.8. Clear Configuration Request 4114 The Clear Configuration Request message is used to reset a WTP's 4115 configuration. 4117 The Clear Configuration Request message is sent by an AC to request 4118 that a WTP reset its configuration to the manufacturing default 4119 configuration. The Clear Config Request message is sent while in the 4120 Run CAPWAP state. 4122 The Clear Configuration Request message carries no message elements. 4124 When a WTP receives a Clear Configuration Request message it resets 4125 its configuration to the manufacturing default configuration. 4127 8.9. Clear Configuration Response 4129 The Clear Configuration Response message is sent by the WTP after 4130 receiving a Clear Configuration Request message and resetting its 4131 configuration parameters back to the manufacturing default values. 4133 The Clear Configuration Request message carries the message elements. 4135 o Result Code, see Section 4.4.31 4137 9. Device Management Operations 4139 This section defines CAPWAP operations responsible for debugging, 4140 gathering statistics, logging, and firmware management. 4142 9.1. Image Data Request 4144 The Image Data Request message is used to update firmware on the WTP. 4145 This message and its companion response message are used by the AC to 4146 ensure that the image being run on each WTP is appropriate. 4148 Image Data Request messages are exchanged between the WTP and the AC 4149 to download a new firmware image to the WTP. When a WTP or AC 4150 receives an Image Data Request message it will respond with an Image 4151 Data Response message. The message elements contained within the 4152 Image Data Request is required in order to determine the intent of 4153 the request. Note that only one message element may be present in 4154 any given Image Data Request message. 4156 The decision that new firmware is to downloaded to the WTP can occur 4157 in one of two methods: 4159 When the WTP joins the AC, and each exchange their software 4160 revision, the WTP may opt to initiate a firmware download by 4161 sending an Image Data Request, which contains an Image Filename 4162 message element. 4164 Once the WTP is in the CAPWAP state, it is possible for the AC to 4165 cause the WTP to initiate a firmware download by initiating an 4166 Image Data Request, with the Initiate Download message element. 4167 The WTP would then transmit the Image Filename message element to 4168 start the download process. 4170 Regardless of how the download was initiated, once the AC receives an 4171 Image Data Request with the Image Filename message element, it begins 4172 the transfer process by transmitting its own request with the Image 4173 Data message element. This continues until the whole firmware image 4174 has been transfered. 4176 The following message elements MAY be included in the Image Data 4177 Request Message. 4179 o Image Data, see Section 4.4.24 4181 o Image Filename, see Section 4.4.25 4183 o Initiate Download, see Section 4.4.26 4185 9.2. Image Data Response 4187 The Image Data Response message acknowledges the Image Data Request 4188 message. 4190 An Image Data Response message is sent in response to a received 4191 Image Data Request message. Its purpose is to acknowledge the 4192 receipt of the Image Data Request message. 4194 The Image Data Response message carries no message elements. 4196 No action is necessary on receipt. 4198 9.3. Reset Request 4200 The Reset Request message is used to cause a WTP to reboot. 4202 A Reset Request message is sent by an AC to cause a WTP to 4203 reinitialize its operation. 4205 The Reset Request carries no message elements. 4207 When a WTP receives a Reset Request it will respond with a Reset 4208 Response indicating success and then reinitialize itself. In the 4209 event the WTP is unable to reset, including a hardware reset, it can 4210 respond with a Reset Response whose Result-Code message element 4211 indicates failure. 4213 9.4. Reset Response 4215 The Reset Response message acknowledges the Reset Request message. 4217 A Reset Response message is sent by the WTP after receiving a Reset 4218 Request message. 4220 The following message elements MAY be included in the Image Data 4221 Request Message. 4223 o Result Code, see Section 4.4.31 4225 When an AC receives a successful Reset Response message, it is 4226 notified that the WTP will reinitialize its operation. An AC that 4227 receives a Reset Response indicating failure may opt to no longer 4228 provide service to the WTP in question. 4230 9.5. WTP Event Request 4232 WTP Event Request message is used by a WTP to send information to its 4233 AC. The WTP Event Request message may be sent periodically, or sent 4234 in response to an asynchronous event on the WTP. For example, a WTP 4235 MAY collect statistics and use the WTP Event Request message to 4236 transmit the statistics to the AC. 4238 When an AC receives a WTP Event Request message it will respond with 4239 a WTP Event Response message. 4241 The WTP Event Request message MUST contain one of the message 4242 elements listed below, or a message element that is defined for a 4243 specific wireless technology. 4245 o Decryption Error Report, see Section 4.4.15 4247 o Duplicate IPv4 Address, see Section 4.4.21 4249 o Duplicate IPv6 Address, see Section 4.4.22 4251 o WTP Operational Statistics, see Section 4.4.42 4253 o WTP Radio Statistics, see Section 4.4.43 4255 o WTP Reboot Statistics, see Section 4.4.44 4257 9.6. WTP Event Response 4259 The WTP Event Response message acknowledges receipt of the WTP Event 4260 Request message. 4262 A WTP Event Response message issent by an AC after receiving a WTP 4263 Event Request message. 4265 The WTP Event Response message carries no message elements. 4267 9.7. Data Transfer Request 4269 The Data Transfer Request message is used to deliver debug 4270 information from the WTP to the AC. 4272 Data Transfer Request messages are sent by the WTP to the AC when the 4273 WTP determines that it has important information to send to the AC. 4274 For instance, if the WTP detects that its previous reboot was caused 4275 by a system crash, it can send the crash file to the AC. The remote 4276 debugger function in the WTP also uses the Data Transfer Request 4277 message to send console output to the AC for debugging purposes. 4279 When the AC receives a Data Transfer Request message it responds to 4280 the WTP ith a Data Transfer Response message. The AC MAY log the 4281 information received. 4283 The Data Transfer Request message MUST contain one of the message 4284 elements listed below. 4286 o Data Transfer Data, see Section 4.4.13 4288 o Data Transfer Mode, see Section 4.4.14 4290 9.8. Data Transfer Response 4292 The Data Transfer Response message acknowledges the Data Transfer 4293 Request message. 4295 A Data Transfer Response message is sent in response to a received 4296 Data Transfer Request message. Its purpose is to acknowledge receipt 4297 of the Data Transfer Request message. 4299 The Data Transfer Response message carries no message elements. 4301 Upon receipt of a Data Transfer Response message, the WTP transmits 4302 more information, if more information is available. 4304 10. Station Session Management 4306 Messages in this section are used by the AC to create, modify or 4307 delete station session state on the WTPs. 4309 10.1. Station Configuration Request 4311 The Station Configuration Request message is used to create, modify 4312 or delete station session state on a WTP. The message is sent by the 4313 AC to the WTP, and may contain one or more message elements. The 4314 message elements for this CAPWAP control message include information 4315 that is generally highly technology specific. Refer to the 4316 appropriate binding section or document for the definitions of the 4317 messages elements that may be used in this control message. 4319 The following CAPWAP Control message elements MAY be included in the 4320 Station Configuration Request message. 4322 o Add Station, see Section 4.4.8 4324 o Delete Station, see Section 4.4.18 4326 10.2. Station Configuration Response 4328 The Station Configuration Response message is used to acknowledge a 4329 previously received Station Configuration Request message. The 4330 following message element MUST be present in the Station 4331 Configuration Response message. 4333 o Result Code, see Section 4.4.31 4335 The Result Code message element indicates that the requested 4336 configuration was successfully applied, or that an error related to 4337 processing of the Station Configuration Request message occurred on 4338 the WTP. 4340 11. NAT Considerations 4342 There are two specific situations in which a NAT system may be used 4343 in conjunction with a CAPWAP-enabled system. The first consists of a 4344 configuration where the WTP is behind a NAT system. Given that all 4345 communication is initiated by the WTP, and all communication is 4346 performed over IP using two UDP ports, the protocol easily traverses 4347 NAT systems in this configuration. 4349 The second configuration is one where the AC sits behind a NAT. Two 4350 issues exist in this situation. First, an AC communicates its 4351 interfaces, and associated WTP load on these interfaces, through the 4352 WTP Manager Control IP Address. This message element is currently 4353 mandatory, and if NAT compliance became an issue, it would be 4354 possible to either: 4356 1. Make the WTP Manager Control IP Address optional, allowing the WTP 4357 to simply use the known IP Address. However, note that this 4358 approach would eliminate the ability to perform load balancing of 4359 WTP across ACs, and therefore is not the recommended approach. 4361 2. Allow an AC to be able to configure a NAT'ed address for every 4362 associated AC that would generally be communicated in the WTP 4363 Manager Control IP Address message element. 4365 3. Require that if a WTP determines that the AC List message element 4366 consists of a set of IP Addresses that are different from the AC's 4367 IP Address it is currently communicating with, then assume that 4368 NAT is being enforced, and require that the WTP communicate with 4369 the original AC's IP Address (and ignore the WTP Manager Control 4370 IP Address message element(s)). 4372 Another issue related to having an AC behind a NAT system is CAPWAP's 4373 support for the CAPWAP Objective to allow the control and data plane 4374 to be separated. In order to support this requirement, the CAPWAP 4375 protocol defines the WTP Manager Data IP Address message element, 4376 which allows the AC to inform the WTP that the CAPWAP data frames are 4377 to be forwarded to a separate IP Address. This feature MUST be 4378 disabled when an AC is behind a NAT. However, there is no easy way 4379 to provide some default mechanism that satisfies both the data/ 4380 control separation and NAT objectives, as they directly conflict with 4381 each other. As a consequence, user intervention will be required to 4382 support such networks. 4384 The CAPWAP protocol allows for all of the ACs identities supporting a 4385 group of WTPs to be communicated through the AC List message element. 4386 This feature must be disabled when the AC is behind a NAT and the IP 4387 Address that is embedded would be invalid. 4389 The CAPWAP protocol has a feature that allows an AC to configure a 4390 static IP address on a WTP. The WTP Static IP Address Information 4391 message element provides such a function, however this feature SHOULD 4392 NOT be used in NAT'ed environments, unless the administrator is 4393 familiar with the internal IP addressing scheme within the WTP's 4394 private network, and does not rely on the public address seen by the 4395 AC. 4397 When a WTP detects the duplicate address condition, it generates a 4398 message to the AC, which includes the Duplicate IP Address message 4399 element. The IP Address embedded within this message element is 4400 different from the public IP address seen by the AC. 4402 12. Security Considerations 4404 This section describes security considerations for the CAPWAP 4405 protocol. It also provides security recommendations for protocols 4406 used in conjunction with CAPWAP. 4408 12.1. CAPWAP Security 4410 As it is currently specified, the CAPWAP protocol sits between the 4411 security mechanisms specified by the wireless link layer protocol 4412 (e.g.IEEE 802.11) and AAA. One goal of CAPWAP is to bootstrap trust 4413 between the STA and WTP using a series of preestablished trust 4414 relationships: 4416 STA WTP AC AAA 4417 ============================================== 4419 DTLS Cred AAA Cred 4420 <------------><-------------> 4422 EAP Credential 4423 <------------------------------------------> 4425 wireless link layer 4426 (e.g. IEEE 802.11 PTK) 4427 <--------------> or 4428 <---------------------------> 4429 (derived) 4431 Within CAPWAP, DTLS is used to secure the link between the WTP and 4432 AC. In addition to securing control messages, it's also a link in 4433 this chain of trust for establishing link layer keys. Consequently, 4434 much rests on the security of DTLS. 4436 In some CAPWAP deployment scenarios, there are two channels between 4437 the WTP and AC: the control channel, carrying CAPWAP control 4438 messages, and the data channel, over which client data packets are 4439 tunneled between the AC and WTP. Typically, the control channel is 4440 secured by DTLS, while the data channel is not. 4442 The use of parallel protected and unprotected channels deserves 4443 special consideration, but does not create a threat. There are two 4444 potential concerns: attempting to convert protected data into un- 4445 protected data and attempting to convert un-protected data into 4446 protected data. These concerns are addressed below. 4448 12.1.1. Converting Protected Data into Unprotected Data 4450 Since CAPWAP does not support authentication-only ciphers (i.e. all 4451 supported ciphersuites include encryption and authentication), it is 4452 not possible to convert protected data into unprotected data. Since 4453 encrypted data is (ideally) indistinguishable from random data, the 4454 probability of an encrypted packet passing for a well-formed packet 4455 is effectively zero. 4457 12.1.2. Converting Unprotected Data into Protected Data (Insertion) 4459 The use of message authentication makes it impossible for the 4460 attacker to forge protected records. This makes conversion of 4461 unprotected records to protected records impossible. 4463 12.1.3. Deletion of Protected Records 4465 An attacker could remove protected records from the stream, though 4466 not undetectably so, due the built-in reliability of the underlying 4467 CAPWAP protocol. In the worst case, the attacker would remove the 4468 same record repeatedly, resulting in a CAPWAP session timeout and 4469 restart. This is effectively a DoS attack, and could be accomplished 4470 by a man in the middle regardless of the CAPWAP protocol security 4471 mechanisms chosen. 4473 12.1.4. Insertion of Unprotected Records 4475 An attacker could inject packets into the unprotected channel, but 4476 this may become evident if sequence number desynchronization occurs 4477 as a result. Only if the attacker is a MiM can packets be inserted 4478 undetectably. This is a consequence of that channel's lack of 4479 protection, and not a new threat resulting from the CAPWAP security 4480 mechanism. 4482 12.2. Use of Preshared Keys in CAPWAP 4484 While use of preshared keys may provide deployment and provisioning 4485 advantages not found in public key based deployments, it also 4486 introduces a number of operational and security concerns. In 4487 particular, because the keys must typically be entered manually, it 4488 is common for people to base them on memorable words or phrases. 4489 These are referred to as "low entropy passwords/passphrases". 4491 Use of low-entropy preshared keys, coupled with the fact that the 4492 keys are often not frequently updated, tends to significantly 4493 increase exposure. For these reasons, we make the following 4494 recommendations: 4496 o When DTLS is used with a preshared-key (PSK) ciphersuite, each WTP 4497 SHOULD have a unique PSK. Since WTPs will likely be widely 4498 deployed, their physical security is not guaranteed. If PSKs are 4499 not unique for each WTP, key reuse would allow the compromise of 4500 one WTP to result in the compromise of others 4502 o Generating PSKs from low entropy passwords is NOT RECOMMENDED. 4504 o It is RECOMMENDED that implementations that allow the 4505 administrator to manually configure the PSK also provide a 4506 capability for generation of new random PSKs, taking RFC 1750 [2] 4507 into account. 4509 o Preshared keys SHOULD be periodically updated. Implementations 4510 may facilitate this by providing an administrative interface for 4511 automatic key generation and periodic update, or it may be 4512 accomplished manually instead. 4514 12.3. Use of Certificates in CAPWAP 4516 For public-key-based DTLS deployments, each device SHOULD have unique 4517 credentials, with an extended key usage authorizing them to act as 4518 either a WTP or AC. If devices do not have unique credentials, it is 4519 possible that by compromising one, any other one using the same 4520 credential may also be considered to be compromised. 4522 Certificate validation involves checking a large variety of things. 4523 Since the necessary things to validate are often environment- 4524 specific, many are beyond the scope of this document. In this 4525 section, we provide some basic guidance on certificate validation. 4527 Each device is responsible for authenticating and authorizing devices 4528 with which they communicate. Authentication entails validation of 4529 the chain of trust leading to the peer certificate, followed by the 4530 the peer certificate itself. At a minimum, devices SHOULD use SSH- 4531 style certificate caching to guarantee consistency. If devices have 4532 access to a certificate authority, they SHOULD properly validate the 4533 trust chain. Implementations SHOULD also provide a secure method for 4534 verifying that the credential in question has not been revoked. 4536 Note that if the WTP relies on the AC for network connectivity (e.g. 4537 the AC is a layer 2 switch to which the WTP is directly connected), 4538 there is a chicken and egg problem, in that the WTP may not be able 4539 to contact an OCSP server or otherwise obtain an up to date CRL if a 4540 compromised AC doesn't explicitly permit this. This cannot be 4541 avoided, except through effective physical security and monitoring 4542 measures at the AC. 4544 Proper validation of certificates typically requires checking to 4545 ensure the certificate has not yet expired. If devices have a real- 4546 time clock, they SHOULD verify the certificate validity dates. If no 4547 real-time clock is available, the device SHOULD make a best-effort 4548 attempt to validate the certificate validity dates through other 4549 means. Failure to check a certificate's temporal validity can make a 4550 device vulnerable to man-in-the-middle attacks launched using 4551 compromised, expired certificates, and therefore devices should make 4552 every effort to perform this validation. 4554 Another important part of certificate authentication is binding a 4555 certificate to a particular device. There are many ways to 4556 accomplish this. Specificaiton of the certificate common name (CN) 4557 as the WTP or AC MAC address formatted as ASCII HEX, for example, 01: 4558 23:45:67:89:ab is REQUIRED for use with the CAPWAP protocol. During 4559 authentication, devices SHOULD ensure that the MAC address matches 4560 the MAC address specified in the CAPWAP header. If this mechanism is 4561 used, the ACs SHOULD maintain list of all authorized WTP MAC 4562 addresses and the WTP SHOULD save the AC credential or credential 4563 identifier. 4565 12.4. AAA Security 4567 The AAA protocol is used to distribute EAP keys to the ACs, and 4568 consequently its security is important to the overall system 4569 security. When used with TLS or IPsec, security guidelines specified 4570 in RFC 3539 [5] SHOULD be followed. 4572 In general, the link between the AC and AAA server SHOULD be secured 4573 using a strong ciphersuite keyed with mutually authenticated session 4574 keys. Implementations SHOULD NOT rely solely on Basic RADIUS shared 4575 secret authentication as it is often vulnerable to dictionary 4576 attacks, but rather SHOULD use stronger underlying security 4577 mechanisms. 4579 13. IANA Considerations 4581 A separate UDP port for data channel communications is (currently) 4582 the selected demultiplexing mechanism, and a port must be assigned 4583 for this purpose. 4585 14. References 4587 14.1. Normative References 4589 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 4590 Levels", BCP 14, RFC 2119, March 1997. 4592 [2] Eastlake, D., Crocker, S., and J. Schiller, "Randomness 4593 Recommendations for Security", RFC 1750, December 1994. 4595 [3] Mills, D., "Network Time Protocol (Version 3) Specification, 4596 Implementation", RFC 1305, March 1992. 4598 [4] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 4599 Public Key Infrastructure Certificate and Certificate 4600 Revocation List (CRL) Profile", RFC 3280, April 2002. 4602 [5] Aboba, B. and J. Wood, "Authentication, Authorization and 4603 Accounting (AAA) Transport Profile", RFC 3539, June 2003. 4605 [6] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for 4606 Transport Layer Security (TLS)", RFC 4279, December 2005. 4608 [7] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 4609 Protocol Version 1.1", RFC 4346, April 2006. 4611 [8] Manner, J. and M. Kojo, "Mobility Related Terminology", 4612 RFC 3753, June 2004. 4614 [9] Clancy, C., "Security Review of the Light Weight Access Point 4615 Protocol", May 2005, 4616 . 4618 [10] Rescorla et al, E., "Datagram Transport Layer Security", 4619 June 2004. 4621 14.2. Informational References 4623 [11] "draft-ietf-capwap-protocol-binding-specification-ieee802dot11- 4624 00". 4626 [12] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On- 4627 line Database", RFC 3232, January 2002. 4629 [13] Modadugu et al, N., "The Design and Implementation of Datagram 4630 TLS", Feb 2004. 4632 Editors' Addresses 4634 Pat R. Calhoun 4635 Cisco Systems, Inc. 4636 170 West Tasman Drive 4637 San Jose, CA 95134 4639 Phone: +1 408-853-5269 4640 Email: pcalhoun@cisco.com 4642 Michael P. Montemurro 4643 Research In Motion 4644 5090 Commerce Blvd 4645 Mississauga, ON L4W 5M4 4646 Canada 4648 Phone: +1 905-629-4746 x4999 4649 Email: mmontemurro@rim.com 4651 Dorothy Stanley 4652 Aruba Networks 4653 1322 Crossman Ave 4654 Sunnyvale, CA 94089 4656 Phone: +1 630-363-1389 4657 Email: dstanley@arubanetworks.com 4659 Full Copyright Statement 4661 Copyright (C) The Internet Society (2006). 4663 This document is subject to the rights, licenses and restrictions 4664 contained in BCP 78, and except as set forth therein, the authors 4665 retain all their rights. 4667 This document and the information contained herein are provided on an 4668 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 4669 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 4670 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 4671 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 4672 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4673 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4675 Intellectual Property 4677 The IETF takes no position regarding the validity or scope of any 4678 Intellectual Property Rights or other rights that might be claimed to 4679 pertain to the implementation or use of the technology described in 4680 this document or the extent to which any license under such rights 4681 might or might not be available; nor does it represent that it has 4682 made any independent effort to identify any such rights. Information 4683 on the procedures with respect to rights in RFC documents can be 4684 found in BCP 78 and BCP 79. 4686 Copies of IPR disclosures made to the IETF Secretariat and any 4687 assurances of licenses to be made available, or the result of an 4688 attempt made to obtain a general license or permission for the use of 4689 such proprietary rights by implementers or users of this 4690 specification can be obtained from the IETF on-line IPR repository at 4691 http://www.ietf.org/ipr. 4693 The IETF invites any interested party to bring to its attention any 4694 copyrights, patents or patent applications, or other proprietary 4695 rights that may cover technology that may be required to implement 4696 this standard. Please address the information to the IETF at 4697 ietf-ipr@ietf.org. 4699 Acknowledgment 4701 Funding for the RFC Editor function is provided by the IETF 4702 Administrative Support Activity (IASA).