idnits 2.17.1 draft-ietf-capwap-protocol-specification-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 6582. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 6593. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 6600. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 6606. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 (July 10, 2008) is 5767 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) == Outdated reference: A later version (-12) exists of draft-ietf-capwap-protocol-binding-ieee80211-06 == Outdated reference: A later version (-02) exists of draft-ietf-capwap-dhc-ac-option-01 -- Possible downref: Non-RFC (?) normative reference: ref. 'FRAME-EXT' Summary: 7 errors (**), 0 flaws (~~), 4 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: Standards Track M. Montemurro, Editor 5 Expires: January 11, 2009 Research In Motion 6 D. Stanley, Editor 7 Aruba Networks 8 July 10, 2008 10 CAPWAP Protocol Specification 11 draft-ietf-capwap-protocol-specification-11 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 January 11, 2009. 38 Abstract 40 This specification defines the Control And Provisioning of Wireless 41 Access Points (CAPWAP) Protocol. The CAPWAP protocol meets the 42 Objectives for Control and Provisioning of Wireless Access Points 43 (CAPWAP). The CAPWAP protocol is designed to be flexible, allowing 44 it to be used for a variety of wireless technologies. This document 45 describes the base CAPWAP protocol, while separate binding extensions 46 will enable its use with additional wireless technologies. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 51 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . 8 52 1.2. Conventions used in this document . . . . . . . . . . . 9 53 1.3. Contributing Authors . . . . . . . . . . . . . . . . . . 9 54 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . 10 55 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12 56 2.1. Wireless Binding Definition . . . . . . . . . . . . . . 13 57 2.2. CAPWAP Session Establishment Overview . . . . . . . . . 14 58 2.3. CAPWAP State Machine Definition . . . . . . . . . . . . 16 59 2.3.1. CAPWAP Protocol State Transitions . . . . . . . . . . 18 60 2.3.2. CAPWAP/DTLS Interface . . . . . . . . . . . . . . . . 31 61 2.4. Use of DTLS in the CAPWAP Protocol . . . . . . . . . . . 33 62 2.4.1. DTLS Handshake Processing . . . . . . . . . . . . . . 34 63 2.4.2. DTLS Session Establishment . . . . . . . . . . . . . 35 64 2.4.3. DTLS Error Handling . . . . . . . . . . . . . . . . . 35 65 2.4.4. DTLS EndPoint Authentication and Authorization . . . 37 66 3. CAPWAP Transport . . . . . . . . . . . . . . . . . . . . . . 41 67 3.1. UDP Transport . . . . . . . . . . . . . . . . . . . . . 41 68 3.2. UDP-Lite Transport . . . . . . . . . . . . . . . . . . . 41 69 3.3. AC Discovery . . . . . . . . . . . . . . . . . . . . . . 42 70 3.4. Fragmentation/Reassembly . . . . . . . . . . . . . . . . 43 71 3.5. MTU Discovery . . . . . . . . . . . . . . . . . . . . . 43 72 4. CAPWAP Packet Formats . . . . . . . . . . . . . . . . . . . . 44 73 4.1. CAPWAP Preamble . . . . . . . . . . . . . . . . . . . . 46 74 4.2. CAPWAP DTLS Header . . . . . . . . . . . . . . . . . . . 46 75 4.3. CAPWAP Header . . . . . . . . . . . . . . . . . . . . . 47 76 4.4. CAPWAP Data Messages . . . . . . . . . . . . . . . . . . 50 77 4.4.1. CAPWAP Data Channel Keepalive . . . . . . . . . . . . 50 78 4.4.2. Data Payload . . . . . . . . . . . . . . . . . . . . 51 79 4.4.3. Establishment of a DTLS Data Channel . . . . . . . . 52 80 4.5. CAPWAP Control Messages . . . . . . . . . . . . . . . . 52 81 4.5.1. Control Message Format . . . . . . . . . . . . . . . 53 82 4.5.2. Control Message Quality of Service . . . . . . . . . 56 83 4.5.3. Retransmissions . . . . . . . . . . . . . . . . . . . 56 84 4.6. CAPWAP Protocol Message Elements . . . . . . . . . . . . 57 85 4.6.1. AC Descriptor . . . . . . . . . . . . . . . . . . . . 59 86 4.6.2. AC IPv4 List . . . . . . . . . . . . . . . . . . . . 61 87 4.6.3. AC IPv6 List . . . . . . . . . . . . . . . . . . . . 62 88 4.6.4. AC Name . . . . . . . . . . . . . . . . . . . . . . . 62 89 4.6.5. AC Name with Index . . . . . . . . . . . . . . . . . 63 90 4.6.6. AC Timestamp . . . . . . . . . . . . . . . . . . . . 63 91 4.6.7. Add MAC ACL Entry . . . . . . . . . . . . . . . . . . 64 92 4.6.8. Add Station . . . . . . . . . . . . . . . . . . . . . 64 93 4.6.9. Add Static MAC ACL Entry . . . . . . . . . . . . . . 65 94 4.6.10. CAPWAP Control IPv4 Address . . . . . . . . . . . . . 65 95 4.6.11. CAPWAP Control IPv6 Address . . . . . . . . . . . . . 66 96 4.6.12. CAPWAP Local IPv4 Address . . . . . . . . . . . . . . 67 97 4.6.13. CAPWAP Local IPv6 Address . . . . . . . . . . . . . . 67 98 4.6.14. CAPWAP Timers . . . . . . . . . . . . . . . . . . . . 68 99 4.6.15. CAPWAP Transport Protocol . . . . . . . . . . . . . . 68 100 4.6.16. Data Transfer Data . . . . . . . . . . . . . . . . . 69 101 4.6.17. Data Transfer Mode . . . . . . . . . . . . . . . . . 70 102 4.6.18. Decryption Error Report . . . . . . . . . . . . . . . 71 103 4.6.19. Decryption Error Report Period . . . . . . . . . . . 71 104 4.6.20. Delete MAC ACL Entry . . . . . . . . . . . . . . . . 72 105 4.6.21. Delete Station . . . . . . . . . . . . . . . . . . . 72 106 4.6.22. Delete Static MAC ACL Entry . . . . . . . . . . . . . 73 107 4.6.23. Discovery Type . . . . . . . . . . . . . . . . . . . 74 108 4.6.24. Duplicate IPv4 Address . . . . . . . . . . . . . . . 74 109 4.6.25. Duplicate IPv6 Address . . . . . . . . . . . . . . . 75 110 4.6.26. Idle Timeout . . . . . . . . . . . . . . . . . . . . 76 111 4.6.27. Image Data . . . . . . . . . . . . . . . . . . . . . 76 112 4.6.28. Image Identifier . . . . . . . . . . . . . . . . . . 77 113 4.6.29. Image Information . . . . . . . . . . . . . . . . . . 77 114 4.6.30. Initiate Download . . . . . . . . . . . . . . . . . . 78 115 4.6.31. Location Data . . . . . . . . . . . . . . . . . . . . 79 116 4.6.32. Maximum Message Length . . . . . . . . . . . . . . . 79 117 4.6.33. Radio Administrative State . . . . . . . . . . . . . 80 118 4.6.34. Radio Operational State . . . . . . . . . . . . . . . 80 119 4.6.35. Result Code . . . . . . . . . . . . . . . . . . . . . 81 120 4.6.36. Returned Message Element . . . . . . . . . . . . . . 83 121 4.6.37. Session ID . . . . . . . . . . . . . . . . . . . . . 84 122 4.6.38. Statistics Timer . . . . . . . . . . . . . . . . . . 84 123 4.6.39. Vendor Specific Payload . . . . . . . . . . . . . . . 84 124 4.6.40. WTP Board Data . . . . . . . . . . . . . . . . . . . 85 125 4.6.41. WTP Descriptor . . . . . . . . . . . . . . . . . . . 86 126 4.6.42. WTP Fallback . . . . . . . . . . . . . . . . . . . . 88 127 4.6.43. WTP Frame Tunnel Mode . . . . . . . . . . . . . . . . 89 128 4.6.44. WTP IPv4 IP Address . . . . . . . . . . . . . . . . . 89 129 4.6.45. WTP IPv6 IP Address . . . . . . . . . . . . . . . . . 90 130 4.6.46. WTP MAC Type . . . . . . . . . . . . . . . . . . . . 90 131 4.6.47. WTP Name . . . . . . . . . . . . . . . . . . . . . . 91 132 4.6.48. WTP Radio Statistics . . . . . . . . . . . . . . . . 91 133 4.6.49. WTP Reboot Statistics . . . . . . . . . . . . . . . . 93 134 4.6.50. WTP Static IP Address Information . . . . . . . . . . 94 135 4.7. CAPWAP Protocol Timers . . . . . . . . . . . . . . . . . 95 136 4.7.1. ChangeStatePendingTimer . . . . . . . . . . . . . . . 95 137 4.7.2. DataChannelKeepAlive . . . . . . . . . . . . . . . . 95 138 4.7.3. DataChannelDeadInterval . . . . . . . . . . . . . . . 96 139 4.7.4. DataCheckTimer . . . . . . . . . . . . . . . . . . . 96 140 4.7.5. DiscoveryInterval . . . . . . . . . . . . . . . . . . 96 141 4.7.6. DTLSSessionDelete . . . . . . . . . . . . . . . . . . 96 142 4.7.7. EchoInterval . . . . . . . . . . . . . . . . . . . . 96 143 4.7.8. IdleTimeout . . . . . . . . . . . . . . . . . . . . . 96 144 4.7.9. ImageDataStartTimer . . . . . . . . . . . . . . . . . 97 145 4.7.10. MaxDiscoveryInterval . . . . . . . . . . . . . . . . 97 146 4.7.11. ReportInterval . . . . . . . . . . . . . . . . . . . 97 147 4.7.12. RetransmitInterval . . . . . . . . . . . . . . . . . 97 148 4.7.13. SilentInterval . . . . . . . . . . . . . . . . . . . 97 149 4.7.14. StatisticsTimer . . . . . . . . . . . . . . . . . . . 97 150 4.7.15. WaitDTLS . . . . . . . . . . . . . . . . . . . . . . 98 151 4.8. CAPWAP Protocol Variables . . . . . . . . . . . . . . . 98 152 4.8.1. AdminState . . . . . . . . . . . . . . . . . . . . . 98 153 4.8.2. DiscoveryCount . . . . . . . . . . . . . . . . . . . 98 154 4.8.3. FailedDTLSAuthFailCount . . . . . . . . . . . . . . . 98 155 4.8.4. FailedDTLSSessionCount . . . . . . . . . . . . . . . 98 156 4.8.5. MaxDiscoveries . . . . . . . . . . . . . . . . . . . 98 157 4.8.6. MaxFailedDTLSSessionRetry . . . . . . . . . . . . . . 98 158 4.8.7. MaxRetransmit . . . . . . . . . . . . . . . . . . . . 99 159 4.8.8. RetransmitCount . . . . . . . . . . . . . . . . . . . 99 160 4.8.9. WTPFallBack . . . . . . . . . . . . . . . . . . . . . 99 161 4.9. WTP Saved Variables . . . . . . . . . . . . . . . . . . 99 162 4.9.1. AdminRebootCount . . . . . . . . . . . . . . . . . . 99 163 4.9.2. FrameEncapType . . . . . . . . . . . . . . . . . . . 99 164 4.9.3. LastRebootReason . . . . . . . . . . . . . . . . . . 99 165 4.9.4. MacType . . . . . . . . . . . . . . . . . . . . . . . 99 166 4.9.5. PreferredACs . . . . . . . . . . . . . . . . . . . . 99 167 4.9.6. RebootCount . . . . . . . . . . . . . . . . . . . . . 100 168 4.9.7. Static ACL Table . . . . . . . . . . . . . . . . . . 100 169 4.9.8. Static IP Address . . . . . . . . . . . . . . . . . . 100 170 4.9.9. WTPLinkFailureCount . . . . . . . . . . . . . . . . . 100 171 4.9.10. WTPLocation . . . . . . . . . . . . . . . . . . . . . 100 172 4.9.11. WTPName . . . . . . . . . . . . . . . . . . . . . . . 100 173 5. CAPWAP Discovery Operations . . . . . . . . . . . . . . . . . 101 174 5.1. Discovery Request Message . . . . . . . . . . . . . . . 101 175 5.2. Discovery Response Message . . . . . . . . . . . . . . . 102 176 5.3. Primary Discovery Request Message . . . . . . . . . . . 103 177 5.4. Primary Discovery Response . . . . . . . . . . . . . . . 104 178 6. CAPWAP Join Operations . . . . . . . . . . . . . . . . . . . 106 179 6.1. Join Request . . . . . . . . . . . . . . . . . . . . . . 106 180 6.2. Join Response . . . . . . . . . . . . . . . . . . . . . 107 182 7. Control Channel Management . . . . . . . . . . . . . . . . . 110 183 7.1. Echo Request . . . . . . . . . . . . . . . . . . . . . . 110 184 7.2. Echo Response . . . . . . . . . . . . . . . . . . . . . 110 185 8. WTP Configuration Management . . . . . . . . . . . . . . . . 112 186 8.1. Configuration Consistency . . . . . . . . . . . . . . . 112 187 8.1.1. Configuration Flexibility . . . . . . . . . . . . . . 113 188 8.2. Configuration Status . . . . . . . . . . . . . . . . . . 113 189 8.3. Configuration Status Response . . . . . . . . . . . . . 114 190 8.4. Configuration Update Request . . . . . . . . . . . . . . 115 191 8.5. Configuration Update Response . . . . . . . . . . . . . 116 192 8.6. Change State Event Request . . . . . . . . . . . . . . . 116 193 8.7. Change State Event Response . . . . . . . . . . . . . . 118 194 8.8. Clear Configuration Request . . . . . . . . . . . . . . 118 195 8.9. Clear Configuration Response . . . . . . . . . . . . . . 118 196 9. Device Management Operations . . . . . . . . . . . . . . . . 120 197 9.1. Firmware Management . . . . . . . . . . . . . . . . . . 120 198 9.1.1. Image Data Request . . . . . . . . . . . . . . . . . 124 199 9.1.2. Image Data Response . . . . . . . . . . . . . . . . . 125 200 9.2. Reset Request . . . . . . . . . . . . . . . . . . . . . 126 201 9.3. Reset Response . . . . . . . . . . . . . . . . . . . . . 127 202 9.4. WTP Event Request . . . . . . . . . . . . . . . . . . . 127 203 9.5. WTP Event Response . . . . . . . . . . . . . . . . . . . 128 204 9.6. Data Transfer . . . . . . . . . . . . . . . . . . . . . 128 205 9.6.1. Data Transfer Request . . . . . . . . . . . . . . . . 129 206 9.6.2. Data Transfer Response . . . . . . . . . . . . . . . 130 207 10. Station Session Management . . . . . . . . . . . . . . . . . 132 208 10.1. Station Configuration Request . . . . . . . . . . . . . 132 209 10.2. Station Configuration Response . . . . . . . . . . . . . 132 210 11. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 134 211 12. Security Considerations . . . . . . . . . . . . . . . . . . . 136 212 12.1. CAPWAP Security . . . . . . . . . . . . . . . . . . . . 136 213 12.1.1. Converting Protected Data into Unprotected Data . . . 137 214 12.1.2. Converting Unprotected Data into Protected Data 215 (Insertion) . . . . . . . . . . . . . . . . . . . . . 137 216 12.1.3. Deletion of Protected Records . . . . . . . . . . . . 137 217 12.1.4. Insertion of Unprotected Records . . . . . . . . . . 137 218 12.2. Session ID Security . . . . . . . . . . . . . . . . . . 137 219 12.3. Discovery or DTLS Setup Attacks . . . . . . . . . . . . 138 220 12.4. Interference with a DTLS Session . . . . . . . . . . . . 139 221 12.5. CAPWAP Pre-Provisioning . . . . . . . . . . . . . . . . 139 222 12.6. Use of Preshared Keys in CAPWAP . . . . . . . . . . . . 140 223 12.7. Use of Certificates in CAPWAP . . . . . . . . . . . . . 141 224 12.8. AAA Security . . . . . . . . . . . . . . . . . . . . . . 142 225 13. Operational Considerations . . . . . . . . . . . . . . . . . 143 226 14. Transport Considerations . . . . . . . . . . . . . . . . . . 144 227 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 145 228 15.1. CAPWAP Message Types . . . . . . . . . . . . . . . . . . 145 229 15.2. CAPWAP Header Flags . . . . . . . . . . . . . . . . . . 145 230 15.3. CAPWAP Control Message Flags . . . . . . . . . . . . . . 145 231 15.4. CAPWAP Control Message Type . . . . . . . . . . . . . . 145 232 15.5. Wireless Binding Identifiers . . . . . . . . . . . . . . 145 233 15.6. AC Security Types . . . . . . . . . . . . . . . . . . . 146 234 15.7. AC DTLS Policy . . . . . . . . . . . . . . . . . . . . . 146 235 15.8. AC Information Type . . . . . . . . . . . . . . . . . . 146 236 15.9. CAPWAP Transport Protocol Types . . . . . . . . . . . . 146 237 15.10. Data Transfer Type . . . . . . . . . . . . . . . . . . . 146 238 15.11. Data Transfer Mode . . . . . . . . . . . . . . . . . . . 146 239 15.12. Discovery Types . . . . . . . . . . . . . . . . . . . . 147 240 15.13. Radio Admin State . . . . . . . . . . . . . . . . . . . 147 241 15.14. Radio Operational State . . . . . . . . . . . . . . . . 147 242 15.15. Radio Failure Causes . . . . . . . . . . . . . . . . . . 147 243 15.16. Result Code . . . . . . . . . . . . . . . . . . . . . . 147 244 15.17. Returned Message Element Reason . . . . . . . . . . . . 147 245 15.18. WTP Board Data Type . . . . . . . . . . . . . . . . . . 148 246 15.19. WTP Descriptor Type . . . . . . . . . . . . . . . . . . 148 247 15.20. WTP Fallback Mode . . . . . . . . . . . . . . . . . . . 148 248 15.21. WTP Frame Tunnel Mode . . . . . . . . . . . . . . . . . 148 249 15.22. WTP MAC Type . . . . . . . . . . . . . . . . . . . . . . 148 250 15.23. WTP Radio Stats Failure Type . . . . . . . . . . . . . . 148 251 15.24. WTP Reboot Stats Failure Type . . . . . . . . . . . . . 149 252 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 150 253 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 151 254 17.1. Normative References . . . . . . . . . . . . . . . . . . 151 255 17.2. Informational References . . . . . . . . . . . . . . . . 152 256 Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 154 257 Intellectual Property and Copyright Statements . . . . . . . . . 155 259 1. Introduction 261 This document describes the CAPWAP Protocol, a standard, 262 interoperable protocol which enables an Access Controller (AC) to 263 manage a collection of Wireless Termination Points (WTPs). The 264 CAPWAP protocol is defined to be independent of layer 2 technology, 265 and meets the Objectives for Control and Provisioning of Wireless 266 Access Points (CAPWAP) [RFC4564]. 268 The emergence of centralized IEEE 802.11 Wireless Local Area Network 269 (WLAN) architectures, in which simple IEEE 802.11 WTPs are managed by 270 an Access Controller (AC) suggested that a standards based, 271 interoperable protocol could radically simplify the deployment and 272 management of wireless networks. WTPs require a set of dynamic 273 management and control functions related to their primary task of 274 connecting the wireless and wired mediums. Traditional protocols for 275 managing WTPs are either manual static configuration via HTTP, 276 proprietary Layer 2 specific or non-existent (if the WTPs are self- 277 contained). An IEEE 802.11 binding is defined in 278 [I-D.ietf-capwap-protocol-binding-ieee80211] to support use of the 279 CAPWAP protocol with IEEE 802.11 WLAN networks. 281 CAPWAP assumes a network configuration consisting of multiple WTPs 282 communicating via the Internet Protocol (IP) to an AC. WTPs are 283 viewed as remote RF interfaces controlled by the AC. The CAPWAP 284 protocol supports two modes of operation: Split and Local MAC. In 285 Split MAC mode all L2 wireless data and management frames are 286 encapsulated via the CAPWAP protocol and exchanged between the AC and 287 the WTP. As shown in Figure 1, the wireless frames received from a 288 mobile device, which is referred to in this specification as a 289 Station (STA), are directly encapsulated by the WTP and forwarded to 290 the AC. 292 +-+ wireless frames +-+ 293 | |--------------------------------| | 294 | | +-+ | | 295 | |--------------| |---------------| | 296 | |wireless PHY/ | | CAPWAP | | 297 | | MAC sublayer | | | | 298 +-+ +-+ +-+ 299 STA WTP AC 301 Figure 1: Representative CAPWAP Architecture for Split MAC 303 The Local MAC mode of operation allows for the data frames to be 304 either locally bridged, or tunneled as 802.3 frames. The latter 305 implies that the WTP performs the 802.11 Integration function. In 306 either case the L2 wireless management frames are processed locally 307 by the WTP, and then forwarded to the AC. Figure 2 shows the Local 308 MAC mode, in which a station transmits a wireless frame which is 309 encapsulated in an 802.3 frame and forwarded to the AC. 311 +-+wireless frames +-+ 802.3 frames +-+ 312 | |----------------| |--------------| | 313 | | | | | | 314 | |----------------| |--------------| | 315 | |wireless PHY/ | | CAPWAP | | 316 | | MAC sublayer | | | | 317 +-+ +-+ +-+ 318 STA WTP AC 320 Figure 2: Representative CAPWAP Architecture for Local MAC 322 Provisioning WTPs with security credentials, and managing which WTPs 323 are authorized to provide service are traditionally handled by 324 proprietary solutions. Allowing these functions to be performed from 325 a centralized AC in an interoperable fashion increases manageability 326 and allows network operators to more tightly control their wireless 327 network infrastructure. 329 1.1. Goals 331 The goals for the CAPWAP protocol are listed below: 333 1. To centralize the authentication and policy enforcement functions 334 for a wireless network. The AC may also provide centralized 335 bridging, forwarding, and encryption of user traffic. 336 Centralization of these functions will enable reduced cost and 337 higher efficiency by applying the capabilities of network 338 processing silicon to the wireless network, as in wired LANs. 340 2. To enable shifting of the higher level protocol processing from 341 the WTP. This leaves the time critical applications of wireless 342 control and access in the WTP, making efficient use of the 343 computing power available in WTPs which are the subject to severe 344 cost pressure. 346 3. To provide an extensible protocol that is not bound to a specific 347 wireless technology. Extensibility is provided via a generic 348 encapsulation and transport mechanism, enabling the CAPWAP 349 protocol to be applied to many access point types in the future, 350 via a specific wireless binding. 352 The CAPWAP protocol concerns itself solely with the interface between 353 the WTP and the AC. Inter-AC and station-to AC-communication are 354 strictly outside the scope of this document. 356 1.2. Conventions used in this document 358 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 359 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 360 document are to be interpreted as described in RFC 2119 [RFC2119]. 362 1.3. Contributing Authors 364 This section lists and acknowledges the authors of significant text 365 and concepts included in this specification. 367 The CAPWAP Working Group selected the Lightweight Access Point 368 Protocol (LWAPP) [I-D.ohara-capwap-lwapp] to be used as the basis of 369 the CAPWAP protocol specification. The following people are authors 370 of the LWAPP document: 372 Bob O'Hara 373 Email: bob.ohara@computer.org 375 Pat Calhoun, Cisco Systems, Inc. 376 170 West Tasman Drive, San Jose, CA 95134 377 Phone: +1 408-902-3240, Email: pcalhoun@cisco.com 379 Rohit Suri, Cisco Systems, Inc. 380 170 West Tasman Drive, San Jose, CA 95134 381 Phone: +1 408-853-5548, Email: rsuri@cisco.com 383 Nancy Cam Winget, Cisco Systems, Inc. 384 170 West Tasman Drive, San Jose, CA 95134 385 Phone: +1 408-853-0532, Email: ncamwing@cisco.com 387 Scott Kelly, Aruba Networks 388 1322 Crossman Ave, Sunnyvale, CA 94089 389 Phone: +1 408-754-8408, Email: skelly@arubanetworks.com 391 Michael Glenn Williams, Nokia, Inc. 392 313 Fairchild Drive, Mountain View, CA 94043 393 Phone: +1 650-714-7758, Email: Michael.G.Williams@Nokia.com 395 Sue Hares, Green Hills Software 396 825 Victors Way, Suite 100, Ann Arbor, MI 48108 397 Phone: +1 734 222 1610, Email: shares@ndzh.com 399 Datagram Transport Layer Security (DTLS) [RFC4346] is used as the 400 security solution for the CAPWAP protocol. The following people are 401 authors of significant DTLS-related text included in this document: 403 Scott Kelly, Aruba Networks 404 1322 Crossman Ave, Sunnyvale, CA 94089 405 Phone: +1 408-754-8408, Email: skelly@arubanetworks.com 407 Eric Rescorla, Network Resonance 408 2483 El Camino Real, #212,Palo Alto CA, 94303 409 Email: ekr@networkresonance.com 411 The concept of using DTLS to secure the CAPWAP protocol was part of 412 the Secure Light Access Point Protocol (SLAPP) proposal 413 [I-D.narasimhan-ietf-slapp]. The following people are authors of the 414 SLAPP proposal: 416 Partha Narasimhan, Aruba Networks 417 1322 Crossman Ave, Sunnyvale, CA 94089 418 Phone: +1 408-480-4716, Email: partha@arubanetworks.com 420 Dan Harkins, Tropos Networks 421 555 Del Rey Avenue, Sunnyvale, CA, 95085 422 Phone: +1 408 470 7372, Email: dharkins@tropos.com 424 Subbu Ponnuswamy, Aruba Networks 425 1322 Crossman Ave, Sunnyvale, CA 94089 426 Phone: +1 408-754-1213, Email: subbu@arubanetworks.com 428 The following individuals contributed significant security related 429 text to the draft: 431 T. Charles Clancy, Laboratory for Telecommunications Sciences, 432 8080 Greenmead Drive, College Park, MD 20740 433 Phone: +1 240-373-5069, Email: clancy@ltsnet.net 435 Scott Kelly, Aruba Networks 436 1322 Crossman Ave, Sunnyvale, CA 94089 437 Phone: +1 408-754-8408, Email: skelly@arubanetworks.com 439 1.4. Terminology 441 Access Controller (AC): The network entity that provides WTP access 442 to the network infrastructure in the data plane, control plane, 443 management plane, or a combination therein. 445 CAPWAP Control Channel: A bi-directional flow defined by the AC IP 446 Address, WTP IP Address, AC control port, WTP control port and the 447 transport-layer protocol (UDP or UDP-Lite) over which CAPWAP control 448 packets are sent and received. 450 CAPWAP Data Channel: A bi-directional flow defined by the AC IP 451 Address, WTP IP Address, AC data port, WTP data port, and the 452 transport-layer protocol (UDP or UDP-Lite) over which CAPWAP data 453 packets are sent and received. 455 Station (STA): A device that contains an interface to a wireless 456 medium (WM). 458 Wireless Termination Point (WTP): The physical or network entity that 459 contains an RF antenna and wireless PHY to transmit and receive 460 station traffic for wireless access networks. 462 This document uses additional terminology defined in [RFC3753]. 464 2. Protocol Overview 466 The CAPWAP protocol is a generic protocol defining AC and WTP control 467 and data plane communication via a CAPWAP protocol transport 468 mechanism. CAPWAP control messages, and optionally CAPWAP data 469 messages, are secured using Datagram Transport Layer Security (DTLS) 470 [RFC4346]. DTLS is a standards-track IETF protocol based upon TLS. 471 The underlying security-related protocol mechanisms of TLS have been 472 successfully deployed for many years. 474 The CAPWAP protocol Transport layer carries two types of payload, 475 CAPWAP Data messages and CAPWAP Control messages. CAPWAP Data 476 messages encapsulate forwarded wireless frames. CAPWAP protocol 477 Control messages are management messages exchanged between a WTP and 478 an AC. The CAPWAP Data and Control packets are sent over separate 479 UDP ports. Since both data and control packets can exceed the 480 Maximum Transmission Unit (MTU) length, the payload of a CAPWAP data 481 or control message can be fragmented. The fragmentation behavior is 482 defined in Section 3. 484 The CAPWAP Protocol begins with a discovery phase. The WTPs send a 485 Discovery Request message, causing any Access Controller (AC) 486 receiving the message to respond with a Discovery Response message. 487 From the Discovery Response messages received, a WTP selects an AC 488 with which to establish a secure DTLS session. In order to establish 489 the secure DTLS connection, the WTP will need some amount of pre- 490 provisioning, which is specified in Section 12.5. CAPWAP protocol 491 messages will be fragmented to the maximum length discovered to be 492 supported by the network. 494 Once the WTP and the AC have completed DTLS session establishment, a 495 configuration exchange occurs in which both devices agree on version 496 information. During this exchange the WTP may receive provisioning 497 settings. The WTP is then enabled for operation. 499 When the WTP and AC have completed the version and provision exchange 500 and the WTP is enabled, the CAPWAP protocol is used to encapsulate 501 the wireless data frames sent between the WTP and AC. The CAPWAP 502 protocol will fragment the L2 frames if the size of the encapsulated 503 wireless user data (Data) or protocol control (Management) frames 504 causes the resulting CAPWAP protocol packet to exceed the MTU 505 supported between the WTP and AC. Fragmented CAPWAP packets are 506 reassembled to reconstitute the original encapsulated payload. MTU 507 Discovery and Fragmentation are described in Section 3. 509 The CAPWAP protocol provides for the delivery of commands from the AC 510 to the WTP for the management of stations that are communicating with 511 the WTP. This may include the creation of local data structures in 512 the WTP for the stations and the collection of statistical 513 information about the communication between the WTP and the stations. 514 The CAPWAP protocol provides a mechanism for the AC to obtain 515 statistical information collected by the WTP. 517 The CAPWAP protocol provides for a keep alive feature that preserves 518 the communication channel between the WTP and AC. If the AC fails to 519 appear alive, the WTP will try to discover a new AC. 521 2.1. Wireless Binding Definition 523 The CAPWAP protocol is independent of a specific WTP radio 524 technology, as well its associated wireless link layer protocol. 525 Elements of the CAPWAP protocol are designed to accommodate the 526 specific needs of each wireless technology in a standard way. 527 Implementation of the CAPWAP protocol for a particular wireless 528 technology MUST follow the binding requirements defined for that 529 technology. 531 When defining a binding for wireless technologies, the authors MUST 532 include any necessary definitions for technology-specific messages 533 and all technology-specific message elements for those messages. At 534 a minimum, a binding MUST provide: 536 1. The definition for a binding-specific Statistics message element, 537 carried in the WTP Event Request message 539 2. A message element carried in the Station Configuration Request 540 message to configure station information on the WTP 542 3. A WTP Radio Information message element carried in the Discovery, 543 Primary Discovery and Join Request and Response messages, 544 indicating the binding specific radio types supported at the WTP 545 and AC. 547 If technology specific message elements are required for any of the 548 existing CAPWAP messages defined in this specification, they MUST 549 also be defined in the technology binding document. 551 The naming of binding-specific message elements MUST begin with the 552 name of the technology type, e.g., the binding for IEEE 802.11, 553 provided in [I-D.ietf-capwap-protocol-binding-ieee80211], begins with 554 "IEEE 802.11". 556 The CAPWAP binding concept MUST also be used in any future 557 specification that add functionality to either the base CAPWAP 558 protocol specification, or any published CAPWAP binding 559 specification. A separate WTP Radio Information message element MUST 560 be created to properly advertise support for the specification. This 561 mechanism allows for future protocol extensibility, while providing 562 the necessary capabilities advertisement, through the WTP Radio 563 Information message element, to ensure WTP/AC interoperability. 565 2.2. CAPWAP Session Establishment Overview 567 This section describes the session establishment process message 568 exchanges between a CAPWAP WTP and AC. The annotated ladder diagram 569 shows the AC on the right, the WTP on the left, and assumes the use 570 of certificates for DTLS authentication. The CAPWAP Protocol State 571 Machine is described in detail in Section 2.3. Note that DTLS allows 572 certain messages to be aggregated into a single frame, which is 573 denoted via an asterisk in Figure 3. 575 ============ ============ 576 WTP AC 577 ============ ============ 578 [----------- begin optional discovery ------------] 580 Discover Request 581 ------------------------------------> 582 Discover Response 583 <------------------------------------ 585 [----------- end optional discovery ------------] 587 (-- begin DTLS handshake --) 589 ClientHello 590 ------------------------------------> 591 HelloVerifyRequest (with cookie) 592 <------------------------------------ 594 ClientHello (with cookie) 595 ------------------------------------> 596 ServerHello, 597 Certificate, 598 ServerHelloDone* 599 <------------------------------------ 601 (-- WTP callout for AC authorization --) 603 Certificate (optional), 604 ClientKeyExchange, 605 CertificateVerify (optional), 606 ChangeCipherSpec, 607 Finished* 608 ------------------------------------> 610 (-- AC callout for WTP authorization --) 612 ChangeCipherSpec, 613 Finished* 614 <------------------------------------ 616 (-- DTLS session is established now --) 618 Join Request 619 ------------------------------------> 620 Join Response 621 <------------------------------------ 622 [-- Join State Complete --] 624 (-- assume image is up to date --) 626 Configuration Status Request 627 ------------------------------------> 628 Configuration Status Response 629 <------------------------------------ 630 [-- Configure State Complete --] 632 Change State Event Request 633 ------------------------------------> 634 Change State Event Response 635 <------------------------------------ 636 [-- Data Check State Complete --] 638 (-- enter RUN state --) 640 : 641 : 643 Echo Request 644 ------------------------------------> 645 Echo Response 646 <------------------------------------ 648 : 649 : 651 Event Request 652 ------------------------------------> 653 Event Response 654 <------------------------------------ 655 : 656 : 658 Figure 3: CAPWAP Control Protocol Exchange 660 At the end of the illustrated CAPWAP message exchange, the AC and WTP 661 are securely exchanging CAPWAP control messages. This illustration 662 is provided to clarify protocol operation, and does not include any 663 possible error conditions. Section 2.3 provides a detailed 664 description of the corresponding state machine. 666 2.3. CAPWAP State Machine Definition 668 The following state diagram represents the lifecycle of a WTP-AC 669 session. Use of DTLS by the CAPWAP protocol results in the 670 juxtaposition of two nominally separate yet tightly bound state 671 machines. The DTLS and CAPWAP state machines are coupled through an 672 API consisting of commands (see Section 2.3.2.1) and notifications 673 (see Section 2.3.2.2). Certain transitions in the DTLS state machine 674 are triggered by commands from the CAPWAP state machine, while 675 certain transitions in the CAPWAP state machine are triggered by 676 notifications from the DTLS state machine. 678 /-------------------------------------\ 679 | /-------------------------\| 680 | p| || 681 | q+----------+ r +------------+ || 682 | | Run |-->| Reset |-\|| 683 | +----------+ +------------+ ||| 684 n| o ^ ^ ^ s||| 685 +------------+--------/ | | ||| 686 | Data Check | /-------/ | ||| 687 +------------+<-------\ | | ||| 688 | | | ||| 689 /------------------+--------\ | ||| 690 f| m| h| j v k| ||| 691 +--------+ +-----------+ +--------------+||| 692 | Join |---->| Configure | | Image Data |||| 693 +--------+ n +-----------+ +--------------+||| 694 ^ |g i| l| ||| 695 | | \-------------------\ | ||| 696 | \--------------------------------------\| | ||| 697 \------------------------\ || | ||| 698 /--------------<----------------+---------------\ || | ||| 699 | /------------<----------------+-------------\ | || | ||| 700 | | 4 |d t| | vv v vvv 701 | | +----------------+ +--------------+ +-----------+ 702 | | | DTLS Setup | | DTLS Connect |-->| DTLS TD | 703 /-|-|---+----------------+ +--------------+ e +-----------+ 704 | | | |$ ^ ^ |5 ^6 ^ ^ |w 705 v v v | | | | \-------\ | | | 706 | | | | | | \---------\ | | /-----------/ | 707 | | | | | \--\ | | | | | 708 | | | | | | | | | | | 709 | | | v 3| 1 |% # v | |a |b v 710 | | \->+------+-->+------+ +-----------+ +--------+ 711 | | | Idle | | Disc | | Authorize | | Dead | 712 | | +------+<--+------+ +-----------+ +--------+ 713 | | ^ 0^ 2 |! 714 | | | | | +-------+ 715 *| |u | \---------+---| Start | 716 | | |@ | +-------+ 717 | \->+---------+<------/ 718 \--->| Sulking | 719 +---------+& 721 Figure 4: CAPWAP Integrated State Machine 723 The CAPWAP protocol state machine, depicted above, is used by both 724 the AC and the WTP. In cases where states are not shared (i.e. not 725 implemented in one or the other of the AC or WTP), this is explicitly 726 called out in the transition descriptions below. For every state 727 defined, only certain messages are permitted to be sent and received. 728 The CAPWAP control message definitions specify the state(s) in which 729 each message is valid. 731 Since the WTP only communicates with a single AC, it only has a 732 single instance of the CAPWAP state machine. The state machine works 733 differently on the AC since it communicates with many WTPs. The AC 734 uses the concept of three threads. Note that the term thread used 735 here does not necessarily imply that implementers must use threads, 736 but it is one possible way of implementing the AC's state machine. 738 Listener Thread: The AC's Listener thread handles inbound DTLS 739 session establishment requests, through the DTLSListen command. 740 Upon creation, the Listener thread starts in the DTLS Setup state. 741 Once a DTLS session has been validated, which occurs when the 742 state machine enters the "Authorize" state, the Listener thread 743 creates a WTP session specific Service thread and state context. 744 The state machine transitions in Figure 4 are represented by 745 numerals. It is necessary for the AC to protect itself against 746 various attacks that exist with non-authenticated frames. See 747 Section 12 for more information. 749 Discovery Thread: The AC's Discovery thread is responsible for 750 receiving, and responding to, Discovery Request messages. The 751 state machine transitions in Figure 4 are represented by numerals. 752 Note that the Discovery thread does not maintain any per-WTP 753 specific context information, and a single state context exists. 754 It is necessary for the AC to protect itself against various 755 attacks that exist with non-authenticated frames. See Section 12 756 for more information. 758 Service Thread: The AC's Service thread handles the per-WTP states, 759 and one such thread exists per-WTP connection. This thread is 760 created by the listener thread when the Authorize state is 761 reached. When created, the Service thread inherits a copy of the 762 state machine context from the Listener thread. When 763 communication with the WTP is complete, the Service thread is 764 terminated and all associated resources are released. The state 765 machine transitions in Figure 4 are represented by alphabetic 766 characters. 768 2.3.1. CAPWAP Protocol State Transitions 770 This section describes the various state transitions, and the events 771 that cause them. This section does not discuss interactions between 772 DTLS- and CAPWAP-specific states. Those interactions, and DTLS- 773 specific states and transitions, are discussed in Section 2.3.2. 775 Start to Idle (0): This transition occurs once device initialization 776 is complete. 778 WTP: This state transition is used to start the WTP's CAPWAP 779 state machine. 781 AC: The AC creates the Discovery and Listener threads and starts 782 the CAPWAP state machine. 784 Idle to Discovery (1): This transition occurs to support the CAPWAP 785 discovery process . 787 WTP: The WTP enters the Discovery state prior to transmitting the 788 first Discovery Request message (see Section 5.1). Upon 789 entering this state, the WTP sets the DiscoveryInterval timer 790 (see Section 4.7). The WTP resets the DiscoveryCount counter 791 to zero (0) (see Section 4.8). The WTP also clears all 792 information from ACs it may have received during a previous 793 Discovery phase. 795 AC: This state transition is executed by the AC's Discovery 796 thread, and occurs when a Discovery Request message is 797 received. The AC SHOULD respond with a Discovery Response 798 message (see Section 5.2). 800 Discovery to Discovery (#): In the Discovery state, the WTP 801 determines which AC to connect to. 803 WTP: This transition occurs when the DiscoveryInterval timer 804 expires. If the WTP is configured with a list of ACs, it 805 transmits a Discovery Request message to every AC from which it 806 has not received a Discovery Response message. For every 807 transition to this event, the WTP increments the DiscoveryCount 808 counter. See Section 5.1 for more information on how the WTP 809 knows the ACs to which it should transmit the Discovery Request 810 messages. The WTP restarts the DiscoveryInterval timer 811 whenever it transmits Discovery Request messages. 813 AC: This is an invalid state transition for the AC. 815 Discovery to Idle (2): This transition occurs on the AC's Discovery 816 thread when the Discovery processing is complete. 818 WTP: This is an invalid state transition for the WTP. 820 AC: This state transition is executed by the AC's Discovery 821 thread when it has transmitted the Discovery Response, in 822 response to a Discovery Request. 824 Discovery to Sulking (!): This transition occurs on a WTP when AC 825 Discovery fails. 827 WTP: The WTP enters this state when the DiscoveryInterval timer 828 expires and the DiscoveryCount variable is equal to the 829 MaxDiscoveries variable (see Section 4.8). Upon entering this 830 state, the WTP MUST start the SilentInterval timer. While in 831 the Sulking state, all received CAPWAP protocol messages MUST 832 be ignored. 834 AC: This is an invalid state transition for the AC. 836 Sulking to Idle (@): This transition occurs on a WTP when it must 837 restart the discovery phase. 839 WTP: The WTP enters this state when the SilentInterval timer (see 840 Section 4.7) expires. The FailedDTLSSessionCount, 841 DiscoveryCount and FailedDTLSAuthFailCount counters are reset 842 to zero. 844 AC: This is an invalid state transition for the AC. 846 Sulking to Sulking (&): The Sulking state provides the silent 847 period, minimizing the possibility for Denial of Service (DoS) 848 attacks. 850 WTP: All packets received from the AC while in the sulking state 851 are ignored. 853 AC: This is an invalid state transition for the AC. 855 Idle to DTLS Setup (3): This transition occurs to establish a secure 856 DTLS session with the peer. 858 WTP: The WTP initiates this transition by invoking the DTLSStart 859 command(see Section 2.3.2.1), which starts the DTLS session 860 establishment with the chosen AC and the WaitDTLS timer is 861 started (see Section 4.7). When the discovery phase is 862 bypassed, it is assumed the WTP has locally configured ACs. 864 AC: Upon entering the Idle state from the Start state, the newly 865 created Listener thread automatically transitions to the DTLS 866 Setup and invokes the DTLSListen command (see Section 2.3.2.1), 867 and the WaitDTLS timer is started (see Section 4.7). 869 Discovery to DTLS Setup (%): This transition occurs to establish a 870 secure DTLS session with the peer. 872 WTP: The WTP initiates this transition by invoking the DTLSStart 873 command (see Section 2.3.2.1), which starts the DTLS session 874 establishment with the chosen AC. The decision of which AC to 875 connect to is the result of the discovery phase, which is 876 described in Section 3.3. 878 AC: This is an invalid state transition for the AC. 880 DTLS Setup to Idle ($): This transition occurs when the DTLS 881 connection setup fails. 883 WTP: The WTP initiates this state transition when it receives a 884 DTLSEstablishFail notification from DTLS (see Section 2.3.2.2), 885 and the FailedDTLSSessionCount or the FailedDTLSAuthFailCount 886 counter have not reached the value of the 887 MaxFailedDTLSSessionRetry variable (see Section 4.8). This 888 error notification aborts the secure DTLS session 889 establishment. When this notification is received, the 890 FailedDTLSSessionCount counter is incremented. This state 891 transition also occurs if the WaitDTLS timer has expired. 893 AC: This is an invalid state transition for the AC. 895 DTLS Setup to Sulking (*): This transition occurs when repeated 896 attempts to setup the DTLS connection have failed. 898 WTP: The WTP enters this state when the FailedDTLSSessionCount or 899 the FailedDTLSAuthFailCount counter reaches the value of the 900 MaxFailedDTLSSessionRetry variable (see Section 4.8). Upon 901 entering this state, the WTP MUST start the SilentInterval 902 timer. While in the Sulking state, all received CAPWAP and 903 DTLS protocol messages received MUST be ignored. 905 AC: This is an invalid state transition for the AC. 907 DTLS Setup to DTLS Setup (4): This transition occurs when the DTLS 908 Session failed to be established. 910 WTP: This is an invalid state transition for the WTP. 912 AC: The AC's Listener initiates this state transition when it 913 receives a DTLSEstablishFail notification from DTLS (see 914 Section 2.3.2.2). This error notification aborts the secure 915 DTLS session establishment. When this notification is 916 received, the FailedDTLSSessionCount counter is incremented. 918 The Listener thread then invokes the DTLSListen command (see 919 Section 2.3.2.1). 921 DTLS Setup to Authorize (5): This transition occurs when an incoming 922 DTLS session is being established, and the DTLS stack needs 923 authorization to proceed with the session establishment. 925 WTP: This state transition occurs when the WTP receives the 926 DTLSPeerAuthorize notification (see Section 2.3.2.2). Upon 927 entering this state, the WTP performs an authorization check 928 against the AC credentials. See Section 2.4.4 for more 929 information on AC authorization. 931 AC: This state transition is handled by the AC's Listener thread 932 when the DTLS module initiates the DTLSPeerAuthorize 933 notification (see Section 2.3.2.2). The Listener thread forks 934 an instance of the Service thread, along with a copy of the 935 state context. Once created, the Service thread performs an 936 authorization check against the WTP credentials. See 937 Section 2.4.4 for more information on WTP authorization. 939 Authorize to DTLS Setup (6): This transition is executed by the 940 Listener thread to enable it to listen for new incoming sessions. 942 WTP: This is an invalid state transition for the WTP. 944 AC: This state transition occurs when the AC's Listener thread 945 has created the WTP context and the Service thread. The 946 Listener thread then invokes the DTLSListen command (see 947 Section 2.3.2.1). 949 Authorize to DTLS Connect (a): This transition occurs to notify the 950 DTLS stack that the session should be established. 952 WTP: This state transition occurs when the WTP has successfully 953 authorized the AC's credentials (see Section 2.4.4). This is 954 done by invoking the DTLSAccept DTLS command (see 955 Section 2.3.2.1). 957 AC: This state transition occurs when the AC has successfully 958 authorized the WTP's credentials (see Section 2.4.4). This is 959 done by invoking the DTLSAccept DTLS command (see 960 Section 2.3.2.1). 962 Authorize to DTLS Teardown (b): This transition occurs to notify the 963 DTLS stack that the session should be aborted. 965 WTP: This state transition occurs when the WTP was unable to 966 authorize the AC, using the AC credentials. The WTP then 967 aborts the DTLS session by invoking the DTLSAbortSession 968 command (see Section 2.3.2.1). This state transition also 969 occurs if the WaitDTLS timer has expired. The WTP starts the 970 DTLSSessionDelete timer (see Section 4.7.6). 972 AC: This state transition occurs when the AC was unable to 973 authorize the WTP, using the WTP credentials. The AC then 974 aborts the DTLS session by invoking the DTLSAbortSession 975 command (see Section 2.3.2.1). This state transition also 976 occurs if the WaitDTLS timer has expired. The AC starts the 977 DTLSSessionDelete timer (see Section 4.7.6). 979 DTLS Connect to DTLS Teardown (c): This transition occurs when the 980 DTLS Session failed to be established. 982 WTP: This state transition occurs when the WTP receives either a 983 DTLSAborted or DTLSAuthenticateFail notification (see 984 Section 2.3.2.2), indicating that the DTLS session was not 985 successfully established. When this transition occurs due to 986 the DTLSAuthenticateFail notification, the 987 FailedDTLSAuthFailCount is incremented, otherwise the 988 FailedDTLSSessionCount counter is incremented. This state 989 transition also occurs if the WaitDTLS timer has expired. The 990 WTP starts the DTLSSessionDelete timer (see Section 4.7.6). 992 AC: This state transition occurs when the AC receives either a 993 DTLSAborted or DTLSAuthenticateFail notification (see 994 Section 2.3.2.2), indicating that the DTLS session was not 995 successfully established, and both of the 996 FailedDTLSAuthFailCount and FailedDTLSSessionCount counters 997 have not reached the value of the MaxFailedDTLSSessionRetry 998 variable (see Section 4.8). This state transition also occurs 999 if the WaitDTLS timer has expired. The AC starts the 1000 DTLSSessionDelete timer (see Section 4.7.6). 1002 DTLS Connect to Join (d): This transition occurs when the DTLS 1003 Session is successfully established. 1005 WTP: This state transition occurs when the WTP receives the 1006 DTLSEstablished notification (see Section 2.3.2.2), indicating 1007 that the DTLS session was successfully established. When this 1008 notification is received, the FailedDTLSSessionCount counter is 1009 set to zero. The WTP enters the Join state by transmiting the 1010 Join Request to the AC. The WTP stops the WaitDTLS timer. 1012 AC: This state transition occurs when the AC receives the 1013 DTLSEstablished notification (see Section 2.3.2.2), indicating 1014 that the DTLS session was successfully established. When this 1015 notification is received, the FailedDTLSSessionCount counter is 1016 set to zero. The AC stops the WaitDTLS timer. 1018 Join to DTLS Teardown (e): This transition occurs when the join 1019 process failed. 1021 WTP: This state transition occurs when the WTP receives a Join 1022 Response message with a Result Code message element containing 1023 an error, if the Image Identifier provided by the AC in the 1024 Join Response message differs from the WTP's currently running 1025 firmware version and the WTP has the requested image in its 1026 non-volatile memory, or if the WaitDTLS timer expires. This 1027 causes the WTP to initiate the DTLSShutdown command (see 1028 Section 2.3.2.1). This transition also occurs if the WTP 1029 receives one of the following DTLS notifications: DTLSAborted, 1030 DTLSReassemblyFailure or DTLSPeerDisconnect. The WTP starts 1031 the DTLSSessionDelete timer (see Section 4.7.6). 1033 AC: This state transition occurs either if the WaitDTLS timer 1034 expires or if the AC transmits a Join Response message with a 1035 Result Code message element containing an error. This causes 1036 the AC to initiate the DTLSShutdown command (see 1037 Section 2.3.2.1). This transition also occurs if the AC 1038 receives one of the following DTLS notifications: DTLSAborted, 1039 DTLSReassemblyFailure or DTLSPeerDisconnect. The AC starts the 1040 DTLSSessionDelete timer (see Section 4.7.6). 1042 Join to Image Data (f): This state transition is used by the WTP and 1043 the AC to download executable firmware. 1045 WTP: The WTP enters the Image Data state when it receives a 1046 successful Join Response message and determines that the 1047 software version in the Image Identifier message element is not 1048 the same as its currently running image. The WTP also detects 1049 that the requested image version is not currently available in 1050 the WTP's non-volatile storage (see Section 9.1 for a full 1051 description of the firmware download process). The WTP 1052 initializes the EchoInterval timer (see Section 4.7), and 1053 transmits the Image Data Request message (see Section 9.1.1) 1054 requesting the start of the firmware download. 1056 AC: This state transition occurs when the AC receives the Image 1057 Data Request message from the WTP, after having sent its Join 1058 Response to the WTP. The AC MUST transmit an Image Data 1059 Response message (see Section 9.1.2) to the WTP, which includes 1060 a portion of the firmware. The AC MUST start the 1061 ImageDataStartTimer timer (see Section 4.7). 1063 Join to Configure (g): This state transition is used by the WTP and 1064 the AC to exchange configuration information. 1066 WTP: The WTP enters the Configure state when it receives a 1067 successful Join Response message, and determines that the 1068 included Image Identifier message element is the same as its 1069 currently running image. The WTP transmits the Configuration 1070 Status message (see Section 8.2) to the AC with message 1071 elements describing its current configuration. 1073 AC: This state transition occurs when it receives the 1074 Configuration Status message from the WTP (see Section 8.2), 1075 which MAY include specific message elements to override the 1076 WTP's configuration. The AC transmits the Configuration Status 1077 Response message (see Section 8.3) and starts the 1078 ChangeStatePendingTimer timer (see Section 4.7). 1080 Configure to Reset (h): This state transition is used to reset the 1081 connection either due to an error during the configuration phase, 1082 or when the WTP determines it needs to reset in order for the new 1083 configuration to take effect. The CAPWAP Reset command is used to 1084 indicate to the peer that it will initiate a DTLS teardown. 1086 WTP: The WTP enters the Reset state when it receives a 1087 Configuration Status Response message indicating an error or 1088 when it determines that a reset of the WTP is required, due to 1089 the characteristics of a new configuration. 1091 AC: The AC transitions to the Reset state when it receives a 1092 Change State Event message from the WTP that contains an error 1093 for which AC policy does not permit the WTP to provide service. 1094 This state transition also occurs when the AC 1095 ChangeStatePendingTimer timer expires. 1097 Configure to DTLS Teardown (i): This transition occurs when the 1098 configuration process aborts due to a DTLS error. 1100 WTP: The WTP enters this state when it receives one of the 1101 following DTLS notifications: DTLSAborted, 1102 DTLSReassemblyFailure or DTLSPeerDisconnect (see 1103 Section 2.3.2.2). The WTP MAY tear down the DTLS session if it 1104 receives frequent DTLSDecapFailure notifications. The WTP 1105 starts the DTLSSessionDelete timer (see Section 4.7.6). 1107 AC: The AC enters this state when it receives one of the 1108 following DTLS notifications: DTLSAborted, 1109 DTLSReassemblyFailure or DTLSPeerDisconnect (see 1110 Section 2.3.2.2). The AC MAY tear down the DTLS session if it 1111 receives frequent DTLSDecapFailure notifications. The AC 1112 starts the DTLSSessionDelete timer (see Section 4.7.6). 1114 Image Data to Image Data (j): The Image Data state is used by the 1115 WTP and the AC during the firmware download phase. 1117 WTP: The WTP enters the Image Data state when it receives an 1118 Image Data Response message indicating that the AC has more 1119 data to send. This state transition also occurs when the WTP 1120 receives the subsequent Image Data Requests, at which time it 1121 resets the ImageDataStartTimer time to ensure it receives the 1122 next expected Image Data Request from the AC. 1124 AC: This state transition occurs when the AC receives the Image 1125 Data Response message from the WTP while already in the Image 1126 Data state. The AC disables the ImageDataStartTimer timer. 1128 Image Data to Reset (k): This state transition is used to reset the 1129 DTLS connection prior to restarting the WTP after an image 1130 download. 1132 WTP: When an image download completes, or if the 1133 ImageDataStartTimer timer expires, the WTP enters the Reset 1134 state. The WTP MAY also transition to this state upon 1135 receiving an Image Data Response message from the AC (see 1136 Section 9.1.2) indicating a failure. 1138 AC: The AC enters the Reset state either when the image transfer 1139 has successfully completed, an error occurs during the image 1140 download process or if the ImageDataStartTimer timer expires. 1142 Image Data to DTLS Teardown (l): This transition occurs when the 1143 firmware download process aborts due to a DTLS error. 1145 WTP: The WTP enters this state when it receives one of the 1146 following DTLS notifications: DTLSAborted, 1147 DTLSReassemblyFailure or DTLSPeerDisconnect (see 1148 Section 2.3.2.2). The WTP MAY tear down the DTLS session if it 1149 receives frequent DTLSDecapFailure notifications. The WTP 1150 starts the DTLSSessionDelete timer (see Section 4.7.6). 1152 AC: The AC enters this state when it receives one of the 1153 following DTLS notifications: DTLSAborted, 1154 DTLSReassemblyFailure or DTLSPeerDisconnect (see 1155 Section 2.3.2.2). The AC MAY tear down the DTLS session if it 1156 receives frequent DTLSDecapFailure notifications. The AC 1157 starts the DTLSSessionDelete timer (see Section 4.7.6). 1159 Configure to Data Check (m): This state transition occurs when the 1160 WTP and AC confirm the configuration. 1162 WTP: The WTP enters this state when it receives a successful 1163 Configuration Status Response message from the AC. The WTP 1164 initializes the EchoInterval timer (see Section 4.7), and 1165 transmits the Change State Event Request message (see 1166 Section 8.6). 1168 AC: This state transition occurs when the AC receives the Change 1169 State Event Request message (see Section 8.6) from the WTP. 1170 The AC responds with a Change State Event Response message (see 1171 Section 8.7). The AC MUST start the DataCheckTimer timer and 1172 stops the ChangeStatePendingTimer timer (see Section 4.7). 1174 Data Check to DTLS Teardown (n): This transition occurs when the WTP 1175 does not complete the Data Check exchange. 1177 WTP: This state transition occurs if the WTP does not receive the 1178 Change State Event Response message before a CAPWAP 1179 retransmission timeout occurs. The WTP also transitions to 1180 this state if the underlying reliable transport's 1181 RetransmitCount counter has reached the MaxRetransmit variable 1182 (see Section 4.7). The WTP starts the DTLSSessionDelete timer 1183 (see Section 4.7.6). 1185 AC: The AC enters this state when the DataCheckTimer timer 1186 expires (see Section 4.7). The AC starts the DTLSSessionDelete 1187 timer (see Section 4.7.6). 1189 Data Check to Run (o): This state transition occurs when the linkage 1190 between the control and data channels is established, causing the 1191 WTP and AC to enter their normal state of operation. 1193 WTP: The WTP enters this state when it receives a successful 1194 Change State Event Response message from the AC. The WTP 1195 initiates the data channel, which MAY require the establishment 1196 of a DTLS session, starts the DataChannelKeepAlive timer (see 1197 Section 4.7.2) and transmits a Data Channel Keep Alive packet 1198 (see Section 4.4.1). The WTP then starts the 1199 DataChannelDeadInterval timer (see Section 4.7). 1201 AC: This state transition occurs when the AC receives the Data 1202 Channel Keep Alive packet (see Section 4.4.1), with a Session 1203 ID message element matching that included by the WTP in the 1204 Join Request message. The AC disables the DataCheckTimer 1205 timer. Note that if AC policy is to require the data channel 1206 to be encrypted, this process would also require the 1207 establishment of a data channel DTLS session. Upon receiving 1208 the Data Channel Keep Alive packet, the AC transmits its own 1209 Data Channel Keep Alive packet. 1211 Run to DTLS Teardown (p): This state transition occurs when an error 1212 has occurred in the DTLS stack, causing the DTLS session to be 1213 torn down. 1215 WTP: The WTP enters this state when it receives one of the 1216 following DTLS notifications: DTLSAborted, 1217 DTLSReassemblyFailure or DTLSPeerDisconnect (see 1218 Section 2.3.2.2). The WTP MAY tear down the DTLS session if it 1219 receives frequent DTLSDecapFailure notifications. The WTP also 1220 transitions to this state if the underlying reliable 1221 transport's RetransmitCount counter has reached the 1222 MaxRetransmit variable (see Section 4.7). The WTP starts the 1223 DTLSSessionDelete timer (see Section 4.7.6). 1225 AC: The AC enters this state when it receives one of the 1226 following DTLS notifications: DTLSAborted, 1227 DTLSReassemblyFailure or DTLSPeerDisconnect (see 1228 Section 2.3.2.2). The AC MAY tear down the DTLS session if it 1229 receives frequent DTLSDecapFailure notifications. The AC 1230 transitions to this state if the underlying reliable 1231 transport's RetransmitCount counter has reached the 1232 MaxRetransmit variable (see Section 4.7). This state 1233 transition also occurs when the AC's EchoInterval timer (see 1234 Section 4.7.7) expires. The AC starts the DTLSSessionDelete 1235 timer (see Section 4.7.6). 1237 Run to Run (q): This is the normal state of operation. 1239 WTP: This is the WTP's normal state of operation. The WTP resets 1240 its EchoInterval timer whenever it transmits a request to the 1241 AC. There are many events that result this state transition: 1243 Configuration Update: The WTP receives a Configuration Update 1244 Request message(see Section 8.4). The WTP MUST respond with 1245 a Configuration Update Response message (see Section 8.5). 1247 Change State Event: The WTP receives a Change State Event 1248 Response message, or determines that it must initiate a 1249 Change State Event Request message, as a result of a failure 1250 or change in the state of a radio. 1252 Echo Request: The WTP sends an Echo Request message 1253 (Section 7.1) or receives the corresponding Echo Response 1254 message, (see Section 7.2) from the AC. When the WTP 1255 receives the Echo Response, it resets its EchoInterval timer 1256 (see Section 4.7.7). 1258 Clear Config Request: The WTP receives a Clear Configuration 1259 Request message (see Section 8.8) and MUST generate a 1260 corresponding Clear Configuration Response message (see 1261 Section 8.9). The WTP MUST reset its configuration back to 1262 manufacturer defaults. 1264 WTP Event: The WTP sends a WTP Event Request message, 1265 delivering information to the AC (see Section 9.4). The WTP 1266 receives a WTP Event Response message from the AC (see 1267 Section 9.5). 1269 Data Transfer: The WTP sends a Data Transfer Request or Data 1270 Transfer Response message to the AC (see Section 9.6). The 1271 WTP receives a Data Transfer Request or Data Transfer 1272 Response message from the AC (see Section 9.6). Upon 1273 receipt of a Data Transfer Request, the WTP transmits a Data 1274 Transfer Response to the AC. 1276 Station Configuration Request: The WTP receives a Station 1277 Configuration Request message (see Section 10.1), to which 1278 it MUST respond with a Station Configuration Response 1279 message (see Section 10.2). 1281 AC: This is the AC's normal state of operation. Note that the 1282 receipt of any Request from the WTP causes the AC to reset its 1283 EchoInterval timer (see Section 4.7.7). 1285 Configuration Update: The AC sends a Configuration Update 1286 Request message (see Section 8.4) to the WTP to update its 1287 configuration. The AC receives a Configuration Update 1288 Response message (see Section 8.5) from the WTP. 1290 Change State Event: The AC receives a Change State Event 1291 Request message (see Section 8.6), to which it MUST respond 1292 with the Change State Event Response message (see 1293 Section 8.7). 1295 Echo Request: The AC receives an Echo Request message (see 1296 Section 7.1), to which it MUST respond with an Echo Response 1297 message(see Section 7.2). 1299 Clear Config Response: The AC sends a Clear Configuration 1300 Request message (see Section 8.8) to the WTP to clear its 1301 configuration. The AC receives a Clear Configuration 1302 Response message from the WTP (see Section 8.9). 1304 WTP Event: The AC receives a WTP Event Request message from 1305 the WTP (see Section 9.4) and MUST generate a corresponding 1306 WTP Event Response message (see Section 9.5). 1308 Data Transfer: The AC sends a Data Transfer Request or Data 1309 Transfer Response message to the WTP (see Section 9.6). The 1310 AC receives a Data Transfer Request or Data Transfer 1311 Response message from the WTP (see Section 9.6). Upon 1312 receipt of a Data Transfer Request, the AC transmits a Data 1313 Transfer Response to the WTP. 1315 Station Configuration Request: The AC sends a Station 1316 Configuration Request message (see Section 10.1) or receives 1317 the corresponding Station Configuration Response message 1318 (see Section 10.2) from the WTP. 1320 Run to Reset (r): This state transition is used when either the AC 1321 or WTP tear down the connection. This may occur as part of normal 1322 operation, or due to error conditions. 1324 WTP: The WTP enters the Reset state when it receives a Reset 1325 Request message from the AC. 1327 AC: The AC enters the Reset state when it transmits a Reset 1328 Request message to the WTP. 1330 Reset to DTLS Teardown (s): This transition occurs when the CAPWAP 1331 reset is complete, to terminate the DTLS session. 1333 WTP: This state transition occurs when the WTP transmits a Reset 1334 Response message. The WTP does not invoke the DTLSShutdown 1335 command (see Section 2.3.2.1). The WTP starts the 1336 DTLSSessionDelete timer (see Section 4.7.6). 1338 AC: This state transition occurs when the AC receives a Reset 1339 Response message. This causes the AC to initiate the 1340 DTLSShutdown command (see Section 2.3.2.1). The AC starts the 1341 DTLSSessionDelete timer (see Section 4.7.6). 1343 DTLS Teardown to Idle (t): This transition occurs when the DTLS 1344 session has been shutdown. 1346 WTP: This state transition occurs when the WTP has successfully 1347 cleaned up all resources associated with the control plane DTLS 1348 session, or if the DTLSSessionDelete timer (see Section 4.7.6) 1349 expires. The data plane DTLS session is also shutdown, and all 1350 resources released, if a DTLS session was established for the 1351 data plane. Any timers set for the current instance of the 1352 state machine are also cleared. 1354 AC: This is an invalid state transition for the AC. 1356 DTLS Teardown to Sulking (u): This transition occurs when repeated 1357 attempts to setup the DTLS connection have failed. 1359 WTP: The WTP enters this state when the FailedDTLSSessionCount or 1360 the FailedDTLSAuthFailCount counter reaches the value of the 1361 MaxFailedDTLSSessionRetry variable (see Section 4.8). Upon 1362 entering this state, the WTP MUST start the SilentInterval 1363 timer. While in the Sulking state, all received CAPWAP and 1364 DTLS protocol messages received MUST be ignored. 1366 AC: This is an invalid state transition for the AC. 1368 DTLS Teardown to Dead (w): This transition occurs when the DTLS 1369 session has been shutdown. 1371 WTP: This is an invalid state transition for the WTP. 1373 AC: This state transition occurs when the AC has successfully 1374 cleaned up all resources associated with the control plane DTLS 1375 session , or if the DTLSSessionDelete timer (see Section 4.7.6) 1376 expires. The data plane DTLS session is also shutdown, and all 1377 resources released, if a DTLS session was established for the 1378 data plane. Any timers set for the current instance of the 1379 state machine are also cleared. The AC's Service thread is 1380 terminated. 1382 2.3.2. CAPWAP/DTLS Interface 1384 This section describes the DTLS Commands used by CAPWAP, and the 1385 notifications received from DTLS to the CAPWAP protocol stack. 1387 2.3.2.1. CAPWAP to DTLS Commands 1389 Six commands are defined for the CAPWAP to DTLS API. These 1390 "commands" are conceptual, and may be implemented as one or more 1391 function calls. This API definition is provided to clarify 1392 interactions between the DTLS and CAPWAP components of the integrated 1393 CAPWAP state machine. 1395 Below is a list of the minimal command API: 1397 o DTLSStart is sent to the DTLS component to cause a DTLS session to 1398 be established. Upon invoking the DTLSStart command, the WaitDTLS 1399 timer is started. The WTP initiates this DTLS command, as the AC 1400 does not initiate DTLS sessions. 1402 o DTLSListen is sent to the DTLS component to allow the DTLS 1403 component to listen for incoming DTLS session requests. 1405 o DTLSAccept is sent to the DTLS component to allow the DTLS session 1406 establishment to continue successfully. 1408 o DTLSAbortSession is sent to the DTLS component to cause the 1409 session that is in the process of being established to be aborted. 1410 This command is also sent when the WaitDTLS timer expires. When 1411 this command is executed, the FailedDTLSSessionCount counter is 1412 incremented. 1414 o DTLSShutdown is sent to the DTLS component to cause session 1415 teardown. 1417 o DTLSMtuUpdate is sent by the CAPWAP component to modify the MTU 1418 size used by the DTLS component. See Section 3.5 for more 1419 information on MTU Discovery. The default size is 1468 bytes. 1421 2.3.2.2. DTLS to CAPWAP Notifications 1423 DTLS notifications are defined for the DTLS to CAPWAP API. These 1424 "notifications" are conceptual, and may be implemented in numerous 1425 ways (e.g. as function return values). This API definition is 1426 provided to clarify interactions between the DTLS and CAPWAP 1427 components of the integrated CAPWAP state machine. It is important 1428 to note that the notifications listed below MAY cause the CAPWAP 1429 state machine to jump from one state to another using a state 1430 transition not listed in Section 2.3.1. When a notification listed 1431 below occurs, the target CAPWAP state shown in Figure 4 becomes the 1432 current state. 1434 Below is a list of the API notifications: 1436 o DTLSPeerAuthorize is sent to the CAPWAP component during DTLS 1437 session establishment once the peer's identity has been received. 1438 This notification MAY be used by the CAPWAP component to authorize 1439 the session, based on the peer's identity. The authorization 1440 process will lead to the CAPWAP component initiating either the 1441 DTLSAccept or DTLSAbortSession commands. 1443 o DTLSEstablished is sent to the CAPWAP component to indicate that 1444 that a secure channel now exists, using the parameters provided 1445 during the DTLS initialization process. When this notification is 1446 received, the FailedDTLSSessionCount counter is reset to zero. 1447 When this notification is received, the WaitDTLS timer is stopped. 1449 o DTLSEstablishFail is sent when the DTLS session establishment has 1450 failed, either due to a local error, or due to the peer rejecting 1451 the session establishment. When this notification is received, 1452 the FailedDTLSSessionCount counter is incremented. 1454 o DTLSAuthenticateFail is sent when DTLS session establishment 1455 failed due to an authentication error. When this notification is 1456 received, the FailedDTLSAuthFailCount counter is incremented. 1458 o DTLSAborted is sent to the CAPWAP component to indicate that 1459 session abort (as requested by CAPWAP) is complete; this occurs to 1460 confirm a DTLS session abort, or when the WaitDTLS timer expires. 1461 When this notification is received, the WaitDTLS timer is stopped. 1463 o DTLSReassemblyFailure MAY be sent to the CAPWAP component to 1464 indicate DTLS fragment reassembly failure. 1466 o DTLSDecapFailure MAY be sent to the CAPWAP module to indicate a 1467 decapsulation failure. DTLSDecapFailure MAY be sent to the CAPWAP 1468 module to indicate an encryption/authentication failure. This 1469 notification is intended for informative purposes only, and is not 1470 intended to cause a change in the CAPWAP state machine (see 1471 Section 12.4). 1473 o DTLSPeerDisconnect is sent to the CAPWAP component to indicate the 1474 DTLS session has been torn down. Note that this notification is 1475 only received if the DTLS session has been established. 1477 2.4. Use of DTLS in the CAPWAP Protocol 1479 DTLS is used as a tightly-integrated, secure wrapper for the CAPWAP 1480 protocol. In this document DTLS and CAPWAP are discussed as 1481 nominally distinct entities; however they are very closely coupled, 1482 and may even be implemented inseparably. Since there are DTLS 1483 library implementations currently available, and since security 1484 protocols (e.g. IPsec, TLS) are often implemented in widely 1485 available acceleration hardware, it is both convenient and forward- 1486 looking to maintain a modular distinction in this document. 1488 This section describes a detailed walk-through of the interactions 1489 between the DTLS module and the CAPWAP module, via 'commands' (CAPWAP 1490 to DTLS) and 'notifications' (DTLS to CAPWAP) as they would be 1491 encountered during the normal course of operation. 1493 2.4.1. DTLS Handshake Processing 1495 Details of the DTLS handshake process are specified in [RFC4347]. 1496 This section describes the interactions between the DTLS session 1497 establishment process and the CAPWAP protocol. Note that the 1498 conceptual DTLS state is shown below to help understand the point at 1499 which the DTLS states transition. In the normal case, the DTLS 1500 handshake will proceed as shown in Figure 5. (NOTE: this example 1501 uses certificates, but preshared keys are also supported): 1503 ============ ============ 1504 WTP AC 1505 ============ ============ 1506 ClientHello ------> 1507 <------ HelloVerifyRequest 1508 (with cookie) 1510 ClientHello ------> 1511 (with cookie) 1512 <------ ServerHello 1513 <------ Certificate 1514 <------ ServerHelloDone 1516 (WTP callout for AC authorization 1517 occurs in CAPWAP Auth state) 1519 Certificate* 1520 ClientKeyExchange 1521 CertificateVerify* 1522 ChangeCipherSpec 1523 Finished ------> 1525 (AC callout for WTP authorization 1526 occurs in CAPWAP Auth state) 1528 ChangeCipherSpec 1529 <------ Finished 1531 Figure 5: DTLS Handshake 1533 DTLS, as specified, provides its own retransmit timers with an 1534 exponential back-off. However, DTLS will never terminate the 1535 handshake due to non-responsiveness; instead, DTLS will continue to 1536 increase its back-off timer period. Hence, timing out incomplete 1537 DTLS handshakes is entirely the responsibility of the CAPWAP module. 1539 The DTLS implementation used by CAPWAP MUST support TLS Session 1540 Resumption. Session resumption is used to establish the DTLS session 1541 used for the data channel. The DTLS implementation on the WTP MUST 1542 return some unique identifier to the CAPWAP module to enable 1543 subsequent establishment of a DTLS-encrypted data channel, if 1544 necessary. 1546 2.4.2. DTLS Session Establishment 1548 The WTP, either through the Discovery process, or through pre- 1549 configuration, determines the AC to connect to. The WTP uses the 1550 DTLSStart command to request that a secure connection be established 1551 to the selected AC. Prior to initiation of the DTLS handshake, the 1552 WTP sets the WaitDTLS timer. Upon receiving the DTLSPeerAuthorize 1553 DTLS notification, the AC sets the WaitDTLS timer. If the 1554 DTLSEstablished notification is not received prior to timer 1555 expiration, the DTLS session is aborted by issuing the 1556 DTLSAbortSession DTLS command. This notification causes the CAPWAP 1557 module to transition to the Idle state. Upon receiving a 1558 DTLSEstablished notification, the WaitDTLS timer is deactivated. 1560 2.4.3. DTLS Error Handling 1562 If the AC does not respond to any DTLS messages sent by the WTP, the 1563 DTLS specification calls for the WTP to retransmit these messages. 1564 If the WaitDTLS timer expires, CAPWAP will issue the DTLSAbortSession 1565 command, causing DTLS to terminate the handshake and remove any 1566 allocated session context. Note that DTLS MAY send a single TLS 1567 Alert message to the AC to indicate session termination. 1569 If the WTP does not respond to any DTLS messages sent by the AC, the 1570 CAPWAP protocol allows for three possibilities, listed below. Note 1571 that DTLS MAY send a single TLS Alert message to the AC to indicate 1572 session termination. 1574 o The message was lost in transit; in this case, the WTP will re- 1575 transmit its last outstanding message, since it did not receive a 1576 reply. 1578 o The WTP sent a DTLS Alert, which was lost in transit; in this 1579 case, the AC's WaitDTLS timer will expire, and the session will be 1580 terminated. 1582 o Communication with the WTP has completely failed; in this case, 1583 the AC's WaitDTLS timer will expire, and the session will be 1584 terminated. 1586 The DTLS specification provides for retransmission of unacknowledged 1587 requests. If retransmissions remain unacknowledged, the WaitDTLS 1588 timer will eventually expire, at which time the CAPWAP component will 1589 terminate the session. 1591 If a cookie fails to validate, this could represent a WTP error, or 1592 it could represent a DoS attack. Hence, AC resource utilization 1593 SHOULD be minimized. The AC MAY log a message indicating the 1594 failure, but SHOULD NOT attempt to reply to the WTP. 1596 Since DTLS handshake messages are potentially larger than the maximum 1597 record size, DTLS supports fragmenting of handshake messages across 1598 multiple records. There are several potential causes of re-assembly 1599 errors, including overlapping and/or lost fragments. The DTLS 1600 component MUST send a DTLSReassemblyFailure notification to the 1601 CAPWAP component. Whether precise information is given along with 1602 notification is an implementation issue, and hence is beyond the 1603 scope of this document. Upon receipt of such an error, the CAPWAP 1604 component SHOULD log an appropriate error message. Whether 1605 processing continues or the DTLS session is terminated is 1606 implementation dependent. 1608 DTLS decapsulation errors consist of three types: decryption errors, 1609 authentication errors, and malformed DTLS record headers. Since DTLS 1610 authenticates the data prior to encapsulation, if decryption fails, 1611 it is difficult to detect this without first attempting to 1612 authenticate the packet. If authentication fails, a decryption error 1613 is also likely, but not guaranteed. Rather than attempt to derive 1614 (and require the implementation of) algorithms for detecting 1615 decryption failures, decryption failures are reported as 1616 authentication failures. The DTLS component MUST provide a 1617 DTLSDecapFailure notification to the CAPWAP component when such 1618 errors occur. If a malformed DTLS record header is detected, the 1619 packets SHOULD be silently discarded, and the receiver MAY log an 1620 error message. 1622 There is currently only one encapsulation error defined: MTU 1623 exceeded. As part of DTLS session establishment, the CAPWAP 1624 component informs the DTLS component of the MTU size. This may be 1625 dynamically modified at any time when the CAPWAP component sends the 1626 DTLSMtuUpdate command to the DTLS component (see Section 2.3.2.1). 1627 The value provided to the DTLS stack is the result of the MTU 1628 Discovery process, which is described in Section 3.5. The DTLS 1629 component returns this notification to the CAPWAP component whenever 1630 a transmission request will result in a packet which exceeds the MTU. 1632 2.4.4. DTLS EndPoint Authentication and Authorization 1634 DTLS supports endpoint authentication with certificates or preshared 1635 keys. The TLS algorithm suites for each endpoint authentication 1636 method are described below. 1638 2.4.4.1. Authenticating with Certificates 1640 CAPWAP implementations only use cipher suites that are recommended 1641 for use with DTLS, see [DTLS-DESIGN]. At present, the following 1642 algorithms MUST be supported when using certificates for CAPWAP 1643 authentication: 1645 o TLS_RSA_WITH_AES_128_CBC_SHA [RFC4279] 1647 The following algorithms SHOULD be supported when using certificates: 1649 o TLS_DHE_RSA_WITH_AES_128_CBC_SHA [RFC4279] 1651 The following algorithms MAY be supported when using certificates: 1653 o TLS_RSA_WITH_AES_256_CBC_SHA [RFC4279] 1655 o TLS_DHE_RSA_WITH_AES_256_CBC_SHA [RFC4279] 1657 Additional ciphers MAY be defined in follow on CAPWAP specifications. 1659 2.4.4.2. Authenticating with Preshared Keys 1661 Pre-shared keys present significant challenges from a security 1662 perspective, and for that reason, their use is strongly discouraged. 1663 Several methods for authenticating with preshared keys are defined 1664 [RFC4279], and we focus on the following two: 1666 o Pre-Shared Key (PSK) key exchange algorithm - simplest method, 1667 ciphersuites use only symmetric key algorithms 1669 o DHE_PSK key exchange algorithm - use a PSK to authenticate a 1670 Diffie-Hellman exchange. These ciphersuites give some additional 1671 protection against dictionary attacks and also provide Perfect 1672 Forward Secrecy (PFS). 1674 The first approach (plain PSK) is susceptible to passive dictionary 1675 attacks; hence, while this algorithm MUST be supported, special care 1676 should be taken when choosing that method. In particular, user- 1677 readable passphrases SHOULD NOT be used, and use of short PSKs SHOULD 1678 be strongly discouraged. 1680 The following cryptographic algorithms MUST be supported when using 1681 preshared keys: 1683 o TLS_PSK_WITH_AES_128_CBC_SHA [RFC4279] 1685 o TLS_DHE_PSK_WITH_AES_128_CBC_SHA [RFC4279] 1687 The following algorithms MAY be supported when using preshared keys: 1689 o TLS_PSK_WITH_AES_256_CBC_SHA [RFC4279] 1691 o TLS_DHE_PSK_WITH_AES_256_CBC_SHA [RFC4279] 1693 o TLS_DHE_PSK_WITH_AES_256_CBC_SHA [RFC4279] 1695 Additional ciphers MAY be defined in follow on CAPWAP specifications. 1697 2.4.4.3. Certificate Usage 1699 Certificate authorization by the AC and WTP is required so that only 1700 an AC may perform the functions of an AC and that only a WTP may 1701 perform the functions of a WTP. This restriction of functions to the 1702 AC or WTP requires that the certificates used by the AC MUST be 1703 distinguishable from the certificate used by the WTP. To accomplish 1704 this differentiation, the x.509 certificates MUST include the 1705 Extended Key Usage (EKU) certificate extension [RFC5280]. 1707 The EKU field indicates one or more purposes for which a certificate 1708 may be used. It is an essential part in authorization. Its syntax 1709 is as follows: 1711 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 1713 KeyPurposeId ::= OBJECT IDENTIFIER 1715 Here we define two KeyPurposeId values, one for the WTP and one for 1716 the AC. Inclusion of one of these two values indicates a certificate 1717 is authorized for use by a WTP or AC, respectively. These values are 1718 formatted as id-kp fields. 1720 id-kp OBJECT IDENTIFIER ::= 1721 { iso(1) identified-organization(3) dod(6) internet(1) 1722 security(5) mechanisms(5) pkix(7) 3 } 1724 id-kp-capwapAC OBJECT IDENTIFIER ::= { id-kp 18 } 1726 id-kp-capwapWTP OBJECT IDENTIFIER ::= { id-kp 19 } 1728 All capwap devices MUST support the ExtendedKeyUsage certificate 1729 extension if it is present in a certificate. If the extension is 1730 present, then the certificate MUST have either the id-kp-capwapAC or 1731 the id-kp-anyExtendedKeyUsage keyPurposeID to act as an AC. 1732 Similarly, if the extension is present, a device MUST have the id-kp- 1733 capwapWTP or id-kp-anyExtendedKeyUsage keyPurposeID to act as a WTP. 1735 Part of the CAPWAP certificate validation process includes ensuring 1736 that the proper EKU is included and allowing the CAPWAP session to be 1737 established only if the extension properly represents the device. 1738 For instance, an AC SHOULD NOT accept a connection request from 1739 another AC, and therefore MUST verify that the id-kp-capwapWTP EKU is 1740 present in the certificate. 1742 CAPWAP implementations MUST support certificates where the common 1743 name (CN) for both the WTP and AC is the MAC address of that device. 1744 The MAC address MUST be formatted as ASCII HEX, e.g. 1745 01:23:45:67:89:ab. Note that the CN field MAY contain either of the 1746 EUI-48 [EUI-48] or EUI-64 [EUI-64] MAC Address formats. 1748 ACs and WTPs MUST authorize (e.g. through access control lists) 1749 certificates of devices to which they are connecting, e.g., based on 1750 the issuer, MAC address, or organizational information specified in 1751 the certificate. The identities specified in the certificates bind a 1752 particular DTLS session to a specific pair of mutually-authenticated 1753 and authorized MAC addresses. The particulars of authorization 1754 filter construction are implementation details which are, for the 1755 most part, not within the scope of this specification. However, at 1756 minimum, all devices MUST verify that the appropriate EKU bit is set 1757 according to the role of the peer device (AC vs. WTP), and that the 1758 issuer of the certificate is appropriate for the domain in question. 1760 2.4.4.4. PSK Usage 1762 When DTLS uses PSK Ciphersuites, the ServerKeyExchange message MUST 1763 contain the "PSK identity hint" field and the ClientKeyExchange 1764 message MUST contain the "PSK identity" field. These fields are used 1765 to help the WTP select the appropriate PSK for use with the AC, and 1766 then indicate to the AC which key is being used. When PSKs are 1767 provisioned to WTPs and ACs, both the PSK Hint and PSK Identity for 1768 the key MUST be specified. 1770 The PSK Hint SHOULD uniquely identify the AC and the PSK Identity 1771 SHOULD uniquely identify the WTP. It is RECOMMENDED that these hints 1772 and identities be the ASCII HEX-formatted MAC addresses of the 1773 respective devices, since each pairwise combination of WTP and AC 1774 SHOULD have a unique PSK. The PSK hint and identity SHOULD be 1775 sufficient to perform authorization, as simply having knowledge of a 1776 PSK does not necessarily imply authorization. 1778 If a single PSK is being used for multiple devices on a CAPWAP 1779 network, which is NOT RECOMMENDED, the PSK Hint and Identity can no 1780 longer be a MAC address, so appropriate hints and identities SHOULD 1781 be selected to identify the group of devices to which the PSK is 1782 provisioned. 1784 3. CAPWAP Transport 1786 Communication between a WTP and an AC is established using the 1787 standard UDP client/server model. The CAPWAP protocol supports both 1788 UDP and UDP-Lite [RFC3828] transport protocols. When run over IPv4, 1789 UDP is used for the CAPWAP control and data channels. 1791 When run over IPv6, the CAPWAP control channel always uses UDP, while 1792 the CAPWAP data channel may use either UDP or UDP-Lite. UDP-Lite is 1793 the default transport protocol for the CAPWAP data channel. However, 1794 if a middlebox or IPv4 to IPv6 gateway has been discovered, UDP is 1795 used for the CAPWAP data channel. 1797 This section describes how the CAPWAP protocol is carried over IP and 1798 UDP/UDP-Lite transport protocols. The CAPWAP Transport Protocol 1799 message element Section 4.6.15 describes the rules to use in 1800 determining which transport protocol is to be used. 1802 3.1. UDP Transport 1804 One of the CAPWAP protocol requirements is to allow a WTP to reside 1805 behind a middlebox, firewall and/or Network Address Translation (NAT) 1806 device. Since a CAPWAP session is initiated by the WTP (client) to 1807 the well-known UDP port of the AC (server), the use of UDP is a 1808 logical choice. The UDP checksum field in CAPWAP packets MUST be set 1809 to zero. 1811 CAPWAP protocol control packets sent from the WTP to the AC use the 1812 CAPWAP control channel, as defined in Section 1.4. The CAPWAP 1813 control port at the AC is the well known UDP port 5246. The CAPWAP 1814 control port at the WTP can be any port selected by the WTP. 1816 CAPWAP protocol data packets sent from the WTP to the AC use the 1817 CAPWAP data channel, as defined in Section 1.4. The CAPWAP data port 1818 at the AC is the well known UDP port 5247. The CAPWAP data port at 1819 the WTP can be any port selected by the WTP. 1821 3.2. UDP-Lite Transport 1823 When CAPWAP is run over IPv6, UDP-Lite is the default transport 1824 protocol, which reduces the checksum processing required for each 1825 packet (compared to the use of UDP over IPv6 [RFC2460]). When UDP- 1826 Lite is used, the checksum field MUST have a coverage of 8 [RFC3828]. 1828 UDP-Lite uses the same port assignments as UDP. 1830 3.3. AC Discovery 1832 The AC discovery phase allows the WTP to determine which ACs are 1833 available, and chose the best AC with which to establish a CAPWAP 1834 session. The discovery phase occurs when the WTP enters the optional 1835 Discovery state. A WTP does not need to complete the AC Discovery 1836 phase if it uses a pre-configured AC. This section details the 1837 mechanism used by a WTP to dynamically discover candidate ACs. 1839 A WTP and an AC will frequently not reside in the same IP subnet 1840 (broadcast domain). When this occurs, the WTP must be capable of 1841 discovering the AC, without requiring that multicast services are 1842 enabled in the network. 1844 When the WTP attempts to establish communication with an AC, it sends 1845 the Discovery Request message and receives the Discovery Response 1846 message from the AC(s). The WTP MUST send the Discovery Request 1847 message to either the limited broadcast IP address (255.255.255.255), 1848 a well known multicast address or to the unicast IP address of the 1849 AC. For IPv6 networks, since broadcast does not exist, the use of 1850 "All ACs multicast address" is used instead. Upon receipt of the 1851 Discovery Request message, the AC sends a Discovery Response message 1852 to the unicast IP address of the WTP, regardless of whether the 1853 Discovery Request message was sent as a broadcast, multicast or 1854 unicast message. 1856 WTP use of a limited IP broadcast, multicast or unicast IP address is 1857 implementation dependent. 1859 When a WTP transmits a Discovery Request message to a unicast 1860 address, the WTP must first obtain the IP address of the AC. Any 1861 static configuration of an AC's IP address on the WTP non-volatile 1862 storage is implementation dependent. However, additional dynamic 1863 schemes are possible, for example: 1865 DHCP: See [I-D.ietf-capwap-dhc-ac-option] for more information on 1866 the use of DHCP to discover AC IP addresses. 1868 DNS: The DNS name "CAPWAP-AC-Address" MAY be resolvable to one or 1869 more AC addresses. 1871 An AC MAY also communicate alternative ACs to the WTP within the 1872 Discovery Response message through the AC IPv4 List (see 1873 Section 4.6.2) and AC IPv6 List (see Section 4.6.2). The addresses 1874 provided in these two message elements are intended to help the WTP 1875 discover additional ACs through means other than those listed above. 1877 The AC Name with Index message element (see Section 4.6.5), is used 1878 to communicate a list of preferred ACs to the WTP. The WTP SHOULD 1879 attempt to utilize the ACs listed in the order provided by the AC. 1880 The Name to IP Address mapping is handled via the Discovery message 1881 exchange, in which the ACs provide their identity in the AC Name (see 1882 Section 4.6.4) message element in the Discovery Response message. 1884 Once the WTP has received Discovery Response messages from the 1885 candidate ACs, it MAY use other factors to determine the preferred 1886 AC. For instance, each binding defines a WTP Radio Information 1887 message element (see Section 2.1), which the AC includes in Discovery 1888 Response messages. The presence of one or more of these message 1889 elements is used to identify the CAPWAP bindings supported by the AC. 1890 A WTP MAY connect to an AC based on the supported bindings 1891 advertised. 1893 3.4. Fragmentation/Reassembly 1895 While fragmentation and reassembly services are provided by IP, the 1896 CAPWAP protocol also provides such services. Environments where the 1897 CAPWAP protocol is used involve firewall, NAT and "middle box" 1898 devices, which tend to drop IP fragments to minimize possible DoS 1899 attacks. By providing fragmentation and reassembly at the 1900 application layer, any fragmentation required due to the tunneling 1901 component of the CAPWAP protocol becomes transparent to these 1902 intermediate devices. Consequently, the CAPWAP protocol can be used 1903 in any network topology including firewall, NAT and middlebox 1904 devices. 1906 3.5. MTU Discovery 1908 Once a WTP has discovered the AC it wishes to establish a CAPWAP 1909 session with, it SHOULD perform a Path MTU (PMTU) discovery. The MTU 1910 discovered is used to configure the DTLS component (see 1911 Section 2.3.2.1), while non-DTLS frames need to be fragmented to fit 1912 the MTU, defined in Section 3.4. The procedures described in 1913 [RFC1191], for IPv4, or [RFC1981], for IPv6 SHOULD be used. 1914 Alternatively, implementers MAY use the procedures defined in 1915 [RFC4821]. The WTP SHOULD also periodically re-evaluate the MTU 1916 using the guidelines provided in these two RFCs. 1918 4. CAPWAP Packet Formats 1920 This section contains the CAPWAP protocol packet formats. A CAPWAP 1921 protocol packet consists of one or more CAPWAP Transport Layer packet 1922 headers followed by a CAPWAP message. The CAPWAP message can be 1923 either of type Control or Data, where Control packets carry 1924 signaling, and Data packets carry user payloads. The CAPWAP frame 1925 formats for CAPWAP Data packets, and for DTLS encapsulated CAPWAP 1926 Data and Control packets are defined below. 1928 The CAPWAP Control protocol includes two messages that are never 1929 protected by DTLS: the Discovery Request message and the Discovery 1930 Response message. These messages need to be in the clear to allow 1931 the CAPWAP protocol to properly identify and process them. The 1932 format of these packets are as follows: 1934 CAPWAP Control Packet (Discovery Request/Response): 1935 +-------------------------------------------+ 1936 | IP | UDP | CAPWAP | Control | Message | 1937 | Hdr | Hdr | Header | Header | Element(s) | 1938 +-------------------------------------------+ 1940 All other CAPWAP control protocol messages MUST be protected via the 1941 DTLS protocol, which ensures that the packets are both authenticated 1942 and encrypted. These packets include the CAPWAP DTLS Header, which 1943 is described in Section 4.2. The format of these packets is as 1944 follows: 1946 CAPWAP Control Packet (DTLS Security Required): 1947 +------------------------------------------------------------------+ 1948 | IP | UDP | CAPWAP | DTLS | CAPWAP | Control| Message | DTLS | 1949 | Hdr | Hdr | DTLS Hdr | Hdr | Header | Header | Element(s)| Trlr | 1950 +------------------------------------------------------------------+ 1951 \---------- authenticated -----------/ 1952 \------------- encrypted ------------/ 1954 The CAPWAP protocol allows optional protection of data packets, using 1955 DTLS. Use of data packet protection is determined by AC policy. 1956 When DTLS is utilized, the optional CAPWAP DTLS Header is present, 1957 which is described in Section 4.2. The format of CAPWAP data packets 1958 is shown below: 1960 CAPWAP Plain Text Data Packet : 1961 +-------------------------------+ 1962 | IP | UDP | CAPWAP | Wireless | 1963 | Hdr | Hdr | Header | Payload | 1964 +-------------------------------+ 1966 DTLS Secured CAPWAP Data Packet: 1967 +--------------------------------------------------------+ 1968 | IP | UDP | CAPWAP | DTLS | CAPWAP | Wireless | DTLS | 1969 | Hdr | Hdr | DTLS Hdr | Hdr | Hdr | Payload | Trlr | 1970 +--------------------------------------------------------+ 1971 \------ authenticated -----/ 1972 \------- encrypted --------/ 1974 UDP Header: All CAPWAP packets are encapsulated within either UDP, 1975 or UDP-Lite when used over IPv6. Section 3 defines the specific 1976 UDP or UDP-Lite usage. 1978 CAPWAP DTLS Header: All DTLS encrypted CAPWAP protocol packets are 1979 prefixed with the CAPWAP DTLS header (see Section 4.2). 1981 DTLS Header: The DTLS header provides authentication and encryption 1982 services to the CAPWAP payload it encapsulates. This protocol is 1983 defined in RFC 4347 [RFC4347]. 1985 CAPWAP Header: All CAPWAP protocol packets use a common header that 1986 immediately follows the CAPWAP preamble or DTLS header. The 1987 CAPWAP Header is defined in Section 4.3. 1989 Wireless Payload: A CAPWAP protocol packet that contains a wireless 1990 payload is a CAPWAP data packet. The CAPWAP protocol does not 1991 specify the format of the wireless payload, which is defined by 1992 the appropriate wireless standard. Additional information is in 1993 Section 4.4. 1995 Control Header: The CAPWAP protocol includes a signaling component, 1996 known as the CAPWAP control protocol. All CAPWAP control packets 1997 include a Control Header, which is defined in Section 4.5.1. 1998 CAPWAP data packets do not contain a Control Header field. 2000 Message Elements: A CAPWAP Control packet includes one or more 2001 message elements, which are found immediately following the 2002 Control Header. These message elements are in a Type/Length/value 2003 style header, defined in Section 4.6. 2005 A CAPWAP implementation MUST be capable of receiving a reassembled 2006 CAPWAP message of length 4096 bytes. A CAPWAP implementation MAY 2007 indicate that it supports a higher maximum message length, by 2008 including the Maximum Message Length message element, see 2009 Section 4.6.32 in the Join Request message or the Join Response 2010 message. 2012 4.1. CAPWAP Preamble 2014 The CAPWAP preamble is common to all CAPWAP transport headers and is 2015 used to identify the header type that immediately follows. The 2016 reason for this preamble is to avoid needing to perform byte 2017 comparisons in order to guess whether the frame is DTLS encrypted or 2018 not. It also provides an extensibility framework that can be used to 2019 support additional transport types. The format of the preamble is as 2020 follows: 2022 0 2023 0 1 2 3 4 5 6 7 2024 +-+-+-+-+-+-+-+-+ 2025 |Version| Type | 2026 +-+-+-+-+-+-+-+-+ 2028 Version: A 4 bit field which contains the version of CAPWAP used in 2029 this packet. The value for this specification is zero (0). 2031 Payload Type: A 4 bit field which specifies the payload type that 2032 follows the UDP header. The following values are supported: 2034 0 - CAPWAP Header. The CAPWAP Header (see Section 4.3) 2035 immediately follows the UDP header. If the packet is received 2036 on the CAPWAP data channel, the CAPWAP stack MUST treat the 2037 packet as a clear text CAPWAP data packet. If received on the 2038 CAPWAP control channel, the CAPWAP stack MUST treat the packet 2039 as a clear text CAPWAP control packet. If the control packet 2040 is not a Discovery Request or Discovery Response packet, the 2041 packet MUST be dropped. 2043 1 - CAPWAP DTLS Header. The CAPWAP DTLS Header, and DTLS packet, 2044 immediately follows the UDP header (see Section 4.2). 2046 4.2. CAPWAP DTLS Header 2048 The CAPWAP DTLS Header is used to identify the packet as a DTLS 2049 encrypted packet. The first eight bits includes the common CAPWAP 2050 Preamble. The remaining 24 bits are padding to ensure 4 byte 2051 alignment, and MAY be used in a future version of the protocol. The 2052 DTLS packet [RFC4347] always immediately follows this header. The 2053 format of the CAPWAP DTLS Header is as follows: 2055 0 1 2 3 2056 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 2057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2058 |CAPWAP Preamble| Reserved | 2059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2061 CAPWAP Preamble: The CAPWAP Preamble is defined in Section 4.1. The 2062 CAPWAP Preamble's Payload Type field MUST be set to one (1). 2064 Reserved: The 24-bit field is reserved for future use. All 2065 implementations complying with this protocol MUST set to zero any 2066 bits that are reserved in the version of the protocol supported by 2067 that implementation. Receivers MUST ignore all bits not defined 2068 for the version of the protocol they support. 2070 4.3. CAPWAP Header 2072 All CAPWAP protocol messages are encapsulated using a common header 2073 format, regardless of the CAPWAP Control or CAPWAP Data transport 2074 used to carry the messages. However, certain flags are not 2075 applicable for a given transport. Refer to the specific transport 2076 section in order to determine which flags are valid. 2078 Note that the optional fields defined in this section MUST be present 2079 in the precise order shown below. 2081 0 1 2 3 2082 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 2083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2084 |CAPWAP Preamble| HLEN | RID | WBID |T|F|L|W|M|K|Flags| 2085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2086 | Fragment ID | Frag Offset |Rsvd | 2087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2088 | (optional) Radio MAC Address | 2089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2090 | (optional) Wireless Specific Information | 2091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2092 | Payload .... | 2093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2095 CAPWAP Preamble: The CAPWAP Preamble is defined in Section 4.1. The 2096 CAPWAP Preamble's Payload Type field MUST be set to zero (0). If 2097 the CAPWAP DTLS Header is present, the version number in both 2098 CAPWAP Preambles MUST match. The reason for this duplicate field 2099 is to avoid any possible tampering of the version field in the 2100 preamble which is not encrypted or authenticated. 2102 HLEN: A 5 bit field containing the length of the CAPWAP transport 2103 header in 4 byte words (Similar to IP header length). This length 2104 includes the optional headers. 2106 RID: A 5 bit field which contains the Radio ID number for this 2107 packet. Given that MAC Addresses are not necessarily unique 2108 across physical radios in a WTP, the Radio Identifier (RID) field 2109 is used to indicate which physical radio the message is associated 2110 with. 2112 WBID: A 5 bit field which is the wireless binding identifier. The 2113 identifier will indicate the type of wireless packet associated 2114 with the radio. The following values are defined: 2116 0 - Reserved 2118 1 - IEEE 802.11 2120 2 - IEEE 802.16 2122 3 - EPCGlobal [EPCGlobal] 2124 T: The Type 'T' bit indicates the format of the frame being 2125 transported in the payload. When this bit is set to one (1), the 2126 payload has the native frame format indicated by the WBID field. 2127 When this bit is zero (0) the payload is an IEEE 802.3 frame. 2129 F: The Fragment 'F' bit indicates whether this packet is a fragment. 2130 When this bit is one (1), the packet is a fragment and MUST be 2131 combined with the other corresponding fragments to reassemble the 2132 complete information exchanged between the WTP and AC. 2134 L: The Last 'L' bit is valid only if the 'F' bit is set and indicates 2135 whether the packet contains the last fragment of a fragmented 2136 exchange between WTP and AC. When this bit is 1, the packet is 2137 the last fragment. When this bit is 0, the packet is not the last 2138 fragment. 2140 W: The Wireless 'W' bit is used to specify whether the optional 2141 Wireless Specific Information field is present in the header. A 2142 value of one (1) is used to represent the fact that the optional 2143 header is present. 2145 M: The M bit is used to indicate that the Radio MAC Address optional 2146 header is present. This is used to communicate the MAC address of 2147 the receiving radio. 2149 K: The 'Keep-alive' K bit indicates the packet is a Data Channel Keep 2150 Alive packet. This packet is used to map the data channel to the 2151 control channel for the specified Session ID and to maintain 2152 freshness of the data channel. The K bit MUST NOT be set for data 2153 packets containing user data. 2155 Flags: A set of reserved bits for future flags in the CAPWAP header. 2156 All implementations complying with this protocol MUST set to zero 2157 any bits that are reserved in the version of the protocol 2158 supported by that implementation. Receivers MUST ignore all bits 2159 not defined for the version of the protocol they support. 2161 Fragment ID: A 16 bit field whose value is assigned to each group of 2162 fragments making up a complete set. The fragment ID space is 2163 managed individually for every WTP/AC pair. The value of Fragment 2164 ID is incremented with each new set of fragments. The Fragment ID 2165 wraps to zero after the maximum value has been used to identify a 2166 set of fragments. 2168 Fragment Offset: A 13 bit field that indicates where in the payload 2169 this fragment belongs during re-assembly. This field is valid 2170 when the 'F' bit is set to 1. The fragment offset is measured in 2171 units of 8 octets (64 bits). The first fragment has offset zero. 2172 Note the CAPWAP protocol does not allow for overlapping fragments. 2174 Reserved: The 3-bit field is reserved for future use. All 2175 implementations complying with this protocol MUST set to zero any 2176 bits that are reserved in the version of the protocol supported by 2177 that implementation. Receivers MUST ignore all bits not defined 2178 for the version of the protocol they support. 2180 Radio MAC Address: This optional field contains the MAC address of 2181 the radio receiving the packet. Because the native wireless frame 2182 format to IEEE 802.3 format causes the MAC address of the WTP's 2183 radio to be lost, this field allows the address to be communicated 2184 to the AC. This field is only present if the 'M' bit is set. The 2185 HLEN field assumes 4 byte alignment, and this field MUST be padded 2186 with zeroes (0x00) if it is not 4 byte aligned. 2188 The field contains the basic format: 2190 0 1 2 3 2191 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 2192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2193 | Length | MAC Address 2194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2196 Length: The length of the MAC Address field. The following 2197 formats, and lengths, are supported [EUI-48] and [EUI-64]. 2199 MAC Address: The MAC Address of the receiving radio. 2201 Wireless Specific Information: This optional field contains 2202 technology specific information that may be used to carry per 2203 packet wireless information. This field is only present if the 2204 'W' bit is set. The WBID field in the CAPWAP header is used to 2205 identify the format of the wireless specific information optional 2206 field. The HLEN field assumes 4 byte alignment, and this field 2207 MUST be padded with zeroes (0x00) if it is not 4 byte aligned. 2209 The Wireless Specific Information field uses the following format: 2211 0 1 2 3 2212 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 2213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2214 | Length | Data... 2215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2217 Length: The 8 bit field contains the length of the data field, 2218 with a maximum size of 255. 2220 Data: Wireless specific information, defined by the wireless 2221 specific binding specified in the CAPWAP Header's WBID field. 2223 Payload: This field contains the header for a CAPWAP Data Message or 2224 CAPWAP Control Message, followed by the data contained in the 2225 message. 2227 4.4. CAPWAP Data Messages 2229 There are two different types of CAPWAP data packets, CAPWAP Data 2230 Channel Keep Alive packets and Data Payload packets. The first is 2231 used by the WTP to synchronize the control and data channels, and to 2232 maintain freshness of the data channel. The second is used to 2233 transmit user payloads between the AC and WTP. This section 2234 describes both types of CAPWAP data packet formats. 2236 Both CAPWAP data messages are transmitted on the CAPWAP data channel. 2238 4.4.1. CAPWAP Data Channel Keepalive 2240 The CAPWAP Data Channel Keep Alive packet is used to bind the CAPWAP 2241 control channel with the data channel, and to maintain freshness of 2242 the data channel, ensuring that the channel is still functioning. 2243 The CAPWAP Data Channel Keep Alive packet is transmitted by the WTP 2244 when the DataChannelKeepAlive timer expires (see Section 4.7.2). 2245 When the CAPWAP Data Channel Keep Alive packet is transmitted, the 2246 WTP sets the DataChannelDeadInterval timer. 2248 In the CAPWAP Data Channel Keep Alive packet, all of the fields in 2249 the CAPWAP header, except the HLEN field and the K bit, are set to 2250 zero upon transmission. Upon receiving a CAPWAP Data Channel Keep 2251 Alive packet, the AC transmits a CAPWAP Data Channel Keep Alive 2252 packet back to the WTP. The contents of the transmitted packet are 2253 identical to the contents of the received packet. 2255 Upon receiving a CAPWAP Data Channel Keep Alive packet, the WTP 2256 cancels the DataChannelDeadInterval timer and resets the 2257 DataChannelKeepAlive timer. The CAPWAP Data Channel Keep Alive 2258 packet is retransmitted by the WTP in the same manner as the CAPWAP 2259 control messages. If the DataChannelDeadInterval timer expires, the 2260 WTP tears down the control DTLS session, and the data DTLS session if 2261 one existed. 2263 The CAPWAP Data Channel Keep Alive packet contains the following 2264 payload immediately following the CAPWAP Header (see Section 4.3) 2266 0 1 2 3 2267 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 2268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2269 | Message Element Length | Message Element [0..N] ... 2270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2272 Message Element Length: The 8 bit Length field indicates the number 2273 of bytes following the CAPWAP Header, with a maximum size of 2274 65535. 2276 Message Element[0..N]: The message element(s) carry the information 2277 pertinent to each of the CAPWAP Data Channel Keepalive message. 2278 The following message elements MUST be present in this CAPWAP 2279 message: 2281 Session ID, see Section 4.6.37 2283 4.4.2. Data Payload 2285 A CAPWAP protocol Data Payload packet encapsulates a forwarded 2286 wireless frame. The CAPWAP protocol defines two different modes of 2287 encapsulation; IEEE 802.3 and native wireless. IEEE 802.3 2288 encapsulation requires that for 802.11 frames, the 802.11 2289 *Integration* function be performed in the WTP. An IEEE 802.3 2290 encapsulated user payload frame has the following format: 2292 +------------------------------------------------------+ 2293 | IP Header | UDP Header | CAPWAP Header | 802.3 Frame | 2294 +------------------------------------------------------+ 2296 The CAPWAP protocol also defines the native wireless encapsulation 2297 mode. The format of the encapsulated CAPWAP data frame is subject to 2298 the rules defined by the specific wireless technology binding. Each 2299 wireless technology binding MUST contain a section entitled "Payload 2300 Encapsulation", which defines the format of the wireless payload that 2301 is encapsulated within CAPWAP Data packets. 2303 For 802.3 payload frames, the 802.3 frame is encapsulated (excluding 2304 the IEEE 802.3 FCS checksum). If the encapsulated frame would exceed 2305 the transport layer's MTU, the sender is responsible for 2306 fragmentation of the frame, as specified in Section 3.4. The CAPWAP 2307 protocol can support IEEE 802.3 frames whose length is defined in the 2308 IEEE 802.3as specification [FRAME-EXT]. 2310 4.4.3. Establishment of a DTLS Data Channel 2312 If the AC and WTP are configured to tunnel the data channel over 2313 DTLS, the proper DTLS session must be initiated. To avoid having to 2314 reauthenticate and reauthorize an AC and WTP, the DTLS data channel 2315 MUST be initiated using the TLS session resumption feature [RFC4346]. 2317 When establishing the DTLS-encrypted data channel, the WTP MUST 2318 provide the identifier returned during the initialization of the 2319 control channel to the DTLS component so it can perform the 2320 resumption using the proper session information. 2322 The AC DTLS implementation MUST NOT accept a session resumption 2323 request for a DTLS session in which the control channel for the 2324 session has been torn down. 2326 4.5. CAPWAP Control Messages 2328 The CAPWAP Control protocol provides a control channel between the 2329 WTP and the AC. Control messages are divided into the following 2330 message types: 2332 Discovery: CAPWAP Discovery messages are used to identify potential 2333 ACs, their load and capabilities. 2335 Join: CAPWAP Join messages are used by a WTP to request service from 2336 an AC, and for the AC to respond to the WTP. 2338 Control Channel Management: CAPWAP control channel management 2339 messages are used to maintain the control channel. 2341 WTP Configuration Management: The WTP Configuration messages are 2342 used by the AC to deliver a specific configuration to the WTP. 2343 Messages which retrieve statistics from a WTP are also included in 2344 WTP Configuration Management. 2346 Station Session Management: Station Session Management messages are 2347 used by the AC to deliver specific station policies to the WTP. 2349 Device Management Operations: Device management operations are used 2350 to request and deliver a firmware image to the WTP. 2352 Binding Specific CAPWAP Management Messages: Messages in this 2353 category are used by the AC and the WTP to exchange protocol- 2354 specific CAPWAP management messages. These messages may or may 2355 not be used to change the link state of a station. 2357 Discovery, Join, Control Channel Management, WTP Configuration 2358 Management and Station Session Management CAPWAP control messages 2359 MUST be implemented. Device Management Operations messages MAY be 2360 implemented. 2362 CAPWAP control messages sent from the WTP to the AC indicate that the 2363 WTP is operational, providing an implicit keep-alive mechanism for 2364 the WTP. The Control Channel Management Echo Request and Echo 2365 Response messages provide an explicit keep-alive mechanism when other 2366 CAPWAP control messages are not exchanged. 2368 4.5.1. Control Message Format 2370 All CAPWAP control messages are sent encapsulated within the CAPWAP 2371 header (see Section 4.3). Immediately following the CAPWAP header, 2372 is the control header, which has the following format: 2374 0 1 2 3 2375 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 2376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2377 | Message Type | 2378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2379 | Seq Num | Msg Element Length | Flags | 2380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2381 | Msg Element [0..N] ... 2382 +-+-+-+-+-+-+-+-+-+-+-+-+ 2384 4.5.1.1. Message Type 2386 The Message Type field identifies the function of the CAPWAP control 2387 message. To provide extensibility, the Message Type field is 2388 comprised of an IANA Enterprise Number [RFC3232] and an enterprise 2389 specific message type number. The first three octets contain the 2390 IANA Enterprise Number in network byte order, with zero used for 2391 CAPWAP base protocol (this specification) defined message types. The 2392 last octet is the enterprise specific message type number, which has 2393 a range from 0 to 255. 2395 The message type field is defined as: 2397 Message Type = 2398 IANA Enterprise Number * 256 + 2399 Enterprise Specific Message Type Number 2401 The CAPWAP protocol reliability mechanism requires that messages be 2402 defined in pairs, consisting of both a Request and a Response 2403 message. The Response message MUST acknowledge the Request message. 2404 The assignment of CAPWAP control Message Type Values always occurs in 2405 pairs. All Request messages have odd numbered Message Type Values, 2406 and all Response messages have even numbered Message Type Values. 2407 The Request value MUST be assigned first. As an example, assigning a 2408 Message Type Value of 3 for a Request message and 4 for a Response 2409 message is valid, while assigning a Message Type Value of 4 for a 2410 Response message and 5 for the corresponding Request message is 2411 invalid. 2413 When a WTP or AC receives a message with a Message Type Value field 2414 that is not recognized and is an odd number, the number in the 2415 Message Type Value Field is incremented by one, and a Response 2416 message with a Message Type Value field containing the incremented 2417 value and containing the Result Code message element with the value 2418 (Unrecognized Request) is returned to the sender of the received 2419 message. If the unknown message type is even, the message is 2420 ignored. 2422 The valid values for CAPWAP Control Message Types are specified in 2423 the table below: 2425 CAPWAP Control Message Message Type 2426 Value 2427 Discovery Request 1 2428 Discovery Response 2 2429 Join Request 3 2430 Join Response 4 2431 Configuration Status 5 2432 Configuration Status Response 6 2433 Configuration Update Request 7 2434 Configuration Update Response 8 2435 WTP Event Request 9 2436 WTP Event Response 10 2437 Change State Event Request 11 2438 Change State Event Response 12 2439 Echo Request 13 2440 Echo Response 14 2441 Image Data Request 15 2442 Image Data Response 16 2443 Reset Request 17 2444 Reset Response 18 2445 Primary Discovery Request 19 2446 Primary Discovery Response 20 2447 Data Transfer Request 21 2448 Data Transfer Response 22 2449 Clear Configuration Request 23 2450 Clear Configuration Response 24 2451 Station Configuration Request 25 2452 Station Configuration Response 26 2454 4.5.1.2. Sequence Number 2456 The Sequence Number Field is an identifier value used to match 2457 Request and Response packets. When a CAPWAP packet with a Request 2458 Message Type Value is received, the value of the Sequence Number 2459 field is copied into the corresponding Response message. 2461 When a CAPWAP control message is sent, the sender's internal sequence 2462 number counter is monotonically incremented, ensuring that no two 2463 pending Request messages have the same Sequence Number. The Sequence 2464 Number field wraps back to zero. 2466 4.5.1.3. Message Element Length 2468 The Length field indicates the number of bytes following the Sequence 2469 Number field. 2471 4.5.1.4. Flags 2473 The Flags field MUST be set to zero. 2475 4.5.1.5. Message Element[0..N] 2477 The message element(s) carry the information pertinent to each of the 2478 control message types. Every control message in this specification 2479 specifies which message elements are permitted. 2481 When a WTP or AC receives a CAPWAP message without a message element 2482 that is specified as mandatory for the CAPWAP message, then the 2483 CAPWAP message is discarded. If the received message was a Request 2484 message for which the corresponding Response message carries message 2485 elements, then a corresponding Response message with a Result Code 2486 message element indicating "Failure - Missing Mandatory Message 2487 Element" is returned to the sender. 2489 When a WTP or AC receives a CAPWAP message with a message element 2490 that the WTP or AC does not recognize, the CAPWAP message is 2491 discarded. If the received message was a Request message for which 2492 the corresponding Response message carries message elements, then a 2493 corresponding Response message with a Result Code message element 2494 indicating "Failure - Unrecognized Message Element" and one or more 2495 Returned Message Element message elements is included, containing the 2496 unrecognized message element(s). 2498 4.5.2. Control Message Quality of Service 2500 It is recommended that CAPWAP control messages be sent by both the AC 2501 and the WTP with an appropriate Quality of Service precedence value, 2502 ensuring that congestion in the network minimizes occurrences of 2503 CAPWAP control channel disconnects. Therefore, a Quality of Service 2504 enabled CAPWAP device SHOULD use the following values: 2506 802.1Q: The priority tag of 7 SHOULD be used. 2508 DSCP: The DSCP value of 46 SHOULD be used. 2510 4.5.3. Retransmissions 2512 The CAPWAP control protocol operates as a reliable transport. For 2513 each Request message, a Response message is defined, which is used to 2514 acknowledge receipt of the Request message. In addition, the control 2515 header Sequence Number field is used to pair the Request and Response 2516 messages (see Section 4.5.1). 2518 Response messages are not explicitly acknowledged, therefore if a 2519 Response message is not received, the original Request message is 2520 retransmitted. Implementations MAY cache Response messages to 2521 respond to a retransmitted Request messages with minimal local 2522 processing. Retransmitted Request messages MUST NOT be altered by 2523 the sender. The sender MUST assume that the original Request message 2524 was processed, but that the Response message was lost. Any 2525 alterations to the original Request message MUST have a new Sequence 2526 Number, and be treated as a new Request message by the receiver. 2528 After transmitting a Request message, the RetransmitInterval (see 2529 Section 4.7) timer and MaxRetransmit (see Section 4.8) variable are 2530 used to determine if the original Request message needs to be 2531 retransmitted. The RetransmitInterval timer is used the first time 2532 the Request is retransmitted. The timer is then doubled every 2533 subsequent time the same Request message is retransmitted, up to 2534 MaxRetransmit but no more than half the EchoInterval timer (see 2535 Section 4.7.7). Response messages are not subject to these timers. 2537 When a Request message is retransmitted, it MUST be re-encrypted via 2538 the DTLS stack. If the peer had received the Request message, and 2539 the corresponding Response message was lost, it is necessary to 2540 ensure that retransmitted Request messages are not identified as 2541 replays by the DTLS stack. Similarly, any cached Response messages 2542 that are retransmitted as a result of receiving a retransmitted 2543 Request message MUST be re-encrypted via DTLS. 2545 Duplicate Response messages, identified by the Sequence Number field 2546 in the CAPWAP control message header, SHOULD be discarded upon 2547 receipt. 2549 4.6. CAPWAP Protocol Message Elements 2551 This section defines the CAPWAP Protocol message elements which are 2552 included in CAPWAP protocol control messages. 2554 Message elements are used to carry information needed in control 2555 messages. Every message element is identified by the Type Value 2556 field, defined below. The total length of the message elements is 2557 indicated in the message element Length field. 2559 All of the message element definitions in this document use a diagram 2560 similar to the one below in order to depict its format. Note that to 2561 simplify this specification, these diagrams do not include the header 2562 fields (Type and Length). The header field values are defined in the 2563 message element descriptions. 2565 Unless otherwise specified, a control message that lists a set of 2566 supported (or expected) message elements MUST NOT expect the message 2567 elements to be in any specific order. The sender MAY include the 2568 message elements in any order. Unless otherwise noted, one message 2569 element of each type is present in a given control message. 2571 Unless otherwise specified, any configuration information sent by the 2572 AC to the WTP MAY be saved to non-volatile storage (see Section 8.1) 2573 for more information). 2575 Additional message elements may be defined in separate IETF 2576 documents. 2578 The format of a message element uses the TLV format shown here: 2580 0 1 2 3 2581 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 2582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2583 | Type | Length | 2584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2585 | Value ... | 2586 +-+-+-+-+-+-+-+-+ 2588 The 16 bit Type field identifies the information carried in the Value 2589 field and Length (16 bits) indicates the number of bytes in the Value 2590 field. Type field values are allocated as follows: 2592 Usage Type Values 2594 CAPWAP Protocol Message Elements 1-1023 2595 IEEE 802.11 Message Elements 1024-2047 2596 IEEE 802.16 Message Elements 2048 - 3071 2597 EPCGlobal Message Elements 3072 - 4095 2598 Reserved for Future Use 4096 - 65024 2600 The table below lists the CAPWAP protocol Message Elements and their 2601 Type values. 2603 CAPWAP Message Element Type Value 2605 AC Descriptor 1 2606 AC IPv4 List 2 2607 AC IPv6 List 3 2608 AC Name 4 2609 AC Name with Index 5 2610 AC Timestamp 6 2611 Add MAC ACL Entry 7 2612 Add Station 8 2613 Add Static MAC ACL Entry 9 2614 CAPWAP Control IPV4 Address 10 2615 CAPWAP Control IPV6 Address 11 2616 CAPWAP Local IPV4 Address 12 2617 CAPWAP Local IPV6 Address 13 2618 CAPWAP Timers 14 2619 CAPWAP Transport Protocol 15 2620 Data Transfer Data 16 2621 Data Transfer Mode 17 2622 Decryption Error Report 18 2623 Decryption Error Report Period 19 2624 Delete MAC ACL Entry 20 2625 Delete Station 21 2626 Delete Static MAC ACL Entry 22 2627 Discovery Type 23 2628 Duplicate IPv4 Address 24 2629 Duplicate IPv6 Address 25 2630 Idle Timeout 26 2631 Image Data 27 2632 Image Identifier 28 2633 Image Info 29 2634 Initiate Download 30 2635 Location Data 31 2636 Maximum Message Length 32 2637 Radio Administrative State 33 2638 Radio Operational State 34 2639 Result Code 35 2640 Returned Message Element 36 2641 Session ID 37 2642 Statistics Timer 38 2643 Vendor Specific Payload 39 2644 WTP Board Data 40 2645 WTP Descriptor 41 2646 WTP Fallback 42 2647 WTP Frame Tunnel Mode 43 2648 WTP IPv4 IP Address 44 2649 WTP IPv6 IP Address 45 2650 WTP MAC Type 46 2651 WTP Name 47 2652 Unused/Reserved 48 2653 WTP Radio Statistics 49 2654 WTP Reboot Statistics 50 2655 WTP Static IP Address Information 51 2657 4.6.1. AC Descriptor 2659 The AC Descriptor message element is used by the AC to communicate 2660 its current state. The value contains the following fields. 2662 0 1 2 3 2663 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 2664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2665 | Stations | Limit | 2666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2667 | Active WTPs | Max WTPs | 2668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2669 | Security | R-MAC Field | Reserved1 | DTLS Policy | 2670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2671 | AC Information Sub-Element... 2672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2674 Type: 1 for AC Descriptor 2676 Length: >= 12 2678 Stations: The number of stations currently served by the AC 2680 Limit: The maximum number of stations supported by the AC 2682 Active WTPs: The number of WTPs currently attached to the AC 2684 Max WTPs: The maximum number of WTPs supported by the AC 2686 Security: A 8 bit mask specifying the authentication credential 2687 type supported by the AC. The following values are supported (see 2688 Section 2.4.4): 2690 1 - X.509 Certificate Based 2692 2 - Pre-Shared Secret 2694 R-MAC Field: The AC supports the optional Radio MAC Address field 2695 in the CAPWAP transport Header (see Section 4.3). 2697 Reserved: A set of reserved bits for future use. All 2698 implementations complying with this protocol MUST set to zero any 2699 bits that are reserved in the version of the protocol supported by 2700 that implementation. Receivers MUST ignore all bits not defined 2701 for the version of the protocol they support. 2703 DTLS Policy: The AC communicates its policy on the use of DTLS for 2704 the CAPWAP data channel. The AC MAY communicate more than one 2705 supported option, represented by the bit field below. The WTP 2706 MUST abide by one of the options communicated by AC. The 2707 following bit field values are supported: 2709 1 - Clear Text Data Channel Supported 2711 2 - DTLS Enabled Data Channel Supported 2713 AC Information Sub-Element: The AC Descriptor message element 2714 contains multiple AC Information sub-elements, and defines two 2715 sub-types, each of which MUST be present. The AC Information sub- 2716 element has the following format: 2718 0 1 2 3 2719 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 2720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2721 | AC Information Vendor Identifier | 2722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2723 | AC Information Type | AC Information Length | 2724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2725 | AC Information Data... 2726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2728 AC Information Vendor Identifier: A 32-bit value containing the 2729 IANA assigned "SMI Network Management Private Enterprise Codes" 2731 AC Information Type: Vendor specific encoding of AC information. 2732 The following enumerated values are supported. Both the 2733 Hardware and Software Version sub-elements MUST be included in 2734 the AC Descriptor message element. 2736 4 - Hardware Version: The AC's hardware version number. 2738 5 - Software Version: The AC's Software (firmware) version 2739 number. 2741 AC Information Length: Length of vendor specific encoding of AC 2742 information, with a maximum size of 1024. 2744 AC Information Data: Vendor specific encoding of AC information. 2746 4.6.2. AC IPv4 List 2748 The AC IPv4 List message element is used to configure a WTP with the 2749 latest list of ACs available for the WTP to join. 2751 0 1 2 3 2752 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 2753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2754 | AC IP Address[] | 2755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2757 Type: 2 for AC IPv4 List 2759 Length: >= 4 2761 AC IP Address: An array of 32-bit integers containing AC IPv4 2762 Addresses, containing no more than 1024 addresses. 2764 4.6.3. AC IPv6 List 2766 The AC IPv6 List message element is used to configure a WTP with the 2767 latest list of ACs available for the WTP to join. 2769 0 1 2 3 2770 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 2771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2772 | AC IP Address[] | 2773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2774 | AC IP Address[] | 2775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2776 | AC IP Address[] | 2777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2778 | AC IP Address[] | 2779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2781 Type: 3 for AC IPV6 List 2783 Length: >= 16 2785 AC IP Address: An array of 128-bit integers containing AC IPv6 2786 Addresses, containing no more than 1024 addresses. 2788 4.6.4. AC Name 2790 The AC Name message element contains an UTF-8 representation of the 2791 AC identity. The value is a variable length byte string. The string 2792 is NOT zero terminated. 2794 0 2795 0 1 2 3 4 5 6 7 2796 +-+-+-+-+-+-+-+-+ 2797 | Name ... 2798 +-+-+-+-+-+-+-+-+ 2800 Type: 4 for AC Name 2802 Length: >= 1 2804 Name: A variable length UTF-8 encoded string containing the AC's 2805 name, whose maximum size MUST NOT exceed 512 bytes. 2807 4.6.5. AC Name with Index 2809 The AC Name with Index message element is sent by the AC to the WTP 2810 to configure preferred ACs. The number of instances of this message 2811 element is equal to the number of ACs configured on the WTP. 2813 0 1 2814 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2816 | Index | AC Name... 2817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2819 Type: 5 for AC Name with Index 2821 Length: >= 2 2823 Index: The index of the preferred server (1=primary, 2=secondary). 2825 AC Name: A variable length UTF-8 encoded string containing the AC 2826 name, whose maximum size MUST NOT exceed 512 bytes. 2828 4.6.6. AC Timestamp 2830 The AC Timestamp message element is sent by the AC to synchronize the 2831 WTP clock. 2833 0 1 2 3 2834 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 2835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2836 | Timestamp | 2837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2839 Type: 6 for AC Timestamp 2841 Length: 4 2843 Timestamp: The AC's current time, allowing all of the WTPs to be 2844 time synchronized in the format defined by Network Time Protocol 2845 (NTP) in RFC 1305 [RFC1305]. 2847 4.6.7. Add MAC ACL Entry 2849 The Add MAC Access Control List (ACL) Entry message element is used 2850 by an AC to add a MAC ACL list entry on a WTP, ensuring that the WTP 2851 no longer provides service to the MAC addresses provided in the 2852 message. The MAC Addresses provided in this message element are not 2853 expected to be saved in non-volatile memory on the WTP. 2855 0 1 2 3 2856 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 2857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2858 | Num of Entries| Length | MAC Address ... 2859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2861 Type: 7 for Add MAC ACL Entry 2863 Length: >= 8 2865 Num of Entries: The number of instances of the Type/MAC Addresses 2866 fields in the array. This value MUST NOT exceed 255. 2868 Length: The length of the MAC Address field. The following formats, 2869 and lengths, are supported [EUI-48] and [EUI-64]. 2871 MAC Address: MAC Addresses to add to the ACL. 2873 4.6.8. Add Station 2875 The Add Station message element is used by the AC to inform a WTP 2876 that it should forward traffic for a station. The Add Station 2877 message element is accompanied by technology specific binding 2878 information element(s) which may include security parameters. 2879 Consequently, the security parameters MUST be applied by the WTP for 2880 the station. 2882 After station policy has been delivered to the WTP through the Add 2883 Station message element, an AC MAY change any policies by sending a 2884 modified Add Station message element. When a WTP receives an Add 2885 Station message element for an existing station, it MUST override any 2886 existing state for the station. 2888 0 1 2 3 2889 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2891 | Radio ID | Length | MAC Address ... 2892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2893 | VLAN Name... 2894 +-+-+-+-+-+-+-+-+ 2896 Type: 8 for Add Station 2898 Length: >= 8 2900 Radio ID: An 8-bit value representing the radio 2902 Length: The length of the MAC Address field. The following formats, 2903 and lengths, are supported [EUI-48] and [EUI-64]. 2905 MAC Address: The station's MAC Address 2907 VLAN Name: An optional variable length UTF-8 encoded string, with a 2908 maximum length of 512 octets, containing the VLAN Name on which 2909 the WTP is to locally bridge user data. Note this field is only 2910 valid with WTPs configured in Local MAC mode. 2912 4.6.9. Add Static MAC ACL Entry 2914 The Add Static MAC ACL Entry message element is used by an AC to add 2915 a permanent ACL entry on a WTP, ensuring that the WTP no longer 2916 provides any service to the MAC addresses provided in the message. 2917 The MAC Addresses provided in this message element are expected to be 2918 saved in non-volatile memory on the WTP. 2920 0 1 2 3 2921 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 2922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2923 | Num of Entries| Length | MAC Address ... 2924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2926 Type: 9 for Add Static MAC ACL Entry 2928 Length: >= 8 2930 Num of Entries: The number of instances of the Type/MAC Addresses 2931 fields in the array. This value MUST NOT exceed 255. 2933 Length: The length of the MAC Address field. The following formats, 2934 and lengths, are supported [EUI-48] and [EUI-64]. 2936 MAC Address: MAC Addresses to add to the permanent ACL. 2938 4.6.10. CAPWAP Control IPv4 Address 2940 The CAPWAP Control IPv4 Address message element is sent by the AC to 2941 the WTP during the discovery process and is used by the AC to provide 2942 the interfaces available on the AC, and the current number of WTPs 2943 connected. When multiple CAPWAP Control IPV4 Address message 2944 elements are returned, the WTP SHOULD perform load balancing across 2945 the multiple interfaces. 2947 0 1 2 3 2948 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 2949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2950 | IP Address | 2951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2952 | WTP Count | 2953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2955 Type: 10 for CAPWAP Control IPv4 Address 2957 Length: 6 2959 IP Address: The IP Address of an interface. 2961 WTP Count: The number of WTPs currently connected to the interface, 2962 with a maximum value of 65535. 2964 4.6.11. CAPWAP Control IPv6 Address 2966 The CAPWAP Control IPv6 Address message element is sent by the AC to 2967 the WTP during the discovery process and is used by the AC to provide 2968 the interfaces available on the AC, and the current number of WTPs 2969 connected. This message element is useful for the WTP to perform 2970 load balancing across multiple interfaces. 2972 0 1 2 3 2973 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 2974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2975 | IP Address | 2976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2977 | IP Address | 2978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2979 | IP Address | 2980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2981 | IP Address | 2982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2983 | WTP Count | 2984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2986 Type: 11 for CAPWAP Control IPv6 Address 2988 Length: 18 2989 IP Address: The IP Address of an interface. 2991 WTP Count: The number of WTPs currently connected to the interface, 2992 with a maximum value of 65535. 2994 4.6.12. CAPWAP Local IPv4 Address 2996 The CAPWAP Local IPv4 Address message element is sent by either the 2997 WTP or the AC in the Join Request, Configuration Status Request or 2998 Image Data Request message in order to communicate the IP Address of 2999 the transmitter. The receiver uses this to determine whether a 3000 middlebox exists between the two peers, by comparing the source IP 3001 address of the packet against the value of the message element. 3003 0 1 2 3 3004 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 3005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3006 | IP Address | 3007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3009 Type: 12 for CAPWAP Local IPv4 Address 3011 Length: 4 3013 IP Address: The IP Address of the sender. 3015 4.6.13. CAPWAP Local IPv6 Address 3017 The CAPWAP Local IPv6 Address message element is sent by either the 3018 WTP or the AC in the Discovery Response or Join Request in order to 3019 communicate the IP Address of the transmitter. The receiver uses 3020 this to determine whether a middlebox exists between the two peers, 3021 by comparing the source IP address of the packet against the value of 3022 the message element. 3024 0 1 2 3 3025 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 3026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3027 | IP Address | 3028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3029 | IP Address | 3030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3031 | IP Address | 3032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3033 | IP Address | 3034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3036 Type: 13 for CAPWAP Local IPv6 Address 3038 Length: 16 3040 IP Address: The IP Address of the sender. 3042 4.6.14. CAPWAP Timers 3044 The CAPWAP Timers message element is used by an AC to configure 3045 CAPWAP timers on a WTP. 3047 0 1 3048 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3050 | Discovery | Echo Request | 3051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3053 Type: 14 for CAPWAP Timers 3055 Length: 2 3057 Discovery: The number of seconds between CAPWAP Discovery messages, 3058 when the WTP is in the discovery phase. This value is used to 3059 configure the MaxDiscoveryInterval timer (see Section 4.7.10). 3061 Echo Request: The number of seconds between WTP Echo Request CAPWAP 3062 messages. This value is used to configure the EchoInterval timer 3063 (see Section 4.7.7). The AC sets its EchoInterval timer to this 3064 value, plus the maximum retransmission time as described in 3065 Section 4.5.3. 3067 4.6.15. CAPWAP Transport Protocol 3069 When CAPWAP is run over IPv6, the UDP-Lite or UDP transports MAY be 3070 used (see Section 3). The CAPWAP IPv6 Transport Protocol message 3071 element is used by either the WTP or the AC to signal which transport 3072 protocol is to be used for the CAPWAP data channel. 3074 Upon receiving the Join Request, the AC MAY set the CAPWAP Transport 3075 Protocol to UDP-Lite in the Configuration Status Request or Image 3076 Data Request message if the CAPWAP message was received over IPv6, 3077 and the CAPWAP Local IPv6 Address message element (see 3078 Section 4.6.13) is present and the address matches the packet's 3079 source IP address. 3081 Upon receiving the Configuration Status Request or Image Data Request 3082 message, the WTP MAY set the CAPWAP Transport Protocol to UDP-Lite in 3083 the Configuration Status Response or Image Data Response message if 3084 the message was received over IPv6, and the CAPWAP Local IPv6 Address 3085 message element (see Section 4.6.13) is present and the address 3086 matches the packet's source IP address. 3088 For any other condition, the CAPWAP Transport Protocol MUST be set to 3089 UDP. 3091 0 3092 0 1 2 3 4 5 6 7 3093 +-+-+-+-+-+-+-+-+ 3094 | Transport | 3095 +-+-+-+-+-+-+-+-+ 3097 Type: 15 for CAPWAP Transport Protocol 3099 Length: 1 3101 Transport: The transport to use for the CAPWAP data channel. The 3102 following enumerated values are supported: 3104 1 - UDP-Lite: The UDP-Lite transport protocol is to be used for 3105 the CAPWAP data channel. Note that this option is illegal is 3106 either the WTP or the AC uses IPv4. 3108 2 - UDP: The UDP transport protocol is to be used for the CAPWAP 3109 data channel. 3111 4.6.16. Data Transfer Data 3113 The Data Transfer Data message element is used by the WTP to provide 3114 information to the AC for debugging purposes. 3116 0 1 2 3 3117 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 3118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3119 | Data Type | Data Mode | Data Length | 3120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3121 | Data .... 3122 +-+-+-+-+-+-+-+-+ 3124 Type: 16 for Data Transfer Data 3126 Length: >= 5 3128 Data Type: An 8-bit value representing the transfer Data Type. The 3129 following enumerated values are supported: 3131 1 - Transfer data is included 3133 2 - Last Transfer Data Block is included (EOF) 3135 5 - An error occurred. Transfer is aborted 3137 Data Mode: An 8-bit value the type of information being 3138 transmitted. The following enumerated values are supported: 3140 0 - Reserved 3142 1 - WTP Crash Data 3144 2 - WTP Memory Dump 3146 Data Length: Length of data field, with a maximum size of 65535. 3148 Data: Data being transferred from the WTP to the AC, whose type is 3149 identified via the Data Mode field. 3151 4.6.17. Data Transfer Mode 3153 The Data Transfer Mode message element is used by the WTP to indicate 3154 the type of data transfer information it is sending to the AC for 3155 debugging purposes. 3157 0 3158 0 1 2 3 4 5 6 7 3159 +-+-+-+-+-+-+-+-+ 3160 | Data Mode | 3161 +-+-+-+-+-+-+-+-+ 3163 Type: 17 for Data Transfer Mode 3165 Length: 1 3167 Data Mode: An 8-bit value the type of information being requested. 3168 The following enumerated values are supported: 3170 0 - Reserved 3172 1 - WTP Crash Data 3174 2 - WTP Memory Dump 3176 4.6.18. Decryption Error Report 3178 The Decryption Error Report message element value is used by the WTP 3179 to inform the AC of decryption errors that have occurred since the 3180 last report. Note that this error reporting mechanism is not used if 3181 encryption and decryption services are provided in the AC. 3183 0 1 2 3184 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 3185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3186 | Radio ID |Num Of Entries | Length | MAC Address... 3187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3189 Type: 18 for Decryption Error Report 3191 Length: >= 9 3193 Radio ID: The Radio Identifier refers to an interface index on the 3194 WTP. 3196 Num of Entries: The number of instances of the Type/MAC Addresses 3197 fields in the array. This field MUST NOT exceed the value of 255. 3199 Length: The length of the MAC Address field. The following formats, 3200 and lengths, are supported [EUI-48] and [EUI-64]. 3202 MAC Address: MAC addresses of the station that has caused 3203 decryption errors. 3205 4.6.19. Decryption Error Report Period 3207 The Decryption Error Report Period message element value is used by 3208 the AC to inform the WTP how frequently it should send decryption 3209 error report messages. Note that this error reporting mechanism is 3210 not used if encryption and decryption services are provided in the 3211 AC. 3213 0 1 2 3214 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 3215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3216 | Radio ID | Report Interval | 3217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3219 Type: 19 for Decryption Error Report Period 3220 Length: 3 3222 Radio ID: The Radio Identifier refers to an interface index on the 3223 WTP. 3225 Report Interval: A 16-bit unsigned integer indicating the time, in 3226 seconds. The default value for this message element can be found 3227 in Section 4.7.11. 3229 4.6.20. Delete MAC ACL Entry 3231 The Delete MAC ACL Entry message element is used by an AC to delete a 3232 MAC ACL entry on a WTP, ensuring that the WTP provides service to the 3233 MAC addresses provided in the message. 3235 0 1 2 3 3236 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 3237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3238 | Num of Entries| Length | MAC Address ... 3239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3241 Type: 20 for Delete MAC ACL Entry 3243 Length: >= 8 3245 Num of Entries: The number of instances of the Type/MAC Addresses 3246 fields in the array. This field MUST NOT exceed the value of 255. 3248 Length: The length of the MAC Address field. The following formats, 3249 and lengths, are supported [EUI-48] and [EUI-64]. 3251 MAC Address: An array of MAC Addresses to delete from the ACL. 3253 4.6.21. Delete Station 3255 The Delete Station message element is used by the AC to inform a WTP 3256 that it should no longer provide service to a particular station. 3257 The WTP MUST terminate service to the station immediately upon 3258 receiving this message element. 3260 The transmission of a Delete Station message element could occur for 3261 various reasons, including for administrative reasons, or if the 3262 station has roamed to another WTP. 3264 The Delete Station message element MAY be sent by the WTP, in the WTP 3265 Event Request message, to inform the AC that a particular station is 3266 no longer being provided service. This could occur as a result of an 3267 Idle Timeout (see section 4.4.43), due to internal resource shortages 3268 or for some other reason. 3270 0 1 2 3 3271 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 3272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3273 | Radio ID | Length | MAC Address... 3274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3276 Type: 21 for Delete Station 3278 Length: >= 8 3280 Radio ID: An 8-bit value representing the radio 3282 Length: The length of the MAC Address field. The following formats, 3283 and lengths, are supported [EUI-48] and [EUI-64]. 3285 MAC Address: The station's MAC Address 3287 4.6.22. Delete Static MAC ACL Entry 3289 The Delete Static MAC ACL Entry message element is used by an AC to 3290 delete a previously added static MAC ACL entry on a WTP, ensuring 3291 that the WTP provides service to the MAC addresses provided in the 3292 message. 3294 0 1 2 3 3295 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 3296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3297 | Num of Entries| Length | MAC Address ... 3298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3300 Type: 22 for Delete Static MAC ACL Entry 3302 Length: >= 8 3304 Num of Entries: The number of instances of the Type/MAC Addresses 3305 fields in the array. This field MUST NOT exceed the value of 3306 1024. 3308 Length: The length of the MAC Address field. The following formats, 3309 and lengths, are supported [EUI-48] and [EUI-64]. 3311 MAC Address: An array of MAC Addresses to delete from the static 3312 MAC ACL entry. 3314 4.6.23. Discovery Type 3316 The Discovery Type message element is used by the WTP to indicate how 3317 it has come to know about the existence of the AC to which it is 3318 sending the Discovery Request message. 3320 0 3321 0 1 2 3 4 5 6 7 3322 +-+-+-+-+-+-+-+-+ 3323 | Discovery Type| 3324 +-+-+-+-+-+-+-+-+ 3326 Type: 23 for Discovery Type 3328 Length: 1 3330 Discovery Type: An 8-bit value indicating how the WTP discovered 3331 the AC. The following enumerated values are supported: 3333 0 - Unknown 3335 1 - Static Configuration 3337 2 - DHCP 3339 3 - DNS 3341 4 - AC Referral (used when the AC was configured either through 3342 the AC IPv4 List or AC IPv6 List message element) 3344 4.6.24. Duplicate IPv4 Address 3346 The Duplicate IPv4 Address message element is used by a WTP to inform 3347 an AC that it has detected another IP device using the same IP 3348 address that the WTP is currently using. 3350 The WTP MUST transmit this message element with the status set to 1 3351 after it has detected a duplicate IP address. When the WTP detects 3352 that the duplicate IP address has been cleared, it MUSY send this 3353 message element with the status set to 0. 3355 0 1 2 3 3356 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 3357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3358 | IP Address | 3359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3360 | Status | Length | MAC Address ... 3361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3363 Type: 24 for Duplicate IPv4 Address 3365 Length: >= 12 3367 IP Address: The IP Address currently used by the WTP. 3369 Status: The status of the duplicate IP address. The value MUST be 3370 set to 1 when a duplicate address is detected, and 0 when the 3371 duplicate address has been cleared. 3373 Length: The length of the MAC Address field. The following formats, 3374 and lengths, are supported [EUI-48] and [EUI-64]. 3376 MAC Address: The MAC Address of the offending device. 3378 4.6.25. Duplicate IPv6 Address 3380 The Duplicate IPv6 Address message element is used by a WTP to inform 3381 an AC that it has detected another host using the same IP address 3382 that the WTP is currently using. 3384 The WTP MUST transmit this message element with the status set to 1 3385 after it has detected a duplicate IP address. When the WTP detects 3386 that the duplicate IP address has been cleared, it MUST send this 3387 message element with the status set to 0. 3389 0 1 2 3 3390 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 3391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3392 | IP Address | 3393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3394 | IP Address | 3395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3396 | IP Address | 3397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3398 | IP Address | 3399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3400 | Status | Length | MAC Address ... 3401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3403 Type: 25 for Duplicate IPv6 Address 3405 Length: >= 24 3407 IP Address: The IP Address currently used by the WTP. 3409 Status: The status of the duplicate IP address. The value MUST be 3410 set to 1 when a duplicate address is detected, and 0 when the 3411 duplicate address has been cleared. 3413 Length: The length of the MAC Address field. The following formats, 3414 and lengths, are supported [EUI-48] and [EUI-64]. 3416 MAC Address: The MAC Address of the offending device. 3418 4.6.26. Idle Timeout 3420 The Idle Timeout message element is sent by the AC to the WTP to 3421 provide the idle timeout value that the WTP SHOULD enforce for its 3422 active stations. The value applies to all radios on the WTP. 3424 0 1 2 3 3425 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 3426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3427 | Timeout | 3428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3430 Type: 26 for Idle Timeout 3432 Length: 4 3434 Timeout: The current idle timeout, in seconds, to be enforced by 3435 the WTP. The default value for this message element is specified 3436 in Section 4.7.8. 3438 4.6.27. Image Data 3440 The Image Data message element is present in the Image Data Request 3441 message sent by the AC and contains the following fields. 3443 0 1 2 3 3444 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 3445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3446 | Data Type | Data .... 3447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3449 Type: 27 for Image Data 3451 Length: >= 1 3453 Data Type: An 8-bit value representing the image Data Type. The 3454 following enumerated values are supported: 3456 1 - Image data is included 3458 2 - Last Image Data Block is included (EOF) 3460 5 - An error occurred. Transfer is aborted 3462 Data: The Image Data field contains up to 1024 characters, and its 3463 length is inferred from this message element's length field. If 3464 the block being sent is the last one, the Opcode is set to 2. The 3465 AC MAY opt to abort the data transfer by setting the Opcode to 5. 3466 When the Opcode is 5, the Value field has a zero length. 3468 4.6.28. Image Identifier 3470 The Image Identifier message element is sent by the AC to the WTP and 3471 is used to indicate the expected active software version that is to 3472 be run on the WTP. The value is a variable length UTF-8 encoded 3473 string, which is NOT zero terminated. 3475 0 1 2 3 3476 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 3477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3478 | Vendor Identifier | 3479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3480 | Data... 3481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3483 Type: 28 for Image Identifier 3485 Length: >= 1 3487 Data Length: Length of data field, with a maximum size of 65535. 3489 Data: A variable length UTF-8 encoded string containing the 3490 firmware identifier to be run on the WTP, whose length MUST NOT 3491 exceed 1024 octets. The length of this field is inferred from 3492 this message element's length field. 3494 4.6.29. Image Information 3496 The Image Information message element is present in the Image Data 3497 Response message sent by the AC to the WTP and contains the following 3498 fields. 3500 0 1 2 3 3501 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 3502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3503 | File Size | 3504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3505 | Hash | 3506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3507 | Hash | 3508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3509 | Hash | 3510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3511 | Hash | 3512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3514 Type: 29 for Image Information 3516 Length: 20 3518 File Size: A 32-bit value containing the size of the file, in 3519 bytes, that will be transferred by the AC to the WTP. 3521 Hash: A 16 octet hash of the image. The hash is computed using 3522 MD5, using the following pseudo-code: 3524 #include 3525 CapwapCreateHash(char *hash, char *image, int image_len) 3526 { 3527 MD_CTX context; 3529 MDInit (&context); 3530 MDUpdate (&context, buffer, len); 3531 MDFinal (hash, &context); 3532 } 3534 4.6.30. Initiate Download 3536 The Initiate Download message element is used by the AC to inform the 3537 WTP that the WTP SHOULD initiate a firmware upgrade. The WTP 3538 subsequently transmits an Image Data Request message which includes 3539 the Image Download message element. This message element does not 3540 contain any data. 3542 Type: 30 for Initiate Download 3544 Length: 0 3546 4.6.31. Location Data 3548 The Location Data message element is a variable length byte UTF-8 3549 encoded string containing user defined location information (e.g. 3550 "Next to Fridge"). This information is configurable by the network 3551 administrator, and allows the WTP location to be determined. The 3552 string is not zero terminated. 3554 0 3555 0 1 2 3 4 5 6 7 3556 +-+-+-+-+-+-+-+-+- 3557 | Location ... 3558 +-+-+-+-+-+-+-+-+- 3560 Type: 31 for Location Data 3562 Length: >= 1 3564 Location: A non-zero terminated UTF-8 encoded string containing the 3565 WTP location, whose maximum size MUST NOT exceed 1024. 3567 4.6.32. Maximum Message Length 3569 The Maximum Message Length message element is included in the Join 3570 Request message by the WTP to indicate the maximum CAPWAP message 3571 length that it supports to the AC. The Maximum Message Length 3572 message element is optionally included in Join Response message by 3573 the AC to indicate the maximum CAPWAP message length that it supports 3574 to the WTP. 3576 0 1 3577 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3579 | Maximum Message Length | 3580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3582 Type: 32 for Maximum Message Length 3584 Length: 2 3586 Maximum Message Length An 16-bit unsigned integer indicating the 3587 maximum message length. 3589 4.6.33. Radio Administrative State 3591 The Radio Administrative State message element is used to communicate 3592 the state of a particular radio. The Radio Administrative State 3593 message element is sent by the AC to change the state of the WTP. 3594 The WTP saves the value, to ensure that it remains across WTP resets. 3595 The WTP communicates this message element during the configuration 3596 phase, in the Configuration Status Request message, to ensure that AC 3597 has the WTP radio current administrative state settings. The message 3598 element contains the following fields. 3600 0 1 3601 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3603 | Radio ID | Admin State | 3604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3606 Type: 33 for Radio Administrative State 3608 Length: 2 3610 Radio ID: An 8-bit value representing the radio to configure. The 3611 Radio ID field MAY also include the value of 0xff, which is used 3612 to identify the WTP. If an AC wishes to change the administrative 3613 state of a WTP, it includes 0xff in the Radio ID field. 3615 Admin State: An 8-bit value representing the administrative state 3616 of the radio. The default value for the Admin State field is 3617 listed in Section 4.8.1. The following enumerated values are 3618 supported: 3620 0 - Reserved 3622 1 - Enabled 3624 2 - Disabled 3626 4.6.34. Radio Operational State 3628 The Radio Operational State message element is sent by the WTP to the 3629 AC to communicate a radio's operational state. This message element 3630 is included in the Configuration Update Response message by the WTP 3631 if it was requested to change the state of its radio, via the Radio 3632 Administrative State message element, but was unable to comply to the 3633 request. This message element is included in the Change State Event 3634 message when a WTP radio state was changed unexpectedly. This could 3635 occur due to a hardware failure. Note that the operational state 3636 setting is not saved on the WTP, and therefore does not remain across 3637 WTP resets. The value contains three fields, as shown below. 3639 0 1 2 3640 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 3641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3642 | Radio ID | State | Cause | 3643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3645 Type: 34 for Radio Operational State 3647 Length: 3 3649 Radio ID: The Radio Identifier refers to an interface index on the 3650 WTP. A value of 0xFF is invalid, as it is not possible to change 3651 the WTP's operational state. 3653 State: An 8-bit boolean value representing the state of the radio. 3654 The following enumerated values are supported: 3656 0 - Reserved 3658 1 - Enabled 3660 2 - Disabled 3662 Cause: When a radio is inoperable, the cause field contains the 3663 reason the radio is out of service. The following enumerated 3664 values are supported: 3666 0 - Normal 3668 1 - Radio Failure 3670 2 - Software Failure 3672 3 - Administratively Set 3674 4.6.35. Result Code 3676 The Result Code message element value is a 32-bit integer value, 3677 indicating the result of the Request message corresponding to the 3678 Sequence Number included in the Response message. 3680 0 1 2 3 3681 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 3682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3683 | Result Code | 3684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3686 Type: 35 for Result Code 3688 Length: 4 3690 Result Code: The following enumerated values are defined: 3692 0 Success 3694 1 Failure (AC List message element MUST be present) 3696 2 Success (NAT detected) 3698 3 Join Failure (unspecified) 3700 4 Join Failure (Resource Depletion) 3702 5 Join Failure (Unknown Source) 3704 6 Join Failure (Incorrect Data) 3706 7 Join Failure (Session ID already in use) 3708 8 Join Failure (WTP Hardware not supported) 3710 9 Join Failure (Binding Not Supported) 3712 10 Reset Failure (Unable to Reset) 3714 11 Reset Failure (Firmware Write Error) 3716 12 Configuration Failure (Unable to Apply Requested Configuration 3717 - Service Provided Anyhow) 3719 13 Configuration Failure (Unable to Apply Requested Configuration 3720 - Service Not Provided) 3722 14 Image Data Error (Invalid Checksum) 3724 15 Image Data Error (Invalid Data Length) 3726 16 Image Data Error (Other Error) 3728 17 Image Data Error (Image Already Present) 3730 18 Message Unexpected (Invalid in current state) 3731 19 Message Unexpected (Unrecognized Request) 3733 20 Failure - Missing Mandatory Message Element 3735 21 Failure - Unrecognized Message Element 3737 22 Data Transfer Error (No Information to Transfer) 3739 4.6.36. Returned Message Element 3741 The Returned Message Element is sent by the WTP in the Change State 3742 Event Request message to communicate to the AC which message elements 3743 in the Configuration Status Response it was unable to apply locally. 3744 The Returned Message Element message element contains a result code 3745 indicating the reason that the configuration could not be applied, 3746 and encapsulates the failed message element. 3748 0 1 2 3 3749 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 3750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3751 | Reason | Length | Message Element... 3752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3754 Type: 36 for Returned Message Element 3756 Length: >= 6 3758 Reason: The reason why the configuration in the offending message 3759 element could not be applied by the WTP. The following enumerated 3760 values are supported: 3762 0 - Reserved 3764 1 - Unknown Message Element 3766 2 - Unsupported Message Element 3768 3 - Unknown Message Element Value 3770 4 - Unsupported Message Element Value 3772 Length: The length of the Message Element field, which MUST NOT 3773 exceed 65535 octets. 3775 Message Element: The Message Element field encapsulates the message 3776 element sent by the AC in the Configuration Status Response 3777 message that caused the error. 3779 4.6.37. Session ID 3781 The Session ID message element value contains a randomly generated 3782 unsigned 32-bit integer. 3784 0 1 2 3 3785 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 3786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3787 | Session ID | 3788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3790 Type: 37 for Session ID 3792 Length: 4 3794 Session ID: A 32-bit unsigned integer used as a random session 3795 identifier 3797 4.6.38. Statistics Timer 3799 The Statistics Timer message element value is used by the AC to 3800 inform the WTP of the frequency with which it expects to receive 3801 updated statistics. 3803 0 1 3804 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3806 | Statistics Timer | 3807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3809 Type: 38 for Statistics Timer 3811 Length: 2 3813 Statistics Timer: A 16-bit unsigned integer indicating the time, in 3814 seconds. The default value for this timer is specified in 3815 Section 4.7.14. 3817 4.6.39. Vendor Specific Payload 3819 The Vendor Specific Payload message element is used to communicate 3820 vendor specific information between the WTP and the AC. The Vendor 3821 Specific Payload message element MAY be present in any CAPWAP 3822 message. The message element uses the following format: 3824 0 1 2 3 3825 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 3826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3827 | Vendor Identifier | 3828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3829 | Element ID | Data... 3830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3832 Type: 39 for Vendor Specific 3834 Length: >= 7 3836 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 3837 Network Management Private Enterprise Codes" [RFC3232] 3839 Element ID: A 16-bit Element Identifier which is managed by the 3840 vendor. 3842 Data: Variable length vendor specific information, whose contents 3843 and format are proprietary and understood based on the Element ID 3844 field. This field MUST NOT exceed 2048 octets. 3846 4.6.40. WTP Board Data 3848 The WTP Board Data message element is sent by the WTP to the AC and 3849 contains information about the hardware present. 3851 0 1 2 3 3852 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 3853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3854 | Vendor Identifier | 3855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3856 | Board Data Sub-Element... 3857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3859 Type: 40 for WTP Board Data 3861 Length: >=14 3863 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 3864 Network Management Private Enterprise Codes" 3866 Board Data Sub-Element: The WTP Board Data message element contains 3867 multiple Board Data sub-elements, some of which are mandatory and 3868 some are optional, as described below. The Board Data sub-element 3869 has the following format: 3871 0 1 2 3 3872 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 3873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3874 | Board Data Type | Board Data Length | 3875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3876 | Board Data Value... 3877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3879 Board Data Type: The Board Data Type field identifies the data 3880 being encoded. The CAPWAP protocol defines the following 3881 values, and each of these types identify whether their presence 3882 is mandatory or optional: 3884 0 - WTP Model Number: The WTP Model Number MUST be included 3885 in the WTP Board Data message element. 3887 1 - WTP Serial Number: The WTP Serial Number MUST be included 3888 in the WTP Board Data message element. 3890 2 - Board ID: A hardware identifier, which MAY be included in 3891 the WTP Board Data message element. 3893 3 - Board Revision A revision number of the board, which MAY 3894 be included in the WTP Board Data message element. 3896 4 - Base MAC Address The WTP's Base MAC Address, which MAY be 3897 assigned to the primary Ethernet interface. 3899 Board Data Length: The length of the data in the Board Data 3900 Value field, whose length MUST NOT exceed 1024 octets. 3902 Board Data Value: The data associated with the Board Data Type 3903 field for this Board Data sub-element. 3905 4.6.41. WTP Descriptor 3907 The WTP Descriptor message element is used by a WTP to communicate 3908 its current hardware and software (firmware) configuration. The 3909 value contains the following fields. 3911 0 1 2 3 3912 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 3913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3914 | Max Radios | Radios in use | Encryption Capabilities | 3915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3916 | Descriptor Sub-Element... 3917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3919 Type: 41 for WTP Descriptor 3921 Length: >= 31 3923 Max Radios: An 8-bit value representing the number of radios (where 3924 each radio is identified via the Radio ID field) supported by the 3925 WTP. 3927 Radios in use: An 8-bit value representing the number of radios in 3928 use in the WTP. 3930 Encryption Capabilities: This 16-bit field is used by the WTP to 3931 communicate its capabilities to the AC. A WTP that does not have 3932 any encryption capabilities sets this field to zero (0). Refer to 3933 the specific wireless binding for further specification of the 3934 Encryption Capabilities field. 3936 Descriptor Sub-Element: The WTP Descriptor message element contains 3937 multiple Descriptor sub-elements, some of which are mandatory and 3938 some are optional, as described below. The Descriptor sub-element 3939 has the following format: 3941 0 1 2 3 3942 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 3943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3944 | Descriptor Vendor Identifier | 3945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3946 | Descriptor Type | Descriptor Length | 3947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3948 | Descriptor Data... 3949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3951 Descriptor Vendor Identifier: A 32-bit value containing the IANA 3952 assigned "SMI Network Management Private Enterprise Codes". 3954 Descriptor Type: The Descriptor Type field identifies the data 3955 being encoded. The CAPWAP protocol defines the following 3956 values, and each of these types identify whether their presence 3957 is mandatory or optional: 3959 0 - Hardware Version: The WTP hardware version number MUST be 3960 present. 3962 1 - Active Software Version: The WTP running software version 3963 number MUST be present. 3965 2 - Boot Version: The WTP boot loader version number MUST be 3966 present. 3968 3 - Other Software Version: The WTP non-running software 3969 (firmware) version number MAY be present. This type is used 3970 to communicate alternate software versions that are 3971 available on the WTP's non-volatile storage. 3973 Descriptor Length: Length of vendor specific encoding of 3974 Descriptor Data field, whose length MUST NOT exceed 1024 3975 octets. 3977 Descriptor Data: Vendor specific data of WTP information encoded 3978 in the UTF-8 format. 3980 4.6.42. WTP Fallback 3982 The WTP Fallback message element is sent by the AC to the WTP to 3983 enable or disable automatic CAPWAP fallback in the event that a WTP 3984 detects its preferred AC, and is not currently connected to it. 3986 0 3987 0 1 2 3 4 5 6 7 3988 +-+-+-+-+-+-+-+-+ 3989 | Mode | 3990 +-+-+-+-+-+-+-+-+ 3992 Type: 42 for WTP Fallback 3994 Length: 1 3996 Mode: The 8-bit value indicates the status of automatic CAPWAP 3997 fallback on the WTP. When enabled, if the WTP detects that its 3998 primary AC is available, and that the WTP is not connected to the 3999 primary AC, the WTP SHOULD automatically disconnect from its 4000 current AC and reconnect to its primary AC. If disabled, the WTP 4001 will only reconnect to its primary AC through manual intervention 4002 (e.g., through the Reset Request message). The default value for 4003 this field is specified in Section 4.8.9. The following 4004 enumerated values are supported: 4006 0 - Reserved 4008 1 - Enabled 4009 2 - Disabled 4011 4.6.43. WTP Frame Tunnel Mode 4013 The WTP Frame Tunnel Mode message element allows the WTP to 4014 communicate the tunneling modes of operation which it supports to the 4015 AC. A WTP that advertises support for all types allows the AC to 4016 select which type will be used, based on its local policy. 4018 0 4019 0 1 2 3 4 5 6 7 4020 +-+-+-+-+-+-+-+-+ 4021 | Tunnel Mode | 4022 +-+-+-+-+-+-+-+-+ 4024 Type: 43 for WTP Frame Tunnel Mode 4026 Length: 1 4028 Frame Tunnel Mode: The Frame Tunnel mode specifies the tunneling 4029 modes for station data that are supported by the WTP. The 4030 following values are supported for this bit field: 4032 1 - Local Bridging: When Local Bridging is used, the WTP does 4033 not tunnel user traffic to the AC; all user traffic is locally 4034 bridged. This value MUST NOT be used when the WTP MAC Type is 4035 set to Split-MAC. 4037 2 - 802.3 Frame Tunnel Mode: The 802.3 Frame Tunnel Mode 4038 requires the WTP and AC to encapsulate all user payload as 4039 native IEEE 802.3 frames (see Section 4.4). All user traffic 4040 is tunneled to the AC. This value MUST NOT be used when the 4041 WTP MAC Type is set to Split-MAC. 4043 4 - Native Frame Tunnel Mode: Native Frame Tunnel mode requires 4044 the WTP and AC to encapsulate all user payloads as native 4045 wireless frames, as defined by the wireless binding (see for 4046 example Section 4.4). 4048 7 - All: The WTP is capable of supporting all frame tunnel 4049 modes. 4051 4.6.44. WTP IPv4 IP Address 4053 The WTP IPv4 address is used to perform NAT detection. 4055 0 1 2 3 4056 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 4057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4058 | WTP IPv4 IP Address | 4059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4061 Type: 44 for WTP IPv4 IP Address 4063 Length: 4 4065 WTP IPv4 IP Address: The IPv4 address from which the WTP is sending 4066 packets. This field is used for NAT detection. 4068 4.6.45. WTP IPv6 IP Address 4070 The WTP IPv6 address is used to perform NAT detection (e.g., IPv4 to 4071 IPv6 NAT to help with technology transition). 4073 0 1 2 3 4074 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 4075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4076 | WTP IPv6 IP Address | 4077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4078 | WTP IPv6 IP Address | 4079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4080 | WTP IPv6 IP Address | 4081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4082 | WTP IPv6 IP Address | 4083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4085 Type: 45 for WTP IPv6 IP Address 4087 Length: 32 4089 WTP IPv6 IP Address: The IPv6 address from which the WTP is sending 4090 packets. This field is used for NAT detection. 4092 4.6.46. WTP MAC Type 4094 The WTP MAC-Type message element allows the WTP to communicate its 4095 mode of operation to the AC. A WTP that advertises support for both 4096 modes allows the AC to select the mode to use, based on local policy. 4098 0 4099 0 1 2 3 4 5 6 7 4100 +-+-+-+-+-+-+-+-+ 4101 | MAC Type | 4102 +-+-+-+-+-+-+-+-+ 4104 Type: 46 for WTP MAC Type 4106 Length: 1 4108 MAC Type: The MAC mode of operation supported by the WTP. The 4109 following enumerated values are supported: 4111 0 - Local-MAC: Local-MAC is the default mode that MUST be 4112 supported by all WTPs. 4114 1 - Split-MAC: Split-MAC support is optional, and allows the AC 4115 to receive and process native wireless frames. 4117 2 - Both: WTP is capable of supporting both Local-MAC and Split- 4118 MAC. 4120 4.6.47. WTP Name 4122 The WTP Name message element is a variable length byte UTF-8 encoded 4123 string. The string is not zero terminated. 4125 0 4126 0 1 2 3 4 5 6 7 4127 +-+-+-+-+-+-+-+-+- 4128 | WTP Name ... 4129 +-+-+-+-+-+-+-+-+- 4131 Type: 47 for WTP Name 4133 Length: >= 1 4135 WTP Name: A non-zero terminated UTF-8 encoded string containing the 4136 WTP name, whose maximum size MUST NOT exceed 512 bytes. 4138 4.6.48. WTP Radio Statistics 4140 The WTP Radio Statistics message element is sent by the WTP to the AC 4141 to communicate statistics on radio behavior and reasons why the WTP 4142 radio has been reset. These counters are never reset on the WTP, and 4143 will therefore roll over to zero when the maximum size has been 4144 reached. 4146 0 1 2 3 4147 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 4148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4149 | Radio ID | Last Fail Type| Reset Count | 4150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4151 | SW Failure Count | HW Failure Count | 4152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4153 | Other Failure Count | Unknown Failure Count | 4154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4155 | Config Update Count | Channel Change Count | 4156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4157 | Band Change Count | Current Noise Floor | 4158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4160 Type: 49 for WTP Radio Statistics 4162 Length: 20 4164 Radio ID: The radio ID of the radio to which the statistics apply. 4166 Last Failure Type: The last WTP failure. The following enumerated 4167 values are supported: 4169 0 - Statistic Not Supported 4171 1 - Software Failure 4173 2 - Hardware Failure 4175 3 - Other Failure 4177 255 - Unknown (e.g., WTP doesn't keep track of info) 4179 Reset Count: The number of times that that the radio has been 4180 reset. 4182 SW Failure Count: The number of times that the radio has failed due 4183 to software related reasons. 4185 HW Failure Count: The number of times that the radio has failed due 4186 to hardware related reasons. 4188 Other Failure Count: The number of times that the radio has failed 4189 due to known reasons, other than software or hardware failure. 4191 Unknown Failure Count: The number of times that the radio has 4192 failed for unknown reasons. 4194 Config Update Count: The number of times that the radio 4195 configuration has been updated. 4197 Channel Change Count: The number of times that the radio channel 4198 has been changed. 4200 Band Change Count: The number of times that the radio has changed 4201 frequency bands. 4203 Current Noise Floor: A signed integer which indicates the noise 4204 floor of the radio receiver in units of dBm. 4206 4.6.49. WTP Reboot Statistics 4208 The WTP Reboot Statistics message element is sent by the WTP to the 4209 AC to communicate reasons why WTP reboots have occurred. These 4210 counters are never reset on the WTP, and will therefore roll over to 4211 zero when the maximum size has been reached. 4213 0 1 2 3 4214 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 4215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4216 | Reboot Count | AC Initiated Count | 4217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4218 | Link Failure Count | SW Failure Count | 4219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4220 | HW Failure Count | Other Failure Count | 4221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4222 | Unknown Failure Count |Last Failure Type| 4223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4225 Type: 50 for WTP Reboot Statistics 4227 Length: 15 4229 Reboot Count: The number of reboots that have occurred due to a WTP 4230 crash. A value of 65535 implies that this information is not 4231 available on the WTP. 4233 AC Initiated Count: The number of reboots that have occurred at the 4234 request of a CAPWAP protocol message, such as a change in 4235 configuration that required a reboot or an explicit CAPWAP 4236 protocol reset request. A value of 65535 implies that this 4237 information is not available on the WTP. 4239 Link Failure Count: The number of times that a CAPWAP protocol 4240 connection with an AC has failed due to link failure. 4242 SW Failure Count: The number of times that a CAPWAP protocol 4243 connection with an AC has failed due to software related reasons. 4245 HW Failure Count: The number of times that a CAPWAP protocol 4246 connection with an AC has failed due to hardware related reasons. 4248 Other Failure Count: The number of times that a CAPWAP protocol 4249 connection with an AC has failed due to known reasons, other than 4250 AC initiated, link, SW or HW failure. 4252 Unknown Failure Count: The number of times that a CAPWAP protocol 4253 connection with an AC has failed for unknown reasons. 4255 Last Failure Type: The failure type of the most recent WTP failure. 4256 The following enumerated values are supported: 4258 0 - Not Supported 4260 1 - AC Initiated (see Section 9.2) 4262 2 - Link Failure 4264 3 - Software Failure 4266 4 - Hardware Failure 4268 5 - Other Failure 4270 255 - Unknown (e.g., WTP doesn't keep track of info) 4272 4.6.50. WTP Static IP Address Information 4274 The WTP Static IP Address Information message element is used by an 4275 AC to configure or clear a previously configured static IP address on 4276 a WTP. 4278 0 1 2 3 4279 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 4280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4281 | IP Address | 4282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4283 | Netmask | 4284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4285 | Gateway | 4286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4287 | Static | 4288 +-+-+-+-+-+-+-+-+ 4290 Type: 51 for WTP Static IP Address Information 4292 Length: 13 4294 IP Address: The IP Address to assign to the WTP. This field is 4295 only valid if the static field is set to one. 4297 Netmask: The IP Netmask. This field is only valid if the static 4298 field is set to one. 4300 Gateway: The IP address of the gateway. This field is only valid 4301 if the static field is set to one. 4303 Netmask: The IP Netmask. This field is only valid if the static 4304 field is set to one. 4306 Static: An 8-bit boolean stating whether the WTP should use a 4307 static IP address or not. A value of zero disables the static IP 4308 address, while a value of one enables it. 4310 4.7. CAPWAP Protocol Timers 4312 This section contains the definition of the CAPWAP timers. 4314 4.7.1. ChangeStatePendingTimer 4316 The maximum time, in seconds, the AC will wait for the Change State 4317 Event Request from the WTP after having transmitted a successful 4318 Configuration Status Response message. 4320 Default: 25 seconds 4322 4.7.2. DataChannelKeepAlive 4324 The DataChannelKeepAlive timer is used by the WTP to determine the 4325 next opportunity when it must transmit the Data Channel KeepAlive, in 4326 seconds. 4328 Default: 30 seconds 4330 4.7.3. DataChannelDeadInterval 4332 The minimum time, in seconds, a WTP MUST wait without having received 4333 a Data Channel Keep Alive packet before the destination for the Data 4334 Channel Keep Alive packets may be considered dead. The value of this 4335 timer MUST be no less than 2*DataChannelKeepAlive seconds and no 4336 greater that 240 seconds. 4338 Default: 60 4340 4.7.4. DataCheckTimer 4342 The number of seconds the AC will wait for the Data Channel Keep 4343 Alive, which is required by the CAPWAP state machine's Data Check 4344 state. The AC resets the state machine if this timer expires prior 4345 to transitioning to the next state. 4347 Default: 30 4349 4.7.5. DiscoveryInterval 4351 The minimum time, in seconds, that a WTP MUST wait after receiving a 4352 Discovery Response message, before initiating a DTLS handshake. 4354 Default: 5 4356 4.7.6. DTLSSessionDelete 4358 The minimum time, in seconds, a WTP MUST wait for DTLS session 4359 deletion. 4361 Default: 5 4363 4.7.7. EchoInterval 4365 The minimum time, in seconds, between sending Echo Request messages 4366 to the AC with which the WTP has joined. 4368 Default: 30 4370 4.7.8. IdleTimeout 4372 The default Idle Timeout is 300 seconds. 4374 4.7.9. ImageDataStartTimer 4376 The number of seconds the AC or WTP will wait for its peer to 4377 transmit the Image Data Request. 4379 Default: 30 4381 4.7.10. MaxDiscoveryInterval 4383 The maximum time allowed between sending Discovery Request messages, 4384 in seconds. This value MUST be no less than 2 seconds and no greater 4385 than 180 seconds. 4387 Default: 20 seconds. 4389 4.7.11. ReportInterval 4391 The ReportInterval is used by the WTP to determine the interval the 4392 WTP uses between sending the Decryption Error message elements to the 4393 AC to decryption errors, in seconds. 4395 The default Report Interval is 120 seconds. 4397 4.7.12. RetransmitInterval 4399 The minimum time, in seconds, in which a non-acknowledged CAPWAP 4400 packet will be retransmitted. 4402 Default: 3 4404 4.7.13. SilentInterval 4406 For a WTP, this is the minimum time, in seconds, a WTP MUST wait 4407 before it MAY again send Discovery Request messages or attempt to a 4408 establish DTLS session. For an AC, this is the minimum time, in 4409 seconds, during which the AC SHOULD ignore all CAPWAP and DTLS 4410 packets received from the WTP that is in the Sulking state. 4412 Default: 30 seconds 4414 4.7.14. StatisticsTimer 4416 The StatisticsTimer is used by the WTP to determine the interval the 4417 WTP uses between the WTP Events Requests it transmits to the AC to 4418 communicate its statistics, in seconds. 4420 Default: 120 seconds 4422 4.7.15. WaitDTLS 4424 The maximum time, in seconds, a WTP MUST wait without having received 4425 a DTLS Handshake message from an AC. This timer MUST be greater than 4426 30 seconds. 4428 Default: 60 4430 4.8. CAPWAP Protocol Variables 4432 This section defines the CAPWAP protocol variables, which are used 4433 for various protocol functions. Some of these variables are 4434 configurable, while others are counters or have a fixed value. For 4435 non counter related variables, default values are specified. 4436 However, when a WTP's variable configuration is explicitly overridden 4437 by an AC, the WTP MUST save the new value. 4439 4.8.1. AdminState 4441 The default Administrative State value is enabled (1). 4443 4.8.2. DiscoveryCount 4445 The number of Discovery Request messages transmitted by a WTP to a 4446 single AC. This is a monotonically increasing counter. 4448 4.8.3. FailedDTLSAuthFailCount 4450 The number of failed DTLS session establishment attempts due to 4451 authentication failures. 4453 4.8.4. FailedDTLSSessionCount 4455 The number of failed DTLS session establishment attempts. 4457 4.8.5. MaxDiscoveries 4459 The maximum number of Discovery Request messages that will be sent 4460 after a WTP boots. 4462 Default: 10 4464 4.8.6. MaxFailedDTLSSessionRetry 4466 The maximum number of failed DTLS session establishment attempts 4467 before the CAPWAP device enters a silent period. 4469 Default: 3. 4471 4.8.7. MaxRetransmit 4473 The maximum number of retransmissions for a given CAPWAP packet 4474 before the link layer considers the peer dead. 4476 Default: 5 4478 4.8.8. RetransmitCount 4480 The number of retransmissions for a given CAPWAP packet. This is a 4481 monotonically increasing counter. 4483 4.8.9. WTPFallBack 4485 The default WTP Fallback value is enabled (1). 4487 4.9. WTP Saved Variables 4489 In addition to the values defined in Section 4.8, the following 4490 values SHOULD be saved on the WTP in non-volatile memory. CAPWAP 4491 wireless bindings MAY define additional values that SHOULD be stored 4492 on the WTP. 4494 4.9.1. AdminRebootCount 4496 The number of times the WTP has rebooted administratively, defined in 4497 Section 4.6.49. 4499 4.9.2. FrameEncapType 4501 For WTPs that support multiple Frame Encapsulation Types, it is 4502 useful to save the value configured by the AC. The Frame 4503 Encapsulation Type is defined in Section 4.6.43. 4505 4.9.3. LastRebootReason 4507 The reason why the WTP last rebooted, defined in Section 4.6.49. 4509 4.9.4. MacType 4511 For WTPs that support multiple MAC Types, it is useful to save the 4512 value configured by the AC. The MACType is defined in 4513 Section 4.6.46. 4515 4.9.5. PreferredACs 4517 The preferred ACs, with the index, defined in Section 4.6.5. 4519 4.9.6. RebootCount 4521 The number of times the WTP has rebooted, defined in Section 4.6.49. 4523 4.9.7. Static ACL Table 4525 The static ACL table saved on the WTP, as configured by the Add 4526 Static MAC ACL Entry message element, see Section 4.6.9. 4528 4.9.8. Static IP Address 4530 The static IP Address assigned to the WTP, as configured by the WTP 4531 Static IP Address Information message element (see Section 4.6.50). 4533 4.9.9. WTPLinkFailureCount 4535 The number of times the link to the AC has failed, see 4536 Section 4.6.49. 4538 4.9.10. WTPLocation 4540 The WTP Location, defined in Section 4.6.31. 4542 4.9.11. WTPName 4544 The WTP Name, defined in Section 4.6.47. 4546 5. CAPWAP Discovery Operations 4548 The Discovery messages are used by a WTP to determine which ACs are 4549 available to provide service, and the capabilities and load of the 4550 ACs. 4552 5.1. Discovery Request Message 4554 The Discovery Request message is used by the WTP to automatically 4555 discover potential ACs available in the network. The Discovery 4556 Request message provides ACs with the primary capabilities of the 4557 WTP. A WTP must exchange this information to ensure subsequent 4558 exchanges with the ACs are consistent with the WTP's functional 4559 characteristics. 4561 Discovery Request messages MUST be sent by a WTP in the Discover 4562 state after waiting for a random delay less than 4563 MaxDiscoveryInterval, after a WTP first comes up or is 4564 (re)initialized. A WTP MUST send no more than the maximum of 4565 MaxDiscoveries Discovery Request messages, waiting for a random delay 4566 less than MaxDiscoveryInterval between each successive message. 4568 This is to prevent an explosion of WTP Discovery Request messages. 4569 An example of this occurring is when many WTPs are powered on at the 4570 same time. 4572 If a Discovery Response message is not received after sending the 4573 maximum number of Discovery Request messages, the WTP enters the 4574 Sulking state and MUST wait for an interval equal to SilentInterval 4575 before sending further Discovery Request messages. 4577 Upon receiving a Discovery Request message, the AC will respond with 4578 a Discovery Response message sent to the address in the source 4579 address of the received Discovery Request message. Once a Discovery 4580 Response has been received, if the WTP decides to establish a session 4581 with the responding AC, it SHOULD perform an MTU discovery, using the 4582 process described in Section 3.5. 4584 It is possible for the AC to receive a cleartext Discovery Request 4585 message while a DTLS session is already active with the WTP. This is 4586 most likely the case if the WTP has rebooted, perhaps due to a 4587 software or power failure, but could also be caused by a DoS attack. 4588 In such cases, any WTP state, including the state machine instance, 4589 MUST NOT be cleared until another DTLS session has been successfully 4590 established, communicated via the DTLSSessionEstablished DTLS 4591 notification (see Section 2.3.2.2). 4593 The binding specific WTP Radio Information message element (see 4594 Section 2.1) is included in the Discovery Request message to 4595 advertise WTP support for one or more CAPWAP bindings. 4597 The Discovery Request message is sent by the WTP when in the 4598 Discovery State. The AC does not transmit this message. 4600 The following message elements MUST be included in the Discovery 4601 Request message: 4603 o Discovery Type, see Section 4.6.23 4605 o WTP Board Data, see Section 4.6.40 4607 o WTP Descriptor, see Section 4.6.41 4609 o WTP Frame Tunnel Mode, see Section 4.6.43 4611 o WTP MAC Type, see Section 4.6.46 4613 o WTP Radio Information message element(s)that the WTP supports; 4614 These are defined by the individual link layer CAPWAP Binding 4615 Protocols (see Section 2.1). 4617 The following message elements MAY be included in the Discovery 4618 Request message: 4620 o Vendor Specific Payload, see Section 4.6.39 4622 5.2. Discovery Response Message 4624 The Discovery Response message provides a mechanism for an AC to 4625 advertise its services to requesting WTPs. 4627 When a WTP receives a Discovery Response message, it MUST wait for an 4628 interval not less than DiscoveryInterval for receipt of additional 4629 Discovery Response messages. After the DiscoveryInterval elapses, 4630 the WTP enters the DTLS-Init state and selects one of the ACs that 4631 sent a Discovery Response message and send a DTLS Handshake to that 4632 AC. 4634 One or more binding specific WTP Radio Information message elements 4635 (see Section 2.1) are included in the Discovery Request message to 4636 advertise AC support for the CAPWAP bindings. The AC MAY include 4637 only the bindings it shares in common with the WTP, known through the 4638 WTP Radio Information message elements received in the Discovery 4639 Request message, or it MAY include all of the bindings supported. 4640 The WTP MAY use the supported bindings in its AC decision process. 4641 Note that if the WTP joins an AC that does not support a specific 4642 CAPWAP binding, service for that binding MUST NOT be provided by the 4643 WTP. 4645 The Discovery Response message is sent by the AC when in the Idle 4646 State. The WTP does not transmit this message. 4648 The following message elements MUST be included in the Discovery 4649 Response Message: 4651 o AC Descriptor, see Section 4.6.1 4653 o AC Name, see Section 4.6.4 4655 o WTP Radio Information message element(s)that the AC supports; 4656 These are defined by the individual link layer CAPWAP Binding 4657 Protocols (see Section 2.1 for more information). 4659 o One of the following message elements MUST be included in the 4660 Discovery Response Message: 4662 * CAPWAP Control IPv4 Address, see Section 4.6.10 4664 * CAPWAP Control IPv6 Address, see Section 4.6.11 4666 The following message elements MAY be included in the Discovery 4667 Response message: 4669 o Vendor Specific Payload, see Section 4.6.39 4671 5.3. Primary Discovery Request Message 4673 The Primary Discovery Request message is sent by the WTP to determine 4674 whether its preferred (or primary) AC is available. 4676 A Primary Discovery Request message is sent by a WTP when it has a 4677 primary AC configured, and is connected to another AC. This 4678 generally occurs as a result of a failover, and is used by the WTP as 4679 a means to discover when its primary AC becomes available. Since the 4680 WTP only has a single instance of the CAPWAP state machine, the 4681 Primary Discovery Request is sent by the WTP when in the Run State. 4682 The AC does not transmit this message. 4684 The frequency of the Primary Discovery Request messages should be no 4685 more often than the sending of the Echo Request message. 4687 Upon receipt of a Primary Discovery Request message, the AC responds 4688 with a Primary Discovery Response message sent to the address in the 4689 source address of the received Primary Discovery Request message. 4691 The following message elements MUST be included in the Primary 4692 Discovery Request message. 4694 o Discovery Type, see Section 4.6.23 4696 o WTP Board Data, see Section 4.6.40 4698 o WTP Descriptor, see Section 4.6.41 4700 o WTP Frame Tunnel Mode, see Section 4.6.43 4702 o WTP MAC Type, see Section 4.6.46 4704 o WTP Radio Information message element(s)that the WTP supports; 4705 These are defined by the individual link layer CAPWAP Binding 4706 Protocols (see Section 2.1 for more information). 4708 The following message elements MAY be included in the Primary 4709 Discovery Request message: 4711 o Vendor Specific Payload, see Section 4.6.39 4713 5.4. Primary Discovery Response 4715 The Primary Discovery Response message enables an AC to advertise its 4716 availability and services to requesting WTPs that are configured to 4717 have the AC as its primary AC. 4719 The Primary Discovery Response message is sent by an AC after 4720 receiving a Primary Discovery Request message. 4722 When a WTP receives a Primary Discovery Response message, it may 4723 establish a CAPWAP protocol connection to its primary AC, based on 4724 the configuration of the WTP Fallback Status message element on the 4725 WTP. 4727 The Primary Discovery Response message is sent by the AC when in the 4728 Idle State. The WTP does not transmit this message. 4730 The following message elements MUST be included in the Primary 4731 Discovery Response message. 4733 o AC Descriptor, see Section 4.6.1 4735 o AC Name, see Section 4.6.4 4737 o WTP Radio Information message element(s)that the AC supports; 4738 These are defined by the individual link layer CAPWAP Binding 4739 Protocols (see Section 2.1 for more information). 4741 One of the following message elements MUST be included in the 4742 Discovery Response Message: 4744 o CAPWAP Control IPv4 Address, see Section 4.6.10 4746 o CAPWAP Control IPv6 Address, see Section 4.6.11 4748 The following message elements MAY be included in the Primary 4749 Discovery Response message: 4751 o Vendor Specific Payload, see Section 4.6.39 4753 6. CAPWAP Join Operations 4755 The Join Request message is used by a WTP to request service from an 4756 AC after a DTLS connection is established to that AC. The Join 4757 Response message is used by the AC to indicate that it will or will 4758 not provide service. 4760 6.1. Join Request 4762 The Join Request message is used by a WTP to request service through 4763 the AC. A Join Request message is sent by a WTP after (optionally) 4764 receiving one or more Discovery Response messages, and completion of 4765 DTLS session establishment. When an AC receives a Join Request 4766 message it responds with a Join Response message. 4768 Upon completion of the DTLS handshake, and receiving the 4769 DTLSEstablished notification, the WTP sends the Join Request message 4770 to the AC. When the AC is notified of the DTLS session 4771 establishment, it does not clear the WaitDTLS timer until it has 4772 received the Join Request message, at which time it sends a Join 4773 Response message to the WTP, indicating success or failure. 4775 One or more WTP Radio Information message elements (see Section 2.1) 4776 are included in the Join Request to request service for the CAPWAP 4777 bindings by the AC. Including a binding that is unsupported by the 4778 AC will result in a failed Join Response. 4780 If the AC rejects the Join Request, it sends a Join Response message 4781 with a failure indication and initiates an abort of the DTLS session 4782 via the DTLSAbort command. 4784 If an invalid (i.e. malformed) Join Request message is received, the 4785 message MUST be silently discarded by the AC. No response is sent to 4786 the WTP. The AC SHOULD log this event. 4788 The Join Request is sent by the WTP when in the Join State. The AC 4789 does not transmit this message. 4791 The following message elements MUST be included in the Join Request 4792 message. 4794 o Location Data, see Section 4.6.31 4796 o WTP Board Data, see Section 4.6.40 4798 o WTP Descriptor, see Section 4.6.41 4799 o WTP Name, see Section 4.6.47 4801 o Session ID, see Section 4.6.37 4803 o WTP Frame Tunnel Mode, see Section 4.6.43 4805 o WTP MAC Type, see Section 4.6.46 4807 o WTP Radio Information message element(s)that the WTP supports; 4808 These are defined by the individual link layer CAPWAP Binding 4809 Protocols (see Section 2.1 for more information). 4811 At least one of the following message element MUST be included in the 4812 Join Request message. 4814 o WTP IPv4 IP Address, see Section 4.6.44 4816 o WTP IPv6 IP Address, see Section 4.6.45 4818 The following message element MAY be included in the Join Request 4819 message. 4821 o Maximum Message Length, see Section 4.6.32 4823 o WTP Reboot Statistics, see Section 4.6.49 4825 o WTP IPv4 IP Address, see Section 4.6.44 4827 o WTP IPv6 IP Address, see Section 4.6.45 4829 o Vendor Specific Payload, see Section 4.6.39 4831 6.2. Join Response 4833 The Join Response message is sent by the AC to indicate to a WTP that 4834 it is capable and willing to provide service to the WTP. 4836 The WTP, receiving a Join Response message, checks for success or 4837 failure. If the message indicates success, the WTP clears the 4838 WaitDTLS timer for the session and proceeds to the Configure state. 4840 If the WaitDTLS Timer expires prior to reception of the Join Response 4841 message, the WTP MUST terminate the handshake, deallocate session 4842 state and initiate the DTLSAbort command. 4844 If an invalid (malformed) Join Response message is received, the WTP 4845 SHOULD log an informative message detailing the error. This error 4846 MUST be treated in the same manner as AC non-responsiveness. The 4847 WaitDTLS timer will eventually expire, and the WTP MAY (if it is so 4848 configured) attempts to join a new AC. 4850 If one of the WTP Radio Information message elements (see 4851 Section 2.1) in the Join Request message requested support for a 4852 CAPWAP binding which the AC does not support, the AC sets the Result 4853 Code message element to "Binding Not Supported". 4855 The AC includes the Image Identifier message element to indicate the 4856 software version it expects the WTP to run. This information is used 4857 to determine whether the WTP MUST either change its currently running 4858 firmware image, or download a new version (see Section 9.1.1). 4860 The Join Response message is sent by the AC when in the Join State. 4861 The WTP does not transmit this message. 4863 The following message elements MUST be included in the Join Response 4864 message. 4866 o Result Code, see Section 4.6.35 4868 o AC Descriptor, see Section 4.6.1 4870 o AC Name, see Section 4.6.4 4872 o WTP Radio Information message element(s)that the AC supports; 4873 These are defined by the individual link layer CAPWAP Binding 4874 Protocols (see Section 2.1). 4876 One of the following message elements MUST be included in the Join 4877 Response Message: 4879 o CAPWAP Control IPv4 Address, see Section 4.6.10 4881 o CAPWAP Control IPv6 Address, see Section 4.6.11 4883 The following message elements MAY be included in the Join Response 4884 message. 4886 o AC IPv4 List, see Section 4.6.2 4888 o AC IPv6 List, see Section 4.6.3 4890 o Image Identifier, see Section 4.6.28 4892 o Maximum Message Length, see Section 4.6.32 4893 o Vendor Specific Payload, see Section 4.6.39 4895 7. Control Channel Management 4897 The Control Channel Management messages are used by the WTP and AC to 4898 maintain a control communication channel. CAPWAP control messages, 4899 such as the WTP Event Request message sent from the WTP to the AC 4900 indicate to the AC that the WTP is operational. When such control 4901 messages are not being sent, the Echo Request and Echo Response 4902 messages are used to maintain the control communication channel. 4904 7.1. Echo Request 4906 The Echo Request message is a keep-alive mechanism for CAPWAP control 4907 messages. 4909 Echo Request messages are sent periodically by a WTP in the Run state 4910 (see Section 2.3) to determine the state of the control connection 4911 between the WTP and the AC. The Echo Request message is sent by the 4912 WTP when the EchoInterval timer expires. 4914 The Echo Request message is sent by the WTP when in the Run State. 4915 The AC does not transmit this message. 4917 The following message elements MAY be included in the Echo Request 4918 message: 4920 o Vendor Specific Payload, see Section 4.6.39 4922 When an AC receives an Echo Request message it responds with an Echo 4923 Response message. 4925 7.2. Echo Response 4927 The Echo Response message acknowledges the Echo Request message. 4929 An Echo Response message is sent by an AC after receiving an Echo 4930 Request message. After transmitting the Echo Response message, the 4931 AC SHOULD reset its EchoInterval timer (see Section 4.7.7. If 4932 another Echo Request message or other control message is not received 4933 by the AC when the timer expires, the AC SHOULD consider the WTP to 4934 be no longer reachable. 4936 The Echo Response message is sent by the AC when in the Run State. 4937 The WTP does not transmit this message. 4939 The following message elements MAY be included in the Echo Response 4940 message: 4942 o Vendor Specific Payload, see Section 4.6.39 4944 When a WTP receives an Echo Response message it initializes the 4945 EchoInterval to the configured value. 4947 8. WTP Configuration Management 4949 WTP Configuration messages are used to exchange configuration 4950 information between the AC and the WTP. 4952 8.1. Configuration Consistency 4954 The CAPWAP protocol provides flexibility in how WTP configuration is 4955 managed. A WTP can behave in one of two ways, which is 4956 implementation specific: 4958 1. The WTP retains no configuration and accepts the configuration 4959 provided by the AC. 4961 2. The WTP saves the configuration of parameters provided by the AC 4962 that are non-default values into local non-volatile memory, and 4963 are enforced during the WTP's power up initialization phase. 4965 If the WTP opts to save configuration locally, the CAPWAP protocol 4966 state machine defines the Configure state, which allows for 4967 configuration exchange. In the Configure state, the WTP sends its 4968 current configuration overrides to the AC via the Configuration 4969 Status message. A configuration override is a non-default parameter. 4970 As an example, in the CAPWAP protocol, the default antenna 4971 configuration is internal omni antenna. A WTP that either has no 4972 internal antennas, or has been explicitly configured by the AC to use 4973 external antennas, sends its antenna configuration during the 4974 configure phase, allowing the AC to become aware of the WTP's current 4975 configuration. 4977 Once the WTP has provided its configuration to the AC, the AC sends 4978 its configuration to the WTP. This allows the WTP to receive 4979 configuration and policies from the AC. 4981 The AC maintains a copy of each active WTP configuration. There is 4982 no need for versioning or other means to identify configuration 4983 changes. If a WTP becomes inactive, the AC MAY delete the inactive 4984 WTP configuration. If a WTP fails, and connects to a new AC, the WTP 4985 provides its overridden configuration parameters, allowing the new AC 4986 to be aware of the WTP configuration. 4988 This model allows for resiliency in case of an AC failure, ensuring 4989 another AC can provide service to the WTP. A new AC would be 4990 automatically updated with WTP configuration changes, eliminating the 4991 need for inter-AC communication and the need for all ACs to be aware 4992 of the configuration of all WTPs in the network. 4994 Once the CAPWAP protocol enters the Run state, the WTPs begin to 4995 provide service. It is common for administrators to require that 4996 configuration changes be made while the network is operational. 4997 Therefore, the Configuration Update Request is sent by the AC to the 4998 WTP to make these changes at run-time. 5000 8.1.1. Configuration Flexibility 5002 The CAPWAP protocol provides the flexibility to configure and manage 5003 WTPs of varying design and functional characteristics. When a WTP 5004 first discovers an AC, it provides primary functional information 5005 relating to its type of MAC and to the nature of frames to be 5006 exchanged. The AC configures the WTP appropriately. The AC also 5007 establishes corresponding internal state for the WTP. 5009 8.2. Configuration Status 5011 The Configuration Status message is sent by a WTP to deliver its 5012 current configuration to the AC. 5014 The Configuration Status message carries binding specific message 5015 elements. Refer to the appropriate binding for the definition of 5016 this structure. 5018 When an AC receives a Configuration Status message it acts upon the 5019 content of the message and responds to the WTP with a Configuration 5020 Status Response message. 5022 The Configuration Status message includes multiple Radio 5023 Administrative State message elements, one for the WTP, and one for 5024 each radio in the WTP. 5026 The Configuration Status message is sent by the WTP when in the 5027 Configure State. The AC does not transmit this message. 5029 The following message elements MUST be included in the Configuration 5030 Status message. 5032 o AC Name, see Section 4.6.4 5034 o AC Name with Index, see Section 4.6.5 5036 o Radio Administrative State, see Section 4.6.33 5038 o Statistics Timer, see Section 4.6.38 5040 o WTP Reboot Statistics, see Section 4.6.49 5042 The following message elements MAY be included in the Configuration 5043 Status message. 5045 o WTP Static IP Address Information, see Section 4.6.50 5047 o Vendor Specific Payload, see Section 4.6.39 5049 8.3. Configuration Status Response 5051 The Configuration Status Response message is sent by an AC and 5052 provides a mechanism for the AC to override a WTP's requested 5053 configuration. 5055 A Configuration Status Response message is sent by an AC after 5056 receiving a Configuration Request message. 5058 The Configuration Status Response message carries binding specific 5059 message elements. Refer to the appropriate binding for the 5060 definition of this structure. 5062 When a WTP receives a Configuration Status Response message it acts 5063 upon the content of the message, as appropriate. If the 5064 Configuration Status Response message includes a Radio Operational 5065 State message element that causes a change in the operational state 5066 of one of the radios, the WTP transmits a Change State Event to the 5067 AC, as an acknowledgement of the change in state. 5069 The Configuration Status Response message is sent by the AC when in 5070 the Configure State. The WTP does not transmit this message. 5072 The following message elements MUST be included in the Configuration 5073 Status Response message. 5075 o AC IPv4 List, see Section 4.6.2 5077 o AC IPv6 List, see Section 4.6.3 5079 o CAPWAP Timers, see Section 4.6.14 5081 o Decryption Error Report Period, see Section 4.6.19 5083 o Idle Timeout, see Section 4.6.26 5085 o WTP Fallback, see Section 4.6.42 5087 The following message element MAY be included in the Configuration 5088 Status Response message. 5090 o WTP Static IP Address Information, see Section 4.6.50 5092 o Vendor Specific Payload, see Section 4.6.39 5094 8.4. Configuration Update Request 5096 Configuration Update Request messages are sent by the AC to provision 5097 the WTP while in the Run state. This is used to modify the 5098 configuration of the WTP while it is operational. 5100 When a WTP receives a Configuration Update Request message, it 5101 responds with a Configuration Update Response message, with a Result 5102 Code message element indicating the result of the configuration 5103 request. 5105 The AC includes the Image Identifier and Initiate Download message 5106 elements to force the WTP to update its firmware while in the Run 5107 state. The WTP MAY proceed to download the requested firmware if it 5108 determines the version specified in the Image Identifier message 5109 element is not in its non-volatile storage (see Section 9.1.1). 5111 The Configuration Update Request is sent by the AC when in the Run 5112 State. The WTP does not transmit this message. 5114 One or more of the following message elements MAY be included in the 5115 Configuration Update message. 5117 o AC Name with Index, see Section 4.6.5 5119 o AC Timestamp, see Section 4.6.6 5121 o Add MAC ACL Entry, see Section 4.6.7 5123 o Add Static MAC ACL Entry, see Section 4.6.9 5125 o CAPWAP Timers, see Section 4.6.14 5127 o Decryption Error Report Period, see Section 4.6.19 5129 o Delete MAC ACL Entry, see Section 4.6.20 5131 o Delete Static MAC ACL Entry, see Section 4.6.22 5133 o Idle Timeout, see Section 4.6.26 5135 o Location Data, see Section 4.6.31 5136 o Radio Administrative State, see Section 4.6.33 5138 o Statistics Timer, see Section 4.6.38 5140 o WTP Fallback, see Section 4.6.42 5142 o WTP Name, see Section 4.6.47 5144 o WTP Static IP Address Information, see Section 4.6.50 5146 o Image Identifier, see Section 4.6.28 5148 o Initiate Download, see Section 4.6.30 5150 o Vendor Specific Payload, see Section 4.6.39 5152 8.5. Configuration Update Response 5154 The Configuration Update Response message is the acknowledgement 5155 message for the Configuration Update Request message. 5157 The Configuration Update Response message is sent by a WTP after 5158 receiving a Configuration Update Request message. 5160 When an AC receives a Configuration Update Response message the 5161 result code indicates if the WTP successfully accepted the 5162 configuration. 5164 The Configuration Update Response message is sent by the WTP when in 5165 the Run State. The AC does not transmit this message. 5167 The following message element MUST be present in the Configuration 5168 Update message. 5170 Result Code, see Section 4.6.35 5172 The following message elements MAY be present in the Configuration 5173 Update Response message. 5175 o Radio Operational State, see Section 4.6.34 5177 o Vendor Specific Payload, see Section 4.6.39 5179 8.6. Change State Event Request 5181 The Change State Event Request message is used by the WTP for two 5182 main purposes: 5184 o When sent by the WTP following the reception of a Configuration 5185 Status Response message from the AC, the WTP uses the Change State 5186 Event Request message to provide an update on the WTP radio's 5187 operational state and to confirm that the configuration provided 5188 by the AC was successfully applied. 5190 o When sent during the Run state, the WTP uses the Change State 5191 Event Request message to notify the AC of an unexpected change in 5192 the WTP's radio operational state. 5194 When an AC receives a Change State Event Request message it responds 5195 with a Change State Event Response message and modifies its data 5196 structures for the WTP as needed. The AC MAY decide not to provide 5197 service to the WTP if it receives an error, based on local policy, 5198 and to transition to the Reset state. 5200 The Change State Event Request message is sent by a WTP to 5201 acknowledge or report an error condition to the AC for a requested 5202 configuration in the Configuration Status Response message. The 5203 Change State Event Request message includes the Result Code message 5204 element, which indicates whether the configuration was successfully 5205 applied. If the WTP is unable to apply a specific configuration 5206 request, it indicates the failure by including one or more Returned 5207 Message Element message elements (see Section 4.6.36). 5209 The Change State Event Request message is sent by the WTP in the 5210 Configure or Run State. The AC does not transmit this message. 5212 The WTP MAY save its configuration to persistent storage prior to 5213 transmitting the response. However, this is implementation specific 5214 and is not required. 5216 The following message elements MUST be present in the Change State 5217 Event Request message. 5219 o Radio Operational State, see Section 4.6.34 5221 o Result Code, see Section 4.6.35 5223 One or more of the following message elements MAY be present in the 5224 Change State Event Request message. 5226 o Returned Message Element(s), see Section 4.6.36 5228 o Vendor Specific Payload, see Section 4.6.39 5230 8.7. Change State Event Response 5232 The Change State Event Response message acknowledges the Change State 5233 Event Request message. 5235 A Change State Event Response message is sent by an AC in response to 5236 a Change State Event Request message. 5238 The Change State Event Response message is sent by the AC when in the 5239 Configure or Run state. The WTP does not transmit this message. 5241 The following message elements MAY be included in the Change State 5242 Event Response message: 5244 o Vendor Specific Payload, see Section 4.6.39 5246 The WTP does not take any action upon receipt of the Change State 5247 Event Response message. 5249 8.8. Clear Configuration Request 5251 The Clear Configuration Request message is used to reset the WTP 5252 configuration. 5254 The Clear Configuration Request message is sent by an AC to request 5255 that a WTP reset its configuration to the manufacturing default 5256 configuration. The Clear Config Request message is sent while in the 5257 Run state. 5259 The Clear Configuration Request is sent by the AC when in the Run 5260 State. The WTP does not transmit this message. 5262 The following message elements MAY be included in the Clear 5263 Configuration Request message: 5265 o Vendor Specific Payload, see Section 4.6.39 5267 When a WTP receives a Clear Configuration Request message it resets 5268 its configuration to the manufacturing default configuration. 5270 8.9. Clear Configuration Response 5272 The Clear Configuration Response message is sent by the WTP after 5273 receiving a Clear Configuration Request message and resetting its 5274 configuration parameters to the manufacturing default values. 5276 The Clear Configuration Response is sent by the WTP when in the Run 5277 State. The AC does not transmit this message. 5279 The Clear Configuration Response message MUST include the following 5280 message element. 5282 o Result Code, see Section 4.6.35 5284 The following message elements MAY be included in the Clear 5285 Configuration Request message: 5287 o Vendor Specific Payload, see Section 4.6.39 5289 9. Device Management Operations 5291 This section defines CAPWAP operations responsible for debugging, 5292 gathering statistics, logging, and firmware management. The 5293 management operations defined in this section are used by the AC to 5294 either push/pull information to/from the WTP, or request that the WTP 5295 reboot. This section does not deal with the management of the AC per 5296 se, and assumes that the AC is operational and configured. 5298 9.1. Firmware Management 5300 This section describes the firmware download procedures used by the 5301 CAPWAP protocol. Firmware download can occur during the Image Data 5302 or Run state. 5304 Figure 6 provides an example of a WTP that performs a firmware 5305 upgrade while in the Image Data state. In this example, the WTP does 5306 not already have the requested firmware (Image Identifier = x), and 5307 downloads the image from the AC. 5309 WTP AC 5311 Join Request 5312 --------------------------------------------------------> 5314 Join Response (Image Identifier = x) 5315 <------------------------------------------------------ 5317 Image Data Request (Image Identifier = x) 5318 --------------------------------------------------------> 5320 Image Data Response (Result Code = Success, 5321 Image Information = {size,hash}, 5322 Initiate Download) 5323 <------------------------------------------------------ 5325 Image Data Request (Image Data = Data) 5326 <------------------------------------------------------ 5328 Image Data Response (Result Code = Success) 5329 --------------------------------------------------------> 5331 ..... 5333 Image Data Request (Image Data = EOF) 5334 <------------------------------------------------------ 5336 Image Data Response (Result Code = Success) 5337 --------------------------------------------------------> 5339 (WTP enters the Reset State) 5341 Figure 6: WTP Firmware Download Case 1 5343 Figure 7 provides an example in which the WTP has the image specified 5344 by the AC in its non-volative storage, but is not its current running 5345 image. In this case, the WTP opts to NOT download the firmware and 5346 immediately reset to the requested image. 5348 WTP AC 5350 Join Request 5351 --------------------------------------------------------> 5353 Join Response (Image Identifier = x) 5354 <------------------------------------------------------ 5356 (WTP enters the Reset State) 5358 Figure 7: WTP Firmware Download Case 2 5360 Figure 8 provides an example of a WTP that performs a firmware 5361 upgrade while in the Run state. This mode of firmware upgrade allows 5362 the WTP to download its image while continuing to provide service. 5363 The WTP will not automatically reset until it is notified by the AC, 5364 with a Reset Request message. 5366 WTP AC 5368 Configuration Update Request (Image Identifier = x) 5369 <------------------------------------------------------ 5371 Configuration Update Response (Result Code = Success) 5372 --------------------------------------------------------> 5374 Image Data Request (Image Identifier = x) 5375 --------------------------------------------------------> 5377 Image Data Response (Result Code = Success, 5378 Image Information = {size,hash}, 5379 Initiate Download) 5380 <------------------------------------------------------ 5382 Image Data Request (Image Data = Data) 5383 <------------------------------------------------------ 5385 Image Data Response (Result Code = Success) 5386 --------------------------------------------------------> 5388 ..... 5390 Image Data Request (Image Data = EOF) 5391 <------------------------------------------------------ 5393 Image Data Response (Result Code = Success) 5394 --------------------------------------------------------> 5396 ..... 5398 (administratively requested reboot request) 5399 Reset Request (Image Identifier = x) 5400 <------------------------------------------------------ 5402 Reset Response (Result Code = Success) 5403 --------------------------------------------------------> 5405 Figure 8: WTP Firmware Download Case 3 5407 Figure 9 provides another example of the firmware download while in 5408 the Run state. In this example, the WTP already has the image 5409 specified by the AC in its non-volative storage. The WTP opts to NOT 5410 download the firmware. The WTP resets upon receipt of a Reset 5411 Request message from the AC. 5413 WTP AC 5415 Configuration Update Request (Image Identifier = x, 5416 Image Information = {size,hash}, 5417 Initiate Download) 5418 <------------------------------------------------------ 5420 Configuration Update Response (Result Code = Already Have Image) 5421 --------------------------------------------------------> 5423 ..... 5425 (administratively requested reboot request) 5426 Reset Request (Image Identifier = x) 5427 <------------------------------------------------------ 5429 Reset Response (Result Code = Success) 5430 --------------------------------------------------------> 5432 Figure 9: WTP Firmware Download Case 4 5434 9.1.1. Image Data Request 5436 The Image Data Request message is used to update firmware on the WTP. 5437 This message and its companion Response message are used by the AC to 5438 ensure that the image being run on each WTP is appropriate. 5440 Image Data Request messages are exchanged between the WTP and the AC 5441 to download a new firmware image to the WTP. When a WTP or AC 5442 receives an Image Data Request message it responds with an Image Data 5443 Response message. The message elements contained within the Image 5444 Data Request message are required to determine the intent of the 5445 request. 5447 The decision that new firmware is to be downloaded to the WTP can 5448 occur in one of two ways: 5450 When the WTP joins the AC, the Join Response message includes the 5451 Image Identifier message element, which informs the WTP of the 5452 firmware it is expected to run. if the WTP does not currently have 5453 the requested firmware version, it transmits an Image Data Request 5454 message, with the appropriate Image Identifier message element. 5455 If the WTP already has the requested firmware in its non-volatile 5456 flash, but is not its currently running image, it simply resets to 5457 run the proper firmware. 5459 Once the WTP is in the Run state, it is possible for the AC to 5460 cause the WTP to initiate a firmware download by sending a 5461 Configuration Update Request message with the Initiate Download 5462 and Image Identifier message elements. The WTP then transmits the 5463 Image Data Request message, which includes the Image Identifier 5464 message element to start the download process. Note that when the 5465 firmware is downloaded in this way, the WTP does not automatically 5466 reset after the download is complete. The WTP will only reset 5467 when it receives a Reset Request message from the AC. If the WTP 5468 already had the requested firmware version in its non-volatile 5469 storage, the WTP does not transmit the Image Data Request message 5470 and responds with a Configuration Update Response message with the 5471 Result Code set to Image Already Present. 5473 Regardless of how the download was initiated, once the AC receives an 5474 Image Data Request message with the Image Identifier message element, 5475 it begins the transfer process by transmitting an Image Data Request 5476 message that includes the Image Data message element. This continues 5477 until the firmware image has been transferred. 5479 The Image Data Request message is sent by the WTP or the AC when in 5480 the Image Data or Run State. 5482 The following message elements MAY be included in the Image Data 5483 Request message. 5485 o Image Data, see Section 4.6.27 5487 o Image Identifier, see Section 4.6.28 5489 o Vendor Specific Payload, see Section 4.6.39 5491 9.1.2. Image Data Response 5493 The Image Data Response message acknowledges the Image Data Request 5494 message. 5496 An Image Data Response message is sent in response to a received 5497 Image Data Request message. Its purpose is to acknowledge the 5498 receipt of the Image Data Request message. The Result Code is 5499 included to indicate whether a previously sent Image Data Request 5500 message was invalid. 5502 The Image Data Response message is sent by the WTP or the AC when in 5503 the Image Data or Run State. 5505 The following message element MUST be included in the Image Data 5506 Response message. 5508 o Result Code, see Section 4.6.35 5510 The following message elements MAY be included in the Image Data 5511 Response message. 5513 o Image Information, see Section 4.6.29 5515 o Initiate Download, see Section 4.6.30 5517 o Vendor Specific Payload, see Section 4.6.39 5519 Upon receiving an Image Data Response message indicating an error, 5520 the WTP MAY retransmit a previous Image Data Request message, or 5521 abandon the firmware download to the WTP by transitioning to the 5522 Reset state. 5524 9.2. Reset Request 5526 The Reset Request message is used to cause a WTP to reboot. 5528 A Reset Request message is sent by an AC to cause a WTP to 5529 reinitialize its operation. 5531 The Reset Request is sent by the AC when in the Run State. The WTP 5532 does not transmit this message. 5534 The following message elements MUST be included in the Reset Request 5535 message. 5537 o Image Identifier, see Section 4.6.28 5539 The following message elements MAY be included in the Reset Request 5540 message: 5542 o Vendor Specific Payload, see Section 4.6.39 5544 When a WTP receives a Reset Request message, it responds with a Reset 5545 Response message indicating success and then reinitialize itself. If 5546 the WTP is unable to write to its non-volatile storage, to ensure 5547 that it runs the requested software version indicated in the Image 5548 Identifier message element, it MAY send the appropriate Result Code 5549 message element, but MUST reboot. If the WTP is unable to reset, 5550 including a hardware reset, it sends a Reset Response message to the 5551 AC with a Result Code message element indicating failure. The AC no 5552 longer provides service to the WTP. 5554 9.3. Reset Response 5556 The Reset Response message acknowledges the Reset Request message. 5558 A Reset Response message is sent by the WTP after receiving a Reset 5559 Request message. 5561 The Reset Response is sent by the WTP when in the Run State. The AC 5562 does not transmit this message. 5564 The following message element MAY be included in the Reset Response 5565 message. 5567 o Result Code, see Section 4.6.35 5569 o Vendor Specific Payload, see Section 4.6.39 5571 When an AC receives a successful Reset Response message, it is 5572 notified that the WTP will reinitialize its operation. An AC that 5573 receives a Reset Response message indicating failure may opt to no 5574 longer provide service to the WTP. 5576 9.4. WTP Event Request 5578 The WTP Event Request message is used by a WTP to send information to 5579 its AC. The WTP Event Request message MAY be sent periodically, or 5580 sent in response to an asynchronous event on the WTP. For example, a 5581 WTP MAY collect statistics and use the WTP Event Request message to 5582 transmit the statistics to the AC. 5584 When an AC receives a WTP Event Request message it will respond with 5585 a WTP Event Response message. 5587 The presence of the Delete Station message element is used by the WTP 5588 to inform the AC that it is no longer providing service to the 5589 station. This could be the result of an Idle Timeout (see 5590 Section 4.6.26), due to resource shortages, or some other reason. 5592 The WTP Event Request message is sent by the WTP when in the Run 5593 State. The AC does not transmit this message. 5595 The WTP Event Request message MUST contain one of the message 5596 elements listed below, or a message element that is defined for a 5597 specific wireless technology. More than one of each message element 5598 listed MAY be included in the WTP Event Request message. 5600 o Decryption Error Report, see Section 4.6.18 5601 o Duplicate IPv4 Address, see Section 4.6.24 5603 o Duplicate IPv6 Address, see Section 4.6.25 5605 o WTP Radio Statistics, see Section 4.6.48 5607 o WTP Reboot Statistics, see Section 4.6.49 5609 o Delete Station, see Section 4.6.21 5611 o Vendor Specific Payload, see Section 4.6.39 5613 9.5. WTP Event Response 5615 The WTP Event Response message acknowledges receipt of the WTP Event 5616 Request message. 5618 A WTP Event Response message is sent by an AC after receiving a WTP 5619 Event Request message. 5621 The WTP Event Response message is sent by the AC when in the Run 5622 State. The WTP does not transmit this message. 5624 The following message elements MAY be included in the WTP Event 5625 Response message: 5627 o Vendor Specific Payload, see Section 4.6.39 5629 9.6. Data Transfer 5631 This section describes the data transfer procedures used by the 5632 CAPWAP protocol. The data transfer mechanism is used to upload 5633 information available at the WTP to the AC, such as crash or debug 5634 information. The data transfer messages can only be exchanged while 5635 in the Run state. 5637 Figure 10 provides an example of an AC that requests that the WTP 5638 transfer its latest crash file. Once the WTP acknowledges that it 5639 has information to send, via the Data Transfer Response, it transmits 5640 its own Data Transfer Request. Upon receipt, the AC responds with a 5641 Data Transfer Response, and the exchange continues until the WTP 5642 transmits a Data Transfer Data message element that indicates an End 5643 of File (EOF). 5645 WTP AC 5647 Data Transfer Request (Data Transfer Mode = Crash Data) 5648 <------------------------------------------------------ 5650 Data Transfer Response (Result Code = Success) 5651 --------------------------------------------------------> 5653 Data Transfer Request (Data Transfer Data = Data) 5654 --------------------------------------------------------> 5656 Data Transfer Response (Result Code = Success) 5657 <------------------------------------------------------ 5659 ..... 5661 Data Transfer Request (Data Transfer Data = EOF) 5662 --------------------------------------------------------> 5664 Data Transfer Response (Result Code = Success) 5665 <------------------------------------------------------ 5667 Figure 10: WTP Data Transfer Case 1 5669 Figure 11 provides an example of an AC that requests that the WTP 5670 transfer its latest crash file. However, in this example, the WTP 5671 does not have any crash information to send, and therefore sends a 5672 Data Transfer Response with a Result Code indicating the error. 5674 WTP AC 5676 Data Transfer Request (Data Transfer Mode = Crash Data) 5677 <------------------------------------------------------ 5679 Data Transfer Response (Result Code = Data Transfer 5680 Error (No Information to Transfer)) 5681 --------------------------------------------------------> 5683 Figure 11: WTP Data Transfer Case 2 5685 9.6.1. Data Transfer Request 5687 The Data Transfer Request message is used to deliver debug 5688 information from the WTP to the AC. 5690 The Data Transfer Request messages can be sent either by the AC or 5691 the WTP. When sent by the AC, it is used to request that data be 5692 transmitted from the WTP to the AC, and includes the Data Transfer 5693 Mode message element, which specifies the information desired by the 5694 AC. The Data Transfer Request is sent by the WTP in order to 5695 transfer actual data to the AC, through the Data Transfer Data 5696 message element. 5698 Given that the CAPWAP protocol minimizes the need for WTPs to be 5699 directly managed, the Data Transfer Request is an important 5700 troubleshooting tool used by the AC to retrieve information that may 5701 be available on the WTP. For instance, some WTPs implementations may 5702 store crash information to help manufacturers identify software 5703 faults. The Data Transfer Request message can be used to send such 5704 information from the WTP to the AC. Another possible use would be to 5705 allow a remote debugger function in the WTP to use the Data Transfer 5706 Request message to send console output to the AC for debugging 5707 purposes. 5709 When the WTP or AC receives a Data Transfer Request message it 5710 responds to the WTP with a Data Transfer Response message. The AC 5711 MAY log the information received through the Data Transfer Data 5712 message element. 5714 The Data Transfer Request message is sent by the WTP or AC when in 5715 the Run State. 5717 When sent by the AC, the Data Transfer Request message MUST contain 5718 the following message elements: 5720 o Data Transfer Mode, see Section 4.6.17 5722 When sent by the WTP, the Data Transfer Request message MUST contain 5723 the following message elements: 5725 o Data Transfer Data, see Section 4.6.16 5727 Regardless of whether the Data Transfer Request is sent by the AC or 5728 WTP, the following message elements MAY be included in the Data 5729 Transfer Request message: 5731 o Vendor Specific Payload, see Section 4.6.39 5733 9.6.2. Data Transfer Response 5735 The Data Transfer Response message acknowledges the Data Transfer 5736 Request message. 5738 A Data Transfer Response message is sent in response to a received 5739 Data Transfer Request message. Its purpose is to acknowledge receipt 5740 of the Data Transfer Request message. When sent by the WTP, the 5741 Result Code message element is used to indicate whether the data 5742 transfer requested by the AC can be completed. When sent by the AC, 5743 the Result Code message element is used to indicate receipt of the 5744 data transfered in the Data Transfer Request message. 5746 The Data Transfer Response message is sent by the WTP or AC when in 5747 the Run State. 5749 The following message element MUST be included in the Data Transfer 5750 Response message. 5752 o Result Code, see Section 4.6.35 5754 The following message elements MAY be included in the Data Transfer 5755 Response message: 5757 o Vendor Specific Payload, see Section 4.6.39 5759 Upon receipt of a Data Transfer Response message, the WTP transmits 5760 more information, if more information is available. 5762 10. Station Session Management 5764 Messages in this section are used by the AC to create, modify or 5765 delete station session state on the WTPs. 5767 10.1. Station Configuration Request 5769 The Station Configuration Request message is used to create, modify 5770 or delete station session state on a WTP. The message is sent by the 5771 AC to the WTP, and MAY contain one or more message elements. The 5772 message elements for this CAPWAP control message include information 5773 that is generally highly technology specific. Refer to the 5774 appropriate binding document for definitions of the messages elements 5775 that are included in this control message. 5777 The Station Configuration Request message is sent by the AC when in 5778 the Run State. The WTP does not transmit this message. 5780 The following CAPWAP Control message elements MAY be included in the 5781 Station Configuration Request message. More than one of each message 5782 element listed MAY be included in the Station Configuration Request 5783 message. 5785 o Add Station, see Section 4.6.8 5787 o Delete Station, see Section 4.6.21 5789 o Vendor Specific Payload, see Section 4.6.39 5791 10.2. Station Configuration Response 5793 The Station Configuration Response message is used to acknowledge a 5794 previously received Station Configuration Request message. 5796 The Station Configuration Response message is sent by the WTP when in 5797 the Run State. The AC does not transmit this message. 5799 The following message element MUST be present in the Station 5800 Configuration Response message. 5802 o Result Code, see Section 4.6.35 5804 The following message elements MAY be included in the Station 5805 Configuration Response message: 5807 o Vendor Specific Payload, see Section 4.6.39 5809 The Result Code message element indicates that the requested 5810 configuration was successfully applied, or that an error related to 5811 processing of the Station Configuration Request message occurred on 5812 the WTP. 5814 11. NAT Considerations 5816 There are three specific situations in which a NAT deployment may be 5817 used in conjunction with a CAPWAP-enabled deployment. The first 5818 consists of a configuration in which a single WTP is behind a NAT 5819 system. Since all communication is initiated by the WTP, and all 5820 communication is performed over IP using two UDP ports, the protocol 5821 easily traverses NAT systems in this configuration. 5823 In the second case, two or more WTPs are deployed behind the same NAT 5824 system. Here, the AC would receive multiple connection requests from 5825 the same IP address, and cannot differentiate the originating WTP of 5826 the connection requests. The CAPWAP Data Check state, which 5827 establishes the data plane connection and communicates the CAPWAP 5828 Data Channel Keepalive, includes the Session Identifier message 5829 element, which is used to bind the control and data plane. Use of 5830 the Session Identifier message element enables the AC to match the 5831 control and data plane flows from multiple WTPs behind the same NAT 5832 system (multiple WTPs sharing the same IP address). 5834 In the third configuration, the AC is deployed behind a NAT. Two 5835 issues exist in this situation. First, an AC communicates its 5836 interfaces and corresponding WTP load using the CAPWAP Control IPv4 5837 Address and CAPWAP Control IPv6 Address message elements. This 5838 message element is mandatory, but contains invalid information if a 5839 middlebox is present between the AC and WTP. The WTP MUST NOT 5840 utilize the information in these message elements if it detects a NAT 5841 (as described in the CAPWAP Transport Protocol message element). 5842 Note this would disable the load balancing capabilities of the CAPWAP 5843 protocol. Alternatively, the AC could have a configured NAT'ed 5844 address, which it would include in either of the two control address 5845 message elements. 5847 The CAPWAP protocol allows for all of the AC identities supporting a 5848 group of WTPs to be communicated through the AC List message element. 5849 This feature MUST be ignored by the WTP when it detects the AC is 5850 behind a middlebox. 5852 The CAPWAP protocol allows an AC to configure a static IP address on 5853 a WTP using the WTP Static IP Address Information message element. 5854 This message element SHOULD NOT be used in NAT'ed environments, 5855 unless the administrator is familiar with the internal IP addressing 5856 scheme within the WTP's private network, and does not rely on the 5857 public address seen by the AC. 5859 When a WTP detects the duplicate address condition, it generates a 5860 message to the AC, which includes the Duplicate IP Address message 5861 element. The IP Address embedded within this message element is 5862 different from the public IP address seen by the AC. 5864 12. Security Considerations 5866 This section describes security considerations for the CAPWAP 5867 protocol. It also provides security recommendations for protocols 5868 used in conjunction with CAPWAP. 5870 12.1. CAPWAP Security 5872 As it is currently specified, the CAPWAP protocol sits between the 5873 security mechanisms specified by the wireless link layer protocol 5874 (e.g.IEEE 802.11i) and AAA. One goal of CAPWAP is to bootstrap trust 5875 between the STA and WTP using a series of preestablished trust 5876 relationships: 5878 STA WTP AC AAA 5879 ============================================== 5881 DTLS Cred AAA Cred 5882 <------------><-------------> 5884 EAP Credential 5885 <------------------------------------------> 5887 wireless link layer 5888 (e.g.802.11 PTK) 5889 <--------------> or 5890 <---------------------------> 5891 (derived) 5893 Figure 12: STA Session Setup 5895 Within CAPWAP, DTLS is used to secure the link between the WTP and 5896 AC. In addition to securing control messages, it's also a link in 5897 this chain of trust for establishing link layer keys. Consequently, 5898 much rests on the security of DTLS. 5900 In some CAPWAP deployment scenarios, there are two channels between 5901 the WTP and AC: the control channel, carrying CAPWAP control 5902 messages, and the data channel, over which client data packets are 5903 tunneled between the AC and WTP. Typically, the control channel is 5904 secured by DTLS, while the data channel is not. 5906 The use of parallel protected and unprotected channels deserves 5907 special consideration, but does not create a threat. There are two 5908 potential concerns: attempting to convert protected data into un- 5909 protected data and attempting to convert un-protected data into 5910 protected data. These concerns are addressed below. 5912 12.1.1. Converting Protected Data into Unprotected Data 5914 Since CAPWAP does not support authentication-only ciphers (i.e. all 5915 supported ciphersuites include encryption and authentication), it is 5916 not possible to convert protected data into unprotected data. Since 5917 encrypted data is (ideally) indistinguishable from random data, the 5918 probability of an encrypted packet passing for a well-formed packet 5919 is effectively zero. 5921 12.1.2. Converting Unprotected Data into Protected Data (Insertion) 5923 The use of message authentication makes it impossible for the 5924 attacker to forge protected records. This makes conversion of 5925 unprotected records to protected records impossible. 5927 12.1.3. Deletion of Protected Records 5929 An attacker could remove protected records from the stream, though 5930 not undetectably so, due the built-in reliability of the underlying 5931 CAPWAP protocol. In the worst case, the attacker would remove the 5932 same record repeatedly, resulting in a CAPWAP session timeout and 5933 restart. This is effectively a DoS attack, and could be accomplished 5934 by a man in the middle regardless of the CAPWAP protocol security 5935 mechanisms chosen. 5937 12.1.4. Insertion of Unprotected Records 5939 An attacker could inject packets into the unprotected channel, but 5940 this may become evident if sequence number desynchronization occurs 5941 as a result. Only if the attacker is a MiM can packets be inserted 5942 undetectably. This is a consequence of that channel's lack of 5943 protection, and not a new threat resulting from the CAPWAP security 5944 mechanism. 5946 12.2. Session ID Security 5948 Since DTLS does not export a unique session identifier, there can be 5949 no explicit protocol binding between the DTLS layer and CAPWAP layer. 5950 As a result, implementations MUST provide a mechanism for performing 5951 this binding. For example, an AC MUST NOT associate decrypted DTLS 5952 control packets with a particular WTP session based solely on the 5953 Session ID in the packet header. Instead, identification should be 5954 done based on which DTLS session decrypted the packet. Otherwise one 5955 authenticated WTP could spoof another authenticated WTP by altering 5956 the Session ID in the encrypted CAPWAP header. 5958 It should be noted that when the CAPWAP data channel is unencrypted, 5959 the WTP Session ID is exposed and possibly known to adversaries and 5960 other WTPs. This would allow the forgery of the source of data- 5961 channel traffic. This, however, should not be a surprise for 5962 unencrypted data channels. When the data channel is encrypted, the 5963 Session ID is not exposed, and therefore can safely be used to 5964 associate a data and control channel. The 64-bit length of the 5965 Session ID mitigates online guessing attacks where an adversarial, 5966 authenticated WTP tries to correlate his own data channel with 5967 another WTP's control channel. Note that for encrypted data 5968 channels, the Session ID should only be used for correlation for the 5969 first packet immediately after the initial DTLS handshake. Future 5970 correlation should instead be done via identification of a packet's 5971 DTLS session. 5973 12.3. Discovery or DTLS Setup Attacks 5975 Since the Discovery Request messages are sent in the clear, it is 5976 important that AC implementations NOT assume that receiving a 5977 Discovery Request message from a WTP implies that the WTP has 5978 rebooted, and consequently tear down any active DTLS sessions. 5979 Discovery Request messages can easily be spoofed by malicious 5980 devices, so it is important that the AC maintain two separate sets of 5981 states for the WTP until the DTLSSessionEstablished notification is 5982 received, indicating that the WTP was authenticated. Once a new DTLS 5983 session is successfully established, any state referring to the old 5984 session can be cleared. 5986 Similarly, entering the DTLS Setup phase SHOULD NOT assume that the 5987 WTP has reset, and therefore should not discard active state until 5988 the DTLS session has been successfully established. While the 5989 HelloVerifyRequest provides some protection against denial of service 5990 (DoS) attacks on the AC, an adversary capable of receiving packets at 5991 a valid address (or a malfunctioning or misconfigured WTP) may 5992 repeatedly attempt DTLS handshakes with the AC, potentially creating 5993 a resource shortage. If either the FailedDTLSSessionCount or the 5994 FailedDTLSAuthFailCount counter reaches the value of 5995 MaxFailedDTLSSessionRetry variable (see Section 4.8), implementations 5996 MAY choose to rate-limit new DTLS handshakes for some period of time. 5997 It is RECOMMENDED that implementations choosing to implement rate 5998 limiting use a random discard technique, rather than mimicking the 5999 WTP's sulking behavior. This will ensure that messages from valid 6000 WTPs will have some probability of eliciting a response, even in the 6001 face of a significant DoS attack. 6003 Some CAPWAP implementations may wish to restrict the DTLS setup 6004 process to only those peers that have been configured in the access 6005 control list, authorizing only those clients to initiate a DTLS 6006 handshake. Note that the impact of this on mitigating denial of 6007 service attacks against the DTLS layer is minimal, because DTLS 6008 already uses client-side cookies to minimize processor consumption 6009 attacks. 6011 12.4. Interference with a DTLS Session 6013 If a WTP or AC repeatedly receives packets which fail DTLS 6014 authentication or decryption, this could indicate a DTLS 6015 desynchronization between the AC and WTP, a link prone to 6016 undetectable bit errors, or an attacker trying to disrupt a DTLS 6017 session. 6019 In the state machine (section 2.3), transitions to the DTLS tear down 6020 state can be triggered by frequently receiving DTLS packets with 6021 authentication or decryption errors. The threshold or technique for 6022 deciding when to move to the tear down state should be chosen 6023 carefully. Being able to easily transition to DTLS TD allows easy 6024 detection of malfunctioning devices, but allows for denial of service 6025 attacks. Making it difficult to transition to DTLS TD prevents 6026 denial of service attacks, but makes it more difficult to detect and 6027 reset a malfunctioning session. Implementers should set this policy 6028 with care. 6030 12.5. CAPWAP Pre-Provisioning 6032 In order for CAPWAP to establish a secure communication with a peer, 6033 some level of pre-provisioning on both the WTP and AC is necessary. 6034 This section will detail the minimal number of configuration 6035 parameters. 6037 When using preshared keys, it is necessary to configure the preshared 6038 key for each possible peer with which a DTLS session may be 6039 established. To support this mode of operation, one or more entries 6040 of the following table may be configured on either the AC or WTP: 6042 o Identity: The identity of the peering AC or WTP. This format MAY 6043 be either in the form of an IP address or host name (the latter of 6044 which needs to be resolved to an IP address using DNS). 6046 o Key: The pre-shared key for use with the peer when establishing 6047 the DTLS session (see Section 12.6 for more information). 6049 o Key Identifier: The pre-shared key identifier, as described in RFC 6050 4279 [RFC4279]. 6052 When using certificates, the following items need to be pre- 6053 provisioned: 6055 o Device Certificate: The local device's certificate (see 6056 Section 12.7 for more information) 6058 o Trust Anchor: Trusted root certificate chain used to validate any 6059 certificate received from CAPWAP peers. Note that one or more 6060 root certificate MAY be configured on a given device. 6062 Regardless of the authentication method, the following items need to 6063 be pre-provisioned: 6065 o Access Control List: The access control list table contains the 6066 identities of one or more CAPWAP peers, along with a rule. The 6067 rule is used to determine whether communication with the peer is 6068 permitted (see Section 2.4.4.3 for more information). 6070 12.6. Use of Preshared Keys in CAPWAP 6072 While use of preshared keys may provide deployment and provisioning 6073 advantages not found in public key based deployments, it also 6074 introduces a number of operational and security concerns. In 6075 particular, because the keys must typically be entered manually, it 6076 is common for people to base them on memorable words or phrases. 6077 These are referred to as "low entropy passwords/passphrases". 6079 Use of low-entropy preshared keys, coupled with the fact that the 6080 keys are often not frequently updated, tends to significantly 6081 increase exposure. For these reasons, the following recommendations 6082 are made: 6084 o When DTLS is used with a preshared-key (PSK) ciphersuite, each WTP 6085 SHOULD have a unique PSK. Since WTPs will likely be widely 6086 deployed, their physical security is not guaranteed. If PSKs are 6087 not unique for each WTP, key reuse would allow the compromise of 6088 one WTP to result in the compromise of others 6090 o Generating PSKs from low entropy passwords is NOT RECOMMENDED. 6092 o It is RECOMMENDED that implementations that allow the 6093 administrator to manually configure the PSK also provide a 6094 capability for generation of new random PSKs, taking RFC 4086 6095 [RFC4086] into account. 6097 o Preshared keys SHOULD be periodically updated. Implementations 6098 MAY facilitate this by providing an administrative interface for 6099 automatic key generation and periodic update, or it MAY be 6100 accomplished manually instead. 6102 Every pairwise combination of WTP and AC on the network SHOULD have a 6103 unique PSK. This prevents the domino effect (see Guidance for AAA 6104 Key Management [RFC4962]). If PSKs are tied to specific WTPs, then 6105 knowledge of the PSK implies a binding to a specified identity that 6106 can be authorized. 6108 If PSKs are shared, this binding between device and identity is no 6109 longer possible. Compromise of one WTP can yield compromise of 6110 another WTP, violating the CAPWAP security hierarchy. Consequently, 6111 sharing keys between WTPs is NOT RECOMMENDED. 6113 12.7. Use of Certificates in CAPWAP 6115 For public-key-based DTLS deployments, each device SHOULD have unique 6116 credentials, with an extended key usage authorizing the device to act 6117 as either a WTP or AC. If devices do not have unique credentials, it 6118 is possible that by compromising one device, any other device using 6119 the same credential may also be considered to be compromised. 6121 Certificate validation involves checking a large variety of things. 6122 Since the necessary things to validate are often environment- 6123 specific, many are beyond the scope of this document. In this 6124 section, we provide some basic guidance on certificate validation. 6126 Each device is responsible for authenticating and authorizing devices 6127 with which they communicate. Authentication entails validation of 6128 the chain of trust leading to the peer certificate, followed by the 6129 peer certificate itself. Implementations SHOULD also provide a 6130 secure method for verifying that the credential in question has not 6131 been revoked. 6133 Note that if the WTP relies on the AC for network connectivity (e.g. 6134 the AC is a layer 2 switch to which the WTP is directly connected), 6135 the WTP may not be able to contact an OCSP server or otherwise obtain 6136 an up to date CRL if a compromised AC doesn't explicitly permit this. 6137 This cannot be avoided, except through effective physical security 6138 and monitoring measures at the AC. 6140 Proper validation of certificates typically requires checking to 6141 ensure the certificate has not yet expired. If devices have a real- 6142 time clock, they SHOULD verify the certificate validity dates. If no 6143 real-time clock is available, the device SHOULD make a best-effort 6144 attempt to validate the certificate validity dates through other 6145 means. Failure to check a certificate's temporal validity can make a 6146 device vulnerable to man-in-the-middle attacks launched using 6147 compromised, expired certificates, and therefore devices should make 6148 every effort to perform this validation. 6150 12.8. AAA Security 6152 The AAA protocol is used to distribute EAP keys to the ACs, and 6153 consequently its security is important to the overall system 6154 security. When used with TLS or IPsec, security guidelines specified 6155 in RFC 3539 [RFC3539] SHOULD be followed. 6157 In general, the link between the AC and AAA server SHOULD be secured 6158 using a strong ciphersuite keyed with mutually authenticated session 6159 keys. Implementations SHOULD NOT rely solely on Basic RADIUS shared 6160 secret authentication as it is often vulnerable to dictionary 6161 attacks, but rather SHOULD use stronger underlying security 6162 mechanisms. 6164 13. Operational Considerations 6166 The CAPWAP protocol assumes that it is the only configuration 6167 interface to the WTP to configure parameters that are specified in 6168 the CAPWAP specifications. While the use of a separate management 6169 protocol MAY be used for the purposes of monitoring the WTP directly, 6170 configuring the WTP through a separate management interface is not 6171 recommended. Configuring the WTP through a separate protocol, such 6172 as via a CLI or SNMP, could lead to the AC state being out of sync 6173 with the WTP. 6175 The CAPWAP protocol does not deal with the management of the ACs. 6176 The AC is assumed to be configured through some separate management 6177 interface, which could be via a proprietary CLI, SNMP, NETCONF or 6178 some other management protocol. 6180 The CAPWAP protocol's control channel is fairly light weight from a 6181 traffic perspective. Once the WTP has been configured, the WTP sends 6182 periodic statistics. Further, the specification calls for a 6183 keepalive packet to be sent on the protocol's data channel to make 6184 sure that any possible middleboxes (e.g., NAT) maintain their UDP 6185 state. The overhead associated with the control and data channel is 6186 not expected to impact network traffic. That said, the CAPWAP 6187 protocol does allow for the frequency of these packets to be modified 6188 through the DataChannelKeepAlive and StatisticsTimer (see 6189 Section 4.7.2 and Section 4.7.14, respectively). 6191 14. Transport Considerations 6193 The CAPWAP WG carefully considered the congestion control 6194 requirements of the CAPWAP protocol, both for the CAPWAP control and 6195 data channels. 6197 CAPWAP specifies a single-threaded command/response protocol to be 6198 used on the control channel, and we have specified that an 6199 exponential back-off algorithm should be used when commands are 6200 retransmitted. When CAPWAP runs in its default mode (Local MAC), the 6201 control channel is the only CAPWAP channel. 6203 However, CAPWAP can also be run in Split MAC mode, in which case 6204 there will be a DTLS-encrypted data channel between each WTP and the 6205 AC. The WG discussed various options for providing congestion 6206 control on this channel. However, due to performance problems with 6207 TCP when it is run over another congestion control mechanism and the 6208 fact that the vast majority of traffic run over the CAPWAP data 6209 channel is likely to be congestion-controlled IP traffic, the CAPWAP 6210 WG felt that specifying a congestion control mechanism for the CAPWAP 6211 data channel would be more likely to cause problems than to resolve 6212 any. 6214 Because there is no congestion control mechanism specified for the 6215 CAPWAP data channel, it is recommended that non-congestion-controlled 6216 traffic not be tunneled over CAPWAP. When a significant amount of 6217 non-congestion-controlled traffic is expected to be present on a 6218 WLAN, the CAPWAP connection between the AC and the WTP for that LAN 6219 should be configured to remain in Local MAC mode with Distribution 6220 function at the WTP. 6222 The lock step nature of the CAPWAP protocol's control channel can 6223 cause the firmware download process to take some time, depending upon 6224 the RTT. This is not expected to be a problem since the CAPWAP 6225 protocol allows firmware to be downloaded while the WTP provides 6226 service to wireless clients/devices. 6228 It is necessary for the WTP and AC to configure their MTU based on 6229 the capabilities of the path. See Section 3.5 for more information. 6231 15. IANA Considerations 6233 IANA needs to assign an organization local multicast address called 6234 the "All ACs multicast address" from the IPv6 multicast address 6235 registry in Section 3.3 6237 15.1. CAPWAP Message Types 6239 The Message Type field in the CAPWAP header (see Section 4.5.1.1) is 6240 used to identify the operation performed by the message. There are 6241 multiple namespaces, which is identified via the first three octets 6242 of the field containing the IANA Enterprise Number [RFC5226]. When 6243 the Enterprise Number is set to zero, the message types are reserved 6244 for use by the base CAPWAP specification which are controlled and 6245 maintained by IANA and requires a Standards Action. 6247 15.2. CAPWAP Header Flags 6249 The Flags field in the CAPWAP header (see Section 4.3) is used to 6250 identify any special treatment related to the message. There are 6251 currently three unused, reserved bits. These bits are controlled and 6252 maintained by IANA and requires a Standards Action. 6254 15.3. CAPWAP Control Message Flags 6256 The Flags field in the CAPWAP Control Message header (see 6257 Section 4.5.1.4) is used to identify any special treatment related to 6258 the control message. There are currently eight unused, reserved 6259 bits. These bits are controlled and maintained by IANA and requires 6260 a Standards Action. 6262 15.4. CAPWAP Control Message Type 6264 The Type field in the CAPWAP Control Message header (see Section 4.6) 6265 is used to identify the data being transported. The 32 bit 6266 enumerated values are currently defined in Section 4.5.1.1. These 6267 values are controlled and maintained by IANA and requires a Standards 6268 Action. 6270 15.5. Wireless Binding Identifiers 6272 The Wireless Binding Identifier (WBID) field in the CAPWAP header 6273 (see Section 4.3) is used to identify the wireless technology 6274 associated with the packet. Due to the limited address space 6275 available, a new WBID request requires Standards Action. 6277 15.6. AC Security Types 6279 The Security field in the AC Descriptor message element (see 6280 Section 4.6.1) is used to identify the authentication type available 6281 on the AC. This document defines two bits, and the remaining bits 6282 are controlled and maintained by IANA and requires a Standards 6283 Action. 6285 15.7. AC DTLS Policy 6287 The DTLS Policy field in the AC Descriptor message element (see 6288 Section 4.6.1) is used to identify the how, and if, the CAPWAP Data 6289 Channel is to be secured. This document defines two bits, and the 6290 remaining bits are controlled and maintained by IANA and requires a 6291 Standards Action. 6293 15.8. AC Information Type 6295 The Information Type field in the AC Descriptor message element (see 6296 Section 4.6.1) is used to represent information about the AC. This 6297 document defines two values, and the remaining values are controlled 6298 and maintained by IANA and requires a Standards Action. 6300 15.9. CAPWAP Transport Protocol Types 6302 The Transport field in the CAPWAP Transport Protocol message element 6303 (see Section 4.6.15) is used to identify the transport to use for the 6304 CAPWAP Data Channel. This document defines two values, and the 6305 remaining values are controlled and maintained by IANA and requires a 6306 Standards Action. 6308 15.10. Data Transfer Type 6310 The Data Type field in the Data Transfer Data message element (see 6311 Section 4.6.16) and Image Data message element (see Section 4.6.27) 6312 is used to provide information about the data being carried. This 6313 document defines three values, and the remaining values are 6314 controlled and maintained by IANA and requires a Standards Action. 6316 15.11. Data Transfer Mode 6318 The Data Mode field in the Data Transfer Data message element (see 6319 Section 4.6.16) and Data Transfer Mode message element (see 6320 Section 15.11) is used to provide information about the data being 6321 carried. This document defines three values, and the remaining 6322 values are controlled and maintained by IANA and requires a Standards 6323 Action. 6325 15.12. Discovery Types 6327 The Discovery Type field in the Discovery Type message element (see 6328 Section 4.6.23) is used by the WTP to indicate to the AC how it was 6329 discovered. This document defines five values, and the remaining 6330 values are controlled and maintained by IANA and requires a Standards 6331 Action. 6333 15.13. Radio Admin State 6335 The Radio Admin field in the Radio Administrative State message 6336 element (see Section 4.6.33) is used by the WTP to represent the 6337 state of its radios. This document defines two bits, and the 6338 remaining bits are controlled and maintained by IANA and requires a 6339 Standards Action. 6341 15.14. Radio Operational State 6343 The State field in the Radio Operational State message element (see 6344 Section 4.6.34) is used by the WTP to represent the operational state 6345 of its radios. This document defines two bits, and the remaining 6346 bits are controlled and maintained by IANA and requires a Standards 6347 Action. 6349 15.15. Radio Failure Causes 6351 The Cause field in the Radio Operational State message element (see 6352 Section 4.6.34) is used by the WTP to represent the reason why a 6353 radio may have failed. This document defines four values, and the 6354 remaining values are controlled and maintained by IANA and requires a 6355 Standards Action. 6357 15.16. Result Code 6359 The Result Code field in the Result Code message element (see 6360 Section 4.6.35) is used to indicate the success, or failure, of a 6361 CAPWAP control message. This document defines 23 values, and the 6362 remaining values are controlled and maintained by IANA and requires a 6363 Standards Action. 6365 15.17. Returned Message Element Reason 6367 The Reason field in the Returned Message Element message element (see 6368 Section 4.6.36) is used to indicate the reason why a message element 6369 was not processed successfully. This document defines five values, 6370 and the remaining values are controlled and maintained by IANA and 6371 requires a Standards Action. 6373 15.18. WTP Board Data Type 6375 The Board Data Type field in the WTP Board Data message element (see 6376 Section 4.6.40) is used to represent information about the WTP 6377 hardware. This document defines five values, and the remaining 6378 values are controlled and maintained by IANA and requires a Standards 6379 Action. 6381 15.19. WTP Descriptor Type 6383 The Descriptor Type field in the WTP Descriptor message element (see 6384 Section 4.6.41) is used to represent information about the WTP 6385 software. This document defines four values, and the remaining 6386 values are controlled and maintained by IANA and requires a Standards 6387 Action. 6389 15.20. WTP Fallback Mode 6391 The Mode field in the WTP Fallback message element (see 6392 Section 4.6.42) is used to indicate to the WTP the type of AC 6393 fallback mechanism it should employ. This document defines three 6394 values, and the remaining values are controlled and maintained by 6395 IANA and requires a Standards Action. 6397 15.21. WTP Frame Tunnel Mode 6399 The Tunnel Type field in the WTP Frame Tunnel Mode message element 6400 (see Section 4.6.43) is used to indicate the type of tunneling to use 6401 between the WTP and the AC. This document defines four values, and 6402 the remaining values are controlled and maintained by IANA and 6403 requires a Standards Action. 6405 15.22. WTP MAC Type 6407 The MAC Type field in the WTP MAC Type message element (see 6408 Section 4.6.46) is used to indicate the type of MAC to use in 6409 tunneled frames between the WTP and the AC. This document defines 6410 three values, and the remaining values are controlled and maintained 6411 by IANA and requires a Standards Action. 6413 15.23. WTP Radio Stats Failure Type 6415 The Last Failure Type field in the WTP Radio Statistics message 6416 element (see Section 4.6.48) is used to indicate the last WTP 6417 failure. This document defines five values, and the remaining values 6418 are controlled and maintained by IANA and requires a Standards 6419 Action. 6421 15.24. WTP Reboot Stats Failure Type 6423 The Last Failure Type field in the WTP Reboot Statistics message 6424 element (see Section 4.6.49) is used to indicate the last reboot 6425 reason. This document defines seven values, and the remaining values 6426 are controlled and maintained by IANA and requires a Standards 6427 Action. 6429 16. Acknowledgements 6431 The following individuals are acknowledged for their contributions to 6432 this protocol specification: Puneet Agarwal, Abhijit Choudhury, 6433 Saravanan Govindan, Peter Nilsson, David Perkins and Yong Zhang. 6435 Michael Vakulenko contributed text to describe how CAPWAP can be used 6436 over layer 3 (IP/UDP) networks. 6438 17. References 6440 17.1. Normative References 6442 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 6443 Requirement Levels", BCP 14, RFC 2119, March 1997. 6445 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 6446 Requirements for Security", BCP 106, RFC 4086, June 2005. 6448 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 6449 Specification, Implementation", RFC 1305, March 1992. 6451 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 6452 Housley, R., and W. Polk, "Internet X.509 Public Key 6453 Infrastructure Certificate and Certificate Revocation List 6454 (CRL) Profile", RFC 5280, May 2008. 6456 [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and 6457 Accounting (AAA) Transport Profile", RFC 3539, June 2003. 6459 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 6460 for Transport Layer Security (TLS)", RFC 4279, 6461 December 2005. 6463 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 6464 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 6466 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 6467 Security", RFC 4347, April 2006. 6469 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 6470 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 6471 May 2008. 6473 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 6474 G. Fairhurst, "The Lightweight User Datagram Protocol 6475 (UDP-Lite)", RFC 3828, July 2004. 6477 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 6478 Discovery", RFC 4821, March 2007. 6480 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 6481 (IPv6) Specification", RFC 2460, December 1998. 6483 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 6484 November 1990. 6486 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 6487 for IP version 6", RFC 1981, August 1996. 6489 [I-D.ietf-capwap-protocol-binding-ieee80211] 6490 Calhoun, P., "CAPWAP Protocol Binding for IEEE 802.11", 6491 draft-ietf-capwap-protocol-binding-ieee80211-06 (work in 6492 progress), February 2008. 6494 [I-D.ietf-capwap-dhc-ac-option] 6495 Calhoun, P., "CAPWAP Access Controller DHCP Option", 6496 draft-ietf-capwap-dhc-ac-option-01 (work in progress), 6497 March 2008. 6499 [FRAME-EXT] 6500 IEEE, "IEEE Standard 802.3as-2006", 2005. 6502 17.2. Informational References 6504 [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by 6505 an On-line Database", RFC 3232, January 2002. 6507 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 6508 RFC 3753, June 2004. 6510 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 6511 Authorization, and Accounting (AAA) Key Management", 6512 BCP 132, RFC 4962, July 2007. 6514 [RFC4564] Govindan, S., Cheng, H., Yao, ZH., Zhou, WH., and L. Yang, 6515 "Objectives for Control and Provisioning of Wireless 6516 Access Points (CAPWAP)", RFC 4564, July 2006. 6518 [I-D.ohara-capwap-lwapp] 6519 Calhoun, P., "Light Weight Access Point Protocol", 6520 draft-ohara-capwap-lwapp-04 (work in progress), 6521 March 2007. 6523 [I-D.narasimhan-ietf-slapp] 6524 Narasimhan, P., "SLAPP : Secure Light Access Point 6525 Protocol", draft-narasimhan-ietf-slapp-01 (work in 6526 progress), March 2006. 6528 [DTLS-DESIGN] 6529 Modadugu et al, N., "The Design and Implementation of 6530 Datagram TLS", Feb 2004. 6532 [EUI-48] IEEE, "Guidelines for use of a 48-bit Extended Unique 6533 Identifier", Dec 2005. 6535 [EUI-64] IEEE, "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) 6536 REGISTRATION AUTHORITY". 6538 [EPCGlobal] 6539 "See http://www.epcglobalinc.org/home". 6541 Editors' Addresses 6543 Pat R. Calhoun 6544 Cisco Systems, Inc. 6545 170 West Tasman Drive 6546 San Jose, CA 95134 6548 Phone: +1 408-902-3240 6549 Email: pcalhoun@cisco.com 6551 Michael P. Montemurro 6552 Research In Motion 6553 5090 Commerce Blvd 6554 Mississauga, ON L4W 5M4 6555 Canada 6557 Phone: +1 905-629-4746 x4999 6558 Email: mmontemurro@rim.com 6560 Dorothy Stanley 6561 Aruba Networks 6562 1322 Crossman Ave 6563 Sunnyvale, CA 94089 6565 Phone: +1 630-363-1389 6566 Email: dstanley@arubanetworks.com 6568 Full Copyright Statement 6570 Copyright (C) The IETF Trust (2008). 6572 This document is subject to the rights, licenses and restrictions 6573 contained in BCP 78, and except as set forth therein, the authors 6574 retain all their rights. 6576 This document and the information contained herein are provided on an 6577 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 6578 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 6579 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 6580 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 6581 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 6582 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 6584 Intellectual Property 6586 The IETF takes no position regarding the validity or scope of any 6587 Intellectual Property Rights or other rights that might be claimed to 6588 pertain to the implementation or use of the technology described in 6589 this document or the extent to which any license under such rights 6590 might or might not be available; nor does it represent that it has 6591 made any independent effort to identify any such rights. Information 6592 on the procedures with respect to rights in RFC documents can be 6593 found in BCP 78 and BCP 79. 6595 Copies of IPR disclosures made to the IETF Secretariat and any 6596 assurances of licenses to be made available, or the result of an 6597 attempt made to obtain a general license or permission for the use of 6598 such proprietary rights by implementers or users of this 6599 specification can be obtained from the IETF on-line IPR repository at 6600 http://www.ietf.org/ipr. 6602 The IETF invites any interested party to bring to its attention any 6603 copyrights, patents or patent applications, or other proprietary 6604 rights that may cover technology that may be required to implement 6605 this standard. Please address the information to the IETF at 6606 ietf-ipr@ietf.org.