idnits 2.17.1 draft-ietf-capwap-protocol-specification-15.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 7107. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 7118. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 7125. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 7131. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. 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 (October 31, 2008) is 5618 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2598' is defined on line 6947, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2598 (Obsoleted by RFC 3246) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) ** Downref: Normative reference to an Informational RFC: RFC 4963 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-12) exists of draft-ietf-capwap-protocol-binding-ieee80211-11 -- Possible downref: Non-RFC (?) normative reference: ref. 'FRAME-EXT' Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 8 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: May 4, 2009 Research In Motion 6 D. Stanley, Editor 7 Aruba Networks 8 October 31, 2008 10 CAPWAP Protocol Specification 11 draft-ietf-capwap-protocol-specification-15 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 May 4, 2009. 38 Abstract 40 This specification defines the Control And Provisioning of Wireless 41 Access Points (CAPWAP) Protocol, meeting the objectives defined by 42 the CAPWAP working group in RFC 4564. The CAPWAP protocol is 43 designed to be flexible, allowing it to be used for a variety of 44 wireless technologies. This document describes the base CAPWAP 45 protocol, while separate binding extensions will enable its use with 46 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 . . . . . . . . . . . . . . . . 32 61 2.4. Use of DTLS in the CAPWAP Protocol . . . . . . . . . . . 34 62 2.4.1. DTLS Handshake Processing . . . . . . . . . . . . . . 34 63 2.4.2. DTLS Session Establishment . . . . . . . . . . . . . 36 64 2.4.3. DTLS Error Handling . . . . . . . . . . . . . . . . . 36 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 . . . . . . . . . . . . . . . . . . . 42 69 3.3. AC Discovery . . . . . . . . . . . . . . . . . . . . . . 42 70 3.4. Fragmentation/Reassembly . . . . . . . . . . . . . . . . 43 71 3.5. MTU Discovery . . . . . . . . . . . . . . . . . . . . . 44 72 4. CAPWAP Packet Formats . . . . . . . . . . . . . . . . . . . . 45 73 4.1. CAPWAP Preamble . . . . . . . . . . . . . . . . . . . . 47 74 4.2. CAPWAP DTLS Header . . . . . . . . . . . . . . . . . . . 47 75 4.3. CAPWAP Header . . . . . . . . . . . . . . . . . . . . . 48 76 4.4. CAPWAP Data Messages . . . . . . . . . . . . . . . . . . 51 77 4.4.1. CAPWAP Data Channel Keepalive . . . . . . . . . . . . 51 78 4.4.2. Data Payload . . . . . . . . . . . . . . . . . . . . 52 79 4.4.3. Establishment of a DTLS Data Channel . . . . . . . . 53 80 4.5. CAPWAP Control Messages . . . . . . . . . . . . . . . . 53 81 4.5.1. Control Message Format . . . . . . . . . . . . . . . 54 82 4.5.2. Quality of Service . . . . . . . . . . . . . . . . . 57 83 4.5.3. Retransmissions . . . . . . . . . . . . . . . . . . . 58 84 4.6. CAPWAP Protocol Message Elements . . . . . . . . . . . . 59 85 4.6.1. AC Descriptor . . . . . . . . . . . . . . . . . . . . 61 86 4.6.2. AC IPv4 List . . . . . . . . . . . . . . . . . . . . 64 87 4.6.3. AC IPv6 List . . . . . . . . . . . . . . . . . . . . 65 88 4.6.4. AC Name . . . . . . . . . . . . . . . . . . . . . . . 65 89 4.6.5. AC Name with Priority . . . . . . . . . . . . . . . . 66 90 4.6.6. AC Timestamp . . . . . . . . . . . . . . . . . . . . 66 91 4.6.7. Add MAC ACL Entry . . . . . . . . . . . . . . . . . . 67 92 4.6.8. Add Station . . . . . . . . . . . . . . . . . . . . . 67 93 4.6.9. CAPWAP Control IPv4 Address . . . . . . . . . . . . . 68 94 4.6.10. CAPWAP Control IPv6 Address . . . . . . . . . . . . . 69 95 4.6.11. CAPWAP Local IPv4 Address . . . . . . . . . . . . . . 69 96 4.6.12. CAPWAP Local IPv6 Address . . . . . . . . . . . . . . 70 97 4.6.13. CAPWAP Timers . . . . . . . . . . . . . . . . . . . . 70 98 4.6.14. CAPWAP Transport Protocol . . . . . . . . . . . . . . 71 99 4.6.15. Data Transfer Data . . . . . . . . . . . . . . . . . 72 100 4.6.16. Data Transfer Mode . . . . . . . . . . . . . . . . . 73 101 4.6.17. Decryption Error Report . . . . . . . . . . . . . . . 73 102 4.6.18. Decryption Error Report Period . . . . . . . . . . . 74 103 4.6.19. Delete MAC ACL Entry . . . . . . . . . . . . . . . . 75 104 4.6.20. Delete Station . . . . . . . . . . . . . . . . . . . 75 105 4.6.21. Discovery Type . . . . . . . . . . . . . . . . . . . 76 106 4.6.22. Duplicate IPv4 Address . . . . . . . . . . . . . . . 76 107 4.6.23. Duplicate IPv6 Address . . . . . . . . . . . . . . . 77 108 4.6.24. Idle Timeout . . . . . . . . . . . . . . . . . . . . 78 109 4.6.25. ECN Support . . . . . . . . . . . . . . . . . . . . . 79 110 4.6.26. Image Data . . . . . . . . . . . . . . . . . . . . . 79 111 4.6.27. Image Identifier . . . . . . . . . . . . . . . . . . 80 112 4.6.28. Image Information . . . . . . . . . . . . . . . . . . 80 113 4.6.29. Initiate Download . . . . . . . . . . . . . . . . . . 81 114 4.6.30. Location Data . . . . . . . . . . . . . . . . . . . . 81 115 4.6.31. Maximum Message Length . . . . . . . . . . . . . . . 82 116 4.6.32. MTU Discovery Padding . . . . . . . . . . . . . . . . 82 117 4.6.33. Radio Administrative State . . . . . . . . . . . . . 83 118 4.6.34. Radio Operational State . . . . . . . . . . . . . . . 84 119 4.6.35. Result Code . . . . . . . . . . . . . . . . . . . . . 85 120 4.6.36. Returned Message Element . . . . . . . . . . . . . . 86 121 4.6.37. Session ID . . . . . . . . . . . . . . . . . . . . . 87 122 4.6.38. Statistics Timer . . . . . . . . . . . . . . . . . . 87 123 4.6.39. Vendor Specific Payload . . . . . . . . . . . . . . . 88 124 4.6.40. WTP Board Data . . . . . . . . . . . . . . . . . . . 89 125 4.6.41. WTP Descriptor . . . . . . . . . . . . . . . . . . . 90 126 4.6.42. WTP Fallback . . . . . . . . . . . . . . . . . . . . 92 127 4.6.43. WTP Frame Tunnel Mode . . . . . . . . . . . . . . . . 93 128 4.6.44. WTP MAC Type . . . . . . . . . . . . . . . . . . . . 94 129 4.6.45. WTP Name . . . . . . . . . . . . . . . . . . . . . . 95 130 4.6.46. WTP Radio Statistics . . . . . . . . . . . . . . . . 95 131 4.6.47. WTP Reboot Statistics . . . . . . . . . . . . . . . . 97 132 4.6.48. WTP Static IP Address Information . . . . . . . . . . 98 134 4.7. CAPWAP Protocol Timers . . . . . . . . . . . . . . . . . 99 135 4.7.1. ChangeStatePendingTimer . . . . . . . . . . . . . . . 99 136 4.7.2. DataChannelKeepAlive . . . . . . . . . . . . . . . . 99 137 4.7.3. DataChannelDeadInterval . . . . . . . . . . . . . . . 99 138 4.7.4. DataCheckTimer . . . . . . . . . . . . . . . . . . . 99 139 4.7.5. DiscoveryInterval . . . . . . . . . . . . . . . . . . 100 140 4.7.6. DTLSSessionDelete . . . . . . . . . . . . . . . . . . 100 141 4.7.7. EchoInterval . . . . . . . . . . . . . . . . . . . . 100 142 4.7.8. IdleTimeout . . . . . . . . . . . . . . . . . . . . . 100 143 4.7.9. ImageDataStartTimer . . . . . . . . . . . . . . . . . 100 144 4.7.10. MaxDiscoveryInterval . . . . . . . . . . . . . . . . 100 145 4.7.11. ReportInterval . . . . . . . . . . . . . . . . . . . 100 146 4.7.12. RetransmitInterval . . . . . . . . . . . . . . . . . 101 147 4.7.13. SilentInterval . . . . . . . . . . . . . . . . . . . 101 148 4.7.14. StatisticsTimer . . . . . . . . . . . . . . . . . . . 101 149 4.7.15. WaitDTLS . . . . . . . . . . . . . . . . . . . . . . 101 150 4.7.16. WaitJoin . . . . . . . . . . . . . . . . . . . . . . 101 151 4.8. CAPWAP Protocol Variables . . . . . . . . . . . . . . . 101 152 4.8.1. AdminState . . . . . . . . . . . . . . . . . . . . . 102 153 4.8.2. DiscoveryCount . . . . . . . . . . . . . . . . . . . 102 154 4.8.3. FailedDTLSAuthFailCount . . . . . . . . . . . . . . . 102 155 4.8.4. FailedDTLSSessionCount . . . . . . . . . . . . . . . 102 156 4.8.5. MaxDiscoveries . . . . . . . . . . . . . . . . . . . 102 157 4.8.6. MaxFailedDTLSSessionRetry . . . . . . . . . . . . . . 102 158 4.8.7. MaxRetransmit . . . . . . . . . . . . . . . . . . . . 102 159 4.8.8. RetransmitCount . . . . . . . . . . . . . . . . . . . 102 160 4.8.9. WTPFallBack . . . . . . . . . . . . . . . . . . . . . 103 161 4.9. WTP Saved Variables . . . . . . . . . . . . . . . . . . 103 162 4.9.1. AdminRebootCount . . . . . . . . . . . . . . . . . . 103 163 4.9.2. FrameEncapType . . . . . . . . . . . . . . . . . . . 103 164 4.9.3. LastRebootReason . . . . . . . . . . . . . . . . . . 103 165 4.9.4. MacType . . . . . . . . . . . . . . . . . . . . . . . 103 166 4.9.5. PreferredACs . . . . . . . . . . . . . . . . . . . . 103 167 4.9.6. RebootCount . . . . . . . . . . . . . . . . . . . . . 103 168 4.9.7. Static IP Address . . . . . . . . . . . . . . . . . . 103 169 4.9.8. WTPLinkFailureCount . . . . . . . . . . . . . . . . . 104 170 4.9.9. WTPLocation . . . . . . . . . . . . . . . . . . . . . 104 171 4.9.10. WTPName . . . . . . . . . . . . . . . . . . . . . . . 104 172 5. CAPWAP Discovery Operations . . . . . . . . . . . . . . . . . 105 173 5.1. Discovery Request Message . . . . . . . . . . . . . . . 105 174 5.2. Discovery Response Message . . . . . . . . . . . . . . . 106 175 5.3. Primary Discovery Request Message . . . . . . . . . . . 107 176 5.4. Primary Discovery Response . . . . . . . . . . . . . . . 108 177 6. CAPWAP Join Operations . . . . . . . . . . . . . . . . . . . 110 178 6.1. Join Request . . . . . . . . . . . . . . . . . . . . . . 110 179 6.2. Join Response . . . . . . . . . . . . . . . . . . . . . 111 180 7. Control Channel Management . . . . . . . . . . . . . . . . . 114 181 7.1. Echo Request . . . . . . . . . . . . . . . . . . . . . . 114 182 7.2. Echo Response . . . . . . . . . . . . . . . . . . . . . 114 183 8. WTP Configuration Management . . . . . . . . . . . . . . . . 116 184 8.1. Configuration Consistency . . . . . . . . . . . . . . . 116 185 8.1.1. Configuration Flexibility . . . . . . . . . . . . . . 117 186 8.2. Configuration Status Request . . . . . . . . . . . . . . 117 187 8.3. Configuration Status Response . . . . . . . . . . . . . 118 188 8.4. Configuration Update Request . . . . . . . . . . . . . . 119 189 8.5. Configuration Update Response . . . . . . . . . . . . . 120 190 8.6. Change State Event Request . . . . . . . . . . . . . . . 120 191 8.7. Change State Event Response . . . . . . . . . . . . . . 122 192 8.8. Clear Configuration Request . . . . . . . . . . . . . . 122 193 8.9. Clear Configuration Response . . . . . . . . . . . . . . 122 194 9. Device Management Operations . . . . . . . . . . . . . . . . 124 195 9.1. Firmware Management . . . . . . . . . . . . . . . . . . 124 196 9.1.1. Image Data Request . . . . . . . . . . . . . . . . . 128 197 9.1.2. Image Data Response . . . . . . . . . . . . . . . . . 129 198 9.2. Reset Request . . . . . . . . . . . . . . . . . . . . . 130 199 9.3. Reset Response . . . . . . . . . . . . . . . . . . . . . 131 200 9.4. WTP Event Request . . . . . . . . . . . . . . . . . . . 131 201 9.5. WTP Event Response . . . . . . . . . . . . . . . . . . . 132 202 9.6. Data Transfer . . . . . . . . . . . . . . . . . . . . . 132 203 9.6.1. Data Transfer Request . . . . . . . . . . . . . . . . 133 204 9.6.2. Data Transfer Response . . . . . . . . . . . . . . . 134 205 10. Station Session Management . . . . . . . . . . . . . . . . . 136 206 10.1. Station Configuration Request . . . . . . . . . . . . . 136 207 10.2. Station Configuration Response . . . . . . . . . . . . . 136 208 11. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 138 209 12. Security Considerations . . . . . . . . . . . . . . . . . . . 140 210 12.1. CAPWAP Security . . . . . . . . . . . . . . . . . . . . 140 211 12.1.1. Converting Protected Data into Unprotected Data . . . 141 212 12.1.2. Converting Unprotected Data into Protected Data 213 (Insertion) . . . . . . . . . . . . . . . . . . . . . 141 214 12.1.3. Deletion of Protected Records . . . . . . . . . . . . 141 215 12.1.4. Insertion of Unprotected Records . . . . . . . . . . 141 216 12.1.5. Use of MD5 . . . . . . . . . . . . . . . . . . . . . 141 217 12.1.6. CAPWAP Fragmentation . . . . . . . . . . . . . . . . 141 218 12.2. Session ID Security . . . . . . . . . . . . . . . . . . 142 219 12.3. Discovery or DTLS Setup Attacks . . . . . . . . . . . . 142 220 12.4. Interference with a DTLS Session . . . . . . . . . . . . 143 221 12.5. CAPWAP Pre-Provisioning . . . . . . . . . . . . . . . . 143 222 12.6. Use of Preshared Keys in CAPWAP . . . . . . . . . . . . 144 223 12.7. Use of Certificates in CAPWAP . . . . . . . . . . . . . 145 224 12.8. Use of MAC Address in CN Field . . . . . . . . . . . . . 146 225 12.9. AAA Security . . . . . . . . . . . . . . . . . . . . . . 146 226 12.10. WTP Firmware . . . . . . . . . . . . . . . . . . . . . . 147 227 13. Operational Considerations . . . . . . . . . . . . . . . . . 148 228 14. Transport Considerations . . . . . . . . . . . . . . . . . . 149 229 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 150 230 15.1. IPv4 Multicast Address . . . . . . . . . . . . . . . . . 150 231 15.2. IPv6 Multicast Address . . . . . . . . . . . . . . . . . 150 232 15.3. UDP Port . . . . . . . . . . . . . . . . . . . . . . . . 150 233 15.4. CAPWAP Message Types . . . . . . . . . . . . . . . . . . 151 234 15.5. CAPWAP Header Flags . . . . . . . . . . . . . . . . . . 151 235 15.6. CAPWAP Control Message Flags . . . . . . . . . . . . . . 151 236 15.7. CAPWAP Message Element Type . . . . . . . . . . . . . . 152 237 15.8. Wireless Binding Identifiers . . . . . . . . . . . . . . 152 238 15.9. AC Security Types . . . . . . . . . . . . . . . . . . . 152 239 15.10. AC DTLS Policy . . . . . . . . . . . . . . . . . . . . . 153 240 15.11. AC Information Type . . . . . . . . . . . . . . . . . . 153 241 15.12. CAPWAP Transport Protocol Types . . . . . . . . . . . . 153 242 15.13. Data Transfer Type . . . . . . . . . . . . . . . . . . . 153 243 15.14. Data Transfer Mode . . . . . . . . . . . . . . . . . . . 154 244 15.15. Discovery Types . . . . . . . . . . . . . . . . . . . . 154 245 15.16. ECN Support . . . . . . . . . . . . . . . . . . . . . . 154 246 15.17. Radio Admin State . . . . . . . . . . . . . . . . . . . 155 247 15.18. Radio Operational State . . . . . . . . . . . . . . . . 155 248 15.19. Radio Failure Causes . . . . . . . . . . . . . . . . . . 155 249 15.20. Result Code . . . . . . . . . . . . . . . . . . . . . . 155 250 15.21. Returned Message Element Reason . . . . . . . . . . . . 156 251 15.22. WTP Board Data Type . . . . . . . . . . . . . . . . . . 156 252 15.23. WTP Descriptor Type . . . . . . . . . . . . . . . . . . 156 253 15.24. WTP Fallback Mode . . . . . . . . . . . . . . . . . . . 156 254 15.25. WTP Frame Tunnel Mode . . . . . . . . . . . . . . . . . 157 255 15.26. WTP MAC Type . . . . . . . . . . . . . . . . . . . . . . 157 256 15.27. WTP Radio Stats Failure Type . . . . . . . . . . . . . . 157 257 15.28. WTP Reboot Stats Failure Type . . . . . . . . . . . . . 158 258 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 159 259 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 160 260 17.1. Normative References . . . . . . . . . . . . . . . . . . 160 261 17.2. Informational References . . . . . . . . . . . . . . . . 162 262 Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 164 263 Intellectual Property and Copyright Statements . . . . . . . . . 165 265 1. Introduction 267 This document describes the CAPWAP Protocol, a standard, 268 interoperable protocol which enables an Access Controller (AC) to 269 manage a collection of Wireless Termination Points (WTPs). The 270 CAPWAP protocol is defined to be independent of layer 2 technology, 271 and meets the Objectives for Control and Provisioning of Wireless 272 Access Points (CAPWAP) [RFC4564]. 274 The emergence of centralized IEEE 802.11 Wireless Local Area Network 275 (WLAN) architectures, in which simple IEEE 802.11 WTPs are managed by 276 an Access Controller (AC) suggested that a standards based, 277 interoperable protocol could radically simplify the deployment and 278 management of wireless networks. WTPs require a set of dynamic 279 management and control functions related to their primary task of 280 connecting the wireless and wired mediums. Traditional protocols for 281 managing WTPs are either manual static configuration via HTTP, 282 proprietary Layer 2 specific or non-existent (if the WTPs are self- 283 contained). An IEEE 802.11 binding is defined in 284 [I-D.ietf-capwap-protocol-binding-ieee80211] to support use of the 285 CAPWAP protocol with IEEE 802.11 WLAN networks. 287 CAPWAP assumes a network configuration consisting of multiple WTPs 288 communicating via the Internet Protocol (IP) to an AC. WTPs are 289 viewed as remote RF interfaces controlled by the AC. The CAPWAP 290 protocol supports two modes of operation: Split and Local MAC. In 291 Split MAC mode all L2 wireless data and management frames are 292 encapsulated via the CAPWAP protocol and exchanged between the AC and 293 the WTP. As shown in Figure 1, the wireless frames received from a 294 mobile device, which is referred to in this specification as a 295 Station (STA), are directly encapsulated by the WTP and forwarded to 296 the AC. 298 +-+ wireless frames +-+ 299 | |--------------------------------| | 300 | | +-+ | | 301 | |--------------| |---------------| | 302 | |wireless PHY/ | | CAPWAP | | 303 | | MAC sublayer | | | | 304 +-+ +-+ +-+ 305 STA WTP AC 307 Figure 1: Representative CAPWAP Architecture for Split MAC 309 The Local MAC mode of operation allows for the data frames to be 310 either locally bridged, or tunneled as 802.3 frames. The latter 311 implies that the WTP performs the 802.11 Integration function. In 312 either case the L2 wireless management frames are processed locally 313 by the WTP, and then forwarded to the AC. Figure 2 shows the Local 314 MAC mode, in which a station transmits a wireless frame which is 315 encapsulated in an 802.3 frame and forwarded to the AC. 317 +-+wireless frames +-+ 802.3 frames +-+ 318 | |----------------| |--------------| | 319 | | | | | | 320 | |----------------| |--------------| | 321 | |wireless PHY/ | | CAPWAP | | 322 | | MAC sublayer | | | | 323 +-+ +-+ +-+ 324 STA WTP AC 326 Figure 2: Representative CAPWAP Architecture for Local MAC 328 Provisioning WTPs with security credentials, and managing which WTPs 329 are authorized to provide service are traditionally handled by 330 proprietary solutions. Allowing these functions to be performed from 331 a centralized AC in an interoperable fashion increases manageability 332 and allows network operators to more tightly control their wireless 333 network infrastructure. 335 1.1. Goals 337 The goals for the CAPWAP protocol are listed below: 339 1. To centralize the authentication and policy enforcement functions 340 for a wireless network. The AC may also provide centralized 341 bridging, forwarding, and encryption of user traffic. 342 Centralization of these functions will enable reduced cost and 343 higher efficiency by applying the capabilities of network 344 processing silicon to the wireless network, as in wired LANs. 346 2. To enable shifting of the higher level protocol processing from 347 the WTP. This leaves the time critical applications of wireless 348 control and access in the WTP, making efficient use of the 349 computing power available in WTPs which are the subject to severe 350 cost pressure. 352 3. To provide an extensible protocol that is not bound to a specific 353 wireless technology. Extensibility is provided via a generic 354 encapsulation and transport mechanism, enabling the CAPWAP 355 protocol to be applied to many access point types in the future, 356 via a specific wireless binding. 358 The CAPWAP protocol concerns itself solely with the interface between 359 the WTP and the AC. Inter-AC and station-to AC-communication are 360 strictly outside the scope of this document. 362 1.2. Conventions used in this document 364 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 365 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 366 document are to be interpreted as described in RFC 2119 [RFC2119]. 368 1.3. Contributing Authors 370 This section lists and acknowledges the authors of significant text 371 and concepts included in this specification. 373 The CAPWAP Working Group selected the Lightweight Access Point 374 Protocol (LWAPP) [I-D.ohara-capwap-lwapp] to be used as the basis of 375 the CAPWAP protocol specification. The following people are authors 376 of the LWAPP document: 378 Bob O'Hara 379 Email: bob.ohara@computer.org 381 Pat Calhoun, Cisco Systems, Inc. 382 170 West Tasman Drive, San Jose, CA 95134 383 Phone: +1 408-902-3240, Email: pcalhoun@cisco.com 385 Rohit Suri, Cisco Systems, Inc. 386 170 West Tasman Drive, San Jose, CA 95134 387 Phone: +1 408-853-5548, Email: rsuri@cisco.com 389 Nancy Cam Winget, Cisco Systems, Inc. 390 170 West Tasman Drive, San Jose, CA 95134 391 Phone: +1 408-853-0532, Email: ncamwing@cisco.com 393 Scott Kelly, Aruba Networks 394 1322 Crossman Ave, Sunnyvale, CA 94089 395 Phone: +1 408-754-8408, Email: skelly@arubanetworks.com 397 Michael Glenn Williams, Nokia, Inc. 398 313 Fairchild Drive, Mountain View, CA 94043 399 Phone: +1 650-714-7758, Email: Michael.G.Williams@Nokia.com 401 Sue Hares, Green Hills Software 402 825 Victors Way, Suite 100, Ann Arbor, MI 48108 403 Phone: +1 734 222 1610, Email: shares@ndzh.com 405 Datagram Transport Layer Security (DTLS) [RFC4347] is used as the 406 security solution for the CAPWAP protocol. The following people are 407 authors of significant DTLS-related text included in this document: 409 Scott Kelly, Aruba Networks 410 1322 Crossman Ave, Sunnyvale, CA 94089 411 Phone: +1 408-754-8408, Email: skelly@arubanetworks.com 413 Eric Rescorla, Network Resonance 414 2483 El Camino Real, #212,Palo Alto CA, 94303 415 Email: ekr@networkresonance.com 417 The concept of using DTLS to secure the CAPWAP protocol was part of 418 the Secure Light Access Point Protocol (SLAPP) proposal 419 [I-D.narasimhan-ietf-slapp]. The following people are authors of the 420 SLAPP proposal: 422 Partha Narasimhan, Aruba Networks 423 1322 Crossman Ave, Sunnyvale, CA 94089 424 Phone: +1 408-480-4716, Email: partha@arubanetworks.com 426 Dan Harkins, Tropos Networks 427 555 Del Rey Avenue, Sunnyvale, CA, 95085 428 Phone: +1 408 470 7372, Email: dharkins@tropos.com 430 Subbu Ponnuswamy, Aruba Networks 431 1322 Crossman Ave, Sunnyvale, CA 94089 432 Phone: +1 408-754-1213, Email: subbu@arubanetworks.com 434 The following individuals contributed significant security related 435 text to the draft: 437 T. Charles Clancy, Laboratory for Telecommunications Sciences, 438 8080 Greenmead Drive, College Park, MD 20740 439 Phone: +1 240-373-5069, Email: clancy@ltsnet.net 441 Scott Kelly, Aruba Networks 442 1322 Crossman Ave, Sunnyvale, CA 94089 443 Phone: +1 408-754-8408, Email: skelly@arubanetworks.com 445 1.4. Terminology 447 Access Controller (AC): The network entity that provides WTP access 448 to the network infrastructure in the data plane, control plane, 449 management plane, or a combination therein. 451 CAPWAP Control Channel: A bi-directional flow defined by the AC IP 452 Address, WTP IP Address, AC control port, WTP control port and the 453 transport-layer protocol (UDP or UDP-Lite) over which CAPWAP control 454 packets are sent and received. 456 CAPWAP Data Channel: A bi-directional flow defined by the AC IP 457 Address, WTP IP Address, AC data port, WTP data port, and the 458 transport-layer protocol (UDP or UDP-Lite) over which CAPWAP data 459 packets are sent and received. 461 Station (STA): A device that contains an interface to a wireless 462 medium (WM). 464 Wireless Termination Point (WTP): The physical or network entity that 465 contains an RF antenna and wireless PHY to transmit and receive 466 station traffic for wireless access networks. 468 This document uses additional terminology defined in [RFC3753]. 470 2. Protocol Overview 472 The CAPWAP protocol is a generic protocol defining AC and WTP control 473 and data plane communication via a CAPWAP protocol transport 474 mechanism. CAPWAP control messages, and optionally CAPWAP data 475 messages, are secured using Datagram Transport Layer Security (DTLS) 476 [RFC4347]. DTLS is a standards-track IETF protocol based upon TLS. 477 The underlying security-related protocol mechanisms of TLS have been 478 successfully deployed for many years. 480 The CAPWAP protocol Transport layer carries two types of payload, 481 CAPWAP Data messages and CAPWAP Control messages. CAPWAP Data 482 messages encapsulate forwarded wireless frames. CAPWAP protocol 483 Control messages are management messages exchanged between a WTP and 484 an AC. The CAPWAP Data and Control packets are sent over separate 485 UDP ports. Since both data and control packets can exceed the 486 Maximum Transmission Unit (MTU) length, the payload of a CAPWAP data 487 or control message can be fragmented. The fragmentation behavior is 488 defined in Section 3. 490 The CAPWAP Protocol begins with a discovery phase. The WTPs send a 491 Discovery Request message, causing any Access Controller (AC) 492 receiving the message to respond with a Discovery Response message. 493 From the Discovery Response messages received, a WTP selects an AC 494 with which to establish a secure DTLS session. In order to establish 495 the secure DTLS connection, the WTP will need some amount of pre- 496 provisioning, which is specified in Section 12.5. CAPWAP protocol 497 messages will be fragmented to the maximum length discovered to be 498 supported by the network. 500 Once the WTP and the AC have completed DTLS session establishment, a 501 configuration exchange occurs in which both devices agree on version 502 information. During this exchange the WTP may receive provisioning 503 settings. The WTP is then enabled for operation. 505 When the WTP and AC have completed the version and provision exchange 506 and the WTP is enabled, the CAPWAP protocol is used to encapsulate 507 the wireless data frames sent between the WTP and AC. The CAPWAP 508 protocol will fragment the L2 frames if the size of the encapsulated 509 wireless user data (Data) or protocol control (Management) frames 510 causes the resulting CAPWAP protocol packet to exceed the MTU 511 supported between the WTP and AC. Fragmented CAPWAP packets are 512 reassembled to reconstitute the original encapsulated payload. MTU 513 Discovery and Fragmentation are described in Section 3. 515 The CAPWAP protocol provides for the delivery of commands from the AC 516 to the WTP for the management of stations that are communicating with 517 the WTP. This may include the creation of local data structures in 518 the WTP for the stations and the collection of statistical 519 information about the communication between the WTP and the stations. 520 The CAPWAP protocol provides a mechanism for the AC to obtain 521 statistical information collected by the WTP. 523 The CAPWAP protocol provides for a keep alive feature that preserves 524 the communication channel between the WTP and AC. If the AC fails to 525 appear alive, the WTP will try to discover a new AC. 527 2.1. Wireless Binding Definition 529 The CAPWAP protocol is independent of a specific WTP radio 530 technology, as well its associated wireless link layer protocol. 531 Elements of the CAPWAP protocol are designed to accommodate the 532 specific needs of each wireless technology in a standard way. 533 Implementation of the CAPWAP protocol for a particular wireless 534 technology MUST follow the binding requirements defined for that 535 technology. 537 When defining a binding for wireless technologies, the authors MUST 538 include any necessary definitions for technology-specific messages 539 and all technology-specific message elements for those messages. At 540 a minimum, a binding MUST provide: 542 1. The definition for a binding-specific Statistics message element, 543 carried in the WTP Event Request message 545 2. A message element carried in the Station Configuration Request 546 message to configure station information on the WTP 548 3. A WTP Radio Information message element carried in the Discovery, 549 Primary Discovery and Join Request and Response messages, 550 indicating the binding specific radio types supported at the WTP 551 and AC. 553 If technology specific message elements are required for any of the 554 existing CAPWAP messages defined in this specification, they MUST 555 also be defined in the technology binding document. 557 The naming of binding-specific message elements MUST begin with the 558 name of the technology type, e.g., the binding for IEEE 802.11, 559 provided in [I-D.ietf-capwap-protocol-binding-ieee80211], begins with 560 "IEEE 802.11". 562 The CAPWAP binding concept MUST also be used in any future 563 specification that add functionality to either the base CAPWAP 564 protocol specification, or any published CAPWAP binding 565 specification. A separate WTP Radio Information message element MUST 566 be created to properly advertise support for the specification. This 567 mechanism allows for future protocol extensibility, while providing 568 the necessary capabilities advertisement, through the WTP Radio 569 Information message element, to ensure WTP/AC interoperability. 571 2.2. CAPWAP Session Establishment Overview 573 This section describes the session establishment process message 574 exchanges between a CAPWAP WTP and AC. The annotated ladder diagram 575 shows the AC on the right, the WTP on the left, and assumes the use 576 of certificates for DTLS authentication. The CAPWAP Protocol State 577 Machine is described in detail in Section 2.3. Note that DTLS allows 578 certain messages to be aggregated into a single frame, which is 579 denoted via an asterisk in Figure 3. 581 ============ ============ 582 WTP AC 583 ============ ============ 584 [----------- begin optional discovery ------------] 586 Discover Request 587 ------------------------------------> 588 Discover Response 589 <------------------------------------ 591 [----------- end optional discovery ------------] 593 (-- begin DTLS handshake --) 595 ClientHello 596 ------------------------------------> 597 HelloVerifyRequest (with cookie) 598 <------------------------------------ 600 ClientHello (with cookie) 601 ------------------------------------> 602 ServerHello, 603 Certificate, 604 ServerHelloDone* 605 <------------------------------------ 607 (-- WTP callout for AC authorization --) 609 Certificate (optional), 610 ClientKeyExchange, 611 CertificateVerify (optional), 612 ChangeCipherSpec, 613 Finished* 614 ------------------------------------> 616 (-- AC callout for WTP authorization --) 618 ChangeCipherSpec, 619 Finished* 620 <------------------------------------ 622 (-- DTLS session is established now --) 624 Join Request 625 ------------------------------------> 626 Join Response 627 <------------------------------------ 628 [-- Join State Complete --] 630 (-- assume image is up to date --) 632 Configuration Status Request 633 ------------------------------------> 634 Configuration Status Response 635 <------------------------------------ 636 [-- Configure State Complete --] 638 Change State Event Request 639 ------------------------------------> 640 Change State Event Response 641 <------------------------------------ 642 [-- Data Check State Complete --] 644 (-- enter RUN state --) 646 : 647 : 649 Echo Request 650 ------------------------------------> 651 Echo Response 652 <------------------------------------ 654 : 655 : 657 Event Request 658 ------------------------------------> 659 Event Response 660 <------------------------------------ 661 : 662 : 664 Figure 3: CAPWAP Control Protocol Exchange 666 At the end of the illustrated CAPWAP message exchange, the AC and WTP 667 are securely exchanging CAPWAP control messages. This illustration 668 is provided to clarify protocol operation, and does not include any 669 possible error conditions. Section 2.3 provides a detailed 670 description of the corresponding state machine. 672 2.3. CAPWAP State Machine Definition 674 The following state diagram represents the lifecycle of a WTP-AC 675 session. Use of DTLS by the CAPWAP protocol results in the 676 juxtaposition of two nominally separate yet tightly bound state 677 machines. The DTLS and CAPWAP state machines are coupled through an 678 API consisting of commands (see Section 2.3.2.1) and notifications 679 (see Section 2.3.2.2). Certain transitions in the DTLS state machine 680 are triggered by commands from the CAPWAP state machine, while 681 certain transitions in the CAPWAP state machine are triggered by 682 notifications from the DTLS state machine. 684 /-------------------------------------\ 685 | /-------------------------\| 686 | p| || 687 | q+----------+ r +------------+ || 688 | | Run |-->| Reset |-\|| 689 | +----------+ +------------+ ||| 690 n| o ^ ^ ^ s||| 691 +------------+--------/ | | ||| 692 | Data Check | /-------/ | ||| 693 +------------+<-------\ | | ||| 694 | | | ||| 695 /------------------+--------\ | ||| 696 f| m| h| j v k| ||| 697 +--------+ +-----------+ +--------------+||| 698 | Join |---->| Configure | | Image Data |||| 699 +--------+ n +-----------+ +--------------+||| 700 ^ |g i| l| ||| 701 | | \-------------------\ | ||| 702 | \--------------------------------------\| | ||| 703 \------------------------\ || | ||| 704 /--------------<----------------+---------------\ || | ||| 705 | /------------<----------------+-------------\ | || | ||| 706 | | 4 |d t| | vv v vvv 707 | | +----------------+ +--------------+ +-----------+ 708 | | | DTLS Setup | | DTLS Connect |-->| DTLS TD | 709 /-|-|---+----------------+ +--------------+ e +-----------+ 710 | | | |$ ^ ^ |5 ^6 ^ ^ |w 711 v v v | | | | \-------\ | | | 712 | | | | | | \---------\ | | /-----------/ | 713 | | | | | \--\ | | | | | 714 | | | | | | | | | | | 715 | | | v 3| 1 |% # v | |a |b v 716 | | \->+------+-->+------+ +-----------+ +--------+ 717 | | | Idle | | Disc | | Authorize | | Dead | 718 | | +------+<--+------+ +-----------+ +--------+ 719 | | ^ 0^ 2 |! 720 | | | | | +-------+ 721 *| |u | \---------+---| Start | 722 | | |@ | +-------+ 723 | \->+---------+<------/ 724 \--->| Sulking | 725 +---------+& 727 Figure 4: CAPWAP Integrated State Machine 729 The CAPWAP protocol state machine, depicted above, is used by both 730 the AC and the WTP. In cases where states are not shared (i.e. not 731 implemented in one or the other of the AC or WTP), this is explicitly 732 called out in the transition descriptions below. For every state 733 defined, only certain messages are permitted to be sent and received. 734 The CAPWAP control message definitions specify the state(s) in which 735 each message is valid. 737 Since the WTP only communicates with a single AC, it only has a 738 single instance of the CAPWAP state machine. The state machine works 739 differently on the AC since it communicates with many WTPs. The AC 740 uses the concept of three threads. Note that the term thread used 741 here does not necessarily imply that implementers must use threads, 742 but it is one possible way of implementing the AC's state machine. 744 Listener Thread: The AC's Listener thread handles inbound DTLS 745 session establishment requests, through the DTLSListen command. 746 Upon creation, the Listener thread starts in the DTLS Setup state. 747 Once a DTLS session has been validated, which occurs when the 748 state machine enters the "Authorize" state, the Listener thread 749 creates a WTP session specific Service thread and state context. 750 The state machine transitions in Figure 4 are represented by 751 numerals. It is necessary for the AC to protect itself against 752 various attacks that exist with non-authenticated frames. See 753 Section 12 for more information. 755 Discovery Thread: The AC's Discovery thread is responsible for 756 receiving, and responding to, Discovery Request messages. The 757 state machine transitions in Figure 4 are represented by numerals. 758 Note that the Discovery thread does not maintain any per-WTP 759 specific context information, and a single state context exists. 760 It is necessary for the AC to protect itself against various 761 attacks that exist with non-authenticated frames. See Section 12 762 for more information. 764 Service Thread: The AC's Service thread handles the per-WTP states, 765 and one such thread exists per-WTP connection. This thread is 766 created by the listener thread when the Authorize state is 767 reached. When created, the Service thread inherits a copy of the 768 state machine context from the Listener thread. When 769 communication with the WTP is complete, the Service thread is 770 terminated and all associated resources are released. The state 771 machine transitions in Figure 4 are represented by alphabetic and 772 punctuation characters. 774 2.3.1. CAPWAP Protocol State Transitions 776 This section describes the various state transitions, and the events 777 that cause them. This section does not discuss interactions between 778 DTLS- and CAPWAP-specific states. Those interactions, and DTLS- 779 specific states and transitions, are discussed in Section 2.3.2. 781 Start to Idle (0): This transition occurs once device initialization 782 is complete. 784 WTP: This state transition is used to start the WTP's CAPWAP 785 state machine. 787 AC: The AC creates the Discovery and Listener threads and starts 788 the CAPWAP state machine. 790 Idle to Discovery (1): This transition occurs to support the CAPWAP 791 discovery process . 793 WTP: The WTP enters the Discovery state prior to transmitting the 794 first Discovery Request message (see Section 5.1). Upon 795 entering this state, the WTP sets the DiscoveryInterval timer 796 (see Section 4.7). The WTP resets the DiscoveryCount counter 797 to zero (0) (see Section 4.8). The WTP also clears all 798 information from ACs it may have received during a previous 799 Discovery phase. 801 AC: This state transition is executed by the AC's Discovery 802 thread, and occurs when a Discovery Request message is 803 received. The AC SHOULD respond with a Discovery Response 804 message (see Section 5.2). 806 Discovery to Discovery (#): In the Discovery state, the WTP 807 determines which AC to connect to. 809 WTP: This transition occurs when the DiscoveryInterval timer 810 expires. If the WTP is configured with a list of ACs, it 811 transmits a Discovery Request message to every AC from which it 812 has not received a Discovery Response message. For every 813 transition to this event, the WTP increments the DiscoveryCount 814 counter. See Section 5.1 for more information on how the WTP 815 knows the ACs to which it should transmit the Discovery Request 816 messages. The WTP restarts the DiscoveryInterval timer 817 whenever it transmits Discovery Request messages. 819 AC: This is an invalid state transition for the AC. 821 Discovery to Idle (2): This transition occurs on the AC's Discovery 822 thread when the Discovery processing is complete. 824 WTP: This is an invalid state transition for the WTP. 826 AC: This state transition is executed by the AC's Discovery 827 thread when it has transmitted the Discovery Response, in 828 response to a Discovery Request. 830 Discovery to Sulking (!): This transition occurs on a WTP when AC 831 Discovery fails. 833 WTP: The WTP enters this state when the DiscoveryInterval timer 834 expires and the DiscoveryCount variable is equal to the 835 MaxDiscoveries variable (see Section 4.8). Upon entering this 836 state, the WTP MUST start the SilentInterval timer. While in 837 the Sulking state, all received CAPWAP protocol messages MUST 838 be ignored. 840 AC: This is an invalid state transition for the AC. 842 Sulking to Idle (@): This transition occurs on a WTP when it must 843 restart the discovery phase. 845 WTP: The WTP enters this state when the SilentInterval timer (see 846 Section 4.7) expires. The FailedDTLSSessionCount, 847 DiscoveryCount and FailedDTLSAuthFailCount counters are reset 848 to zero. 850 AC: This is an invalid state transition for the AC. 852 Sulking to Sulking (&): The Sulking state provides the silent 853 period, minimizing the possibility for Denial of Service (DoS) 854 attacks. 856 WTP: All packets received from the AC while in the sulking state 857 are ignored. 859 AC: This is an invalid state transition for the AC. 861 Idle to DTLS Setup (3): This transition occurs to establish a secure 862 DTLS session with the peer. 864 WTP: The WTP initiates this transition by invoking the DTLSStart 865 command(see Section 2.3.2.1), which starts the DTLS session 866 establishment with the chosen AC and the WaitDTLS timer is 867 started (see Section 4.7). When the discovery phase is 868 bypassed, it is assumed the WTP has locally configured ACs. 870 AC: Upon entering the Idle state from the Start state, the newly 871 created Listener thread automatically transitions to the DTLS 872 Setup and invokes the DTLSListen command (see Section 2.3.2.1), 873 and the WaitDTLS timer is started (see Section 4.7). 875 Discovery to DTLS Setup (%): This transition occurs to establish a 876 secure DTLS session with the peer. 878 WTP: The WTP initiates this transition by invoking the DTLSStart 879 command (see Section 2.3.2.1), which starts the DTLS session 880 establishment with the chosen AC. The decision of which AC to 881 connect to is the result of the discovery phase, which is 882 described in Section 3.3. 884 AC: This is an invalid state transition for the AC. 886 DTLS Setup to Idle ($): This transition occurs when the DTLS 887 connection setup fails. 889 WTP: The WTP initiates this state transition when it receives a 890 DTLSEstablishFail notification from DTLS (see Section 2.3.2.2), 891 and the FailedDTLSSessionCount or the FailedDTLSAuthFailCount 892 counter have not reached the value of the 893 MaxFailedDTLSSessionRetry variable (see Section 4.8). This 894 error notification aborts the secure DTLS session 895 establishment. When this notification is received, the 896 FailedDTLSSessionCount counter is incremented. This state 897 transition also occurs if the WaitDTLS timer has expired. 899 AC: This is an invalid state transition for the AC. 901 DTLS Setup to Sulking (*): This transition occurs when repeated 902 attempts to setup the DTLS connection have failed. 904 WTP: The WTP enters this state when the FailedDTLSSessionCount or 905 the FailedDTLSAuthFailCount counter reaches the value of the 906 MaxFailedDTLSSessionRetry variable (see Section 4.8). Upon 907 entering this state, the WTP MUST start the SilentInterval 908 timer. While in the Sulking state, all received CAPWAP and 909 DTLS protocol messages received MUST be ignored. 911 AC: This is an invalid state transition for the AC. 913 DTLS Setup to DTLS Setup (4): This transition occurs when the DTLS 914 Session failed to be established. 916 WTP: This is an invalid state transition for the WTP. 918 AC: The AC's Listener initiates this state transition when it 919 receives a DTLSEstablishFail notification from DTLS (see 920 Section 2.3.2.2). This error notification aborts the secure 921 DTLS session establishment. When this notification is 922 received, the FailedDTLSSessionCount counter is incremented. 924 The Listener thread then invokes the DTLSListen command (see 925 Section 2.3.2.1). 927 DTLS Setup to Authorize (5): This transition occurs when an incoming 928 DTLS session is being established, and the DTLS stack needs 929 authorization to proceed with the session establishment. 931 WTP: This state transition occurs when the WTP receives the 932 DTLSPeerAuthorize notification (see Section 2.3.2.2). Upon 933 entering this state, the WTP performs an authorization check 934 against the AC credentials. See Section 2.4.4 for more 935 information on AC authorization. 937 AC: This state transition is handled by the AC's Listener thread 938 when the DTLS module initiates the DTLSPeerAuthorize 939 notification (see Section 2.3.2.2). The Listener thread forks 940 an instance of the Service thread, along with a copy of the 941 state context. Once created, the Service thread performs an 942 authorization check against the WTP credentials. See 943 Section 2.4.4 for more information on WTP authorization. 945 Authorize to DTLS Setup (6): This transition is executed by the 946 Listener thread to enable it to listen for new incoming sessions. 948 WTP: This is an invalid state transition for the WTP. 950 AC: This state transition occurs when the AC's Listener thread 951 has created the WTP context and the Service thread. The 952 Listener thread then invokes the DTLSListen command (see 953 Section 2.3.2.1). 955 Authorize to DTLS Connect (a): This transition occurs to notify the 956 DTLS stack that the session should be established. 958 WTP: This state transition occurs when the WTP has successfully 959 authorized the AC's credentials (see Section 2.4.4). This is 960 done by invoking the DTLSAccept DTLS command (see 961 Section 2.3.2.1). 963 AC: This state transition occurs when the AC has successfully 964 authorized the WTP's credentials (see Section 2.4.4). This is 965 done by invoking the DTLSAccept DTLS command (see 966 Section 2.3.2.1). 968 Authorize to DTLS Teardown (b): This transition occurs to notify the 969 DTLS stack that the session should be aborted. 971 WTP: This state transition occurs when the WTP was unable to 972 authorize the AC, using the AC credentials. The WTP then 973 aborts the DTLS session by invoking the DTLSAbortSession 974 command (see Section 2.3.2.1). This state transition also 975 occurs if the WaitDTLS timer has expired. The WTP starts the 976 DTLSSessionDelete timer (see Section 4.7.6). 978 AC: This state transition occurs when the AC was unable to 979 authorize the WTP, using the WTP credentials. The AC then 980 aborts the DTLS session by invoking the DTLSAbortSession 981 command (see Section 2.3.2.1). This state transition also 982 occurs if the WaitDTLS timer has expired. The AC starts the 983 DTLSSessionDelete timer (see Section 4.7.6). 985 DTLS Connect to DTLS Teardown (c): This transition occurs when the 986 DTLS Session failed to be established. 988 WTP: This state transition occurs when the WTP receives either a 989 DTLSAborted or DTLSAuthenticateFail notification (see 990 Section 2.3.2.2), indicating that the DTLS session was not 991 successfully established. When this transition occurs due to 992 the DTLSAuthenticateFail notification, the 993 FailedDTLSAuthFailCount is incremented, otherwise the 994 FailedDTLSSessionCount counter is incremented. This state 995 transition also occurs if the WaitDTLS timer has expired. The 996 WTP starts the DTLSSessionDelete timer (see Section 4.7.6). 998 AC: This state transition occurs when the AC receives either a 999 DTLSAborted or DTLSAuthenticateFail notification (see 1000 Section 2.3.2.2), indicating that the DTLS session was not 1001 successfully established, and both of the 1002 FailedDTLSAuthFailCount and FailedDTLSSessionCount counters 1003 have not reached the value of the MaxFailedDTLSSessionRetry 1004 variable (see Section 4.8). This state transition also occurs 1005 if the WaitDTLS timer has expired. The AC starts the 1006 DTLSSessionDelete timer (see Section 4.7.6). 1008 DTLS Connect to Join (d): This transition occurs when the DTLS 1009 Session is successfully established. 1011 WTP: This state transition occurs when the WTP receives the 1012 DTLSEstablished notification (see Section 2.3.2.2), indicating 1013 that the DTLS session was successfully established. When this 1014 notification is received, the FailedDTLSSessionCount counter is 1015 set to zero. The WTP enters the Join state by transmiting the 1016 Join Request to the AC. The WTP stops the WaitDTLS timer. 1018 AC: This state transition occurs when the AC receives the 1019 DTLSEstablished notification (see Section 2.3.2.2), indicating 1020 that the DTLS session was successfully established. When this 1021 notification is received, the FailedDTLSSessionCount counter is 1022 set to zero. The AC stops the WaitDTLS timer, and starts the 1023 WaitJoin timer. 1025 Join to DTLS Teardown (e): This transition occurs when the join 1026 process failed. 1028 WTP: This state transition occurs when the WTP receives a Join 1029 Response message with a Result Code message element containing 1030 an error, or if the Image Identifier provided by the AC in the 1031 Join Response message differs from the WTP's currently running 1032 firmware version and the WTP has the requested image in its 1033 non-volatile memory. This causes the WTP to initiate the 1034 DTLSShutdown command (see Section 2.3.2.1). This transition 1035 also occurs if the WTP receives one of the following DTLS 1036 notifications: DTLSAborted, DTLSReassemblyFailure or 1037 DTLSPeerDisconnect. The WTP starts the DTLSSessionDelete timer 1038 (see Section 4.7.6). 1040 AC: This state transition occurs either if the WaitJoin timer 1041 expires or if the AC transmits a Join Response message with a 1042 Result Code message element containing an error. This causes 1043 the AC to initiate the DTLSShutdown command (see 1044 Section 2.3.2.1). This transition also occurs if the AC 1045 receives one of the following DTLS notifications: DTLSAborted, 1046 DTLSReassemblyFailure or DTLSPeerDisconnect. The AC starts the 1047 DTLSSessionDelete timer (see Section 4.7.6). 1049 Join to Image Data (f): This state transition is used by the WTP and 1050 the AC to download executable firmware. 1052 WTP: The WTP enters the Image Data state when it receives a 1053 successful Join Response message and determines that the 1054 software version in the Image Identifier message element is not 1055 the same as its currently running image. The WTP also detects 1056 that the requested image version is not currently available in 1057 the WTP's non-volatile storage (see Section 9.1 for a full 1058 description of the firmware download process). The WTP 1059 initializes the EchoInterval timer (see Section 4.7), and 1060 transmits the Image Data Request message (see Section 9.1.1) 1061 requesting the start of the firmware download. 1063 AC: This state transition occurs when the AC receives the Image 1064 Data Request message from the WTP, after having sent its Join 1065 Response to the WTP. The AC stops the WaitJoin timer. The AC 1066 MUST transmit an Image Data Response message (see 1067 Section 9.1.2) to the WTP, which includes a portion of the 1068 firmware. 1070 Join to Configure (g): This state transition is used by the WTP and 1071 the AC to exchange configuration information. 1073 WTP: The WTP enters the Configure state when it receives a 1074 successful Join Response message, and determines that the 1075 included Image Identifier message element is the same as its 1076 currently running image. The WTP transmits the Configuration 1077 Status Request message (see Section 8.2) to the AC with message 1078 elements describing its current configuration. 1080 AC: This state transition occurs when it receives the 1081 Configuration Status Request message from the WTP (see 1082 Section 8.2), which MAY include specific message elements to 1083 override the WTP's configuration. The AC stops the WaitJoin 1084 timer. The AC transmits the Configuration Status Response 1085 message (see Section 8.3) and starts the 1086 ChangeStatePendingTimer timer (see Section 4.7). 1088 Configure to Reset (h): This state transition is used to reset the 1089 connection either due to an error during the configuration phase, 1090 or when the WTP determines it needs to reset in order for the new 1091 configuration to take effect. The CAPWAP Reset command is used to 1092 indicate to the peer that it will initiate a DTLS teardown. 1094 WTP: The WTP enters the Reset state when it receives a 1095 Configuration Status Response message indicating an error or 1096 when it determines that a reset of the WTP is required, due to 1097 the characteristics of a new configuration. 1099 AC: The AC transitions to the Reset state when it receives a 1100 Change State Event message from the WTP that contains an error 1101 for which AC policy does not permit the WTP to provide service. 1102 This state transition also occurs when the AC 1103 ChangeStatePendingTimer timer expires. 1105 Configure to DTLS Teardown (i): This transition occurs when the 1106 configuration process aborts due to a DTLS error. 1108 WTP: The WTP enters this state when it receives one of the 1109 following DTLS notifications: DTLSAborted, 1110 DTLSReassemblyFailure or DTLSPeerDisconnect (see 1111 Section 2.3.2.2). The WTP MAY tear down the DTLS session if it 1112 receives frequent DTLSDecapFailure notifications. The WTP 1113 starts the DTLSSessionDelete timer (see Section 4.7.6). 1115 AC: The AC enters this state when it receives one of the 1116 following DTLS notifications: DTLSAborted, 1117 DTLSReassemblyFailure or DTLSPeerDisconnect (see 1118 Section 2.3.2.2). The AC MAY tear down the DTLS session if it 1119 receives frequent DTLSDecapFailure notifications. The AC 1120 starts the DTLSSessionDelete timer (see Section 4.7.6). 1122 Image Data to Image Data (j): The Image Data state is used by the 1123 WTP and the AC during the firmware download phase. 1125 WTP: The WTP enters the Image Data state when it receives an 1126 Image Data Response message indicating that the AC has more 1127 data to send. This state transition also occurs when the WTP 1128 receives the subsequent Image Data Requests, at which time it 1129 resets the ImageDataStartTimer time to ensure it receives the 1130 next expected Image Data Request from the AC. This state 1131 transition can also occur when the WTP's EchoInterval timer 1132 (see Section 4.7.7) expires, in which case the WTP transmits an 1133 Echo Request message (see Section 7.1), and resets its 1134 EchoInterval timer. The state transition also occurs when the 1135 WTP receives an Echo Response from the AC (see Section 7.2. 1137 AC: This state transition occurs either when the AC receives the 1138 Image Data Response message from the WTP while already in the 1139 Image Data state. This state transition also occurs when the 1140 AC receives an Echo Request (see Section 7.1) from the WTP, in 1141 which case it responds with an Echo Response (see Section 7.2), 1142 and resets its EchoInterval timer (see Section 4.7.7). 1144 Image Data to Reset (k): This state transition is used to reset the 1145 DTLS connection prior to restarting the WTP after an image 1146 download. 1148 WTP: When an image download completes, or if the 1149 ImageDataStartTimer timer expires, the WTP enters the Reset 1150 state. The WTP MAY also transition to this state upon 1151 receiving an Image Data Response message from the AC (see 1152 Section 9.1.2) indicating a failure. 1154 AC: The AC enters the Reset state either when the image transfer 1155 has successfully completed or an error occurs during the image 1156 download process. 1158 Image Data to DTLS Teardown (l): This transition occurs when the 1159 firmware download process aborts due to a DTLS error. 1161 WTP: The WTP enters this state when it receives one of the 1162 following DTLS notifications: DTLSAborted, 1163 DTLSReassemblyFailure or DTLSPeerDisconnect (see 1164 Section 2.3.2.2). The WTP MAY tear down the DTLS session if it 1165 receives frequent DTLSDecapFailure notifications. The WTP 1166 starts the DTLSSessionDelete timer (see Section 4.7.6). 1168 AC: The AC enters this state when it receives one of the 1169 following DTLS notifications: DTLSAborted, 1170 DTLSReassemblyFailure or DTLSPeerDisconnect (see 1171 Section 2.3.2.2). The AC MAY tear down the DTLS session if it 1172 receives frequent DTLSDecapFailure notifications. The AC 1173 starts the DTLSSessionDelete timer (see Section 4.7.6). 1175 Configure to Data Check (m): This state transition occurs when the 1176 WTP and AC confirm the configuration. 1178 WTP: The WTP enters this state when it receives a successful 1179 Configuration Status Response message from the AC. The WTP 1180 transmits the Change State Event Request message (see 1181 Section 8.6). 1183 AC: This state transition occurs when the AC receives the Change 1184 State Event Request message (see Section 8.6) from the WTP. 1185 The AC responds with a Change State Event Response message (see 1186 Section 8.7). The AC MUST start the DataCheckTimer timer and 1187 stops the ChangeStatePendingTimer timer (see Section 4.7). 1189 Data Check to DTLS Teardown (n): This transition occurs when the WTP 1190 does not complete the Data Check exchange. 1192 WTP: This state transition occurs if the WTP does not receive the 1193 Change State Event Response message before a CAPWAP 1194 retransmission timeout occurs. The WTP also transitions to 1195 this state if the underlying reliable transport's 1196 RetransmitCount counter has reached the MaxRetransmit variable 1197 (see Section 4.7). The WTP starts the DTLSSessionDelete timer 1198 (see Section 4.7.6). 1200 AC: The AC enters this state when the DataCheckTimer timer 1201 expires (see Section 4.7). The AC starts the DTLSSessionDelete 1202 timer (see Section 4.7.6). 1204 Data Check to Run (o): This state transition occurs when the linkage 1205 between the control and data channels is established, causing the 1206 WTP and AC to enter their normal state of operation. 1208 WTP: The WTP enters this state when it receives a successful 1209 Change State Event Response message from the AC. The WTP 1210 initiates the data channel, which MAY require the establishment 1211 of a DTLS session, starts the DataChannelKeepAlive timer (see 1212 Section 4.7.2) and transmits a Data Channel Keep Alive packet 1213 (see Section 4.4.1). The WTP then starts the EchoInterval 1214 timer and DataChannelDeadInterval timer (see Section 4.7). 1216 AC: This state transition occurs when the AC receives the Data 1217 Channel Keep Alive packet (see Section 4.4.1), with a Session 1218 ID message element matching that included by the WTP in the 1219 Join Request message. The AC disables the DataCheckTimer 1220 timer. Note that if AC policy is to require the data channel 1221 to be encrypted, this process would also require the 1222 establishment of a data channel DTLS session. Upon receiving 1223 the Data Channel Keep Alive packet, the AC transmits its own 1224 Data Channel Keep Alive packet. 1226 Run to DTLS Teardown (p): This state transition occurs when an error 1227 has occurred in the DTLS stack, causing the DTLS session to be 1228 torn down. 1230 WTP: The WTP enters this state when it receives one of the 1231 following DTLS notifications: DTLSAborted, 1232 DTLSReassemblyFailure or DTLSPeerDisconnect (see 1233 Section 2.3.2.2). The WTP MAY tear down the DTLS session if it 1234 receives frequent DTLSDecapFailure notifications. The WTP also 1235 transitions to this state if the underlying reliable 1236 transport's RetransmitCount counter has reached the 1237 MaxRetransmit variable (see Section 4.7). The WTP starts the 1238 DTLSSessionDelete timer (see Section 4.7.6). 1240 AC: The AC enters this state when it receives one of the 1241 following DTLS notifications: DTLSAborted, 1242 DTLSReassemblyFailure or DTLSPeerDisconnect (see 1243 Section 2.3.2.2). The AC MAY tear down the DTLS session if it 1244 receives frequent DTLSDecapFailure notifications. The AC 1245 transitions to this state if the underlying reliable 1246 transport's RetransmitCount counter has reached the 1247 MaxRetransmit variable (see Section 4.7). This state 1248 transition also occurs when the AC's EchoInterval timer (see 1249 Section 4.7.7) expires. The AC starts the DTLSSessionDelete 1250 timer (see Section 4.7.6). 1252 Run to Run (q): This is the normal state of operation. 1254 WTP: This is the WTP's normal state of operation. The WTP resets 1255 its EchoInterval timer whenever it transmits a request to the 1256 AC. There are many events that result this state transition: 1258 Configuration Update: The WTP receives a Configuration Update 1259 Request message(see Section 8.4). The WTP MUST respond with 1260 a Configuration Update Response message (see Section 8.5). 1262 Change State Event: The WTP receives a Change State Event 1263 Response message, or determines that it must initiate a 1264 Change State Event Request message, as a result of a failure 1265 or change in the state of a radio. 1267 Echo Request: The WTP sends an Echo Request message 1268 (Section 7.1) or receives the corresponding Echo Response 1269 message, (see Section 7.2) from the AC. When the WTP 1270 receives the Echo Response, it resets its EchoInterval timer 1271 (see Section 4.7.7). 1273 Clear Config Request: The WTP receives a Clear Configuration 1274 Request message (see Section 8.8) and MUST generate a 1275 corresponding Clear Configuration Response message (see 1276 Section 8.9). The WTP MUST reset its configuration back to 1277 manufacturer defaults. 1279 WTP Event: The WTP sends a WTP Event Request message, 1280 delivering information to the AC (see Section 9.4). The WTP 1281 receives a WTP Event Response message from the AC (see 1282 Section 9.5). 1284 Data Transfer: The WTP sends a Data Transfer Request or Data 1285 Transfer Response message to the AC (see Section 9.6). The 1286 WTP receives a Data Transfer Request or Data Transfer 1287 Response message from the AC (see Section 9.6). Upon 1288 receipt of a Data Transfer Request, the WTP transmits a Data 1289 Transfer Response to the AC. 1291 Station Configuration Request: The WTP receives a Station 1292 Configuration Request message (see Section 10.1), to which 1293 it MUST respond with a Station Configuration Response 1294 message (see Section 10.2). 1296 AC: This is the AC's normal state of operation. Note that the 1297 receipt of any Request from the WTP causes the AC to reset its 1298 EchoInterval timer (see Section 4.7.7). 1300 Configuration Update: The AC sends a Configuration Update 1301 Request message (see Section 8.4) to the WTP to update its 1302 configuration. The AC receives a Configuration Update 1303 Response message (see Section 8.5) from the WTP. 1305 Change State Event: The AC receives a Change State Event 1306 Request message (see Section 8.6), to which it MUST respond 1307 with the Change State Event Response message (see 1308 Section 8.7). 1310 Echo Request: The AC receives an Echo Request message (see 1311 Section 7.1), to which it MUST respond with an Echo Response 1312 message(see Section 7.2). 1314 Clear Config Response: The AC sends a Clear Configuration 1315 Request message (see Section 8.8) to the WTP to clear its 1316 configuration. The AC receives a Clear Configuration 1317 Response message from the WTP (see Section 8.9). 1319 WTP Event: The AC receives a WTP Event Request message from 1320 the WTP (see Section 9.4) and MUST generate a corresponding 1321 WTP Event Response message (see Section 9.5). 1323 Data Transfer: The AC sends a Data Transfer Request or Data 1324 Transfer Response message to the WTP (see Section 9.6). The 1325 AC receives a Data Transfer Request or Data Transfer 1326 Response message from the WTP (see Section 9.6). Upon 1327 receipt of a Data Transfer Request, the AC transmits a Data 1328 Transfer Response to the WTP. 1330 Station Configuration Request: The AC sends a Station 1331 Configuration Request message (see Section 10.1) or receives 1332 the corresponding Station Configuration Response message 1333 (see Section 10.2) from the WTP. 1335 Run to Reset (r): This state transition is used when either the AC 1336 or WTP tear down the connection. This may occur as part of normal 1337 operation, or due to error conditions. 1339 WTP: The WTP enters the Reset state when it receives a Reset 1340 Request message from the AC. 1342 AC: The AC enters the Reset state when it transmits a Reset 1343 Request message to the WTP. 1345 Reset to DTLS Teardown (s): This transition occurs when the CAPWAP 1346 reset is complete, to terminate the DTLS session. 1348 WTP: This state transition occurs when the WTP transmits a Reset 1349 Response message. The WTP does not invoke the DTLSShutdown 1350 command (see Section 2.3.2.1). The WTP starts the 1351 DTLSSessionDelete timer (see Section 4.7.6). 1353 AC: This state transition occurs when the AC receives a Reset 1354 Response message. This causes the AC to initiate the 1355 DTLSShutdown command (see Section 2.3.2.1). The AC starts the 1356 DTLSSessionDelete timer (see Section 4.7.6). 1358 DTLS Teardown to Idle (t): This transition occurs when the DTLS 1359 session has been shutdown. 1361 WTP: This state transition occurs when the WTP has successfully 1362 cleaned up all resources associated with the control plane DTLS 1363 session, or if the DTLSSessionDelete timer (see Section 4.7.6) 1364 expires. The data plane DTLS session is also shutdown, and all 1365 resources released, if a DTLS session was established for the 1366 data plane. Any timers set for the current instance of the 1367 state machine are also cleared. 1369 AC: This is an invalid state transition for the AC. 1371 DTLS Teardown to Sulking (u): This transition occurs when repeated 1372 attempts to setup the DTLS connection have failed. 1374 WTP: The WTP enters this state when the FailedDTLSSessionCount or 1375 the FailedDTLSAuthFailCount counter reaches the value of the 1376 MaxFailedDTLSSessionRetry variable (see Section 4.8). Upon 1377 entering this state, the WTP MUST start the SilentInterval 1378 timer. While in the Sulking state, all received CAPWAP and 1379 DTLS protocol messages received MUST be ignored. 1381 AC: This is an invalid state transition for the AC. 1383 DTLS Teardown to Dead (w): This transition occurs when the DTLS 1384 session has been shutdown. 1386 WTP: This is an invalid state transition for the WTP. 1388 AC: This state transition occurs when the AC has successfully 1389 cleaned up all resources associated with the control plane DTLS 1390 session , or if the DTLSSessionDelete timer (see Section 4.7.6) 1391 expires. The data plane DTLS session is also shutdown, and all 1392 resources released, if a DTLS session was established for the 1393 data plane. Any timers set for the current instance of the 1394 state machine are also cleared. The AC's Service thread is 1395 terminated. 1397 2.3.2. CAPWAP/DTLS Interface 1399 This section describes the DTLS Commands used by CAPWAP, and the 1400 notifications received from DTLS to the CAPWAP protocol stack. 1402 2.3.2.1. CAPWAP to DTLS Commands 1404 Six commands are defined for the CAPWAP to DTLS API. These 1405 "commands" are conceptual, and may be implemented as one or more 1406 function calls. This API definition is provided to clarify 1407 interactions between the DTLS and CAPWAP components of the integrated 1408 CAPWAP state machine. 1410 Below is a list of the minimal command API: 1412 o DTLSStart is sent to the DTLS component to cause a DTLS session to 1413 be established. Upon invoking the DTLSStart command, the WaitDTLS 1414 timer is started. The WTP initiates this DTLS command, as the AC 1415 does not initiate DTLS sessions. 1417 o DTLSListen is sent to the DTLS component to allow the DTLS 1418 component to listen for incoming DTLS session requests. 1420 o DTLSAccept is sent to the DTLS component to allow the DTLS session 1421 establishment to continue successfully. 1423 o DTLSAbortSession is sent to the DTLS component to cause the 1424 session that is in the process of being established to be aborted. 1425 This command is also sent when the WaitDTLS timer expires. When 1426 this command is executed, the FailedDTLSSessionCount counter is 1427 incremented. 1429 o DTLSShutdown is sent to the DTLS component to cause session 1430 teardown. 1432 o DTLSMtuUpdate is sent by the CAPWAP component to modify the MTU 1433 size used by the DTLS component. See Section 3.5 for more 1434 information on MTU Discovery. The default size is 1468 bytes. 1436 2.3.2.2. DTLS to CAPWAP Notifications 1438 DTLS notifications are defined for the DTLS to CAPWAP API. These 1439 "notifications" are conceptual, and may be implemented in numerous 1440 ways (e.g. as function return values). This API definition is 1441 provided to clarify interactions between the DTLS and CAPWAP 1442 components of the integrated CAPWAP state machine. It is important 1443 to note that the notifications listed below MAY cause the CAPWAP 1444 state machine to jump from one state to another using a state 1445 transition not listed in Section 2.3.1. When a notification listed 1446 below occurs, the target CAPWAP state shown in Figure 4 becomes the 1447 current state. 1449 Below is a list of the API notifications: 1451 o DTLSPeerAuthorize is sent to the CAPWAP component during DTLS 1452 session establishment once the peer's identity has been received. 1453 This notification MAY be used by the CAPWAP component to authorize 1454 the session, based on the peer's identity. The authorization 1455 process will lead to the CAPWAP component initiating either the 1456 DTLSAccept or DTLSAbortSession commands. 1458 o DTLSEstablished is sent to the CAPWAP component to indicate that 1459 that a secure channel now exists, using the parameters provided 1460 during the DTLS initialization process. When this notification is 1461 received, the FailedDTLSSessionCount counter is reset to zero. 1462 When this notification is received, the WaitDTLS timer is stopped. 1464 o DTLSEstablishFail is sent when the DTLS session establishment has 1465 failed, either due to a local error, or due to the peer rejecting 1466 the session establishment. When this notification is received, 1467 the FailedDTLSSessionCount counter is incremented. 1469 o DTLSAuthenticateFail is sent when DTLS session establishment 1470 failed due to an authentication error. When this notification is 1471 received, the FailedDTLSAuthFailCount counter is incremented. 1473 o DTLSAborted is sent to the CAPWAP component to indicate that 1474 session abort (as requested by CAPWAP) is complete; this occurs to 1475 confirm a DTLS session abort, or when the WaitDTLS timer expires. 1476 When this notification is received, the WaitDTLS timer is stopped. 1478 o DTLSReassemblyFailure MAY be sent to the CAPWAP component to 1479 indicate DTLS fragment reassembly failure. 1481 o DTLSDecapFailure MAY be sent to the CAPWAP module to indicate a 1482 decapsulation failure. DTLSDecapFailure MAY be sent to the CAPWAP 1483 module to indicate an encryption/authentication failure. This 1484 notification is intended for informative purposes only, and is not 1485 intended to cause a change in the CAPWAP state machine (see 1486 Section 12.4). 1488 o DTLSPeerDisconnect is sent to the CAPWAP component to indicate the 1489 DTLS session has been torn down. Note that this notification is 1490 only received if the DTLS session has been established. 1492 2.4. Use of DTLS in the CAPWAP Protocol 1494 DTLS is used as a tightly-integrated, secure wrapper for the CAPWAP 1495 protocol. In this document DTLS and CAPWAP are discussed as 1496 nominally distinct entities; however they are very closely coupled, 1497 and may even be implemented inseparably. Since there are DTLS 1498 library implementations currently available, and since security 1499 protocols (e.g. IPsec, TLS) are often implemented in widely 1500 available acceleration hardware, it is both convenient and forward- 1501 looking to maintain a modular distinction in this document. 1503 This section describes a detailed walk-through of the interactions 1504 between the DTLS module and the CAPWAP module, via 'commands' (CAPWAP 1505 to DTLS) and 'notifications' (DTLS to CAPWAP) as they would be 1506 encountered during the normal course of operation. 1508 2.4.1. DTLS Handshake Processing 1510 Details of the DTLS handshake process are specified in [RFC4347]. 1511 This section describes the interactions between the DTLS session 1512 establishment process and the CAPWAP protocol. Note that the 1513 conceptual DTLS state is shown below to help understand the point at 1514 which the DTLS states transition. In the normal case, the DTLS 1515 handshake will proceed as shown in Figure 5. (NOTE: this example 1516 uses certificates, but preshared keys are also supported): 1518 ============ ============ 1519 WTP AC 1520 ============ ============ 1521 ClientHello ------> 1522 <------ HelloVerifyRequest 1523 (with cookie) 1525 ClientHello ------> 1526 (with cookie) 1527 <------ ServerHello 1528 <------ Certificate 1529 <------ ServerHelloDone 1531 (WTP callout for AC authorization 1532 occurs in CAPWAP Auth state) 1534 Certificate* 1535 ClientKeyExchange 1536 CertificateVerify* 1537 ChangeCipherSpec 1538 Finished ------> 1540 (AC callout for WTP authorization 1541 occurs in CAPWAP Auth state) 1543 ChangeCipherSpec 1544 <------ Finished 1546 Figure 5: DTLS Handshake 1548 DTLS, as specified, provides its own retransmit timers with an 1549 exponential back-off. [RFC4347] does not specify how long 1550 retransmissions should continue. Consequently, timing out incomplete 1551 DTLS handshakes is entirely the responsibility of the CAPWAP module. 1553 The DTLS implementation used by CAPWAP MUST support TLS Session 1554 Resumption. Session resumption is typically used to establish the 1555 DTLS session used for the data channel. Since the data channel uses 1556 different port numbers than the control channel, the DTLS 1557 implementation on the WTP MUST provide an interface that allows the 1558 CAPWAP module to request session resumption despite the use of the 1559 different port numbers (TLS implementations usually attempt session 1560 resumption only when connecting to the same IP address and port 1561 number). Note that session resumption is not guaranteed to occur, 1562 and a full DTLS handshake may occur instead. 1564 The DTLS implementation used by CAPWAP MUST use replay detection, per 1565 Section 3.3 of [RFC4347]. Since the CAPWAP protocol handles 1566 retransmissions by re-encrypting lost frames, any duplicate DTLS 1567 frames are either unintentional or malicious, and should be silently 1568 discarded. 1570 2.4.2. DTLS Session Establishment 1572 The WTP, either through the Discovery process, or through pre- 1573 configuration, determines the AC to connect to. The WTP uses the 1574 DTLSStart command to request that a secure connection be established 1575 to the selected AC. Prior to initiation of the DTLS handshake, the 1576 WTP sets the WaitDTLS timer. Upon invoking the DTLSStart or 1577 DTLSListen commands, the WTP and AC, respectively, set the WaitDTLS 1578 timer. If the DTLSEstablished notification is not received prior to 1579 timer expiration, the DTLS session is aborted by issuing the 1580 DTLSAbortSession DTLS command. This notification causes the CAPWAP 1581 module to transition to the Idle state. Upon receiving a 1582 DTLSEstablished notification, the WaitDTLS timer is deactivated. 1584 2.4.3. DTLS Error Handling 1586 If the AC or WTP does not respond to any DTLS handshake messages sent 1587 by its peer, the DTLS specification calls for the message to be 1588 retransmited. Note that during the handshake, when both the AC and 1589 the WTP are expecting additional handshake messages, they both 1590 retransmit if an expected message has not been received (note that 1591 retransmissions for CAPWAP Control messages work differently: all 1592 CAPWAP Control messages are either requests or responses, and the 1593 peer who sent the request is responsible for retransmissions). 1595 If the WTP or the AC does not receive an expected DTLS handshake 1596 message despite of retransmissions, the WaitDTLS timer will 1597 eventually expire, and the session will be terminated. This can 1598 happen if communication between the peers has completely failed, or 1599 if one of the peers sent a DTLS Alert message which was lost in 1600 transit (DTLS does not retransmit Alert messages). 1602 If a cookie fails to validate, this could represent a WTP error, or 1603 it could represent a DoS attack. Hence, AC resource utilization 1604 SHOULD be minimized. The AC MAY log a message indicating the 1605 failure, and SHOULD treat the message as though no cookie were 1606 present. 1608 Since DTLS handshake messages are potentially larger than the maximum 1609 record size, DTLS supports fragmenting of handshake messages across 1610 multiple records. There are several potential causes of re-assembly 1611 errors, including overlapping and/or lost fragments. The DTLS 1612 component MUST send a DTLSReassemblyFailure notification to the 1613 CAPWAP component. Whether precise information is given along with 1614 notification is an implementation issue, and hence is beyond the 1615 scope of this document. Upon receipt of such an error, the CAPWAP 1616 component SHOULD log an appropriate error message. Whether 1617 processing continues or the DTLS session is terminated is 1618 implementation dependent. 1620 DTLS decapsulation errors consist of three types: decryption errors, 1621 authentication errors, and malformed DTLS record headers. Since DTLS 1622 authenticates the data prior to encapsulation, if decryption fails, 1623 it is difficult to detect this without first attempting to 1624 authenticate the packet. If authentication fails, a decryption error 1625 is also likely, but not guaranteed. Rather than attempt to derive 1626 (and require the implementation of) algorithms for detecting 1627 decryption failures, decryption failures are reported as 1628 authentication failures. The DTLS component MUST provide a 1629 DTLSDecapFailure notification to the CAPWAP component when such 1630 errors occur. If a malformed DTLS record header is detected, the 1631 packets SHOULD be silently discarded, and the receiver MAY log an 1632 error message. 1634 There is currently only one encapsulation error defined: MTU 1635 exceeded. As part of DTLS session establishment, the CAPWAP 1636 component informs the DTLS component of the MTU size. This may be 1637 dynamically modified at any time when the CAPWAP component sends the 1638 DTLSMtuUpdate command to the DTLS component (see Section 2.3.2.1). 1639 The value provided to the DTLS stack is the result of the MTU 1640 Discovery process, which is described in Section 3.5. The DTLS 1641 component returns this notification to the CAPWAP component whenever 1642 a transmission request will result in a packet which exceeds the MTU. 1644 2.4.4. DTLS EndPoint Authentication and Authorization 1646 DTLS supports endpoint authentication with certificates or preshared 1647 keys. The TLS algorithm suites for each endpoint authentication 1648 method are described below. 1650 2.4.4.1. Authenticating with Certificates 1652 CAPWAP implementations only use cipher suites that are recommended 1653 for use with DTLS, see [DTLS-DESIGN]. At present, the following 1654 algorithms MUST be supported when using certificates for CAPWAP 1655 authentication: 1657 o TLS_RSA_WITH_AES_128_CBC_SHA [RFC4346] 1659 The following algorithms SHOULD be supported when using certificates: 1661 o TLS_DHE_RSA_WITH_AES_128_CBC_SHA [RFC4346] 1663 The following algorithms MAY be supported when using certificates: 1665 o TLS_RSA_WITH_AES_256_CBC_SHA [RFC4346] 1667 o TLS_DHE_RSA_WITH_AES_256_CBC_SHA [RFC4346] 1669 Additional ciphers MAY be defined in follow on CAPWAP specifications. 1671 2.4.4.2. Authenticating with Preshared Keys 1673 Pre-shared keys present significant challenges from a security 1674 perspective, and for that reason, their use is strongly discouraged. 1675 Several methods for authenticating with preshared keys are defined 1676 [RFC4279], and we focus on the following two: 1678 o Pre-Shared Key (PSK) key exchange algorithm - simplest method, 1679 ciphersuites use only symmetric key algorithms 1681 o DHE_PSK key exchange algorithm - use a PSK to authenticate a 1682 Diffie-Hellman exchange. These ciphersuites give some additional 1683 protection against dictionary attacks and also provide Perfect 1684 Forward Secrecy (PFS). 1686 The first approach (plain PSK) is susceptible to passive dictionary 1687 attacks; hence, while this algorithm MUST be supported, special care 1688 should be taken when choosing that method. In particular, user- 1689 readable passphrases SHOULD NOT be used, and use of short PSKs SHOULD 1690 be strongly discouraged. 1692 The following cryptographic algorithms MUST be supported when using 1693 preshared keys: 1695 o TLS_PSK_WITH_AES_128_CBC_SHA [RFC4346] 1697 o TLS_DHE_PSK_WITH_AES_128_CBC_SHA [RFC4346] 1699 The following algorithms MAY be supported when using preshared keys: 1701 o TLS_PSK_WITH_AES_256_CBC_SHA [RFC4346] 1703 o TLS_DHE_PSK_WITH_AES_256_CBC_SHA [RFC4346] 1705 Additional ciphers MAY be defined in follow on CAPWAP specifications. 1707 2.4.4.3. Certificate Usage 1709 Certificate authorization by the AC and WTP is required so that only 1710 an AC may perform the functions of an AC and that only a WTP may 1711 perform the functions of a WTP. This restriction of functions to the 1712 AC or WTP requires that the certificates used by the AC MUST be 1713 distinguishable from the certificate used by the WTP. To accomplish 1714 this differentiation, the x.509 certificates MUST include the 1715 Extended Key Usage (EKU) certificate extension [RFC5280]. 1717 The EKU field indicates one or more purposes for which a certificate 1718 may be used. It is an essential part in authorization. Its syntax 1719 is described in [RFC5280] and [ISO.9834-1.1993] and is as follows: 1721 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 1723 KeyPurposeId ::= OBJECT IDENTIFIER 1725 Here we define two KeyPurposeId values, one for the WTP and one for 1726 the AC. Inclusion of one of these two values indicates a certificate 1727 is authorized for use by a WTP or AC, respectively. These values are 1728 formatted as id-kp fields. 1730 id-kp OBJECT IDENTIFIER ::= 1731 { iso(1) identified-organization(3) dod(6) internet(1) 1732 security(5) mechanisms(5) pkix(7) 3 } 1734 id-kp-capwapAC OBJECT IDENTIFIER ::= { id-kp 18 } 1736 id-kp-capwapWTP OBJECT IDENTIFIER ::= { id-kp 19 } 1738 All capwap devices MUST support the ExtendedKeyUsage certificate 1739 extension if it is present in a certificate. If the extension is 1740 present, then the certificate MUST have either the id-kp-capwapAC or 1741 the id-kp-anyExtendedKeyUsage keyPurposeID to act as an AC. 1742 Similarly, if the extension is present, a device MUST have the id-kp- 1743 capwapWTP or id-kp-anyExtendedKeyUsage keyPurposeID to act as a WTP. 1745 Part of the CAPWAP certificate validation process includes ensuring 1746 that the proper EKU is included and allowing the CAPWAP session to be 1747 established only if the extension properly represents the device. 1748 For instance, an AC SHOULD NOT accept a connection request from 1749 another AC, and therefore MUST verify that the id-kp-capwapWTP EKU is 1750 present in the certificate. 1752 CAPWAP implementations MUST support certificates where the common 1753 name (CN) for both the WTP and AC is the MAC address of that device. 1755 The MAC address MUST be encoded in the PrintableString format, using 1756 the well recognized MAC address format of 01:23:45:67:89:ab. The CN 1757 field MAY contain either of the EUI-48 [EUI-48] or EUI-64 [EUI-64] 1758 MAC Address formats. This seemingly unconventional use of the CN 1759 field is consistent with other standards that rely on device 1760 certificates that are provisioned during the manufacturing process, 1761 such as Packet Cable [PacketCable], Cable Labs [CableLabs] and WiMAX 1762 [WiMAX]. See Section 12.8 for more information on the use of the MAC 1763 Address in the CN field. 1765 ACs and WTPs MUST authorize (e.g. through access control lists) 1766 certificates of devices to which they are connecting, e.g., based on 1767 the issuer, MAC address, or organizational information specified in 1768 the certificate. The identities specified in the certificates bind a 1769 particular DTLS session to a specific pair of mutually-authenticated 1770 and authorized MAC addresses. The particulars of authorization 1771 filter construction are implementation details which are, for the 1772 most part, not within the scope of this specification. However, at 1773 minimum, all devices MUST verify that the appropriate EKU bit is set 1774 according to the role of the peer device (AC vs. WTP), and that the 1775 issuer of the certificate is appropriate for the domain in question. 1777 2.4.4.4. PSK Usage 1779 When DTLS uses PSK Ciphersuites, the ServerKeyExchange message MUST 1780 contain the "PSK identity hint" field and the ClientKeyExchange 1781 message MUST contain the "PSK identity" field. These fields are used 1782 to help the WTP select the appropriate PSK for use with the AC, and 1783 then indicate to the AC which key is being used. When PSKs are 1784 provisioned to WTPs and ACs, both the PSK Hint and PSK Identity for 1785 the key MUST be specified. 1787 The PSK Hint SHOULD uniquely identify the AC and the PSK Identity 1788 SHOULD uniquely identify the WTP. It is RECOMMENDED that these hints 1789 and identities be the ASCII HEX-formatted MAC addresses of the 1790 respective devices, since each pairwise combination of WTP and AC 1791 SHOULD have a unique PSK. The PSK hint and identity SHOULD be 1792 sufficient to perform authorization, as simply having knowledge of a 1793 PSK does not necessarily imply authorization. 1795 If a single PSK is being used for multiple devices on a CAPWAP 1796 network, which is NOT RECOMMENDED, the PSK Hint and Identity can no 1797 longer be a MAC address, so appropriate hints and identities SHOULD 1798 be selected to identify the group of devices to which the PSK is 1799 provisioned. 1801 3. CAPWAP Transport 1803 Communication between a WTP and an AC is established using the 1804 standard UDP client/server model. The CAPWAP protocol supports both 1805 UDP and UDP-Lite [RFC3828] transport protocols. When run over IPv4, 1806 UDP is used for the CAPWAP control and data channels. 1808 When run over IPv6, the CAPWAP control channel always uses UDP, while 1809 the CAPWAP data channel may use either UDP or UDP-Lite. UDP-Lite is 1810 the default transport protocol for the CAPWAP data channel. However, 1811 if a middlebox or IPv4 to IPv6 gateway has been discovered, UDP is 1812 used for the CAPWAP data channel. 1814 This section describes how the CAPWAP protocol is carried over IP and 1815 UDP/UDP-Lite transport protocols. The CAPWAP Transport Protocol 1816 message element Section 4.6.14 describes the rules to use in 1817 determining which transport protocol is to be used. 1819 In order for CAPWAP to be compatible with potential middleboxes in 1820 the network, CAPWAP implementations MUST send return traffic from the 1821 same port on which it received traffic from a given peer. Further, 1822 any unsolicited requests generated by a CAPWAP node MUST be sent on 1823 the same port. 1825 3.1. UDP Transport 1827 One of the CAPWAP protocol requirements is to allow a WTP to reside 1828 behind a middlebox, firewall and/or Network Address Translation (NAT) 1829 device. Since a CAPWAP session is initiated by the WTP (client) to 1830 the well-known UDP port of the AC (server), the use of UDP is a 1831 logical choice. When CAPWAP is run over IPv4, the UDP checksum field 1832 in CAPWAP packets MUST be set to zero. 1834 CAPWAP protocol control packets sent from the WTP to the AC use the 1835 CAPWAP control channel, as defined in Section 1.4. The CAPWAP 1836 control port at the AC is the well known UDP port 5246. The CAPWAP 1837 control port at the WTP can be any port selected by the WTP. 1839 CAPWAP protocol data packets sent from the WTP to the AC use the 1840 CAPWAP data channel, as defined in Section 1.4. The CAPWAP data port 1841 at the AC is the well known UDP port 5247. If an AC permits the 1842 administrator to change the CAPWAP control port, the CAPWAP data port 1843 MUST be the next consecutive port number. The CAPWAP data port at 1844 the WTP can be any port selected by the WTP. 1846 3.2. UDP-Lite Transport 1848 When CAPWAP is run over IPv6, UDP-Lite is the default transport 1849 protocol, which reduces the checksum processing required for each 1850 packet (compared to the use of UDP over IPv6 [RFC2460]). When UDP- 1851 Lite is used, the checksum field MUST have a coverage of 8 [RFC3828]. 1853 UDP-Lite uses the same port assignments as UDP. 1855 3.3. AC Discovery 1857 The AC discovery phase allows the WTP to determine which ACs are 1858 available, and chose the best AC with which to establish a CAPWAP 1859 session. The discovery phase occurs when the WTP enters the optional 1860 Discovery state. A WTP does not need to complete the AC Discovery 1861 phase if it uses a pre-configured AC. This section details the 1862 mechanism used by a WTP to dynamically discover candidate ACs. 1864 A WTP and an AC will frequently not reside in the same IP subnet 1865 (broadcast domain). When this occurs, the WTP must be capable of 1866 discovering the AC, without requiring that multicast services are 1867 enabled in the network. 1869 When the WTP attempts to establish communication with an AC, it sends 1870 the Discovery Request message and receives the Discovery Response 1871 message from the AC(s). The WTP MUST send the Discovery Request 1872 message to either the limited broadcast IP address (255.255.255.255), 1873 the well known CAPWAP multicast address (xx.xx.xx.xx) or to the 1874 unicast IP address of the AC. For IPv6 networks, since broadcast 1875 does not exist, the use of "All ACs multicast address" is used 1876 instead. Upon receipt of the Discovery Request message, the AC sends 1877 a Discovery Response message to the unicast IP address of the WTP, 1878 regardless of whether the Discovery Request message was sent as a 1879 broadcast, multicast or unicast message. 1881 WTP use of a limited IP broadcast, multicast or unicast IP address is 1882 implementation dependent. ACs, on the other hand, MUST support 1883 broadcast, multicast and unicast discovery. 1885 When a WTP transmits a Discovery Request message to a unicast 1886 address, the WTP must first obtain the IP address of the AC. Any 1887 static configuration of an AC's IP address on the WTP non-volatile 1888 storage is implementation dependent. However, additional dynamic 1889 schemes are possible, for example: 1891 DHCP: See [I-D.ietf-capwap-dhc-ac-option] for more information on 1892 the use of DHCP to discover AC IP addresses. 1894 DNS: The WTP MAY support use of DNS SRV records [RFC2782] to 1895 discover the AC address(es). In this case, the WTP first obtains 1896 (e.g., from local configuration) the correct domain name suffix 1897 (e.g., "example.com") and performs a SRV lookup with Service name 1898 "capwap-control" and Proto "udp". Thus, the name resolved in DNS 1899 would be, e.g., "_capwap-control._udp.example.com". Note that the 1900 SRV record MAY specify a non-default port number for the control 1901 channel; the port number for the data channel is the next port 1902 number (control channel port + 1). 1904 An AC MAY also communicate alternative ACs to the WTP within the 1905 Discovery Response message through the AC IPv4 List (see 1906 Section 4.6.2) and AC IPv6 List (see Section 4.6.2). The addresses 1907 provided in these two message elements are intended to help the WTP 1908 discover additional ACs through means other than those listed above. 1910 The AC Name with Priority message element (see Section 4.6.5), is 1911 used to communicate a list of preferred ACs to the WTP. The WTP 1912 SHOULD attempt to utilize the ACs listed in the order provided by the 1913 AC. The Name to IP Address mapping is handled via the Discovery 1914 message exchange, in which the ACs provide their identity in the AC 1915 Name (see Section 4.6.4) message element in the Discovery Response 1916 message. 1918 Once the WTP has received Discovery Response messages from the 1919 candidate ACs, it MAY use other factors to determine the preferred 1920 AC. For instance, each binding defines a WTP Radio Information 1921 message element (see Section 2.1), which the AC includes in Discovery 1922 Response messages. The presence of one or more of these message 1923 elements is used to identify the CAPWAP bindings supported by the AC. 1924 A WTP MAY connect to an AC based on the supported bindings 1925 advertised. 1927 3.4. Fragmentation/Reassembly 1929 While fragmentation and reassembly services are provided by IP, the 1930 CAPWAP protocol also provides such services. Environments where the 1931 CAPWAP protocol is used involve firewall, NAT and "middle box" 1932 devices, which tend to drop IP fragments to minimize possible DoS 1933 attacks. By providing fragmentation and reassembly at the 1934 application layer, any fragmentation required due to the tunneling 1935 component of the CAPWAP protocol becomes transparent to these 1936 intermediate devices. Consequently, the CAPWAP protocol can be used 1937 in any network topology including firewall, NAT and middlebox 1938 devices. 1940 It is important to note that the fragmentation mechanism employed by 1941 CAPWAP has known limitations and deficiencies, which are similar to 1942 those described in [RFC4963]. The limited size of the Fragment ID 1943 field (see Section 4.3 can cause wrapping of the field, and hence 1944 cause fragments from different datagrams to be incorrectly spliced 1945 together (known as "mis-associated"). For example, a 100Mpbs link 1946 with an MTU of 1500 (causing fragmentation at 1450 bytes) would cause 1947 the Fragment ID field wrap in 8 seconds. Consequently, CAPWAP 1948 implementors are warned to properly size their buffers for reassembly 1949 purposes based on the expected wireless technology throughput. 1951 CAPWAP implementations SHOULD perform MTU Discovery (see 1952 Section 3.5), which can avoid the need for fragmentation. At the 1953 time of writing of this specification, most enterprise switching and 1954 routing infrastructure were capable of supporting "mini-jumbo" frames 1955 (1800 bytes), which eliminates the need for fragmentation (assuming 1956 the station's MTU is 1500 bytes). The need for fragmentation 1957 typically continues to exist when the WTP communicates with the AC 1958 over a Wide Area Network (WAN). Therefore, future versions of the 1959 CAPWAP protocol SHOULD either consider increasing the size of the 1960 Fragment ID field, or provide alternatives extensions. 1962 3.5. MTU Discovery 1964 Once a WTP has discovered the AC it wishes to establish a CAPWAP 1965 session with, it SHOULD perform a Path MTU (PMTU) discovery. One 1966 recommendation for performing PMTU discovery is to have the WTP 1967 transmit Discovery Request (see Section 5.1) messages, and include 1968 the MTU Discovery Padding message element (see Section 4.6.32). The 1969 actual procedures used for PMTU discovery are described in [RFC1191], 1970 for IPv4, or for IPv6 [RFC1981] SHOULD be used. Alternatively, 1971 implementers MAY use the procedures defined in [RFC4821]. The WTP 1972 SHOULD also periodically re-evaluate the PMTU using the guidelines 1973 provided in these two RFCs, using the Primary Discovery Request (see 1974 Section 5.3) along with the MTU Discovery Padding message element 1975 (see Section 4.6.32). When the MTU is initially known, or updated in 1976 the case where an existing session already exists, the discovered 1977 PMTU is used to configure the DTLS component (see Section 2.3.2.1), 1978 while non-DTLS frames need to be fragmented to fit the MTU, defined 1979 in Section 3.4. 1981 4. CAPWAP Packet Formats 1983 This section contains the CAPWAP protocol packet formats. A CAPWAP 1984 protocol packet consists of one or more CAPWAP Transport Layer packet 1985 headers followed by a CAPWAP message. The CAPWAP message can be 1986 either of type Control or Data, where Control packets carry 1987 signaling, and Data packets carry user payloads. The CAPWAP frame 1988 formats for CAPWAP Data packets, and for DTLS encapsulated CAPWAP 1989 Data and Control packets are defined below. 1991 The CAPWAP Control protocol includes two messages that are never 1992 protected by DTLS: the Discovery Request message and the Discovery 1993 Response message. These messages need to be in the clear to allow 1994 the CAPWAP protocol to properly identify and process them. The 1995 format of these packets are as follows: 1997 CAPWAP Control Packet (Discovery Request/Response): 1998 +-------------------------------------------+ 1999 | IP | UDP | CAPWAP | Control | Message | 2000 | Hdr | Hdr | Header | Header | Element(s) | 2001 +-------------------------------------------+ 2003 All other CAPWAP control protocol messages MUST be protected via the 2004 DTLS protocol, which ensures that the packets are both authenticated 2005 and encrypted. These packets include the CAPWAP DTLS Header, which 2006 is described in Section 4.2. The format of these packets is as 2007 follows: 2009 CAPWAP Control Packet (DTLS Security Required): 2010 +------------------------------------------------------------------+ 2011 | IP | UDP | CAPWAP | DTLS | CAPWAP | Control| Message | DTLS | 2012 | Hdr | Hdr | DTLS Hdr | Hdr | Header | Header | Element(s)| Trlr | 2013 +------------------------------------------------------------------+ 2014 \---------- authenticated -----------/ 2015 \------------- encrypted ------------/ 2017 The CAPWAP protocol allows optional protection of data packets, using 2018 DTLS. Use of data packet protection is determined by AC policy. 2019 When DTLS is utilized, the optional CAPWAP DTLS Header is present, 2020 which is described in Section 4.2. The format of CAPWAP data packets 2021 is shown below: 2023 CAPWAP Plain Text Data Packet : 2024 +-------------------------------+ 2025 | IP | UDP | CAPWAP | Wireless | 2026 | Hdr | Hdr | Header | Payload | 2027 +-------------------------------+ 2029 DTLS Secured CAPWAP Data Packet: 2030 +--------------------------------------------------------+ 2031 | IP | UDP | CAPWAP | DTLS | CAPWAP | Wireless | DTLS | 2032 | Hdr | Hdr | DTLS Hdr | Hdr | Hdr | Payload | Trlr | 2033 +--------------------------------------------------------+ 2034 \------ authenticated -----/ 2035 \------- encrypted --------/ 2037 UDP Header: All CAPWAP packets are encapsulated within either UDP, 2038 or UDP-Lite when used over IPv6. Section 3 defines the specific 2039 UDP or UDP-Lite usage. 2041 CAPWAP DTLS Header: All DTLS encrypted CAPWAP protocol packets are 2042 prefixed with the CAPWAP DTLS header (see Section 4.2). 2044 DTLS Header: The DTLS header provides authentication and encryption 2045 services to the CAPWAP payload it encapsulates. This protocol is 2046 defined in RFC 4347 [RFC4347]. 2048 CAPWAP Header: All CAPWAP protocol packets use a common header that 2049 immediately follows the CAPWAP preamble or DTLS header. The 2050 CAPWAP Header is defined in Section 4.3. 2052 Wireless Payload: A CAPWAP protocol packet that contains a wireless 2053 payload is a CAPWAP data packet. The CAPWAP protocol does not 2054 specify the format of the wireless payload, which is defined by 2055 the appropriate wireless standard. Additional information is in 2056 Section 4.4. 2058 Control Header: The CAPWAP protocol includes a signaling component, 2059 known as the CAPWAP control protocol. All CAPWAP control packets 2060 include a Control Header, which is defined in Section 4.5.1. 2061 CAPWAP data packets do not contain a Control Header field. 2063 Message Elements: A CAPWAP Control packet includes one or more 2064 message elements, which are found immediately following the 2065 Control Header. These message elements are in a Type/Length/value 2066 style header, defined in Section 4.6. 2068 A CAPWAP implementation MUST be capable of receiving a reassembled 2069 CAPWAP message of length 4096 bytes. A CAPWAP implementation MAY 2070 indicate that it supports a higher maximum message length, by 2071 including the Maximum Message Length message element, see 2072 Section 4.6.31 in the Join Request message or the Join Response 2073 message. 2075 4.1. CAPWAP Preamble 2077 The CAPWAP preamble is common to all CAPWAP transport headers and is 2078 used to identify the header type that immediately follows. The 2079 reason for this preamble is to avoid needing to perform byte 2080 comparisons in order to guess whether the frame is DTLS encrypted or 2081 not. It also provides an extensibility framework that can be used to 2082 support additional transport types. The format of the preamble is as 2083 follows: 2085 0 2086 0 1 2 3 4 5 6 7 2087 +-+-+-+-+-+-+-+-+ 2088 |Version| Type | 2089 +-+-+-+-+-+-+-+-+ 2091 Version: A 4 bit field which contains the version of CAPWAP used in 2092 this packet. The value for this specification is zero (0). 2094 Type: A 4 bit field which specifies the payload type that follows 2095 the UDP header. The following values are supported: 2097 0 - CAPWAP Header. The CAPWAP Header (see Section 4.3) 2098 immediately follows the UDP header. If the packet is received 2099 on the CAPWAP data channel, the CAPWAP stack MUST treat the 2100 packet as a clear text CAPWAP data packet. If received on the 2101 CAPWAP control channel, the CAPWAP stack MUST treat the packet 2102 as a clear text CAPWAP control packet. If the control packet 2103 is not a Discovery Request or Discovery Response packet, the 2104 packet MUST be dropped. 2106 1 - CAPWAP DTLS Header. The CAPWAP DTLS Header, and DTLS packet, 2107 immediately follows the UDP header (see Section 4.2). 2109 4.2. CAPWAP DTLS Header 2111 The CAPWAP DTLS Header is used to identify the packet as a DTLS 2112 encrypted packet. The first eight bits includes the common CAPWAP 2113 Preamble. The remaining 24 bits are padding to ensure 4 byte 2114 alignment, and MAY be used in a future version of the protocol. The 2115 DTLS packet [RFC4347] always immediately follows this header. The 2116 format of the CAPWAP DTLS Header is as follows: 2118 0 1 2 3 2119 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 2120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2121 |CAPWAP Preamble| Reserved | 2122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2124 CAPWAP Preamble: The CAPWAP Preamble is defined in Section 4.1. The 2125 CAPWAP Preamble's Payload Type field MUST be set to one (1). 2127 Reserved: The 24-bit field is reserved for future use. All 2128 implementations complying with this protocol MUST set to zero any 2129 bits that are reserved in the version of the protocol supported by 2130 that implementation. Receivers MUST ignore all bits not defined 2131 for the version of the protocol they support. 2133 4.3. CAPWAP Header 2135 All CAPWAP protocol messages are encapsulated using a common header 2136 format, regardless of the CAPWAP Control or CAPWAP Data transport 2137 used to carry the messages. However, certain flags are not 2138 applicable for a given transport. Refer to the specific transport 2139 section in order to determine which flags are valid. 2141 Note that the optional fields defined in this section MUST be present 2142 in the precise order shown below. 2144 0 1 2 3 2145 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 2146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2147 |CAPWAP Preamble| HLEN | RID | WBID |T|F|L|W|M|K|Flags| 2148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2149 | Fragment ID | Frag Offset |Rsvd | 2150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2151 | (optional) Radio MAC Address | 2152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2153 | (optional) Wireless Specific Information | 2154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2155 | Payload .... | 2156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2158 CAPWAP Preamble: The CAPWAP Preamble is defined in Section 4.1. The 2159 CAPWAP Preamble's Payload Type field MUST be set to zero (0). If 2160 the CAPWAP DTLS Header is present, the version number in both 2161 CAPWAP Preambles MUST match. The reason for this duplicate field 2162 is to avoid any possible tampering of the version field in the 2163 preamble which is not encrypted or authenticated. 2165 HLEN: A 5 bit field containing the length of the CAPWAP transport 2166 header in 4 byte words (Similar to IP header length). This length 2167 includes the optional headers. 2169 RID: A 5 bit field which contains the Radio ID number for this 2170 packet, whose value is between one (1) and 31. Given that MAC 2171 Addresses are not necessarily unique across physical radios in a 2172 WTP, the Radio Identifier (RID) field is used to indicate which 2173 physical radio the message is associated with. 2175 WBID: A 5 bit field which is the wireless binding identifier. The 2176 identifier will indicate the type of wireless packet associated 2177 with the radio. The following values are defined: 2179 0 - Reserved 2181 1 - IEEE 802.11 2183 2 - Reserved 2185 3 - EPCGlobal [EPCGlobal] 2187 T: The Type 'T' bit indicates the format of the frame being 2188 transported in the payload. When this bit is set to one (1), the 2189 payload has the native frame format indicated by the WBID field. 2190 When this bit is zero (0) the payload is an IEEE 802.3 frame. 2192 F: The Fragment 'F' bit indicates whether this packet is a fragment. 2193 When this bit is one (1), the packet is a fragment and MUST be 2194 combined with the other corresponding fragments to reassemble the 2195 complete information exchanged between the WTP and AC. 2197 L: The Last 'L' bit is valid only if the 'F' bit is set and indicates 2198 whether the packet contains the last fragment of a fragmented 2199 exchange between WTP and AC. When this bit is 1, the packet is 2200 the last fragment. When this bit is 0, the packet is not the last 2201 fragment. 2203 W: The Wireless 'W' bit is used to specify whether the optional 2204 Wireless Specific Information field is present in the header. A 2205 value of one (1) is used to represent the fact that the optional 2206 header is present. 2208 M: The M bit is used to indicate that the Radio MAC Address optional 2209 header is present. This is used to communicate the MAC address of 2210 the receiving radio. 2212 K: The 'Keep-alive' K bit indicates the packet is a Data Channel Keep 2213 Alive packet. This packet is used to map the data channel to the 2214 control channel for the specified Session ID and to maintain 2215 freshness of the data channel. The K bit MUST NOT be set for data 2216 packets containing user data. 2218 Flags: A set of reserved bits for future flags in the CAPWAP header. 2219 All implementations complying with this protocol MUST set to zero 2220 any bits that are reserved in the version of the protocol 2221 supported by that implementation. Receivers MUST ignore all bits 2222 not defined for the version of the protocol they support. 2224 Fragment ID: A 16 bit field whose value is assigned to each group of 2225 fragments making up a complete set. The fragment ID space is 2226 managed individually for each direction for every WTP/AC pair. 2227 The value of Fragment ID is incremented with each new set of 2228 fragments. The Fragment ID wraps to zero after the maximum value 2229 has been used to identify a set of fragments. 2231 Fragment Offset: A 13 bit field that indicates where in the payload 2232 this fragment belongs during re-assembly. This field is valid 2233 when the 'F' bit is set to 1. The fragment offset is measured in 2234 units of 8 octets (64 bits). The first fragment has offset zero. 2235 Note the CAPWAP protocol does not allow for overlapping fragments. 2237 Reserved: The 3-bit field is reserved for future use. All 2238 implementations complying with this protocol MUST set to zero any 2239 bits that are reserved in the version of the protocol supported by 2240 that implementation. Receivers MUST ignore all bits not defined 2241 for the version of the protocol they support. 2243 Radio MAC Address: This optional field contains the MAC address of 2244 the radio receiving the packet. Because the native wireless frame 2245 format to IEEE 802.3 format causes the MAC address of the WTP's 2246 radio to be lost, this field allows the address to be communicated 2247 to the AC. This field is only present if the 'M' bit is set. The 2248 HLEN field assumes 4 byte alignment, and this field MUST be padded 2249 with zeroes (0x00) if it is not 4 byte aligned. 2251 The field contains the basic format: 2253 0 1 2 3 2254 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 2255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2256 | Length | MAC Address 2257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2259 Length: The length of the MAC Address field. The following 2260 formats, and lengths, are supported [EUI-48] and [EUI-64]. 2262 MAC Address: The MAC Address of the receiving radio. 2264 Wireless Specific Information: This optional field contains 2265 technology specific information that may be used to carry per 2266 packet wireless information. This field is only present if the 2267 'W' bit is set. The WBID field in the CAPWAP header is used to 2268 identify the format of the wireless specific information optional 2269 field. The HLEN field assumes 4 byte alignment, and this field 2270 MUST be padded with zeroes (0x00) if it is not 4 byte aligned. 2272 The Wireless Specific Information field uses the following format: 2274 0 1 2 3 2275 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2277 | Length | Data... 2278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2280 Length: The 8 bit field contains the length of the data field, 2281 with a maximum size of 255. 2283 Data: Wireless specific information, defined by the wireless 2284 specific binding specified in the CAPWAP Header's WBID field. 2286 Payload: This field contains the header for a CAPWAP Data Message or 2287 CAPWAP Control Message, followed by the data contained in the 2288 message. 2290 4.4. CAPWAP Data Messages 2292 There are two different types of CAPWAP data packets, CAPWAP Data 2293 Channel Keep Alive packets and Data Payload packets. The first is 2294 used by the WTP to synchronize the control and data channels, and to 2295 maintain freshness of the data channel. The second is used to 2296 transmit user payloads between the AC and WTP. This section 2297 describes both types of CAPWAP data packet formats. 2299 Both CAPWAP data messages are transmitted on the CAPWAP data channel. 2301 4.4.1. CAPWAP Data Channel Keepalive 2303 The CAPWAP Data Channel Keep Alive packet is used to bind the CAPWAP 2304 control channel with the data channel, and to maintain freshness of 2305 the data channel, ensuring that the channel is still functioning. 2306 The CAPWAP Data Channel Keep Alive packet is transmitted by the WTP 2307 when the DataChannelKeepAlive timer expires (see Section 4.7.2). 2308 When the CAPWAP Data Channel Keep Alive packet is transmitted, the 2309 WTP sets the DataChannelDeadInterval timer. 2311 In the CAPWAP Data Channel Keep Alive packet, all of the fields in 2312 the CAPWAP header, except the HLEN field and the K bit, are set to 2313 zero upon transmission. Upon receiving a CAPWAP Data Channel Keep 2314 Alive packet, the AC transmits a CAPWAP Data Channel Keep Alive 2315 packet back to the WTP. The contents of the transmitted packet are 2316 identical to the contents of the received packet. 2318 Upon receiving a CAPWAP Data Channel Keep Alive packet, the WTP 2319 cancels the DataChannelDeadInterval timer and resets the 2320 DataChannelKeepAlive timer. The CAPWAP Data Channel Keep Alive 2321 packet is retransmitted by the WTP in the same manner as the CAPWAP 2322 control messages. If the DataChannelDeadInterval timer expires, the 2323 WTP tears down the control DTLS session, and the data DTLS session if 2324 one existed. 2326 The CAPWAP Data Channel Keep Alive packet contains the following 2327 payload immediately following the CAPWAP Header (see Section 4.3) 2329 0 1 2 3 2330 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2332 | Message Element Length | Message Element [0..N] ... 2333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2335 Message Element Length: The 16 bit Length field indicates the 2336 number of bytes following the CAPWAP Header, with a maximum size 2337 of 65535. 2339 Message Element[0..N]: The message element(s) carry the information 2340 pertinent to each of the CAPWAP Data Channel Keepalive message. 2341 The following message elements MUST be present in this CAPWAP 2342 message: 2344 Session ID, see Section 4.6.37 2346 4.4.2. Data Payload 2348 A CAPWAP protocol Data Payload packet encapsulates a forwarded 2349 wireless frame. The CAPWAP protocol defines two different modes of 2350 encapsulation; IEEE 802.3 and native wireless. IEEE 802.3 2351 encapsulation requires that for 802.11 frames, the 802.11 2352 *Integration* function be performed in the WTP. An IEEE 802.3 2353 encapsulated user payload frame has the following format: 2355 +------------------------------------------------------+ 2356 | IP Header | UDP Header | CAPWAP Header | 802.3 Frame | 2357 +------------------------------------------------------+ 2359 The CAPWAP protocol also defines the native wireless encapsulation 2360 mode. The format of the encapsulated CAPWAP data frame is subject to 2361 the rules defined by the specific wireless technology binding. Each 2362 wireless technology binding MUST contain a section entitled "Payload 2363 Encapsulation", which defines the format of the wireless payload that 2364 is encapsulated within CAPWAP Data packets. 2366 For 802.3 payload frames, the 802.3 frame is encapsulated (excluding 2367 the IEEE 802.3 Preamble, Start Frame Delimiter (SFD) and Frame Check 2368 Sequence (FCS) Fields). If the encapsulated frame would exceed the 2369 transport layer's MTU, the sender is responsible for fragmentation of 2370 the frame, as specified in Section 3.4. The CAPWAP protocol can 2371 support IEEE 802.3 frames whose length is defined in the IEEE 802.3as 2372 specification [FRAME-EXT]. 2374 4.4.3. Establishment of a DTLS Data Channel 2376 If the AC and WTP are configured to tunnel the data channel over 2377 DTLS, the proper DTLS session must be initiated. To avoid having to 2378 reauthenticate and reauthorize an AC and WTP, the DTLS data channel 2379 SHOULD be initiated using the TLS session resumption feature 2380 [RFC4346]. 2382 The AC DTLS implementation MUST NOT initiate a data channel session 2383 for a DTLS session for which there is no active control channel 2384 session. 2386 4.5. CAPWAP Control Messages 2388 The CAPWAP Control protocol provides a control channel between the 2389 WTP and the AC. Control messages are divided into the following 2390 message types: 2392 Discovery: CAPWAP Discovery messages are used to identify potential 2393 ACs, their load and capabilities. 2395 Join: CAPWAP Join messages are used by a WTP to request service from 2396 an AC, and for the AC to respond to the WTP. 2398 Control Channel Management: CAPWAP control channel management 2399 messages are used to maintain the control channel. 2401 WTP Configuration Management: The WTP Configuration messages are 2402 used by the AC to deliver a specific configuration to the WTP. 2403 Messages which retrieve statistics from a WTP are also included in 2404 WTP Configuration Management. 2406 Station Session Management: Station Session Management messages are 2407 used by the AC to deliver specific station policies to the WTP. 2409 Device Management Operations: Device management operations are used 2410 to request and deliver a firmware image to the WTP. 2412 Binding Specific CAPWAP Management Messages: Messages in this 2413 category are used by the AC and the WTP to exchange protocol- 2414 specific CAPWAP management messages. These messages may or may 2415 not be used to change the link state of a station. 2417 Discovery, Join, Control Channel Management, WTP Configuration 2418 Management and Station Session Management CAPWAP control messages 2419 MUST be implemented. Device Management Operations messages MAY be 2420 implemented. 2422 CAPWAP control messages sent from the WTP to the AC indicate that the 2423 WTP is operational, providing an implicit keep-alive mechanism for 2424 the WTP. The Control Channel Management Echo Request and Echo 2425 Response messages provide an explicit keep-alive mechanism when other 2426 CAPWAP control messages are not exchanged. 2428 4.5.1. Control Message Format 2430 All CAPWAP control messages are sent encapsulated within the CAPWAP 2431 header (see Section 4.3). Immediately following the CAPWAP header, 2432 is the control header, which has the following format: 2434 0 1 2 3 2435 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 2436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2437 | Message Type | 2438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2439 | Seq Num | Msg Element Length | Flags | 2440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2441 | Msg Element [0..N] ... 2442 +-+-+-+-+-+-+-+-+-+-+-+-+ 2444 4.5.1.1. Message Type 2446 The Message Type field identifies the function of the CAPWAP control 2447 message. To provide extensibility, the Message Type field is 2448 comprised of an IANA Enterprise Number [RFC3232] and an enterprise 2449 specific message type number. The first three octets contain the 2450 IANA Enterprise Number in network byte order, with zero used for 2451 CAPWAP base protocol (this specification) defined message types. The 2452 last octet is the enterprise specific message type number, which has 2453 a range from 0 to 255. 2455 The message type field is defined as: 2457 Message Type = 2458 IANA Enterprise Number * 256 + 2459 Enterprise Specific Message Type Number 2461 The CAPWAP protocol reliability mechanism requires that messages be 2462 defined in pairs, consisting of both a Request and a Response 2463 message. The Response message MUST acknowledge the Request message. 2464 The assignment of CAPWAP control Message Type Values always occurs in 2465 pairs. All Request messages have odd numbered Message Type Values, 2466 and all Response messages have even numbered Message Type Values. 2467 The Request value MUST be assigned first. As an example, assigning a 2468 Message Type Value of 3 for a Request message and 4 for a Response 2469 message is valid, while assigning a Message Type Value of 4 for a 2470 Response message and 5 for the corresponding Request message is 2471 invalid. 2473 When a WTP or AC receives a message with a Message Type Value field 2474 that is not recognized and is an odd number, the number in the 2475 Message Type Value Field is incremented by one, and a Response 2476 message with a Message Type Value field containing the incremented 2477 value and containing the Result Code message element with the value 2478 (Unrecognized Request) is returned to the sender of the received 2479 message. If the unknown message type is even, the message is 2480 ignored. 2482 The valid values for CAPWAP Control Message Types are specified in 2483 the table below: 2485 CAPWAP Control Message Message Type 2486 Value 2487 Discovery Request 1 2488 Discovery Response 2 2489 Join Request 3 2490 Join Response 4 2491 Configuration Status Request 5 2492 Configuration Status Response 6 2493 Configuration Update Request 7 2494 Configuration Update Response 8 2495 WTP Event Request 9 2496 WTP Event Response 10 2497 Change State Event Request 11 2498 Change State Event Response 12 2499 Echo Request 13 2500 Echo Response 14 2501 Image Data Request 15 2502 Image Data Response 16 2503 Reset Request 17 2504 Reset Response 18 2505 Primary Discovery Request 19 2506 Primary Discovery Response 20 2507 Data Transfer Request 21 2508 Data Transfer Response 22 2509 Clear Configuration Request 23 2510 Clear Configuration Response 24 2511 Station Configuration Request 25 2512 Station Configuration Response 26 2514 4.5.1.2. Sequence Number 2516 The Sequence Number Field is an identifier value used to match 2517 Request and Response packets. When a CAPWAP packet with a Request 2518 Message Type Value is received, the value of the Sequence Number 2519 field is copied into the corresponding Response message. 2521 When a CAPWAP control message is sent, the sender's internal sequence 2522 number counter is monotonically incremented, ensuring that no two 2523 pending Request messages have the same Sequence Number. The Sequence 2524 Number field wraps back to zero. 2526 4.5.1.3. Message Element Length 2528 The Length field indicates the number of bytes following the Sequence 2529 Number field. 2531 4.5.1.4. Flags 2533 The Flags field MUST be set to zero. 2535 4.5.1.5. Message Element[0..N] 2537 The message element(s) carry the information pertinent to each of the 2538 control message types. Every control message in this specification 2539 specifies which message elements are permitted. 2541 When a WTP or AC receives a CAPWAP message without a message element 2542 that is specified as mandatory for the CAPWAP message, then the 2543 CAPWAP message is discarded. If the received message was a Request 2544 message for which the corresponding Response message carries message 2545 elements, then a corresponding Response message with a Result Code 2546 message element indicating "Failure - Missing Mandatory Message 2547 Element" is returned to the sender. 2549 When a WTP or AC receives a CAPWAP message with a message element 2550 that the WTP or AC does not recognize, the CAPWAP message is 2551 discarded. If the received message was a Request message for which 2552 the corresponding Response message carries message elements, then a 2553 corresponding Response message with a Result Code message element 2554 indicating "Failure - Unrecognized Message Element" and one or more 2555 Returned Message Element message elements is included, containing the 2556 unrecognized message element(s). 2558 4.5.2. Quality of Service 2560 The CAPWAP base protocol does not provide any Quality of Service 2561 (QoS) recommendations for use with the CAPWAP data messages. Any 2562 wireless specific CAPWAP binding specification that has QoS 2563 requirements MUST define the application of QoS to the CAPWAP data 2564 messages. 2566 The IP header also includes the Explicit Congestion Notification 2567 (ECN) bits [RFC3168]. Section 9.1.1 of [RFC3168] describes two 2568 levels of ECN functionality, full functionality and limited 2569 functionality. CAPWAP ACs and WTPs SHALL implement the limited 2570 functionality and are RECOMMENDED to implement the full functionality 2571 described in [RFC3168]. 2573 4.5.2.1. Applying QoS to CAPWAP Control Message 2575 It is recommended that CAPWAP control messages be sent by both the AC 2576 and the WTP with an appropriate Quality of Service precedence value, 2577 ensuring that congestion in the network minimizes occurrences of 2578 CAPWAP control channel disconnects. Therefore, a Quality of Service 2579 enabled CAPWAP device SHOULD use the following values: 2581 802.1Q: The priority tag of 7 SHOULD be used. 2583 DSCP: The CS6 per-hop behavior Service Class SHOULD be used, which 2584 is described in [RFC2474]). 2586 4.5.3. Retransmissions 2588 The CAPWAP control protocol operates as a reliable transport. For 2589 each Request message, a Response message is defined, which is used to 2590 acknowledge receipt of the Request message. In addition, the control 2591 header Sequence Number field is used to pair the Request and Response 2592 messages (see Section 4.5.1). 2594 Response messages are not explicitly acknowledged, therefore if a 2595 Response message is not received, the original Request message is 2596 retransmitted. 2598 Implementations MUST keep track of the Sequence Number of the last 2599 received Request message, and MUST cache the corresponding Response 2600 message. If a retransmission with the same Sequence Number is 2601 received, the cached Response message MUST be retransmitted without 2602 re-processing the Request. If an older Request message is received, 2603 meaning one where the sequence number is smaller, it MUST be ignored. 2604 A newer Request message, meaning one whose sequence number is larger, 2605 is processed as usual. 2607 Note: A sequence number is considered "smaller" when s1 is smaller 2608 than s2 modulo 256 if and only if (s1s2 2609 and (s1-s2)>128) 2611 Both the WTP and the AC can only have a single request outstanding at 2612 any given time. Retransmitted Request messages MUST NOT be altered 2613 by the sender. 2615 After transmitting a Request message, the RetransmitInterval (see 2616 Section 4.7) timer and MaxRetransmit (see Section 4.8) variable are 2617 used to determine if the original Request message needs to be 2618 retransmitted. The RetransmitInterval timer is used the first time 2619 the Request is retransmitted. The timer is then doubled every 2620 subsequent time the same Request message is retransmitted, up to 2621 MaxRetransmit but no more than half the EchoInterval timer (see 2622 Section 4.7.7). Response messages are not subject to these timers. 2624 If the sender stops retransmitting a Request message before reaching 2625 MaxRetransmit retransmissions (which leads to transition to DTLS 2626 Teardown, as described in Section 2.3.1), it cannot know whether the 2627 recipient received and processed the Request or not. In most 2628 situations, the sender SHOULD NOT do this, and instead continue 2629 retransmitting until a Response message is received, or transition to 2630 DTLS Teardown occurs. However, if the sender does decide to continue 2631 the connection with a new or modified Request message, the new 2632 message MUST have a new Sequence Number, and be treated as a new 2633 Request message by the receiver. Note that there is a high chance 2634 that both the WTP and the AC's sequence numbers will become out of 2635 sync. 2637 When a Request message is retransmitted, it MUST be re-encrypted via 2638 the DTLS stack. If the peer had received the Request message, and 2639 the corresponding Response message was lost, it is necessary to 2640 ensure that retransmitted Request messages are not identified as 2641 replays by the DTLS stack. Similarly, any cached Response messages 2642 that are retransmitted as a result of receiving a retransmitted 2643 Request message MUST be re-encrypted via DTLS. 2645 Duplicate Response messages, identified by the Sequence Number field 2646 in the CAPWAP control message header, SHOULD be discarded upon 2647 receipt. 2649 4.6. CAPWAP Protocol Message Elements 2651 This section defines the CAPWAP Protocol message elements which are 2652 included in CAPWAP protocol control messages. 2654 Message elements are used to carry information needed in control 2655 messages. Every message element is identified by the Type Value 2656 field, defined below. The total length of the message elements is 2657 indicated in the message element Length field. 2659 All of the message element definitions in this document use a diagram 2660 similar to the one below in order to depict its format. Note that to 2661 simplify this specification, these diagrams do not include the header 2662 fields (Type and Length). The header field values are defined in the 2663 message element descriptions. 2665 Unless otherwise specified, a control message that lists a set of 2666 supported (or expected) message elements MUST NOT expect the message 2667 elements to be in any specific order. The sender MAY include the 2668 message elements in any order. Unless otherwise noted, one message 2669 element of each type is present in a given control message. 2671 Unless otherwise specified, any configuration information sent by the 2672 AC to the WTP MAY be saved to non-volatile storage (see Section 8.1) 2673 for more information). 2675 Additional message elements may be defined in separate IETF 2676 documents. 2678 The format of a message element uses the TLV format shown here: 2680 0 1 2 3 2681 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 2682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2683 | Type | Length | 2684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2685 | Value ... | 2686 +-+-+-+-+-+-+-+-+ 2688 The 16 bit Type field identifies the information carried in the Value 2689 field and Length (16 bits) indicates the number of bytes in the Value 2690 field. The value of zero (0) is reserved and MUST NOT be used. The 2691 rest of the Type field values are allocated as follows: 2693 Usage Type Values 2695 CAPWAP Protocol Message Elements 1 - 1023 2696 IEEE 802.11 Message Elements 1024 - 2047 2697 Reserved for Future Use 2048 - 3071 2698 EPCGlobal Message Elements 3072 - 4095 2699 Reserved for Future Use 4096 - 65535 2701 The table below lists the CAPWAP protocol Message Elements and their 2702 Type values. 2704 CAPWAP Message Element Type Value 2706 AC Descriptor 1 2707 AC IPv4 List 2 2708 AC IPv6 List 3 2709 AC Name 4 2710 AC Name with Priority 5 2711 AC Timestamp 6 2712 Add MAC ACL Entry 7 2713 Add Station 8 2714 Reserved 9 2715 CAPWAP Control IPV4 Address 10 2716 CAPWAP Control IPV6 Address 11 2717 CAPWAP Local IPV4 Address 30 2718 CAPWAP Local IPV6 Address 50 2719 CAPWAP Timers 12 2720 CAPWAP Transport Protocol 51 2721 Data Transfer Data 13 2722 Data Transfer Mode 14 2723 Decryption Error Report 15 2724 Decryption Error Report Period 16 2725 Delete MAC ACL Entry 17 2726 Delete Station 18 2727 Reserved 19 2728 Discovery Type 20 2729 Duplicate IPv4 Address 21 2730 Duplicate IPv6 Address 22 2731 ECN Support 53 2732 Idle Timeout 23 2733 Image Data 24 2734 Image Identifier 25 2735 Image Information 26 2736 Initiate Download 27 2737 Location Data 28 2738 Maximum Message Length 29 2739 MTU Discovery Padding 52 2740 Radio Administrative State 31 2741 Radio Operational State 32 2742 Result Code 33 2743 Returned Message Element 34 2744 Session ID 35 2745 Statistics Timer 36 2746 Vendor Specific Payload 37 2747 WTP Board Data 38 2748 WTP Descriptor 39 2749 WTP Fallback 40 2750 WTP Frame Tunnel Mode 41 2751 Reserved 42 2752 Reserved 43 2753 WTP MAC Type 44 2754 WTP Name 45 2755 Unused/Reserved 46 2756 WTP Radio Statistics 47 2757 WTP Reboot Statistics 48 2758 WTP Static IP Address Information 49 2760 4.6.1. AC Descriptor 2762 The AC Descriptor message element is used by the AC to communicate 2763 its current state. The value contains the following fields. 2765 0 1 2 3 2766 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2768 | Stations | Limit | 2769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2770 | Active WTPs | Max WTPs | 2771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2772 | Security | R-MAC Field | Reserved1 | DTLS Policy | 2773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2774 | AC Information Sub-Element... 2775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2777 Type: 1 for AC Descriptor 2779 Length: >= 12 2781 Stations: The number of stations currently served by the AC 2783 Limit: The maximum number of stations supported by the AC 2785 Active WTPs: The number of WTPs currently attached to the AC 2787 Max WTPs: The maximum number of WTPs supported by the AC 2789 Security: A 8 bit mask specifying the authentication credential 2790 type supported by the AC (See Section 2.4.4). The field has the 2791 following format: 2793 0 1 2 3 4 5 6 7 2794 +-+-+-+-+-+-+-+-+ 2795 |Reserved |S|X|R| 2796 +-+-+-+-+-+-+-+-+ 2798 Reserved: A set of reserved bits for future use. All 2799 implementations complying with this protocol MUST set to zero 2800 any bits that are reserved in the version of the protocol 2801 supported by that implementation. Receivers MUST ignore all 2802 bits not defined for the version of the protocol they support. 2804 S: The AC supports the pre-shared secret authentication, as 2805 described in Section 12.6. 2807 X: The AC supports X.509 Certificate authentication, as 2808 described in Section 12.7. 2810 R: A reserved bit for future use. All implementations complying 2811 with this protocol MUST set to zero any bits that are reserved 2812 in the version of the protocol supported by that 2813 implementation. Receivers MUST ignore all bits not defined for 2814 the version of the protocol they support. 2816 R-MAC Field: The AC supports the optional Radio MAC Address field 2817 in the CAPWAP transport Header (see Section 4.3). The following 2818 enumerated values are supported: 2820 0 - Reserved 2822 1 - Supported 2824 2 - Not Supported 2826 Reserved: A set of reserved bits for future use. All 2827 implementations complying with this protocol MUST set to zero any 2828 bits that are reserved in the version of the protocol supported by 2829 that implementation. Receivers MUST ignore all bits not defined 2830 for the version of the protocol they support. 2832 DTLS Policy: The AC communicates its policy on the use of DTLS for 2833 the CAPWAP data channel. The AC MAY communicate more than one 2834 supported option, represented by the bit field below. The WTP 2835 MUST abide by one of the options communicated by AC. The field 2836 has the following format: 2838 0 1 2 3 4 5 6 7 2839 +-+-+-+-+-+-+-+-+ 2840 |Reserved |D|C|R| 2841 +-+-+-+-+-+-+-+-+ 2843 Reserved: A set of reserved bits for future use. All 2844 implementations complying with this protocol MUST set to zero 2845 any bits that are reserved in the version of the protocol 2846 supported by that implementation. Receivers MUST ignore all 2847 bits not defined for the version of the protocol they support. 2849 D: DTLS Enabled Data Channel Supported 2851 C: Clear Text Data Channel Supported 2853 R: A reserved bit for future use. All implementations complying 2854 with this protocol MUST set to zero any bits that are reserved 2855 in the version of the protocol supported by that 2856 implementation. Receivers MUST ignore all bits not defined for 2857 the version of the protocol they support. 2859 AC Information Sub-Element: The AC Descriptor message element 2860 contains multiple AC Information sub-elements, and defines two 2861 sub-types, each of which MUST be present. The AC Information sub- 2862 element has the following format: 2864 0 1 2 3 2865 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 2866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2867 | AC Information Vendor Identifier | 2868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2869 | AC Information Type | AC Information Length | 2870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2871 | AC Information Data... 2872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2874 AC Information Vendor Identifier: A 32-bit value containing the 2875 IANA assigned "SMI Network Management Private Enterprise Codes" 2877 AC Information Type: Vendor specific encoding of AC information 2878 in the UTF-8 format [RFC3629]. The following enumerated values 2879 are supported. Both the Hardware and Software Version sub- 2880 elements MUST be included in the AC Descriptor message element. 2881 The values listed below are used in conjunction with the AC 2882 Information Vendor Identifier field, whose value MUST be set to 2883 zero (0). This field, combined with the AC Information Vendor 2884 Identifier set to a non-zero (0) value, allows vendors to use a 2885 private namespace. 2887 4 - Hardware Version: The AC's hardware version number. 2889 5 - Software Version: The AC's Software (firmware) version 2890 number. 2892 AC Information Length: Length of vendor specific encoding of AC 2893 information, with a maximum size of 1024. 2895 AC Information Data: Vendor specific encoding of AC information. 2897 4.6.2. AC IPv4 List 2899 The AC IPv4 List message element is used to configure a WTP with the 2900 latest list of ACs available for the WTP to join. 2902 0 1 2 3 2903 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 2904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2905 | AC IP Address[] | 2906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2908 Type: 2 for AC IPv4 List 2910 Length: >= 4 2912 AC IP Address: An array of 32-bit integers containing AC IPv4 2913 Addresses, containing no more than 1024 addresses. 2915 4.6.3. AC IPv6 List 2917 The AC IPv6 List message element is used to configure a WTP with the 2918 latest list of ACs available for the WTP to join. 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 | AC IP Address[] | 2924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2925 | AC IP Address[] | 2926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2927 | AC IP Address[] | 2928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2929 | AC IP Address[] | 2930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2932 Type: 3 for AC IPV6 List 2934 Length: >= 16 2936 AC IP Address: An array of 128-bit integers containing AC IPv6 2937 Addresses, containing no more than 1024 addresses. 2939 4.6.4. AC Name 2941 The AC Name message element contains an UTF-8 [RFC3629] 2942 representation of the AC identity. The value is a variable length 2943 byte string. The string is NOT zero terminated. 2945 0 2946 0 1 2 3 4 5 6 7 2947 +-+-+-+-+-+-+-+-+ 2948 | Name ... 2949 +-+-+-+-+-+-+-+-+ 2951 Type: 4 for AC Name 2953 Length: >= 1 2955 Name: A variable length UTF-8 encoded string [RFC3629] containing 2956 the AC's name, whose maximum size MUST NOT exceed 512 bytes. 2958 4.6.5. AC Name with Priority 2960 The AC Name with Priority message element is sent by the AC to the 2961 WTP to configure preferred ACs. The number of instances of this 2962 message element is equal to the number of ACs configured on the WTP. 2963 The WTP also uses this message element to send its configuration to 2964 the AC. 2966 0 1 2967 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2969 | Priority | AC Name... 2970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2972 Type: 5 for AC Name with Priority 2974 Length: >= 2 2976 Priority: A value between 1 and 255 specifying the priority order 2977 of the preferred AC. For instance, the value of one (1) is used 2978 to set the primary AC, the value of two (2) is used to set the 2979 secondary, etc. 2981 AC Name: A variable length UTF-8 encoded string [RFC3629] 2982 containing the AC name, whose maximum size MUST NOT exceed 512 2983 bytes. 2985 4.6.6. AC Timestamp 2987 The AC Timestamp message element is sent by the AC to synchronize the 2988 WTP clock. 2990 0 1 2 3 2991 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 2992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2993 | Timestamp | 2994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2996 Type: 6 for AC Timestamp 2998 Length: 4 3000 Timestamp: The AC's current time, allowing all of the WTPs to be 3001 time synchronized in the format defined by Network Time Protocol 3002 (NTP) in RFC 1305 [RFC1305]. Only the most significant 32 bits of 3003 the NTP time is included in this field. 3005 4.6.7. Add MAC ACL Entry 3007 The Add MAC Access Control List (ACL) Entry message element is used 3008 by an AC to add a MAC ACL list entry on a WTP, ensuring that the WTP 3009 no longer provides service to the MAC addresses provided in the 3010 message. The MAC Addresses provided in this message element are not 3011 expected to be saved in non-volatile memory on the WTP. The MAC ACL 3012 table on the WTP is cleared everytime the WTP establishes a new 3013 session with an AC. 3015 0 1 2 3 3016 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3018 | Num of Entries| Length | MAC Address ... 3019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3021 Type: 7 for Add MAC ACL Entry 3023 Length: >= 8 3025 Num of Entries: The number of instances of the Length/MAC Addresses 3026 fields in the array. This value MUST NOT exceed 255. 3028 Length: The length of the MAC Address field. The following formats, 3029 and lengths, are supported [EUI-48] and [EUI-64]. 3031 MAC Address: MAC Addresses to add to the ACL. 3033 4.6.8. Add Station 3035 The Add Station message element is used by the AC to inform a WTP 3036 that it should forward traffic for a station. The Add Station 3037 message element is accompanied by technology specific binding 3038 information element(s) which may include security parameters. 3039 Consequently, the security parameters MUST be applied by the WTP for 3040 the station. 3042 After station policy has been delivered to the WTP through the Add 3043 Station message element, an AC MAY change any policies by sending a 3044 modified Add Station message element. When a WTP receives an Add 3045 Station message element for an existing station, it MUST override any 3046 existing state for the station. 3048 0 1 2 3 3049 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 3050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3051 | Radio ID | Length | MAC Address ... 3052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3053 | VLAN Name... 3054 +-+-+-+-+-+-+-+-+ 3056 Type: 8 for Add Station 3058 Length: >= 8 3060 Radio ID: An 8-bit value representing the radio, whose value is 3061 between one (1) and 31. 3063 Length: The length of the MAC Address field. The following formats, 3064 and lengths, are supported [EUI-48] and [EUI-64]. 3066 MAC Address: The station's MAC Address 3068 VLAN Name: An optional variable length UTF-8 encoded 3069 string[RFC3629], with a maximum length of 512 octets, containing 3070 the VLAN Name on which the WTP is to locally bridge user data. 3071 Note this field is only valid with WTPs configured in Local MAC 3072 mode. 3074 4.6.9. CAPWAP Control IPv4 Address 3076 The CAPWAP Control IPv4 Address message element is sent by the AC to 3077 the WTP during the discovery process and is used by the AC to provide 3078 the interfaces available on the AC, and the current number of WTPs 3079 connected. When multiple CAPWAP Control IPV4 Address message 3080 elements are returned, the WTP SHOULD perform load balancing across 3081 the multiple interfaces (see Section 6.1). 3083 0 1 2 3 3084 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 3085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3086 | IP Address | 3087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3088 | WTP Count | 3089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3091 Type: 10 for CAPWAP Control IPv4 Address 3093 Length: 6 3095 IP Address: The IP Address of an interface. 3097 WTP Count: The number of WTPs currently connected to the interface, 3098 with a maximum value of 65535. 3100 4.6.10. CAPWAP Control IPv6 Address 3102 The CAPWAP Control IPv6 Address message element is sent by the AC to 3103 the WTP during the discovery process and is used by the AC to provide 3104 the interfaces available on the AC, and the current number of WTPs 3105 connected. This message element is useful for the WTP to perform 3106 load balancing across multiple interfaces (see Section 6.1). 3108 0 1 2 3 3109 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 3110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3111 | IP Address | 3112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3113 | IP Address | 3114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3115 | IP Address | 3116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3117 | IP Address | 3118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3119 | WTP Count | 3120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3122 Type: 11 for CAPWAP Control IPv6 Address 3124 Length: 18 3126 IP Address: The IP Address of an interface. 3128 WTP Count: The number of WTPs currently connected to the interface, 3129 with a maximum value of 65535. 3131 4.6.11. CAPWAP Local IPv4 Address 3133 The CAPWAP Local IPv4 Address message element is sent by either the 3134 WTP, in the Join Request, or by the AC, in the Join Response. The 3135 CAPWAP Local IPv4 Address message element is used to communicate the 3136 IP Address of the transmitter. The receiver uses this to determine 3137 whether a middlebox exists between the two peers, by comparing the 3138 source IP address of the packet against the value of the message 3139 element. 3141 0 1 2 3 3142 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 3143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3144 | IP Address | 3145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3147 Type: 30 for CAPWAP Local IPv4 Address 3149 Length: 4 3151 IP Address: The IP Address of the sender. 3153 4.6.12. CAPWAP Local IPv6 Address 3155 The CAPWAP Local IPv6 Address message element is sent by either the 3156 WTP, in the Join Request, or by the AC, in the Join Response. The 3157 CAPWAP Local IPv6 Address message element is used to communicate the 3158 IP Address of the transmitter. The receiver uses this to determine 3159 whether a middlebox exists between the two peers, by comparing the 3160 source IP address of the packet against the value of the message 3161 element. 3163 0 1 2 3 3164 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 3165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3166 | IP Address | 3167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3168 | IP Address | 3169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3170 | IP Address | 3171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3172 | IP Address | 3173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3175 Type: 50 for CAPWAP Local IPv6 Address 3177 Length: 16 3179 IP Address: The IP Address of the sender. 3181 4.6.13. CAPWAP Timers 3183 The CAPWAP Timers message element is used by an AC to configure 3184 CAPWAP timers on a WTP. 3186 0 1 3187 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3189 | Discovery | Echo Request | 3190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3192 Type: 12 for CAPWAP Timers 3194 Length: 2 3196 Discovery: The number of seconds between CAPWAP Discovery messages, 3197 when the WTP is in the discovery phase. This value is used to 3198 configure the MaxDiscoveryInterval timer (see Section 4.7.10). 3200 Echo Request: The number of seconds between WTP Echo Request CAPWAP 3201 messages. This value is used to configure the EchoInterval timer 3202 (see Section 4.7.7). The AC sets its EchoInterval timer to this 3203 value, plus the maximum retransmission time as described in 3204 Section 4.5.3. 3206 4.6.14. CAPWAP Transport Protocol 3208 When CAPWAP is run over IPv6, the UDP-Lite or UDP transports MAY be 3209 used (see Section 3). The CAPWAP IPv6 Transport Protocol message 3210 element is used by either the WTP or the AC to signal which transport 3211 protocol is to be used for the CAPWAP data channel. 3213 Upon receiving the Join Request, the AC MAY set the CAPWAP Transport 3214 Protocol to UDP-Lite in the Join Response message if the CAPWAP 3215 message was received over IPv6, and the CAPWAP Local IPv6 Address 3216 message element (see Section 4.6.12) is present and no middlebox was 3217 detected (see Section 11). 3219 Upon receiving the Join Response, the WTP MAY set the CAPWAP 3220 Transport Protocol to UDP-Lite in the Configuration Status Request or 3221 Image Data Request message if the AC advertised support for UDP-Lite, 3222 the message was received over IPv6, the CAPWAP Local IPv6 Address 3223 message element (see Section 4.6.12) and no middlebox was detected 3224 (see Section 11). Upon receiving either the Configuration Status 3225 Request or the Image Data Request, the AC MUST observe the preference 3226 indicated by the WTP in the CAPWAP Transport Protocol, as long as it 3227 is consistent with what the AC advertised in the Join Response. 3229 For any other condition, the CAPWAP Transport Protocol MUST be set to 3230 UDP. 3232 0 3233 0 1 2 3 4 5 6 7 3234 +-+-+-+-+-+-+-+-+ 3235 | Transport | 3236 +-+-+-+-+-+-+-+-+ 3238 Type: 51 for CAPWAP Transport Protocol 3240 Length: 1 3242 Transport: The transport to use for the CAPWAP data channel. The 3243 following enumerated values are supported: 3245 1 - UDP-Lite: The UDP-Lite transport protocol is to be used for 3246 the CAPWAP data channel. Note that this option MUST NOT be 3247 used if the CAPWAP control channel is being used over IPv4. 3249 2 - UDP: The UDP transport protocol is to be used for the CAPWAP 3250 data channel. 3252 4.6.15. Data Transfer Data 3254 The Data Transfer Data message element is used by the WTP to provide 3255 information to the AC for debugging purposes. 3257 0 1 2 3 3258 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 3259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3260 | Data Type | Data Mode | Data Length | 3261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3262 | Data .... 3263 +-+-+-+-+-+-+-+-+ 3265 Type: 13 for Data Transfer Data 3267 Length: >= 5 3269 Data Type: An 8-bit value representing the transfer Data Type. The 3270 following enumerated values are supported: 3272 1 - Transfer data is included 3274 2 - Last Transfer Data Block is included (EOF) 3276 5 - An error occurred. Transfer is aborted 3278 Data Mode: An 8-bit value the type of information being 3279 transmitted. The following enumerated values are supported: 3281 0 - Reserved 3283 1 - WTP Crash Data 3285 2 - WTP Memory Dump 3287 Data Length: Length of data field, with a maximum size of 65535. 3289 Data: Data being transferred from the WTP to the AC, whose type is 3290 identified via the Data Mode field. 3292 4.6.16. Data Transfer Mode 3294 The Data Transfer Mode message element is used by the WTP to indicate 3295 the type of data transfer information it is sending to the AC for 3296 debugging purposes. 3298 0 3299 0 1 2 3 4 5 6 7 3300 +-+-+-+-+-+-+-+-+ 3301 | Data Mode | 3302 +-+-+-+-+-+-+-+-+ 3304 Type: 14 for Data Transfer Mode 3306 Length: 1 3308 Data Mode: An 8-bit value the type of information being requested. 3309 The following enumerated values are supported: 3311 0 - Reserved 3313 1 - WTP Crash Data 3315 2 - WTP Memory Dump 3317 4.6.17. Decryption Error Report 3319 The Decryption Error Report message element value is used by the WTP 3320 to inform the AC of decryption errors that have occurred since the 3321 last report. Note that this error reporting mechanism is not used if 3322 encryption and decryption services are provided in the AC. 3324 0 1 2 3325 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 3326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3327 | Radio ID |Num Of Entries | Length | MAC Address... 3328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3330 Type: 15 for Decryption Error Report 3332 Length: >= 9 3334 Radio ID: The Radio Identifier refers to an interface index on the 3335 WTP, whose value is between one (1) and 31. 3337 Num of Entries: The number of instances of the Length/MAC Addresses 3338 fields in the array. This field MUST NOT exceed the value of 255. 3340 Length: The length of the MAC Address field. The following formats, 3341 and lengths, are supported [EUI-48] and [EUI-64]. 3343 MAC Address: MAC addresses of the station that has caused 3344 decryption errors. 3346 4.6.18. Decryption Error Report Period 3348 The Decryption Error Report Period message element value is used by 3349 the AC to inform the WTP how frequently it should send decryption 3350 error report messages. Note that this error reporting mechanism is 3351 not used if encryption and decryption services are provided in the 3352 AC. 3354 0 1 2 3355 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 3356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3357 | Radio ID | Report Interval | 3358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3360 Type: 16 for Decryption Error Report Period 3362 Length: 3 3364 Radio ID: The Radio Identifier refers to an interface index on the 3365 WTP, whose value is between one (1) and 31. 3367 Report Interval: A 16-bit unsigned integer indicating the time, in 3368 seconds. The default value for this message element can be found 3369 in Section 4.7.11. 3371 4.6.19. Delete MAC ACL Entry 3373 The Delete MAC ACL Entry message element is used by an AC to delete a 3374 MAC ACL entry on a WTP, ensuring that the WTP provides service to the 3375 MAC addresses provided in the message. 3377 0 1 2 3 3378 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 3379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3380 | Num of Entries| Length | MAC Address ... 3381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3383 Type: 17 for Delete MAC ACL Entry 3385 Length: >= 8 3387 Num of Entries: The number of instances of the Length/MAC Addresses 3388 fields in the array. This field MUST NOT exceed the value of 255. 3390 Length: The length of the MAC Address field. The following formats, 3391 and lengths, are supported [EUI-48] and [EUI-64]. 3393 MAC Address: An array of MAC Addresses to delete from the ACL. 3395 4.6.20. Delete Station 3397 The Delete Station message element is used by the AC to inform a WTP 3398 that it should no longer provide service to a particular station. 3399 The WTP MUST terminate service to the station immediately upon 3400 receiving this message element. 3402 The transmission of a Delete Station message element could occur for 3403 various reasons, including for administrative reasons, or if the 3404 station has roamed to another WTP. 3406 The Delete Station message element MAY be sent by the WTP, in the WTP 3407 Event Request message, to inform the AC that a particular station is 3408 no longer being provided service. This could occur as a result of an 3409 Idle Timeout (see section 4.4.43), due to internal resource shortages 3410 or for some other reason. 3412 0 1 2 3 3413 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3415 | Radio ID | Length | MAC Address... 3416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3418 Type: 18 for Delete Station 3420 Length: >= 8 3422 Radio ID: An 8-bit value representing the radio, whose value is 3423 between one (1) and 31. 3425 Length: The length of the MAC Address field. The following formats, 3426 and lengths, are supported [EUI-48] and [EUI-64]. 3428 MAC Address: The station's MAC Address 3430 4.6.21. Discovery Type 3432 The Discovery Type message element is used by the WTP to indicate how 3433 it has come to know about the existence of the AC to which it is 3434 sending the Discovery Request message. 3436 0 3437 0 1 2 3 4 5 6 7 3438 +-+-+-+-+-+-+-+-+ 3439 | Discovery Type| 3440 +-+-+-+-+-+-+-+-+ 3442 Type: 20 for Discovery Type 3444 Length: 1 3446 Discovery Type: An 8-bit value indicating how the WTP discovered 3447 the AC. The following enumerated values are supported: 3449 0 - Unknown 3451 1 - Static Configuration 3453 2 - DHCP 3455 3 - DNS 3457 4 - AC Referral (used when the AC was configured either through 3458 the AC IPv4 List or AC IPv6 List message element) 3460 4.6.22. Duplicate IPv4 Address 3462 The Duplicate IPv4 Address message element is used by a WTP to inform 3463 an AC that it has detected another IP device using the same IP 3464 address that the WTP is currently using. 3466 The WTP MUST transmit this message element with the status set to 1 3467 after it has detected a duplicate IP address. When the WTP detects 3468 that the duplicate IP address has been cleared, it MUSY send this 3469 message element with the status set to 0. 3471 0 1 2 3 3472 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 3473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3474 | IP Address | 3475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3476 | Status | Length | MAC Address ... 3477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3479 Type: 21 for Duplicate IPv4 Address 3481 Length: >= 12 3483 IP Address: The IP Address currently used by the WTP. 3485 Status: The status of the duplicate IP address. The value MUST be 3486 set to 1 when a duplicate address is detected, and 0 when the 3487 duplicate address has been cleared. 3489 Length: The length of the MAC Address field. The following formats, 3490 and lengths, are supported [EUI-48] and [EUI-64]. 3492 MAC Address: The MAC Address of the offending device. 3494 4.6.23. Duplicate IPv6 Address 3496 The Duplicate IPv6 Address message element is used by a WTP to inform 3497 an AC that it has detected another host using the same IP address 3498 that the WTP is currently using. 3500 The WTP MUST transmit this message element with the status set to 1 3501 after it has detected a duplicate IP address. When the WTP detects 3502 that the duplicate IP address has been cleared, it MUST send this 3503 message element with the status set to 0. 3505 0 1 2 3 3506 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 3507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3508 | IP Address | 3509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3510 | IP Address | 3511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3512 | IP Address | 3513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3514 | IP Address | 3515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3516 | Status | Length | MAC Address ... 3517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3519 Type: 22 for Duplicate IPv6 Address 3521 Length: >= 24 3523 IP Address: The IP Address currently used by the WTP. 3525 Status: The status of the duplicate IP address. The value MUST be 3526 set to 1 when a duplicate address is detected, and 0 when the 3527 duplicate address has been cleared. 3529 Length: The length of the MAC Address field. The following formats, 3530 and lengths, are supported [EUI-48] and [EUI-64]. 3532 MAC Address: The MAC Address of the offending device. 3534 4.6.24. Idle Timeout 3536 The Idle Timeout message element is sent by the AC to the WTP to 3537 provide the idle timeout value that the WTP SHOULD enforce for its 3538 active stations. The value applies to all radios on the WTP. 3540 0 1 2 3 3541 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 3542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3543 | Timeout | 3544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3546 Type: 23 for Idle Timeout 3548 Length: 4 3549 Timeout: The current idle timeout, in seconds, to be enforced by 3550 the WTP. The default value for this message element is specified 3551 in Section 4.7.8. 3553 4.6.25. ECN Support 3555 The ECN Support message element is sent by both the WTP and the AC to 3556 indicate their support for the Explicit Congestion Notification (ECN) 3557 bits, as defined in [RFC3168]. 3559 0 3560 0 1 2 3 4 5 6 7 3561 +-+-+-+-+-+-+-+-+ 3562 | ECN Support | 3563 +-+-+-+-+-+-+-+-+ 3565 Type: 53 for ECN Support 3567 Length: 1 3569 ECN Support: An 8-bit value representing the sender's support for 3570 ECN, as defined in [RFC3168]. 3572 0 - Limited ECN Support 3574 1 - Full and Limited ECN Support 3576 4.6.26. Image Data 3578 The Image Data message element is present in the Image Data Request 3579 message sent by the AC and contains the following fields. 3581 0 1 2 3 3582 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 3583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3584 | Data Type | Data .... 3585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3587 Type: 24 for Image Data 3589 Length: >= 1 3591 Data Type: An 8-bit value representing the image Data Type. The 3592 following enumerated values are supported: 3594 1 - Image data is included 3596 2 - Last Image Data Block is included (EOF) 3598 5 - An error occurred. Transfer is aborted 3600 Data: The Image Data field contains up to 1024 characters, and its 3601 length is inferred from this message element's length field. If 3602 the block being sent is the last one, the Data Type field is set 3603 to 2. The AC MAY opt to abort the data transfer by setting the 3604 Data Type field to 5. When the Data Type field is 5, the Value 3605 field has a zero length. 3607 4.6.27. Image Identifier 3609 The Image Identifier message element is sent by the AC to the WTP to 3610 indicate the expected active software version that is to be run on 3611 the WTP. The WTP sends the Image Identifier message element in order 3612 to request a specific software version from the AC. The actual 3613 download process is defined in Section 9.1. The value is a variable 3614 length UTF-8 encoded string [RFC3629], which is NOT zero terminated. 3616 0 1 2 3 3617 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 3618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3619 | Vendor Identifier | 3620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3621 | Data... 3622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3624 Type: 25 for Image Identifier 3626 Length: >= 5 3628 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 3629 Network Management Private Enterprise Codes" 3631 Data: A variable length UTF-8 encoded string [RFC3629] containing 3632 the firmware identifier to be run on the WTP, whose length MUST 3633 NOT exceed 1024 octets. The length of this field is inferred from 3634 this message element's length field. 3636 4.6.28. Image Information 3638 The Image Information message element is present in the Image Data 3639 Response message sent by the AC to the WTP and contains the following 3640 fields. 3642 0 1 2 3 3643 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 3644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3645 | File Size | 3646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3647 | Hash | 3648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3649 | Hash | 3650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3651 | Hash | 3652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3653 | Hash | 3654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3656 Type: 26 for Image Information 3658 Length: 20 3660 File Size: A 32-bit value containing the size of the file, in 3661 bytes, that will be transferred by the AC to the WTP. 3663 Hash: A 16 octet MD5 hash of the image using the procedures defined 3664 in [RFC1321]. 3666 4.6.29. Initiate Download 3668 The Initiate Download message element is used by the WTP to inform 3669 the AC that the AC SHOULD initiate a firmware upgrade. The AC 3670 subsequently transmits an Image Data Request message which includes 3671 the Image Data message element. This message element does not 3672 contain any data. 3674 Type: 27 for Initiate Download 3676 Length: 0 3678 4.6.30. Location Data 3680 The Location Data message element is a variable length byte UTF-8 3681 encoded string [RFC3629] containing user defined location information 3682 (e.g. "Next to Fridge"). This information is configurable by the 3683 network administrator, and allows the WTP location to be determined. 3684 The string is not zero terminated. 3686 0 3687 0 1 2 3 4 5 6 7 3688 +-+-+-+-+-+-+-+-+- 3689 | Location ... 3691 +-+-+-+-+-+-+-+-+- 3693 Type: 28 for Location Data 3695 Length: >= 1 3697 Location: A non-zero terminated UTF-8 encoded string [RFC3629] 3698 containing the WTP location, whose maximum size MUST NOT exceed 3699 1024. 3701 4.6.31. Maximum Message Length 3703 The Maximum Message Length message element is included in the Join 3704 Request message by the WTP to indicate the maximum CAPWAP message 3705 length that it supports to the AC. The Maximum Message Length 3706 message element is optionally included in Join Response message by 3707 the AC to indicate the maximum CAPWAP message length that it supports 3708 to the WTP. 3710 0 1 3711 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3713 | Maximum Message Length | 3714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3716 Type: 29 for Maximum Message Length 3718 Length: 2 3720 Maximum Message Length An 16-bit unsigned integer indicating the 3721 maximum message length. 3723 4.6.32. MTU Discovery Padding 3725 The MTU Discovery Padding message element is used as padding to 3726 perform MTU discovery, and MUST contain octets of value 0xFF, of any 3727 length. 3729 0 3730 0 1 2 3 4 5 6 7 3731 +-+-+-+-+-+-+-+-+ 3732 | Padding... 3733 +-+-+-+-+-+-+-+- 3735 Type: 52 for MTU Discovery Padding 3737 Length: variable 3739 Pad: A variable length pad, filled with the value 0xFF. 3741 4.6.33. Radio Administrative State 3743 The Radio Administrative State message element is used to communicate 3744 the state of a particular radio. The Radio Administrative State 3745 message element is sent by the AC to change the state of the WTP. 3746 The WTP saves the value, to ensure that it remains across WTP resets. 3747 The WTP communicates this message element during the configuration 3748 phase, in the Configuration Status Request message, to ensure that AC 3749 has the WTP radio current administrative state settings. The message 3750 element contains the following fields. 3752 0 1 3753 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3755 | Radio ID | Admin State | 3756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3758 Type: 31 for Radio Administrative State 3760 Length: 2 3762 Radio ID: An 8-bit value representing the radio to configure, whose 3763 value is between one (1) and 31. The Radio ID field MAY also 3764 include the value of 0xff, which is used to identify the WTP. If 3765 an AC wishes to change the administrative state of a WTP, it 3766 includes 0xff in the Radio ID field. 3768 Admin State: An 8-bit value representing the administrative state 3769 of the radio. The default value for the Admin State field is 3770 listed in Section 4.8.1. The following enumerated values are 3771 supported: 3773 0 - Reserved 3775 1 - Enabled 3777 2 - Disabled 3779 4.6.34. Radio Operational State 3781 The Radio Operational State message element is sent by the WTP to the 3782 AC to communicate a radio's operational state. This message element 3783 is included in the Configuration Update Response message by the WTP 3784 if it was requested to change the state of its radio, via the Radio 3785 Administrative State message element, but was unable to comply to the 3786 request. This message element is included in the Change State Event 3787 message when a WTP radio state was changed unexpectedly. This could 3788 occur due to a hardware failure. Note that the operational state 3789 setting is not saved on the WTP, and therefore does not remain across 3790 WTP resets. The value contains three fields, as shown below. 3792 0 1 2 3793 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 3794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3795 | Radio ID | State | Cause | 3796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3798 Type: 32 for Radio Operational State 3800 Length: 3 3802 Radio ID: The Radio Identifier refers to an interface index on the 3803 WTP, whose value is between one (1) and 31. A value of 0xFF is 3804 invalid, as it is not possible to change the WTP's operational 3805 state. 3807 State: An 8-bit boolean value representing the state of the radio. 3808 The following enumerated values are supported: 3810 0 - Reserved 3812 1 - Enabled 3814 2 - Disabled 3816 Cause: When a radio is inoperable, the cause field contains the 3817 reason the radio is out of service. The following enumerated 3818 values are supported: 3820 0 - Normal 3822 1 - Radio Failure 3823 2 - Software Failure 3825 3 - Administratively Set 3827 4.6.35. Result Code 3829 The Result Code message element value is a 32-bit integer value, 3830 indicating the result of the Request message corresponding to the 3831 Sequence Number included in the Response message. 3833 0 1 2 3 3834 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 3835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3836 | Result Code | 3837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3839 Type: 33 for Result Code 3841 Length: 4 3843 Result Code: The following enumerated values are defined: 3845 0 Success 3847 1 Failure (AC List message element MUST be present) 3849 2 Success (NAT detected) 3851 3 Join Failure (unspecified) 3853 4 Join Failure (Resource Depletion) 3855 5 Join Failure (Unknown Source) 3857 6 Join Failure (Incorrect Data) 3859 7 Join Failure (Session ID already in use) 3861 8 Join Failure (WTP Hardware not supported) 3863 9 Join Failure (Binding Not Supported) 3865 10 Reset Failure (Unable to Reset) 3867 11 Reset Failure (Firmware Write Error) 3868 12 Configuration Failure (Unable to Apply Requested Configuration 3869 - Service Provided Anyhow) 3871 13 Configuration Failure (Unable to Apply Requested Configuration 3872 - Service Not Provided) 3874 14 Image Data Error (Invalid Checksum) 3876 15 Image Data Error (Invalid Data Length) 3878 16 Image Data Error (Other Error) 3880 17 Image Data Error (Image Already Present) 3882 18 Message Unexpected (Invalid in current state) 3884 19 Message Unexpected (Unrecognized Request) 3886 20 Failure - Missing Mandatory Message Element 3888 21 Failure - Unrecognized Message Element 3890 22 Data Transfer Error (No Information to Transfer) 3892 4.6.36. Returned Message Element 3894 The Returned Message Element is sent by the WTP in the Change State 3895 Event Request message to communicate to the AC which message elements 3896 in the Configuration Status Response it was unable to apply locally. 3897 The Returned Message Element message element contains a result code 3898 indicating the reason that the configuration could not be applied, 3899 and encapsulates the failed message element. 3901 0 1 2 3 3902 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 3903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3904 | Reason | Length | Message Element... 3905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3907 Type: 34 for Returned Message Element 3909 Length: >= 6 3911 Reason: The reason why the configuration in the offending message 3912 element could not be applied by the WTP. The following enumerated 3913 values are supported: 3915 0 - Reserved 3917 1 - Unknown Message Element 3919 2 - Unsupported Message Element 3921 3 - Unknown Message Element Value 3923 4 - Unsupported Message Element Value 3925 Length: The length of the Message Element field, which MUST NOT 3926 exceed 255 octets. 3928 Message Element: The Message Element field encapsulates the message 3929 element sent by the AC in the Configuration Status Response 3930 message that caused the error. 3932 4.6.37. Session ID 3934 The Session ID message element value contains a randomly generated 3935 unsigned 128-bit integer. 3937 0 1 2 3 3938 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 3939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3940 | Session ID | 3941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3942 | Session ID | 3943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3944 | Session ID | 3945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3946 | Session ID | 3947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3949 Type: 35 for Session ID 3951 Length: 16 3953 Session ID: A 128-bit unsigned integer used as a random session 3954 identifier 3956 4.6.38. Statistics Timer 3958 The Statistics Timer message element value is used by the AC to 3959 inform the WTP of the frequency with which it expects to receive 3960 updated statistics. 3962 0 1 3963 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3965 | Statistics Timer | 3966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3968 Type: 36 for Statistics Timer 3970 Length: 2 3972 Statistics Timer: A 16-bit unsigned integer indicating the time, in 3973 seconds. The default value for this timer is specified in 3974 Section 4.7.14. 3976 4.6.39. Vendor Specific Payload 3978 The Vendor Specific Payload message element is used to communicate 3979 vendor specific information between the WTP and the AC. The Vendor 3980 Specific Payload message element MAY be present in any CAPWAP 3981 message. The exchange of vendor specific data between the MUST NOT 3982 modify the behavior of the base CAPWAP protocol and state machine. 3983 The message element uses the following format: 3985 0 1 2 3 3986 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 3987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3988 | Vendor Identifier | 3989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3990 | Element ID | Data... 3991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3993 Type: 37 for Vendor Specific Payload 3995 Length: >= 7 3997 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 3998 Network Management Private Enterprise Codes" [RFC3232] 4000 Element ID: A 16-bit Element Identifier which is managed by the 4001 vendor. 4003 Data: Variable length vendor specific information, whose contents 4004 and format are proprietary and understood based on the Element ID 4005 field. This field MUST NOT exceed 2048 octets. 4007 4.6.40. WTP Board Data 4009 The WTP Board Data message element is sent by the WTP to the AC and 4010 contains information about the hardware present. 4012 0 1 2 3 4013 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 4014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4015 | Vendor Identifier | 4016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4017 | Board Data Sub-Element... 4018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4020 Type: 38 for WTP Board Data 4022 Length: >=14 4024 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 4025 Network Management Private Enterprise Codes", identifying the WTP 4026 hardware manufacturer. The Vendor Identifier field MUST NOT be 4027 set to zero. 4029 Board Data Sub-Element: The WTP Board Data message element contains 4030 multiple Board Data sub-elements, some of which are mandatory and 4031 some are optional, as described below. The Board Data Type values 4032 are not extensible by vendors, and is therefore not coupled along 4033 with the Vendor Identifier field. The Board Data sub-element has 4034 the following format: 4036 0 1 2 3 4037 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 4038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4039 | Board Data Type | Board Data Length | 4040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4041 | Board Data Value... 4042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4044 Board Data Type: The Board Data Type field identifies the data 4045 being encoded. The CAPWAP protocol defines the following 4046 values, and each of these types identify whether their presence 4047 is mandatory or optional: 4049 0 - WTP Model Number: The WTP Model Number MUST be included 4050 in the WTP Board Data message element. 4052 1 - WTP Serial Number: The WTP Serial Number MUST be included 4053 in the WTP Board Data message element. 4055 2 - Board ID: A hardware identifier, which MAY be included in 4056 the WTP Board Data message element. 4058 3 - Board Revision A revision number of the board, which MAY 4059 be included in the WTP Board Data message element. 4061 4 - Base MAC Address The WTP's Base MAC Address, which MAY be 4062 assigned to the primary Ethernet interface. 4064 Board Data Length: The length of the data in the Board Data 4065 Value field, whose length MUST NOT exceed 1024 octets. 4067 Board Data Value: The data associated with the Board Data Type 4068 field for this Board Data sub-element. 4070 4.6.41. WTP Descriptor 4072 The WTP Descriptor message element is used by a WTP to communicate 4073 its current hardware and software (firmware) configuration. The 4074 value contains the following fields. 4076 0 1 2 3 4077 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 4078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4079 | Max Radios | Radios in use | Num Encrypt |Encryp Sub-Elmt| 4080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4081 | Encryption Sub-Element | Descriptor Sub-Element... 4082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4084 Type: 39 for WTP Descriptor 4086 Length: >= 33 4088 Max Radios: An 8-bit value representing the number of radios (where 4089 each radio is identified via the Radio ID field) supported by the 4090 WTP. 4092 Radios in use: An 8-bit value representing the number of radios in 4093 use in the WTP. 4095 Num Encrypt: The number of 3 byte Encryption Sub-Elements that 4096 follow this field. The value of the Num Encrypt field MUST be 4097 between one (1) and 255. 4099 Encryption Sub-Element: The WTP Descriptor message element MUST 4100 contain at least one Encryption sub-element. One sub-element is 4101 present for each binding supported by the WTP. The Encryption 4102 sub-element has the following format: 4104 0 1 2 4105 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4107 |Resvd| WBID | Encryption Capabilities | 4108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4110 Resvd: The 3-bit field is reserved for future use. All 4111 implementations complying with this protocol MUST set to zero 4112 any bits that are reserved in the version of the protocol 4113 supported by that implementation. Receivers MUST ignore all 4114 bits not defined for the version of the protocol they support. 4116 WBID: A 5 bit field which is the wireless binding identifier. 4117 The identifier will indicate the type of wireless packet 4118 associated with the radio. The WBIDs defined in this 4119 specification can be found in Section 4.3 4121 Encryption Capabilities: This 16-bit field is used by the WTP to 4122 communicate its capabilities to the AC. A WTP that does not 4123 have any encryption capabilities sets this field to zero (0). 4124 Refer to the specific wireless binding for further 4125 specification of the Encryption Capabilities field. 4127 Descriptor Sub-Element: The WTP Descriptor message element contains 4128 multiple Descriptor sub-elements, some of which are mandatory and 4129 some are optional, as described below. The Descriptor sub-element 4130 has the following format: 4132 0 1 2 3 4133 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 4134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4135 | Descriptor Vendor Identifier | 4136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4137 | Descriptor Type | Descriptor Length | 4138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4139 | Descriptor Data... 4140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4142 Descriptor Vendor Identifier: A 32-bit value containing the IANA 4143 assigned "SMI Network Management Private Enterprise Codes". 4145 Descriptor Type: The Descriptor Type field identifies the data 4146 being encoded. The format of the data is vendor specific 4147 encoded in the UTF-8 format [RFC3629]. The CAPWAP protocol 4148 defines the following values, and each of these types identify 4149 whether their presence is mandatory or optional. The values 4150 listed below are used in conjunction with the Descriptor Vendor 4151 Identifier field, whose value MUST be set to zero (0). This 4152 field, combined with the Descriptor Vendor Identifier set to a 4153 non-zero (0) value, allows vendors to use a private namespace. 4155 0 - Hardware Version: The WTP hardware version number MUST be 4156 present. 4158 1 - Active Software Version: The WTP running software version 4159 number MUST be present. 4161 2 - Boot Version: The WTP boot loader version number MUST be 4162 present. 4164 3 - Other Software Version: The WTP non-running software 4165 (firmware) version number MAY be present. This type is used 4166 to communicate alternate software versions that are 4167 available on the WTP's non-volatile storage. 4169 Descriptor Length: Length of vendor specific encoding of 4170 Descriptor Data field, whose length MUST NOT exceed 1024 4171 octets. 4173 Descriptor Data: Vendor specific data of WTP information encoded 4174 in the UTF-8 format [RFC3629]. 4176 4.6.42. WTP Fallback 4178 The WTP Fallback message element is sent by the AC to the WTP to 4179 enable or disable automatic CAPWAP fallback in the event that a WTP 4180 detects its preferred AC, and is not currently connected to it. 4182 0 4183 0 1 2 3 4 5 6 7 4184 +-+-+-+-+-+-+-+-+ 4185 | Mode | 4186 +-+-+-+-+-+-+-+-+ 4188 Type: 40 for WTP Fallback 4189 Length: 1 4191 Mode: The 8-bit value indicates the status of automatic CAPWAP 4192 fallback on the WTP. When enabled, if the WTP detects that its 4193 primary AC is available, and that the WTP is not connected to the 4194 primary AC, the WTP SHOULD automatically disconnect from its 4195 current AC and reconnect to its primary AC. If disabled, the WTP 4196 will only reconnect to its primary AC through manual intervention 4197 (e.g., through the Reset Request message). The default value for 4198 this field is specified in Section 4.8.9. The following 4199 enumerated values are supported: 4201 0 - Reserved 4203 1 - Enabled 4205 2 - Disabled 4207 4.6.43. WTP Frame Tunnel Mode 4209 The WTP Frame Tunnel Mode message element allows the WTP to 4210 communicate the tunneling modes of operation which it supports to the 4211 AC. A WTP that advertises support for all types allows the AC to 4212 select which type will be used, based on its local policy. 4214 0 4215 0 1 2 3 4 5 6 7 4216 +-+-+-+-+-+-+-+-+ 4217 |Reservd|N|E|L|U| 4218 +-+-+-+-+-+-+-+-+ 4220 Type: 41 for WTP Frame Tunnel Mode 4222 Length: 1 4224 Reservd: A set of reserved bits for future use. All 4225 implementations complying with this protocol MUST set to zero any 4226 bits that are reserved in the version of the protocol supported by 4227 that implementation. Receivers MUST ignore all bits not defined 4228 for the version of the protocol they support. 4230 N: Native Frame Tunnel mode requires the WTP and AC to encapsulate 4231 all user payloads as native wireless frames, as defined by the 4232 wireless binding (see for example Section 4.4) 4234 E: The 802.3 Frame Tunnel Mode requires the WTP and AC to 4235 encapsulate all user payload as native IEEE 802.3 frames (see 4236 Section 4.4). All user traffic is tunneled to the AC. This value 4237 MUST NOT be used when the WTP MAC Type is set to Split-MAC. 4239 L: When Local Bridging is used, the WTP does not tunnel user 4240 traffic to the AC; all user traffic is locally bridged. This 4241 value MUST NOT be used when the WTP MAC Type is set to Split-MAC. 4243 R: A reserved bit for future use. All implementations complying 4244 with this protocol MUST set to zero any bits that are reserved in 4245 the version of the protocol supported by that implementation. 4246 Receivers MUST ignore all bits not defined for the version of the 4247 protocol they support. 4249 4.6.44. WTP MAC Type 4251 The WTP MAC-Type message element allows the WTP to communicate its 4252 mode of operation to the AC. A WTP that advertises support for both 4253 modes allows the AC to select the mode to use, based on local policy. 4255 0 4256 0 1 2 3 4 5 6 7 4257 +-+-+-+-+-+-+-+-+ 4258 | MAC Type | 4259 +-+-+-+-+-+-+-+-+ 4261 Type: 44 for WTP MAC Type 4263 Length: 1 4265 MAC Type: The MAC mode of operation supported by the WTP. The 4266 following enumerated values are supported: 4268 0 - Local-MAC: Local-MAC is the default mode that MUST be 4269 supported by all WTPs. When tunneling is enabled (see 4270 Section 4.6.43), the encapsulated frames MUST be in the 802.3 4271 format (see Section 4.4.2), unless a wireless management or 4272 control frame which MAY be in its native format. Any CAPWAP 4273 binding needs to specify the format of management and control 4274 wireless frames. 4276 1 - Split-MAC: Split-MAC support is optional, and allows the AC 4277 to receive and process native wireless frames. 4279 2 - Both: WTP is capable of supporting both Local-MAC and Split- 4280 MAC. 4282 4.6.45. WTP Name 4284 The WTP Name message element is a variable length byte UTF-8 encoded 4285 string [RFC3629]. The string is not zero terminated. 4287 0 4288 0 1 2 3 4 5 6 7 4289 +-+-+-+-+-+-+-+-+- 4290 | WTP Name ... 4291 +-+-+-+-+-+-+-+-+- 4293 Type: 45 for WTP Name 4295 Length: >= 1 4297 WTP Name: A non-zero terminated UTF-8 encoded string [RFC3629] 4298 containing the WTP name, whose maximum size MUST NOT exceed 512 4299 bytes. 4301 4.6.46. WTP Radio Statistics 4303 The WTP Radio Statistics message element is sent by the WTP to the AC 4304 to communicate statistics on radio behavior and reasons why the WTP 4305 radio has been reset. These counters are never reset on the WTP, and 4306 will therefore roll over to zero when the maximum size has been 4307 reached. 4309 0 1 2 3 4310 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 4311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4312 | Radio ID | Last Fail Type| Reset Count | 4313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4314 | SW Failure Count | HW Failure Count | 4315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4316 | Other Failure Count | Unknown Failure Count | 4317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4318 | Config Update Count | Channel Change Count | 4319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4320 | Band Change Count | Current Noise Floor | 4321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4323 Type: 47 for WTP Radio Statistics 4325 Length: 20 4327 Radio ID: The radio ID of the radio to which the statistics apply, 4328 whose value is between one (1) and 31. 4330 Last Failure Type: The last WTP failure. The following enumerated 4331 values are supported: 4333 0 - Statistic Not Supported 4335 1 - Software Failure 4337 2 - Hardware Failure 4339 3 - Other Failure 4341 255 - Unknown (e.g., WTP doesn't keep track of info) 4343 Reset Count: The number of times that that the radio has been 4344 reset. 4346 SW Failure Count: The number of times that the radio has failed due 4347 to software related reasons. 4349 HW Failure Count: The number of times that the radio has failed due 4350 to hardware related reasons. 4352 Other Failure Count: The number of times that the radio has failed 4353 due to known reasons, other than software or hardware failure. 4355 Unknown Failure Count: The number of times that the radio has 4356 failed for unknown reasons. 4358 Config Update Count: The number of times that the radio 4359 configuration has been updated. 4361 Channel Change Count: The number of times that the radio channel 4362 has been changed. 4364 Band Change Count: The number of times that the radio has changed 4365 frequency bands. 4367 Current Noise Floor: A signed integer which indicates the noise 4368 floor of the radio receiver in units of dBm. 4370 4.6.47. WTP Reboot Statistics 4372 The WTP Reboot Statistics message element is sent by the WTP to the 4373 AC to communicate reasons why WTP reboots have occurred. These 4374 counters are never reset on the WTP, and will therefore roll over to 4375 zero when the maximum size has been reached. 4377 0 1 2 3 4378 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 4379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4380 | Reboot Count | AC Initiated Count | 4381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4382 | Link Failure Count | SW Failure Count | 4383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4384 | HW Failure Count | Other Failure Count | 4385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4386 | Unknown Failure Count |Last Failure Type| 4387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4389 Type: 48 for WTP Reboot Statistics 4391 Length: 15 4393 Reboot Count: The number of reboots that have occurred due to a WTP 4394 crash. A value of 65535 implies that this information is not 4395 available on the WTP. 4397 AC Initiated Count: The number of reboots that have occurred at the 4398 request of a CAPWAP protocol message, such as a change in 4399 configuration that required a reboot or an explicit CAPWAP 4400 protocol reset request. A value of 65535 implies that this 4401 information is not available on the WTP. 4403 Link Failure Count: The number of times that a CAPWAP protocol 4404 connection with an AC has failed due to link failure. 4406 SW Failure Count: The number of times that a CAPWAP protocol 4407 connection with an AC has failed due to software related reasons. 4409 HW Failure Count: The number of times that a CAPWAP protocol 4410 connection with an AC has failed due to hardware related reasons. 4412 Other Failure Count: The number of times that a CAPWAP protocol 4413 connection with an AC has failed due to known reasons, other than 4414 AC initiated, link, SW or HW failure. 4416 Unknown Failure Count: The number of times that a CAPWAP protocol 4417 connection with an AC has failed for unknown reasons. 4419 Last Failure Type: The failure type of the most recent WTP failure. 4420 The following enumerated values are supported: 4422 0 - Not Supported 4424 1 - AC Initiated (see Section 9.2) 4426 2 - Link Failure 4428 3 - Software Failure 4430 4 - Hardware Failure 4432 5 - Other Failure 4434 255 - Unknown (e.g., WTP doesn't keep track of info) 4436 4.6.48. WTP Static IP Address Information 4438 The WTP Static IP Address Information message element is used by an 4439 AC to configure or clear a previously configured static IP address on 4440 a WTP. IPv6 WTPs are expected to use dynamic addresses. 4442 0 1 2 3 4443 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 4444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4445 | IP Address | 4446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4447 | Netmask | 4448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4449 | Gateway | 4450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4451 | Static | 4452 +-+-+-+-+-+-+-+-+ 4454 Type: 49 for WTP Static IP Address Information 4456 Length: 13 4458 IP Address: The IP Address to assign to the WTP. This field is 4459 only valid if the static field is set to one. 4461 Netmask: The IP Netmask. This field is only valid if the static 4462 field is set to one. 4464 Gateway: The IP address of the gateway. This field is only valid 4465 if the static field is set to one. 4467 Static: An 8-bit boolean stating whether the WTP should use a 4468 static IP address or not. A value of zero disables the static IP 4469 address, while a value of one enables it. 4471 4.7. CAPWAP Protocol Timers 4473 This section contains the definition of the CAPWAP timers. 4475 4.7.1. ChangeStatePendingTimer 4477 The maximum time, in seconds, the AC will wait for the Change State 4478 Event Request from the WTP after having transmitted a successful 4479 Configuration Status Response message. 4481 Default: 25 seconds 4483 4.7.2. DataChannelKeepAlive 4485 The DataChannelKeepAlive timer is used by the WTP to determine the 4486 next opportunity when it must transmit the Data Channel KeepAlive, in 4487 seconds. 4489 Default: 30 seconds 4491 4.7.3. DataChannelDeadInterval 4493 The minimum time, in seconds, a WTP MUST wait without having received 4494 a Data Channel Keep Alive packet before the destination for the Data 4495 Channel Keep Alive packets may be considered dead. The value of this 4496 timer MUST be no less than 2*DataChannelKeepAlive seconds and no 4497 greater that 240 seconds. 4499 Default: 60 4501 4.7.4. DataCheckTimer 4503 The number of seconds the AC will wait for the Data Channel Keep 4504 Alive, which is required by the CAPWAP state machine's Data Check 4505 state. The AC resets the state machine if this timer expires prior 4506 to transitioning to the next state. 4508 Default: 30 4510 4.7.5. DiscoveryInterval 4512 The minimum time, in seconds, that a WTP MUST wait after receiving a 4513 Discovery Response message, before initiating a DTLS handshake. 4515 Default: 5 4517 4.7.6. DTLSSessionDelete 4519 The minimum time, in seconds, a WTP MUST wait for DTLS session 4520 deletion. 4522 Default: 5 4524 4.7.7. EchoInterval 4526 The minimum time, in seconds, between sending Echo Request messages 4527 to the AC with which the WTP has joined. 4529 Default: 30 4531 4.7.8. IdleTimeout 4533 The default Idle Timeout is 300 seconds. 4535 4.7.9. ImageDataStartTimer 4537 The number of seconds the WTP will wait for its peer to transmit the 4538 Image Data Request. 4540 Default: 30 4542 4.7.10. MaxDiscoveryInterval 4544 The maximum time allowed between sending Discovery Request messages, 4545 in seconds. This value MUST be no less than 2 seconds and no greater 4546 than 180 seconds. 4548 Default: 20 seconds. 4550 4.7.11. ReportInterval 4552 The ReportInterval is used by the WTP to determine the interval the 4553 WTP uses between sending the Decryption Error message elements to 4554 inform the AC of decryption errors, in seconds. 4556 The default Report Interval is 120 seconds. 4558 4.7.12. RetransmitInterval 4560 The minimum time, in seconds, in which a non-acknowledged CAPWAP 4561 packet will be retransmitted. 4563 Default: 3 4565 4.7.13. SilentInterval 4567 For a WTP, this is the minimum time, in seconds, a WTP MUST wait 4568 before it MAY again send Discovery Request messages or attempt to a 4569 establish DTLS session. For an AC, this is the minimum time, in 4570 seconds, during which the AC SHOULD ignore all CAPWAP and DTLS 4571 packets received from the WTP that is in the Sulking state. 4573 Default: 30 seconds 4575 4.7.14. StatisticsTimer 4577 The StatisticsTimer is used by the WTP to determine the interval the 4578 WTP uses between the WTP Events Requests it transmits to the AC to 4579 communicate its statistics, in seconds. 4581 Default: 120 seconds 4583 4.7.15. WaitDTLS 4585 The maximum time, in seconds, a WTP MUST wait without having received 4586 a DTLS Handshake message from an AC. This timer MUST be greater than 4587 30 seconds. 4589 Default: 60 4591 4.7.16. WaitJoin 4593 The maximum time, in seconds, an AC will wait after the DTLS session 4594 has been established until it receives the Join Request from the WTP. 4595 This timer MUST be greater than 20 seconds. 4597 Default: 60 4599 4.8. CAPWAP Protocol Variables 4601 This section defines the CAPWAP protocol variables, which are used 4602 for various protocol functions. Some of these variables are 4603 configurable, while others are counters or have a fixed value. For 4604 non counter related variables, default values are specified. 4605 However, when a WTP's variable configuration is explicitly overridden 4606 by an AC, the WTP MUST save the new value. 4608 4.8.1. AdminState 4610 The default Administrative State value is enabled (1). 4612 4.8.2. DiscoveryCount 4614 The number of Discovery Request messages transmitted by a WTP to a 4615 single AC. This is a monotonically increasing counter. 4617 4.8.3. FailedDTLSAuthFailCount 4619 The number of failed DTLS session establishment attempts due to 4620 authentication failures. 4622 4.8.4. FailedDTLSSessionCount 4624 The number of failed DTLS session establishment attempts. 4626 4.8.5. MaxDiscoveries 4628 The maximum number of Discovery Request messages that will be sent 4629 after a WTP boots. 4631 Default: 10 4633 4.8.6. MaxFailedDTLSSessionRetry 4635 The maximum number of failed DTLS session establishment attempts 4636 before the CAPWAP device enters a silent period. 4638 Default: 3. 4640 4.8.7. MaxRetransmit 4642 The maximum number of retransmissions for a given CAPWAP packet 4643 before the link layer considers the peer dead. 4645 Default: 5 4647 4.8.8. RetransmitCount 4649 The number of retransmissions for a given CAPWAP packet. This is a 4650 monotonically increasing counter. 4652 4.8.9. WTPFallBack 4654 The default WTP Fallback value is enabled (1). 4656 4.9. WTP Saved Variables 4658 In addition to the values defined in Section 4.8, the following 4659 values SHOULD be saved on the WTP in non-volatile memory. CAPWAP 4660 wireless bindings MAY define additional values that SHOULD be stored 4661 on the WTP. 4663 4.9.1. AdminRebootCount 4665 The number of times the WTP has rebooted administratively, defined in 4666 Section 4.6.47. 4668 4.9.2. FrameEncapType 4670 For WTPs that support multiple Frame Encapsulation Types, it is 4671 useful to save the value configured by the AC. The Frame 4672 Encapsulation Type is defined in Section 4.6.43. 4674 4.9.3. LastRebootReason 4676 The reason why the WTP last rebooted, defined in Section 4.6.47. 4678 4.9.4. MacType 4680 For WTPs that support multiple MAC Types, it is useful to save the 4681 value configured by the AC. The MACType is defined in 4682 Section 4.6.44. 4684 4.9.5. PreferredACs 4686 The preferred ACs, with the index, defined in Section 4.6.5. 4688 4.9.6. RebootCount 4690 The number of times the WTP has rebooted, defined in Section 4.6.47. 4692 4.9.7. Static IP Address 4694 The static IP Address assigned to the WTP, as configured by the WTP 4695 Static IP Address Information message element (see Section 4.6.48). 4697 4.9.8. WTPLinkFailureCount 4699 The number of times the link to the AC has failed, see 4700 Section 4.6.47. 4702 4.9.9. WTPLocation 4704 The WTP Location, defined in Section 4.6.30. 4706 4.9.10. WTPName 4708 The WTP Name, defined in Section 4.6.45. 4710 5. CAPWAP Discovery Operations 4712 The Discovery messages are used by a WTP to determine which ACs are 4713 available to provide service, and the capabilities and load of the 4714 ACs. 4716 5.1. Discovery Request Message 4718 The Discovery Request message is used by the WTP to automatically 4719 discover potential ACs available in the network. The Discovery 4720 Request message provides ACs with the primary capabilities of the 4721 WTP. A WTP must exchange this information to ensure subsequent 4722 exchanges with the ACs are consistent with the WTP's functional 4723 characteristics. 4725 Discovery Request messages MUST be sent by a WTP in the Discover 4726 state after waiting for a random delay less than 4727 MaxDiscoveryInterval, after a WTP first comes up or is 4728 (re)initialized. A WTP MUST send no more than the maximum of 4729 MaxDiscoveries Discovery Request messages, waiting for a random delay 4730 less than MaxDiscoveryInterval between each successive message. 4732 This is to prevent an explosion of WTP Discovery Request messages. 4733 An example of this occurring is when many WTPs are powered on at the 4734 same time. 4736 If a Discovery Response message is not received after sending the 4737 maximum number of Discovery Request messages, the WTP enters the 4738 Sulking state and MUST wait for an interval equal to SilentInterval 4739 before sending further Discovery Request messages. 4741 Upon receiving a Discovery Request message, the AC will respond with 4742 a Discovery Response message sent to the address in the source 4743 address of the received Discovery Request message. Once a Discovery 4744 Response has been received, if the WTP decides to establish a session 4745 with the responding AC, it SHOULD perform an MTU discovery, using the 4746 process described in Section 3.5. 4748 It is possible for the AC to receive a cleartext Discovery Request 4749 message while a DTLS session is already active with the WTP. This is 4750 most likely the case if the WTP has rebooted, perhaps due to a 4751 software or power failure, but could also be caused by a DoS attack. 4752 In such cases, any WTP state, including the state machine instance, 4753 MUST NOT be cleared until another DTLS session has been successfully 4754 established, communicated via the DTLSSessionEstablished DTLS 4755 notification (see Section 2.3.2.2). 4757 The binding specific WTP Radio Information message element (see 4758 Section 2.1) is included in the Discovery Request message to 4759 advertise WTP support for one or more CAPWAP bindings. 4761 The Discovery Request message is sent by the WTP when in the 4762 Discovery State. The AC does not transmit this message. 4764 The following message elements MUST be included in the Discovery 4765 Request message: 4767 o Discovery Type, see Section 4.6.21 4769 o WTP Board Data, see Section 4.6.40 4771 o WTP Descriptor, see Section 4.6.41 4773 o WTP Frame Tunnel Mode, see Section 4.6.43 4775 o WTP MAC Type, see Section 4.6.44 4777 o WTP Radio Information message element(s)that the WTP supports; 4778 These are defined by the individual link layer CAPWAP Binding 4779 Protocols (see Section 2.1). 4781 The following message elements MAY be included in the Discovery 4782 Request message: 4784 o MTU Discovery Padding, see Section 4.6.32 4786 o Vendor Specific Payload, see Section 4.6.39 4788 5.2. Discovery Response Message 4790 The Discovery Response message provides a mechanism for an AC to 4791 advertise its services to requesting WTPs. 4793 When a WTP receives a Discovery Response message, it MUST wait for an 4794 interval not less than DiscoveryInterval for receipt of additional 4795 Discovery Response messages. After the DiscoveryInterval elapses, 4796 the WTP enters the DTLS-Init state and selects one of the ACs that 4797 sent a Discovery Response message and send a DTLS Handshake to that 4798 AC. 4800 One or more binding specific WTP Radio Information message elements 4801 (see Section 2.1) are included in the Discovery Request message to 4802 advertise AC support for the CAPWAP bindings. The AC MAY include 4803 only the bindings it shares in common with the WTP, known through the 4804 WTP Radio Information message elements received in the Discovery 4805 Request message, or it MAY include all of the bindings supported. 4807 The WTP MAY use the supported bindings in its AC decision process. 4808 Note that if the WTP joins an AC that does not support a specific 4809 CAPWAP binding, service for that binding MUST NOT be provided by the 4810 WTP. 4812 The Discovery Response message is sent by the AC when in the Idle 4813 State. The WTP does not transmit this message. 4815 The following message elements MUST be included in the Discovery 4816 Response Message: 4818 o AC Descriptor, see Section 4.6.1 4820 o AC Name, see Section 4.6.4 4822 o WTP Radio Information message element(s)that the AC supports; 4823 These are defined by the individual link layer CAPWAP Binding 4824 Protocols (see Section 2.1 for more information). 4826 o One of the following message elements MUST be included in the 4827 Discovery Response Message: 4829 * CAPWAP Control IPv4 Address, see Section 4.6.9 4831 * CAPWAP Control IPv6 Address, see Section 4.6.10 4833 The following message elements MAY be included in the Discovery 4834 Response message: 4836 o Vendor Specific Payload, see Section 4.6.39 4838 5.3. Primary Discovery Request Message 4840 The Primary Discovery Request message is sent by the WTP to determine 4841 whether its preferred (or primary) AC is available or to perform a 4842 Path MTU Discovery (see section Section 3.5. 4844 A Primary Discovery Request message is sent by a WTP when it has a 4845 primary AC configured, and is connected to another AC. This 4846 generally occurs as a result of a failover, and is used by the WTP as 4847 a means to discover when its primary AC becomes available. Since the 4848 WTP only has a single instance of the CAPWAP state machine, the 4849 Primary Discovery Request is sent by the WTP when in the Run State. 4850 The AC does not transmit this message. 4852 The frequency of the Primary Discovery Request messages should be no 4853 more often than the sending of the Echo Request message. 4855 Upon receipt of a Primary Discovery Request message, the AC responds 4856 with a Primary Discovery Response message sent to the address in the 4857 source address of the received Primary Discovery Request message. 4859 The following message elements MUST be included in the Primary 4860 Discovery Request message. 4862 o Discovery Type, see Section 4.6.21 4864 o WTP Board Data, see Section 4.6.40 4866 o WTP Descriptor, see Section 4.6.41 4868 o WTP Frame Tunnel Mode, see Section 4.6.43 4870 o WTP MAC Type, see Section 4.6.44 4872 o WTP Radio Information message element(s)that the WTP supports; 4873 These are defined by the individual link layer CAPWAP Binding 4874 Protocols (see Section 2.1 for more information). 4876 The following message elements MAY be included in the Primary 4877 Discovery Request message: 4879 o MTU Discovery Padding, see Section 4.6.32 4881 o Vendor Specific Payload, see Section 4.6.39 4883 5.4. Primary Discovery Response 4885 The Primary Discovery Response message enables an AC to advertise its 4886 availability and services to requesting WTPs that are configured to 4887 have the AC as its primary AC. 4889 The Primary Discovery Response message is sent by an AC after 4890 receiving a Primary Discovery Request message. 4892 When a WTP receives a Primary Discovery Response message, it may 4893 establish a CAPWAP protocol connection to its primary AC, based on 4894 the configuration of the WTP Fallback Status message element on the 4895 WTP. 4897 The Primary Discovery Response message is sent by the AC when in the 4898 Idle State. The WTP does not transmit this message. 4900 The following message elements MUST be included in the Primary 4901 Discovery Response message. 4903 o AC Descriptor, see Section 4.6.1 4905 o AC Name, see Section 4.6.4 4907 o WTP Radio Information message element(s)that the AC supports; 4908 These are defined by the individual link layer CAPWAP Binding 4909 Protocols (see Section 2.1 for more information). 4911 One of the following message elements MUST be included in the 4912 Discovery Response Message: 4914 o CAPWAP Control IPv4 Address, see Section 4.6.9 4916 o CAPWAP Control IPv6 Address, see Section 4.6.10 4918 The following message elements MAY be included in the Primary 4919 Discovery Response message: 4921 o Vendor Specific Payload, see Section 4.6.39 4923 6. CAPWAP Join Operations 4925 The Join Request message is used by a WTP to request service from an 4926 AC after a DTLS connection is established to that AC. The Join 4927 Response message is used by the AC to indicate that it will or will 4928 not provide service. 4930 6.1. Join Request 4932 The Join Request message is used by a WTP to request service through 4933 the AC. If the WTP is performing the optional AC discovery process 4934 (see Section 3.3), the join process occurs after the WTP has received 4935 one or more Discovery Response messages. During the discovery 4936 process, an AC MAY return more than one CAPWAP Control IPv4 Address 4937 or CAPWAP Control IPv6 Address message elements. When more than one 4938 such message element is returned, the WTP SHOULD perform "load 4939 balancing" by choosing the interface that is servicing the least 4940 number of WTPs (known through the WTP Count field of the message 4941 element). Note, however, that other load balancing algorithms are 4942 also permitted. Once the WTP has determined its preferred AC, and 4943 its associated interface, to connect to, it establishes the DTLS 4944 session, and transmits the Join Request over the secured control 4945 channel. When an AC receives a Join Request message it responds with 4946 a Join Response message. 4948 Upon completion of the DTLS handshake, and receiving the 4949 DTLSEstablished notification, the WTP sends the Join Request message 4950 to the AC. When the AC is notified of the DTLS session 4951 establishment, it does not clear the WaitDTLS timer until it has 4952 received the Join Request message, at which time it sends a Join 4953 Response message to the WTP, indicating success or failure. 4955 One or more WTP Radio Information message elements (see Section 2.1) 4956 are included in the Join Request to request service for the CAPWAP 4957 bindings by the AC. Including a binding that is unsupported by the 4958 AC will result in a failed Join Response. 4960 If the AC rejects the Join Request, it sends a Join Response message 4961 with a failure indication and initiates an abort of the DTLS session 4962 via the DTLSAbort command. 4964 If an invalid (i.e. malformed) Join Request message is received, the 4965 message MUST be silently discarded by the AC. No response is sent to 4966 the WTP. The AC SHOULD log this event. 4968 The Join Request is sent by the WTP when in the Join State. The AC 4969 does not transmit this message. 4971 The following message elements MUST be included in the Join Request 4972 message. 4974 o Location Data, see Section 4.6.30 4976 o WTP Board Data, see Section 4.6.40 4978 o WTP Descriptor, see Section 4.6.41 4980 o WTP Name, see Section 4.6.45 4982 o Session ID, see Section 4.6.37 4984 o WTP Frame Tunnel Mode, see Section 4.6.43 4986 o WTP MAC Type, see Section 4.6.44 4988 o WTP Radio Information message element(s)that the WTP supports; 4989 These are defined by the individual link layer CAPWAP Binding 4990 Protocols (see Section 2.1 for more information). 4992 o ECN Support, see Section 4.6.25 4994 At least one of the following message element MUST be included in the 4995 Join Request message. 4997 o CAPWAP Local IPv4 Address, see Section 4.6.11 4999 o CAPWAP Local IPv6 Address, see Section 4.6.12 5001 The following message element MAY be included in the Join Request 5002 message. 5004 o CAPWAP Transport Protocol, see Section 4.6.14 5006 o Maximum Message Length, see Section 4.6.31 5008 o WTP Reboot Statistics, see Section 4.6.47 5010 o Vendor Specific Payload, see Section 4.6.39 5012 6.2. Join Response 5014 The Join Response message is sent by the AC to indicate to a WTP that 5015 it is capable and willing to provide service to the WTP. 5017 The WTP, receiving a Join Response message, checks for success or 5018 failure. If the message indicates success, the WTP clears the 5019 WaitDTLS timer for the session and proceeds to the Configure state. 5021 If the WaitDTLS Timer expires prior to reception of the Join Response 5022 message, the WTP MUST terminate the handshake, deallocate session 5023 state and initiate the DTLSAbort command. 5025 If an invalid (malformed) Join Response message is received, the WTP 5026 SHOULD log an informative message detailing the error. This error 5027 MUST be treated in the same manner as AC non-responsiveness. The 5028 WaitDTLS timer will eventually expire, and the WTP MAY (if it is so 5029 configured) attempts to join a new AC. 5031 If one of the WTP Radio Information message elements (see 5032 Section 2.1) in the Join Request message requested support for a 5033 CAPWAP binding which the AC does not support, the AC sets the Result 5034 Code message element to "Binding Not Supported". 5036 The AC includes the Image Identifier message element to indicate the 5037 software version it expects the WTP to run. This information is used 5038 to determine whether the WTP MUST either change its currently running 5039 firmware image, or download a new version (see Section 9.1.1). 5041 The Join Response message is sent by the AC when in the Join State. 5042 The WTP does not transmit this message. 5044 The following message elements MUST be included in the Join Response 5045 message. 5047 o Result Code, see Section 4.6.35 5049 o AC Descriptor, see Section 4.6.1 5051 o AC Name, see Section 4.6.4 5053 o WTP Radio Information message element(s)that the AC supports; 5054 These are defined by the individual link layer CAPWAP Binding 5055 Protocols (see Section 2.1). 5057 o ECN Support, see Section 4.6.25 5059 One of the following message elements MUST be included in the Join 5060 Response Message: 5062 o CAPWAP Control IPv4 Address, see Section 4.6.9 5064 o CAPWAP Control IPv6 Address, see Section 4.6.10 5066 One of the following message elements MUST be included in the Join 5067 Response Message: 5069 o CAPWAP Local IPv4 Address, see Section 4.6.11 5071 o CAPWAP Local IPv6 Address, see Section 4.6.12 5073 The following message elements MAY be included in the Join Response 5074 message. 5076 o AC IPv4 List, see Section 4.6.2 5078 o AC IPv6 List, see Section 4.6.3 5080 o CAPWAP Transport Protocol, see Section 4.6.14 5082 o Image Identifier, see Section 4.6.27 5084 o Maximum Message Length, see Section 4.6.31 5086 o Vendor Specific Payload, see Section 4.6.39 5088 7. Control Channel Management 5090 The Control Channel Management messages are used by the WTP and AC to 5091 maintain a control communication channel. CAPWAP control messages, 5092 such as the WTP Event Request message sent from the WTP to the AC 5093 indicate to the AC that the WTP is operational. When such control 5094 messages are not being sent, the Echo Request and Echo Response 5095 messages are used to maintain the control communication channel. 5097 7.1. Echo Request 5099 The Echo Request message is a keep-alive mechanism for CAPWAP control 5100 messages. 5102 Echo Request messages are sent periodically by a WTP in the Image 5103 Data or Run state (see Section 2.3) to determine the state of the 5104 control connection between the WTP and the AC. The Echo Request 5105 message is sent by the WTP when the EchoInterval timer expires. 5107 The Echo Request message is sent by the WTP when in the Run State. 5108 The AC does not transmit this message. 5110 The following message elements MAY be included in the Echo Request 5111 message: 5113 o Vendor Specific Payload, see Section 4.6.39 5115 When an AC receives an Echo Request message it responds with an Echo 5116 Response message. 5118 7.2. Echo Response 5120 The Echo Response message acknowledges the Echo Request message. 5122 An Echo Response message is sent by an AC after receiving an Echo 5123 Request message. After transmitting the Echo Response message, the 5124 AC SHOULD reset its EchoInterval timer (see Section 4.7.7. If 5125 another Echo Request message or other control message is not received 5126 by the AC when the timer expires, the AC SHOULD consider the WTP to 5127 be no longer reachable. 5129 The Echo Response message is sent by the AC when in the Run State. 5130 The WTP does not transmit this message. 5132 The following message elements MAY be included in the Echo Response 5133 message: 5135 o Vendor Specific Payload, see Section 4.6.39 5137 When a WTP receives an Echo Response message it initializes the 5138 EchoInterval to the configured value. 5140 8. WTP Configuration Management 5142 WTP Configuration messages are used to exchange configuration 5143 information between the AC and the WTP. 5145 8.1. Configuration Consistency 5147 The CAPWAP protocol provides flexibility in how WTP configuration is 5148 managed. A WTP can behave in one of two ways, which is 5149 implementation specific: 5151 1. The WTP retains no configuration and accepts the configuration 5152 provided by the AC. 5154 2. The WTP saves the configuration of parameters provided by the AC 5155 that are non-default values into local non-volatile memory, and 5156 are enforced during the WTP's power up initialization phase. 5158 If the WTP opts to save configuration locally, the CAPWAP protocol 5159 state machine defines the Configure state, which allows for 5160 configuration exchange. In the Configure state, the WTP sends its 5161 current configuration overrides to the AC via the Configuration 5162 Status Request message. A configuration override is a non-default 5163 parameter. As an example, in the CAPWAP protocol, the default 5164 antenna configuration is internal omni antenna. A WTP that either 5165 has no internal antennas, or has been explicitly configured by the AC 5166 to use external antennas, sends its antenna configuration during the 5167 configure phase, allowing the AC to become aware of the WTP's current 5168 configuration. 5170 Once the WTP has provided its configuration to the AC, the AC sends 5171 its configuration to the WTP. This allows the WTP to receive 5172 configuration and policies from the AC. 5174 The AC maintains a copy of each active WTP configuration. There is 5175 no need for versioning or other means to identify configuration 5176 changes. If a WTP becomes inactive, the AC MAY delete the inactive 5177 WTP configuration. If a WTP fails, and connects to a new AC, the WTP 5178 provides its overridden configuration parameters, allowing the new AC 5179 to be aware of the WTP configuration. 5181 This model allows for resiliency in case of an AC failure, ensuring 5182 another AC can provide service to the WTP. A new AC would be 5183 automatically updated with WTP configuration changes, eliminating the 5184 need for inter-AC communication and the need for all ACs to be aware 5185 of the configuration of all WTPs in the network. 5187 Once the CAPWAP protocol enters the Run state, the WTPs begin to 5188 provide service. It is common for administrators to require that 5189 configuration changes be made while the network is operational. 5190 Therefore, the Configuration Update Request is sent by the AC to the 5191 WTP to make these changes at run-time. 5193 8.1.1. Configuration Flexibility 5195 The CAPWAP protocol provides the flexibility to configure and manage 5196 WTPs of varying design and functional characteristics. When a WTP 5197 first discovers an AC, it provides primary functional information 5198 relating to its type of MAC and to the nature of frames to be 5199 exchanged. The AC configures the WTP appropriately. The AC also 5200 establishes corresponding internal state for the WTP. 5202 8.2. Configuration Status Request 5204 The Configuration Status Request message is sent by a WTP to deliver 5205 its current configuration to the AC. 5207 The Configuration Status Request message carries binding specific 5208 message elements. Refer to the appropriate binding for the 5209 definition of this structure. 5211 When an AC receives a Configuration Status Request message it acts 5212 upon the content of the message and responds to the WTP with a 5213 Configuration Status Response message. 5215 The Configuration Status Request message includes multiple Radio 5216 Administrative State message elements, one for the WTP, and one for 5217 each radio in the WTP. 5219 The Configuration Status Request message is sent by the WTP when in 5220 the Configure State. The AC does not transmit this message. 5222 The following message elements MUST be included in the Configuration 5223 Status Request message. 5225 o AC Name, see Section 4.6.4 5227 o Radio Administrative State, see Section 4.6.33 5229 o Statistics Timer, see Section 4.6.38 5231 o WTP Reboot Statistics, see Section 4.6.47 5233 The following message elements MAY be included in the Configuration 5234 Status Request message. 5236 o AC Name with Priority, see Section 4.6.5 5238 o CAPWAP Transport Protocol, see Section 4.6.14 5240 o WTP Static IP Address Information, see Section 4.6.48 5242 o Vendor Specific Payload, see Section 4.6.39 5244 8.3. Configuration Status Response 5246 The Configuration Status Response message is sent by an AC and 5247 provides a mechanism for the AC to override a WTP's requested 5248 configuration. 5250 A Configuration Status Response message is sent by an AC after 5251 receiving a Configuration Status Request message. 5253 The Configuration Status Response message carries binding specific 5254 message elements. Refer to the appropriate binding for the 5255 definition of this structure. 5257 When a WTP receives a Configuration Status Response message it acts 5258 upon the content of the message, as appropriate. If the 5259 Configuration Status Response message includes a Radio Operational 5260 State message element that causes a change in the operational state 5261 of one of the radios, the WTP transmits a Change State Event to the 5262 AC, as an acknowledgement of the change in state. 5264 The Configuration Status Response message is sent by the AC when in 5265 the Configure State. The WTP does not transmit this message. 5267 The following message elements MUST be included in the Configuration 5268 Status Response message. 5270 o CAPWAP Timers, see Section 4.6.13 5272 o Decryption Error Report Period, see Section 4.6.18 5274 o Idle Timeout, see Section 4.6.24 5276 o WTP Fallback, see Section 4.6.42 5278 One or both of the following message elements MUST be included in the 5279 Configuration Status Response Message: 5281 o AC IPv4 List, see Section 4.6.2 5282 o AC IPv6 List, see Section 4.6.3 5284 The following message element MAY be included in the Configuration 5285 Status Response message. 5287 o WTP Static IP Address Information, see Section 4.6.48 5289 o Vendor Specific Payload, see Section 4.6.39 5291 8.4. Configuration Update Request 5293 Configuration Update Request messages are sent by the AC to provision 5294 the WTP while in the Run state. This is used to modify the 5295 configuration of the WTP while it is operational. 5297 When a WTP receives a Configuration Update Request message, it 5298 responds with a Configuration Update Response message, with a Result 5299 Code message element indicating the result of the configuration 5300 request. 5302 The AC includes the Image Identifier message element (see 5303 Section 4.6.27) to force the WTP to update its firmware while in the 5304 Run state. The WTP MAY proceed to download the requested firmware if 5305 it determines the version specified in the Image Identifier message 5306 element is not in its non-volatile storage by transmitting an Image 5307 Data Request (see Section 9.1.1) that includes the Initiate Download 5308 message element (see Section 4.6.29). 5310 The Configuration Update Request is sent by the AC when in the Run 5311 State. The WTP does not transmit this message. 5313 One or more of the following message elements MAY be included in the 5314 Configuration Update message. 5316 o AC Name with Priority, see Section 4.6.5 5318 o AC Timestamp, see Section 4.6.6 5320 o Add MAC ACL Entry, see Section 4.6.7 5322 o CAPWAP Timers, see Section 4.6.13 5324 o Decryption Error Report Period, see Section 4.6.18 5326 o Delete MAC ACL Entry, see Section 4.6.19 5328 o Idle Timeout, see Section 4.6.24 5329 o Location Data, see Section 4.6.30 5331 o Radio Administrative State, see Section 4.6.33 5333 o Statistics Timer, see Section 4.6.38 5335 o WTP Fallback, see Section 4.6.42 5337 o WTP Name, see Section 4.6.45 5339 o WTP Static IP Address Information, see Section 4.6.48 5341 o Image Identifier, see Section 4.6.27 5343 o Vendor Specific Payload, see Section 4.6.39 5345 8.5. Configuration Update Response 5347 The Configuration Update Response message is the acknowledgement 5348 message for the Configuration Update Request message. 5350 The Configuration Update Response message is sent by a WTP after 5351 receiving a Configuration Update Request message. 5353 When an AC receives a Configuration Update Response message the 5354 result code indicates if the WTP successfully accepted the 5355 configuration. 5357 The Configuration Update Response message is sent by the WTP when in 5358 the Run State. The AC does not transmit this message. 5360 The following message element MUST be present in the Configuration 5361 Update message. 5363 Result Code, see Section 4.6.35 5365 The following message elements MAY be present in the Configuration 5366 Update Response message. 5368 o Radio Operational State, see Section 4.6.34 5370 o Vendor Specific Payload, see Section 4.6.39 5372 8.6. Change State Event Request 5374 The Change State Event Request message is used by the WTP for two 5375 main purposes: 5377 o When sent by the WTP following the reception of a Configuration 5378 Status Response message from the AC, the WTP uses the Change State 5379 Event Request message to provide an update on the WTP radio's 5380 operational state and to confirm that the configuration provided 5381 by the AC was successfully applied. 5383 o When sent during the Run state, the WTP uses the Change State 5384 Event Request message to notify the AC of an unexpected change in 5385 the WTP's radio operational state. 5387 When an AC receives a Change State Event Request message it responds 5388 with a Change State Event Response message and modifies its data 5389 structures for the WTP as needed. The AC MAY decide not to provide 5390 service to the WTP if it receives an error, based on local policy, 5391 and to transition to the Reset state. 5393 The Change State Event Request message is sent by a WTP to 5394 acknowledge or report an error condition to the AC for a requested 5395 configuration in the Configuration Status Response message. The 5396 Change State Event Request message includes the Result Code message 5397 element, which indicates whether the configuration was successfully 5398 applied. If the WTP is unable to apply a specific configuration 5399 request, it indicates the failure by including one or more Returned 5400 Message Element message elements (see Section 4.6.36). 5402 The Change State Event Request message is sent by the WTP in the 5403 Configure or Run State. The AC does not transmit this message. 5405 The WTP MAY save its configuration to persistent storage prior to 5406 transmitting the response. However, this is implementation specific 5407 and is not required. 5409 The following message elements MUST be present in the Change State 5410 Event Request message. 5412 o Radio Operational State, see Section 4.6.34 5414 o Result Code, see Section 4.6.35 5416 One or more of the following message elements MAY be present in the 5417 Change State Event Request message. 5419 o Returned Message Element(s), see Section 4.6.36 5421 o Vendor Specific Payload, see Section 4.6.39 5423 8.7. Change State Event Response 5425 The Change State Event Response message acknowledges the Change State 5426 Event Request message. 5428 A Change State Event Response message is sent by an AC in response to 5429 a Change State Event Request message. 5431 The Change State Event Response message is sent by the AC when in the 5432 Configure or Run state. The WTP does not transmit this message. 5434 The following message elements MAY be included in the Change State 5435 Event Response message: 5437 o Vendor Specific Payload, see Section 4.6.39 5439 The WTP does not take any action upon receipt of the Change State 5440 Event Response message. 5442 8.8. Clear Configuration Request 5444 The Clear Configuration Request message is used to reset the WTP 5445 configuration. 5447 The Clear Configuration Request message is sent by an AC to request 5448 that a WTP reset its configuration to the manufacturing default 5449 configuration. The Clear Config Request message is sent while in the 5450 Run state. 5452 The Clear Configuration Request is sent by the AC when in the Run 5453 State. The WTP does not transmit this message. 5455 The following message elements MAY be included in the Clear 5456 Configuration Request message: 5458 o Vendor Specific Payload, see Section 4.6.39 5460 When a WTP receives a Clear Configuration Request message it resets 5461 its configuration to the manufacturing default configuration. 5463 8.9. Clear Configuration Response 5465 The Clear Configuration Response message is sent by the WTP after 5466 receiving a Clear Configuration Request message and resetting its 5467 configuration parameters to the manufacturing default values. 5469 The Clear Configuration Response is sent by the WTP when in the Run 5470 State. The AC does not transmit this message. 5472 The Clear Configuration Response message MUST include the following 5473 message element. 5475 o Result Code, see Section 4.6.35 5477 The following message elements MAY be included in the Clear 5478 Configuration Request message: 5480 o Vendor Specific Payload, see Section 4.6.39 5482 9. Device Management Operations 5484 This section defines CAPWAP operations responsible for debugging, 5485 gathering statistics, logging, and firmware management. The 5486 management operations defined in this section are used by the AC to 5487 either push/pull information to/from the WTP, or request that the WTP 5488 reboot. This section does not deal with the management of the AC per 5489 se, and assumes that the AC is operational and configured. 5491 9.1. Firmware Management 5493 This section describes the firmware download procedures used by the 5494 CAPWAP protocol. Firmware download can occur during the Image Data 5495 or Run state. The former allows the download to occur at boot time, 5496 while the latter is used to trigger the download while an active 5497 CAPWAP session exists. It is important to note that the CAPWAP 5498 protocol does not provide the ability for the AC to identify whether 5499 the firmware information provided by the WTP is correct, nor whether 5500 the WTP is properly storing the firmware (see Section 12.10 for more 5501 information. 5503 Figure 6 provides an example of a WTP that performs a firmware 5504 upgrade while in the Image Data state. In this example, the WTP does 5505 not already have the requested firmware (Image Identifier = x), and 5506 downloads the image from the AC. 5508 WTP AC 5510 Join Request 5511 --------------------------------------------------------> 5513 Join Response (Image Identifier = x) 5514 <------------------------------------------------------ 5516 Image Data Request (Image Identifier = x, 5517 Initiate Download) 5518 --------------------------------------------------------> 5520 Image Data Response (Result Code = Success, 5521 Image Information = {size,hash}) 5522 <------------------------------------------------------ 5524 Image Data Request (Image Data = Data) 5525 <------------------------------------------------------ 5527 Image Data Response (Result Code = Success) 5528 --------------------------------------------------------> 5530 ..... 5532 Image Data Request (Image Data = EOF) 5533 <------------------------------------------------------ 5535 Image Data Response (Result Code = Success) 5536 --------------------------------------------------------> 5538 (WTP enters the Reset State) 5540 Figure 6: WTP Firmware Download Case 1 5542 Figure 7 provides an example in which the WTP has the image specified 5543 by the AC in its non-volative storage, but is not its current running 5544 image. In this case, the WTP opts to NOT download the firmware and 5545 immediately reset to the requested image. 5547 WTP AC 5549 Join Request 5550 --------------------------------------------------------> 5552 Join Response (Image Identifier = x) 5553 <------------------------------------------------------ 5555 (WTP enters the Reset State) 5557 Figure 7: WTP Firmware Download Case 2 5559 Figure 8 provides an example of a WTP that performs a firmware 5560 upgrade while in the Run state. This mode of firmware upgrade allows 5561 the WTP to download its image while continuing to provide service. 5562 The WTP will not automatically reset until it is notified by the AC, 5563 with a Reset Request message. 5565 WTP AC 5567 Configuration Update Request (Image Identifier = x) 5568 <------------------------------------------------------ 5570 Configuration Update Response (Result Code = Success) 5571 --------------------------------------------------------> 5573 Image Data Request (Image Identifier = x, 5574 Initiate Download) 5575 --------------------------------------------------------> 5577 Image Data Response (Result Code = Success, 5578 Image Information = {size,hash}) 5579 <------------------------------------------------------ 5581 Image Data Request (Image Data = Data) 5582 <------------------------------------------------------ 5584 Image Data Response (Result Code = Success) 5585 --------------------------------------------------------> 5587 ..... 5589 Image Data Request (Image Data = EOF) 5590 <------------------------------------------------------ 5592 Image Data Response (Result Code = Success) 5593 --------------------------------------------------------> 5595 ..... 5597 (administratively requested reboot request) 5598 Reset Request (Image Identifier = x) 5599 <------------------------------------------------------ 5601 Reset Response (Result Code = Success) 5602 --------------------------------------------------------> 5604 Figure 8: WTP Firmware Download Case 3 5606 Figure 9 provides another example of the firmware download while in 5607 the Run state. In this example, the WTP already has the image 5608 specified by the AC in its non-volative storage. The WTP opts to NOT 5609 download the firmware. The WTP resets upon receipt of a Reset 5610 Request message from the AC. 5612 WTP AC 5614 Configuration Update Request (Image Identifier = x) 5615 <------------------------------------------------------ 5617 Configuration Update Response (Result Code = Already Have Image) 5618 --------------------------------------------------------> 5620 ..... 5622 (administratively requested reboot request) 5623 Reset Request (Image Identifier = x) 5624 <------------------------------------------------------ 5626 Reset Response (Result Code = Success) 5627 --------------------------------------------------------> 5629 Figure 9: WTP Firmware Download Case 4 5631 9.1.1. Image Data Request 5633 The Image Data Request message is used to update firmware on the WTP. 5634 This message and its companion Response message are used by the AC to 5635 ensure that the image being run on each WTP is appropriate. 5637 Image Data Request messages are exchanged between the WTP and the AC 5638 to download a new firmware image to the WTP. When a WTP or AC 5639 receives an Image Data Request message it responds with an Image Data 5640 Response message. The message elements contained within the Image 5641 Data Request message are required to determine the intent of the 5642 request. 5644 The decision that new firmware is to be downloaded to the WTP can 5645 occur in one of two ways: 5647 When the WTP joins the AC, the Join Response message includes the 5648 Image Identifier message element, which informs the WTP of the 5649 firmware it is expected to run. if the WTP does not currently have 5650 the requested firmware version, it transmits an Image Data Request 5651 message, with the appropriate Image Identifier message element. 5652 If the WTP already has the requested firmware in its non-volatile 5653 flash, but is not its currently running image, it simply resets to 5654 run the proper firmware. 5656 Once the WTP is in the Run state, it is possible for the AC to 5657 cause the WTP to initiate a firmware download by sending an 5658 Configuration Update Request message with the Image Identifier 5659 message elements. This will cause the WTP to transmit an Image 5660 Data Request with the Image Identifier and the Initiate Download 5661 message elements. Note that when the firmware is downloaded in 5662 this way, the WTP does not automatically reset after the download 5663 is complete. The WTP will only reset when it receives a Reset 5664 Request message from the AC. If the WTP already had the requested 5665 firmware version in its non-volatile storage, the WTP does not 5666 transmit the Image Data Request message and responds with a 5667 Configuration Update Response message with the Result Code set to 5668 Image Already Present. 5670 Regardless of how the download was initiated, once the AC receives an 5671 Image Data Request message with the Image Identifier message element, 5672 it begins the transfer process by transmitting an Image Data Request 5673 message that includes the Image Data message element. This continues 5674 until the firmware image has been transferred. 5676 The Image Data Request message is sent by the WTP or the AC when in 5677 the Image Data or Run State. 5679 The following message elements MAY be included in the Image Data 5680 Request message. 5682 o CAPWAP Transport Protocol, see Section 4.6.14 5684 o Image Data, see Section 4.6.26 5686 o Vendor Specific Payload, see Section 4.6.39 5688 The following message elements MAY be included in the Image Data 5689 Request message when sent by the WTP. 5691 o Image Identifier, see Section 4.6.27 5693 o Initiate Download, see Section 4.6.29 5695 9.1.2. Image Data Response 5697 The Image Data Response message acknowledges the Image Data Request 5698 message. 5700 An Image Data Response message is sent in response to a received 5701 Image Data Request message. Its purpose is to acknowledge the 5702 receipt of the Image Data Request message. The Result Code is 5703 included to indicate whether a previously sent Image Data Request 5704 message was invalid. 5706 The Image Data Response message is sent by the WTP or the AC when in 5707 the Image Data or Run State. 5709 The following message element MUST be included in the Image Data 5710 Response message. 5712 o Result Code, see Section 4.6.35 5714 The following message elements MAY be included in the Image Data 5715 Response message. 5717 o Vendor Specific Payload, see Section 4.6.39 5719 The following message elements MAY be included in the Image Data 5720 Response message when sent by the AC. 5722 o Image Information, see Section 4.6.28 5724 Upon receiving an Image Data Response message indicating an error, 5725 the WTP MAY retransmit a previous Image Data Request message, or 5726 abandon the firmware download to the WTP by transitioning to the 5727 Reset state. 5729 9.2. Reset Request 5731 The Reset Request message is used to cause a WTP to reboot. 5733 A Reset Request message is sent by an AC to cause a WTP to 5734 reinitialize its operation. If the AC includes the Image Identifier 5735 message element (see Section 4.6.27), it indicates to the WTP that it 5736 SHOULD use that version of software upon reboot. 5738 The Reset Request is sent by the AC when in the Run State. The WTP 5739 does not transmit this message. 5741 The following message elements MUST be included in the Reset Request 5742 message. 5744 o Image Identifier, see Section 4.6.27 5746 The following message elements MAY be included in the Reset Request 5747 message: 5749 o Vendor Specific Payload, see Section 4.6.39 5751 When a WTP receives a Reset Request message, it responds with a Reset 5752 Response message indicating success and then reinitialize itself. If 5753 the WTP is unable to write to its non-volatile storage, to ensure 5754 that it runs the requested software version indicated in the Image 5755 Identifier message element, it MAY send the appropriate Result Code 5756 message element, but MUST reboot. If the WTP is unable to reset, 5757 including a hardware reset, it sends a Reset Response message to the 5758 AC with a Result Code message element indicating failure. The AC no 5759 longer provides service to the WTP. 5761 9.3. Reset Response 5763 The Reset Response message acknowledges the Reset Request message. 5765 A Reset Response message is sent by the WTP after receiving a Reset 5766 Request message. 5768 The Reset Response is sent by the WTP when in the Run State. The AC 5769 does not transmit this message. 5771 The following message element MAY be included in the Reset Response 5772 message. 5774 o Result Code, see Section 4.6.35 5776 o Vendor Specific Payload, see Section 4.6.39 5778 When an AC receives a successful Reset Response message, it is 5779 notified that the WTP will reinitialize its operation. An AC that 5780 receives a Reset Response message indicating failure may opt to no 5781 longer provide service to the WTP. 5783 9.4. WTP Event Request 5785 The WTP Event Request message is used by a WTP to send information to 5786 its AC. The WTP Event Request message MAY be sent periodically, or 5787 sent in response to an asynchronous event on the WTP. For example, a 5788 WTP MAY collect statistics and use the WTP Event Request message to 5789 transmit the statistics to the AC. 5791 When an AC receives a WTP Event Request message it will respond with 5792 a WTP Event Response message. 5794 The presence of the Delete Station message element is used by the WTP 5795 to inform the AC that it is no longer providing service to the 5796 station. This could be the result of an Idle Timeout (see 5797 Section 4.6.24), due to resource shortages, or some other reason. 5799 The WTP Event Request message is sent by the WTP when in the Run 5800 State. The AC does not transmit this message. 5802 The WTP Event Request message MUST contain one of the message 5803 elements listed below, or a message element that is defined for a 5804 specific wireless technology. More than one of each message element 5805 listed MAY be included in the WTP Event Request message. 5807 o Decryption Error Report, see Section 4.6.17 5809 o Duplicate IPv4 Address, see Section 4.6.22 5811 o Duplicate IPv6 Address, see Section 4.6.23 5813 o WTP Radio Statistics, see Section 4.6.46 5815 o WTP Reboot Statistics, see Section 4.6.47 5817 o Delete Station, see Section 4.6.20 5819 o Vendor Specific Payload, see Section 4.6.39 5821 9.5. WTP Event Response 5823 The WTP Event Response message acknowledges receipt of the WTP Event 5824 Request message. 5826 A WTP Event Response message is sent by an AC after receiving a WTP 5827 Event Request message. 5829 The WTP Event Response message is sent by the AC when in the Run 5830 State. The WTP does not transmit this message. 5832 The following message elements MAY be included in the WTP Event 5833 Response message: 5835 o Vendor Specific Payload, see Section 4.6.39 5837 9.6. Data Transfer 5839 This section describes the data transfer procedures used by the 5840 CAPWAP protocol. The data transfer mechanism is used to upload 5841 information available at the WTP to the AC, such as crash or debug 5842 information. The data transfer messages can only be exchanged while 5843 in the Run state. 5845 Figure 10 provides an example of an AC that requests that the WTP 5846 transfer its latest crash file. Once the WTP acknowledges that it 5847 has information to send, via the Data Transfer Response, it transmits 5848 its own Data Transfer Request. Upon receipt, the AC responds with a 5849 Data Transfer Response, and the exchange continues until the WTP 5850 transmits a Data Transfer Data message element that indicates an End 5851 of File (EOF). 5853 WTP AC 5855 Data Transfer Request (Data Transfer Mode = Crash Data) 5856 <------------------------------------------------------ 5858 Data Transfer Response (Result Code = Success) 5859 --------------------------------------------------------> 5861 Data Transfer Request (Data Transfer Data = Data) 5862 --------------------------------------------------------> 5864 Data Transfer Response (Result Code = Success) 5865 <------------------------------------------------------ 5867 ..... 5869 Data Transfer Request (Data Transfer Data = EOF) 5870 --------------------------------------------------------> 5872 Data Transfer Response (Result Code = Success) 5873 <------------------------------------------------------ 5875 Figure 10: WTP Data Transfer Case 1 5877 Figure 11 provides an example of an AC that requests that the WTP 5878 transfer its latest crash file. However, in this example, the WTP 5879 does not have any crash information to send, and therefore sends a 5880 Data Transfer Response with a Result Code indicating the error. 5882 WTP AC 5884 Data Transfer Request (Data Transfer Mode = Crash Data) 5885 <------------------------------------------------------ 5887 Data Transfer Response (Result Code = Data Transfer 5888 Error (No Information to Transfer)) 5889 --------------------------------------------------------> 5891 Figure 11: WTP Data Transfer Case 2 5893 9.6.1. Data Transfer Request 5895 The Data Transfer Request message is used to deliver debug 5896 information from the WTP to the AC. 5898 The Data Transfer Request messages can be sent either by the AC or 5899 the WTP. When sent by the AC, it is used to request that data be 5900 transmitted from the WTP to the AC, and includes the Data Transfer 5901 Mode message element, which specifies the information desired by the 5902 AC. The Data Transfer Request is sent by the WTP in order to 5903 transfer actual data to the AC, through the Data Transfer Data 5904 message element. 5906 Given that the CAPWAP protocol minimizes the need for WTPs to be 5907 directly managed, the Data Transfer Request is an important 5908 troubleshooting tool used by the AC to retrieve information that may 5909 be available on the WTP. For instance, some WTPs implementations may 5910 store crash information to help manufacturers identify software 5911 faults. The Data Transfer Request message can be used to send such 5912 information from the WTP to the AC. Another possible use would be to 5913 allow a remote debugger function in the WTP to use the Data Transfer 5914 Request message to send console output to the AC for debugging 5915 purposes. 5917 When the WTP or AC receives a Data Transfer Request message it 5918 responds to the WTP with a Data Transfer Response message. The AC 5919 MAY log the information received through the Data Transfer Data 5920 message element. 5922 The Data Transfer Request message is sent by the WTP or AC when in 5923 the Run State. 5925 When sent by the AC, the Data Transfer Request message MUST contain 5926 the following message elements: 5928 o Data Transfer Mode, see Section 4.6.16 5930 When sent by the WTP, the Data Transfer Request message MUST contain 5931 the following message elements: 5933 o Data Transfer Data, see Section 4.6.15 5935 Regardless of whether the Data Transfer Request is sent by the AC or 5936 WTP, the following message elements MAY be included in the Data 5937 Transfer Request message: 5939 o Vendor Specific Payload, see Section 4.6.39 5941 9.6.2. Data Transfer Response 5943 The Data Transfer Response message acknowledges the Data Transfer 5944 Request message. 5946 A Data Transfer Response message is sent in response to a received 5947 Data Transfer Request message. Its purpose is to acknowledge receipt 5948 of the Data Transfer Request message. When sent by the WTP, the 5949 Result Code message element is used to indicate whether the data 5950 transfer requested by the AC can be completed. When sent by the AC, 5951 the Result Code message element is used to indicate receipt of the 5952 data transfered in the Data Transfer Request message. 5954 The Data Transfer Response message is sent by the WTP or AC when in 5955 the Run State. 5957 The following message element MUST be included in the Data Transfer 5958 Response message. 5960 o Result Code, see Section 4.6.35 5962 The following message elements MAY be included in the Data Transfer 5963 Response message: 5965 o Vendor Specific Payload, see Section 4.6.39 5967 Upon receipt of a Data Transfer Response message, the WTP transmits 5968 more information, if more information is available. 5970 10. Station Session Management 5972 Messages in this section are used by the AC to create, modify or 5973 delete station session state on the WTPs. 5975 10.1. Station Configuration Request 5977 The Station Configuration Request message is used to create, modify 5978 or delete station session state on a WTP. The message is sent by the 5979 AC to the WTP, and MAY contain one or more message elements. The 5980 message elements for this CAPWAP control message include information 5981 that is generally highly technology specific. Refer to the 5982 appropriate binding document for definitions of the messages elements 5983 that are included in this control message. 5985 The Station Configuration Request message is sent by the AC when in 5986 the Run State. The WTP does not transmit this message. 5988 The following CAPWAP Control message elements MAY be included in the 5989 Station Configuration Request message. More than one of each message 5990 element listed MAY be included in the Station Configuration Request 5991 message. 5993 o Add Station, see Section 4.6.8 5995 o Delete Station, see Section 4.6.20 5997 o Vendor Specific Payload, see Section 4.6.39 5999 10.2. Station Configuration Response 6001 The Station Configuration Response message is used to acknowledge a 6002 previously received Station Configuration Request message. 6004 The Station Configuration Response message is sent by the WTP when in 6005 the Run State. The AC does not transmit this message. 6007 The following message element MUST be present in the Station 6008 Configuration Response message. 6010 o Result Code, see Section 4.6.35 6012 The following message elements MAY be included in the Station 6013 Configuration Response message: 6015 o Vendor Specific Payload, see Section 4.6.39 6017 The Result Code message element indicates that the requested 6018 configuration was successfully applied, or that an error related to 6019 processing of the Station Configuration Request message occurred on 6020 the WTP. 6022 11. NAT Considerations 6024 There are three specific situations in which a NAT deployment may be 6025 used in conjunction with a CAPWAP-enabled deployment. The first 6026 consists of a configuration in which a single WTP is behind a NAT 6027 system. Since all communication is initiated by the WTP, and all 6028 communication is performed over IP using two UDP ports, the protocol 6029 easily traverses NAT systems in this configuration. 6031 In the second case, two or more WTPs are deployed behind the same NAT 6032 system. Here, the AC would receive multiple connection requests from 6033 the same IP address, and therefore cannot use the WTP's IP address 6034 alone to bind the CAPWAP control and data channel. The CAPWAP Data 6035 Check state, which establishes the data plane connection and 6036 communicates the CAPWAP Data Channel Keepalive, includes the Session 6037 Identifier message element, which is used to bind the control and 6038 data plane. Use of the Session Identifier message element enables 6039 the AC to match the control and data plane flows from multiple WTPs 6040 behind the same NAT system (multiple WTPs sharing the same IP 6041 address). CAPWAP implementations MUST also use DTLS session 6042 information on any encrypted CAPWAP channel to validate the source of 6043 both the control and data plane, as described in Section 12.2. 6045 In the third configuration, the AC is deployed behind a NAT. In this 6046 case, the AC is not reachable by the WTP unless a specific rule has 6047 been configured on the NAT to translate the address and redirect 6048 CAPWAP messages to the AC. This deployment presents two issues. 6049 First, an AC communicates its interfaces and corresponding WTP load 6050 using the CAPWAP Control IPv4 Address and CAPWAP Control IPv6 Address 6051 message elements. This message element is mandatory, but contains IP 6052 addresses that are only valid in the private address space used by 6053 the AC, which is not reachable by the WTP. The WTP MUST NOT utilize 6054 the information in these message elements if it detects a NAT (as 6055 described in the CAPWAP Transport Protocol message element in 6056 Section 4.6.14). Second, since the addresses cannot be used by the 6057 WTP, this effectively disables the load balancing capabilities (see 6058 Section 6.1) of the CAPWAP protocol. Alternatively, the AC could 6059 have a configured NAT'ed address, which it would include in either of 6060 the two control address message elements, and the NAT would need to 6061 be configured accordingly. 6063 In order for a CAPWAP WTP or AC to detect whether a middlebox is 6064 present, both the Join Request (see Section 6.1) and the Join 6065 Response (see Section 6.2) include either the CAPWAP Local IPv4 6066 Address (see Section 4.6.11), or the CAPWAP Local IPv6 Address (see 6067 Section 4.6.12) message element. Upon receiving one of these 6068 messages, if the packet's source IP address differs from the address 6069 found in either one of these message elements, it indicates that a 6070 middlebox is present. 6072 In order for CAPWAP to be compatible with potential middleboxes in 6073 the network, CAPWAP implementations MUST send return traffic from the 6074 same port on which it received traffic from a given peer. Further, 6075 any unsolicited requests generated by a CAPWAP node MUST be sent on 6076 the same port. 6078 Note that this middlebox detection technique is not foolproof. If 6079 the public IP address assigned to the NAT is identical to the private 6080 IP address used by the AC, detection by the WTP would fail. This 6081 failure can lead to various protocol errors, so it is therefore 6082 necessary for deployments to ensure that the NAT's IP address is not 6083 the same as the ACs. 6085 The CAPWAP protocol allows for all of the AC identities supporting a 6086 group of WTPs to be communicated through the AC List message element. 6087 This feature MUST be ignored by the WTP when it detects the AC is 6088 behind a middlebox. 6090 The CAPWAP protocol allows an AC to configure a static IP address on 6091 a WTP using the WTP Static IP Address Information message element. 6092 This message element SHOULD NOT be used in NAT'ed environments, 6093 unless the administrator is familiar with the internal IP addressing 6094 scheme within the WTP's private network, and does not rely on the 6095 public address seen by the AC. 6097 When a WTP detects the duplicate address condition, it generates a 6098 message to the AC, which includes the Duplicate IP Address message 6099 element. The IP Address embedded within this message element is 6100 different from the public IP address seen by the AC. 6102 12. Security Considerations 6104 This section describes security considerations for the CAPWAP 6105 protocol. It also provides security recommendations for protocols 6106 used in conjunction with CAPWAP. 6108 12.1. CAPWAP Security 6110 As it is currently specified, the CAPWAP protocol sits between the 6111 security mechanisms specified by the wireless link layer protocol 6112 (e.g.IEEE 802.11i) and AAA. One goal of CAPWAP is to bootstrap trust 6113 between the STA and WTP using a series of preestablished trust 6114 relationships: 6116 STA WTP AC AAA 6117 ============================================== 6119 DTLS Cred AAA Cred 6120 <------------><-------------> 6122 EAP Credential 6123 <------------------------------------------> 6125 wireless link layer 6126 (e.g.802.11 PTK) 6127 <--------------> or 6128 <---------------------------> 6129 (derived) 6131 Figure 12: STA Session Setup 6133 Within CAPWAP, DTLS is used to secure the link between the WTP and 6134 AC. In addition to securing control messages, it's also a link in 6135 this chain of trust for establishing link layer keys. Consequently, 6136 much rests on the security of DTLS. 6138 In some CAPWAP deployment scenarios, there are two channels between 6139 the WTP and AC: the control channel, carrying CAPWAP control 6140 messages, and the data channel, over which client data packets are 6141 tunneled between the AC and WTP. Typically, the control channel is 6142 secured by DTLS, while the data channel is not. 6144 The use of parallel protected and unprotected channels deserves 6145 special consideration, but does not create a threat. There are two 6146 potential concerns: attempting to convert protected data into un- 6147 protected data and attempting to convert un-protected data into 6148 protected data. These concerns are addressed below. 6150 12.1.1. Converting Protected Data into Unprotected Data 6152 Since CAPWAP does not support authentication-only ciphers (i.e. all 6153 supported ciphersuites include encryption and authentication), it is 6154 not possible to convert protected data into unprotected data. Since 6155 encrypted data is (ideally) indistinguishable from random data, the 6156 probability of an encrypted packet passing for a well-formed packet 6157 is effectively zero. 6159 12.1.2. Converting Unprotected Data into Protected Data (Insertion) 6161 The use of message authentication makes it impossible for the 6162 attacker to forge protected records. This makes conversion of 6163 unprotected records to protected records impossible. 6165 12.1.3. Deletion of Protected Records 6167 An attacker could remove protected records from the stream, though 6168 not undetectably so, due the built-in reliability of the underlying 6169 CAPWAP protocol. In the worst case, the attacker would remove the 6170 same record repeatedly, resulting in a CAPWAP session timeout and 6171 restart. This is effectively a DoS attack, and could be accomplished 6172 by a man in the middle regardless of the CAPWAP protocol security 6173 mechanisms chosen. 6175 12.1.4. Insertion of Unprotected Records 6177 An attacker could inject packets into the unprotected channel, but 6178 this may become evident if sequence number desynchronization occurs 6179 as a result. Only if the attacker is a MiM can packets be inserted 6180 undetectably. This is a consequence of that channel's lack of 6181 protection, and not a new threat resulting from the CAPWAP security 6182 mechanism. 6184 12.1.5. Use of MD5 6186 The Image Information Section 4.6.28) message element makes use of 6187 MD5 to compute the hash field. The authenticity and integrity of the 6188 image file is protected by DTLS, and in this context, MD5 is not used 6189 as a cryptographically secure hash, but just as a basic checksum. 6190 Therefore, the use of MD5 is not considered a security vulnerability, 6191 and no mechanisms for algorithm agility are provided. 6193 12.1.6. CAPWAP Fragmentation 6195 RFC 4963 [RFC4963] describes a possible security vulnerability where 6196 a malicious entity can "corrupt" a flow by injecting fragments. By 6197 sending "high" fragments (those with offset greater than zero) with a 6198 forged source address, the attacker can deliberately cause 6199 corruption. The use of DTLS on the CAPWAP Data channel can be used 6200 to avoid this possible vulnerability. 6202 12.2. Session ID Security 6204 Since DTLS does not export a unique session identifier, there can be 6205 no explicit protocol binding between the DTLS layer and CAPWAP layer. 6206 As a result, implementations MUST provide a mechanism for performing 6207 this binding. For example, an AC MUST NOT associate decrypted DTLS 6208 control packets with a particular WTP session based solely on the 6209 Session ID in the packet header. Instead, identification should be 6210 done based on which DTLS session decrypted the packet. Otherwise one 6211 authenticated WTP could spoof another authenticated WTP by altering 6212 the Session ID in the encrypted CAPWAP header. 6214 It should be noted that when the CAPWAP data channel is unencrypted, 6215 the WTP Session ID is exposed and possibly known to adversaries and 6216 other WTPs. This would allow the forgery of the source of data- 6217 channel traffic. This, however, should not be a surprise for 6218 unencrypted data channels. When the data channel is encrypted, the 6219 Session ID is not exposed, and therefore can safely be used to 6220 associate a data and control channel. The 128-bit length of the 6221 Session ID mitigates online guessing attacks where an adversarial, 6222 authenticated WTP tries to correlate his own data channel with 6223 another WTP's control channel. Note that for encrypted data 6224 channels, the Session ID should only be used for correlation for the 6225 first packet immediately after the initial DTLS handshake. Future 6226 correlation should instead be done via identification of a packet's 6227 DTLS session. 6229 12.3. Discovery or DTLS Setup Attacks 6231 Since the Discovery Request messages are sent in the clear, it is 6232 important that AC implementations NOT assume that receiving a 6233 Discovery Request message from a WTP implies that the WTP has 6234 rebooted, and consequently tear down any active DTLS sessions. 6235 Discovery Request messages can easily be spoofed by malicious 6236 devices, so it is important that the AC maintain two separate sets of 6237 states for the WTP until the DTLSSessionEstablished notification is 6238 received, indicating that the WTP was authenticated. Once a new DTLS 6239 session is successfully established, any state referring to the old 6240 session can be cleared. 6242 Similarly, entering the DTLS Setup phase SHOULD NOT assume that the 6243 WTP has reset, and therefore should not discard active state until 6244 the DTLS session has been successfully established. While the 6245 HelloVerifyRequest provides some protection against denial of service 6246 (DoS) attacks on the AC, an adversary capable of receiving packets at 6247 a valid address (or a malfunctioning or misconfigured WTP) may 6248 repeatedly attempt DTLS handshakes with the AC, potentially creating 6249 a resource shortage. If either the FailedDTLSSessionCount or the 6250 FailedDTLSAuthFailCount counter reaches the value of 6251 MaxFailedDTLSSessionRetry variable (see Section 4.8), implementations 6252 MAY choose to rate-limit new DTLS handshakes for some period of time. 6253 It is RECOMMENDED that implementations choosing to implement rate 6254 limiting use a random discard technique, rather than mimicking the 6255 WTP's sulking behavior. This will ensure that messages from valid 6256 WTPs will have some probability of eliciting a response, even in the 6257 face of a significant DoS attack. 6259 Some CAPWAP implementations may wish to restrict the DTLS setup 6260 process to only those peers that have been configured in the access 6261 control list, authorizing only those clients to initiate a DTLS 6262 handshake. Note that the impact of this on mitigating denial of 6263 service attacks against the DTLS layer is minimal, because DTLS 6264 already uses client-side cookies to minimize processor consumption 6265 attacks. 6267 12.4. Interference with a DTLS Session 6269 If a WTP or AC repeatedly receives packets which fail DTLS 6270 authentication or decryption, this could indicate a DTLS 6271 desynchronization between the AC and WTP, a link prone to 6272 undetectable bit errors, or an attacker trying to disrupt a DTLS 6273 session. 6275 In the state machine (section 2.3), transitions to the DTLS tear down 6276 state can be triggered by frequently receiving DTLS packets with 6277 authentication or decryption errors. The threshold or technique for 6278 deciding when to move to the tear down state should be chosen 6279 carefully. Being able to easily transition to DTLS TD allows easy 6280 detection of malfunctioning devices, but allows for denial of service 6281 attacks. Making it difficult to transition to DTLS TD prevents 6282 denial of service attacks, but makes it more difficult to detect and 6283 reset a malfunctioning session. Implementers should set this policy 6284 with care. 6286 12.5. CAPWAP Pre-Provisioning 6288 In order for CAPWAP to establish a secure communication with a peer, 6289 some level of pre-provisioning on both the WTP and AC is necessary. 6290 This section will detail the minimal number of configuration 6291 parameters. 6293 When using preshared keys, it is necessary to configure the preshared 6294 key for each possible peer with which a DTLS session may be 6295 established. To support this mode of operation, one or more entries 6296 of the following table may be configured on either the AC or WTP: 6298 o Identity: The identity of the peering AC or WTP. This format MAY 6299 be either in the form of an IP address or host name (the latter of 6300 which needs to be resolved to an IP address using DNS). 6302 o Key: The pre-shared key for use with the peer when establishing 6303 the DTLS session (see Section 12.6 for more information). 6305 o PSK Identity: Identity hint associated with the provisioned key 6306 (see Section 2.4.4.4 for more information). 6308 When using certificates, the following items need to be pre- 6309 provisioned: 6311 o Device Certificate: The local device's certificate (see 6312 Section 12.7 for more information) 6314 o Trust Anchor: Trusted root certificate chain used to validate any 6315 certificate received from CAPWAP peers. Note that one or more 6316 root certificate MAY be configured on a given device. 6318 Regardless of the authentication method, the following items need to 6319 be pre-provisioned: 6321 o Access Control List: The access control list table contains the 6322 identities of one or more CAPWAP peers, along with a rule. The 6323 rule is used to determine whether communication with the peer is 6324 permitted (see Section 2.4.4.3 for more information). 6326 12.6. Use of Preshared Keys in CAPWAP 6328 While use of preshared keys may provide deployment and provisioning 6329 advantages not found in public key based deployments, it also 6330 introduces a number of operational and security concerns. In 6331 particular, because the keys must typically be entered manually, it 6332 is common for people to base them on memorable words or phrases. 6333 These are referred to as "low entropy passwords/passphrases". 6335 Use of low-entropy preshared keys, coupled with the fact that the 6336 keys are often not frequently updated, tends to significantly 6337 increase exposure. For these reasons, the following recommendations 6338 are made: 6340 o When DTLS is used with a preshared-key (PSK) ciphersuite, each WTP 6341 SHOULD have a unique PSK. Since WTPs will likely be widely 6342 deployed, their physical security is not guaranteed. If PSKs are 6343 not unique for each WTP, key reuse would allow the compromise of 6344 one WTP to result in the compromise of others 6346 o Generating PSKs from low entropy passwords is NOT RECOMMENDED. 6348 o It is RECOMMENDED that implementations that allow the 6349 administrator to manually configure the PSK also provide a 6350 capability for generation of new random PSKs, taking RFC 4086 6351 [RFC4086] into account. 6353 o Preshared keys SHOULD be periodically updated. Implementations 6354 MAY facilitate this by providing an administrative interface for 6355 automatic key generation and periodic update, or it MAY be 6356 accomplished manually instead. 6358 Every pairwise combination of WTP and AC on the network SHOULD have a 6359 unique PSK. This prevents the domino effect (see Guidance for AAA 6360 Key Management [RFC4962]). If PSKs are tied to specific WTPs, then 6361 knowledge of the PSK implies a binding to a specified identity that 6362 can be authorized. 6364 If PSKs are shared, this binding between device and identity is no 6365 longer possible. Compromise of one WTP can yield compromise of 6366 another WTP, violating the CAPWAP security hierarchy. Consequently, 6367 sharing keys between WTPs is NOT RECOMMENDED. 6369 12.7. Use of Certificates in CAPWAP 6371 For public-key-based DTLS deployments, each device SHOULD have unique 6372 credentials, with an extended key usage authorizing the device to act 6373 as either a WTP or AC. If devices do not have unique credentials, it 6374 is possible that by compromising one device, any other device using 6375 the same credential may also be considered to be compromised. 6377 Certificate validation involves checking a large variety of things. 6378 Since the necessary things to validate are often environment- 6379 specific, many are beyond the scope of this document. In this 6380 section, we provide some basic guidance on certificate validation. 6382 Each device is responsible for authenticating and authorizing devices 6383 with which they communicate. Authentication entails validation of 6384 the chain of trust leading to the peer certificate, followed by the 6385 peer certificate itself. Implementations SHOULD also provide a 6386 secure method for verifying that the credential in question has not 6387 been revoked. 6389 Note that if the WTP relies on the AC for network connectivity (e.g. 6391 the AC is a layer 2 switch to which the WTP is directly connected), 6392 the WTP may not be able to contact an OCSP server or otherwise obtain 6393 an up to date CRL if a compromised AC doesn't explicitly permit this. 6394 This cannot be avoided, except through effective physical security 6395 and monitoring measures at the AC. 6397 Proper validation of certificates typically requires checking to 6398 ensure the certificate has not yet expired. If devices have a real- 6399 time clock, they SHOULD verify the certificate validity dates. If no 6400 real-time clock is available, the device SHOULD make a best-effort 6401 attempt to validate the certificate validity dates through other 6402 means. Failure to check a certificate's temporal validity can make a 6403 device vulnerable to man-in-the-middle attacks launched using 6404 compromised, expired certificates, and therefore devices should make 6405 every effort to perform this validation. 6407 12.8. Use of MAC Address in CN Field 6409 The CAPWAP protocol is an evolution of an existing protocol 6410 [I-D.ohara-capwap-lwapp] which is implemented on a large number of 6411 already deployed ACs and WTPs. Everyone of these devices have an 6412 existing X.509 certificate, which is provisioned at manufacturing 6413 time. These X.509 certificates use the device's MAC Address in the 6414 Common Name (CN) field. It is well understood that encoding the MAC 6415 Address in the CN field is less than optimal, and using the 6416 SubjectAltName field would be preferable. However, at the time of 6417 publication, there is no URN specification that allows for the MAC 6418 Address to be used in the SubjectAltName field. As such a 6419 specification is published by the IETF, future versions of the CAPWAP 6420 protocol MAY require support for the new URN scheme. 6422 12.9. AAA Security 6424 The AAA protocol is used to distribute EAP keys to the ACs, and 6425 consequently its security is important to the overall system 6426 security. When used with TLS or IPsec, security guidelines specified 6427 in RFC 3539 [RFC3539] SHOULD be followed. 6429 In general, the link between the AC and AAA server SHOULD be secured 6430 using a strong ciphersuite keyed with mutually authenticated session 6431 keys. Implementations SHOULD NOT rely solely on Basic RADIUS shared 6432 secret authentication as it is often vulnerable to dictionary 6433 attacks, but rather SHOULD use stronger underlying security 6434 mechanisms. 6436 12.10. WTP Firmware 6438 The CAPWAP protocol defines a mechanism by which the AC downloads new 6439 firmware to the WTP. During the session establishment process, the 6440 WTP provides information about its current firmware to the AC. The 6441 AC then decides whether the WTP's firmware needs to be updated. It 6442 is important to note that the CAPWAP specification makes the explicit 6443 assumption that the WTP is providing the correct firmware version to 6444 the AC, and is therefore not lying. Fruther, during the firmware 6445 download process, the CAPWAP protocol does not provide any mechanisms 6446 to recognize whether the WTP is actually storing the firmware for 6447 future use. 6449 13. Operational Considerations 6451 The CAPWAP protocol assumes that it is the only configuration 6452 interface to the WTP to configure parameters that are specified in 6453 the CAPWAP specifications. While the use of a separate management 6454 protocol MAY be used for the purposes of monitoring the WTP directly, 6455 configuring the WTP through a separate management interface is not 6456 recommended. Configuring the WTP through a separate protocol, such 6457 as via a CLI or SNMP, could lead to the AC state being out of sync 6458 with the WTP. 6460 The CAPWAP protocol does not deal with the management of the ACs. 6461 The AC is assumed to be configured through some separate management 6462 interface, which could be via a proprietary CLI, SNMP, NETCONF or 6463 some other management protocol. 6465 The CAPWAP protocol's control channel is fairly light weight from a 6466 traffic perspective. Once the WTP has been configured, the WTP sends 6467 periodic statistics. Further, the specification calls for a 6468 keepalive packet to be sent on the protocol's data channel to make 6469 sure that any possible middleboxes (e.g., NAT) maintain their UDP 6470 state. The overhead associated with the control and data channel is 6471 not expected to impact network traffic. That said, the CAPWAP 6472 protocol does allow for the frequency of these packets to be modified 6473 through the DataChannelKeepAlive and StatisticsTimer (see 6474 Section 4.7.2 and Section 4.7.14, respectively). 6476 14. Transport Considerations 6478 The CAPWAP WG carefully considered the congestion control 6479 requirements of the CAPWAP protocol, both for the CAPWAP control and 6480 data channels. 6482 CAPWAP specifies a single-threaded command/response protocol to be 6483 used on the control channel, and we have specified that an 6484 exponential back-off algorithm should be used when commands are 6485 retransmitted. When CAPWAP runs in its default mode (Local MAC), the 6486 control channel is the only CAPWAP channel. 6488 However, CAPWAP can also be run in Split MAC mode, in which case 6489 there will be a DTLS-encrypted data channel between each WTP and the 6490 AC. The WG discussed various options for providing congestion 6491 control on this channel. However, due to performance problems with 6492 TCP when it is run over another congestion control mechanism and the 6493 fact that the vast majority of traffic run over the CAPWAP data 6494 channel is likely to be congestion-controlled IP traffic, the CAPWAP 6495 WG felt that specifying a congestion control mechanism for the CAPWAP 6496 data channel would be more likely to cause problems than to resolve 6497 any. 6499 Because there is no congestion control mechanism specified for the 6500 CAPWAP data channel, it is RECOMMENDED that non-congestion-controlled 6501 traffic not be tunneled over CAPWAP. When a significant amount of 6502 non-congestion-controlled traffic is expected to be present on a 6503 WLAN, the CAPWAP connection between the AC and the WTP for that LAN 6504 should be configured to remain in Local MAC mode with Distribution 6505 function at the WTP. 6507 The lock step nature of the CAPWAP protocol's control channel can 6508 cause the firmware download process to take some time, depending upon 6509 the RTT. This is not expected to be a problem since the CAPWAP 6510 protocol allows firmware to be downloaded while the WTP provides 6511 service to wireless clients/devices. 6513 It is necessary for the WTP and AC to configure their MTU based on 6514 the capabilities of the path. See Section 3.5 for more information. 6516 The CAPWAP protocol mandates support of the Explicit Congestion 6517 Notification (ECN) through a mode of operation named "limited 6518 functionality option", detailed in section 9.1.1 of [RFC3168]. 6519 Future versions of the CAPWAP protocol should consider mandating 6520 support for the "full functionality option". 6522 15. IANA Considerations 6524 This section details the actions to be taken by IANA during the 6525 publication of the specification. There are numerous registries that 6526 need to be created, and the contents, document action (see [RFC5226], 6527 and registry format are all included below. Note that in cases where 6528 bit fields are referred to, the bit numbering is left to right, where 6529 the leftmost bit is labelled as bit zero (0). 6531 For registration requests where an Expert Review is required, a 6532 Designated Expert should be consulted, which is appointed by the 6533 responsible IESG area director. The intention is that any allocation 6534 will be accompanied by a published RFC, but given that other SDOs may 6535 want to create standards built on top of CAPWAP, a document the 6536 Designated Expert can review is also acceptable. IANA should allow 6537 for allocation of values prior to documents being approved for 6538 publication, so the Designated Expert can approve allocations once it 6539 seems clear that publication will occur. The Designated expert will 6540 post a request to the CAPWAP WG mailing list (or a successor 6541 designated by the Area Director) for comment and review. Before a 6542 period of 30 days has passed, the Designated Expert will either 6543 approve or deny the registration request and publish a notice of the 6544 decision to the CAPWAP WG mailing list or its successor, as well as 6545 informing IANA. A denial notice must be justified by an explanation, 6546 and in the cases where it is possible, concrete suggestions on how 6547 the request can be modified so as to become acceptable should be 6548 provided. 6550 15.1. IPv4 Multicast Address 6552 This document requires a new IPv4 multicast address called 6553 "capwap-ac" from the Local Network Control Block IPv4 multicast 6554 address registry [to be removed upon publication 6555 http://www.iana.org/assignments/multicast-addresses]. The new 6556 multicast address is to replace the text xx.xx.xx.xx in Section 3.3. 6558 15.2. IPv6 Multicast Address 6560 This document requires a new organization local multicast address 6561 called the "All ACs multicast address" from the Variable Scope IPv6 6562 multicast address registry [to be removed upon publication 6563 http://www.iana.org/assignments/ipv6-multicast-addresses]. The new 6564 multicast address is to be inserted in Section 3.3. 6566 15.3. UDP Port 6568 This document requires a two UDP Ports organization local multicast 6569 address from the registered port numbers registry [to be removed upon 6570 publication http://www.iana.org/assignments/port-numbers]. The new 6571 UDP Ports numbers have already been assigned and can be found in 6572 Section 3.1. The following values are being registered: 6574 Keyword Decimal Description References 6575 ------- ------- ----------- ---------- 6576 capwap-control 5246/udp CAPWAP Control Protocol This Document 6577 capwap-data 5247/udp CAPWAP Data Protocol This Document 6579 15.4. CAPWAP Message Types 6581 The Message Type field in the CAPWAP header (see Section 4.5.1.1) is 6582 used to identify the operation performed by the message. There are 6583 multiple namespaces, which is identified via the first three octets 6584 of the field containing the IANA Enterprise Number [RFC5226]. 6586 IANA will create and maintain the CAPWAP Message Types registry for 6587 all message types whose Enterprise Number is set to zero (0). The 6588 namespace is 8 bits (0-255), where the value of zero (0) is reserved 6589 and must not be assigned. The values one (1) through 26 are 6590 allocated in this specification, and can be found in Section 4.5.1.1. 6591 Any new assignments of a CAPWAP Message Type, whose Enterprise Number 6592 is set to zero (0) requires a Expert Review. The format of the 6593 registry to be maintained by IANA has the following format: 6595 CAPWAP Control Message Message Type Reference 6596 Value 6598 15.5. CAPWAP Header Flags 6600 The Flags field in the CAPWAP header (see Section 4.3) is 9 bits in 6601 length and is used to identify any special treatment related to the 6602 message. This specification defines bits zero (0) through five (5), 6603 while bits six (6) through eight (8) are reserved. There are 6604 currently three unused, reserved bits which are managed by IANA and 6605 whose assignment requires a Expert Review. IANA will create the 6606 CAPWAP Header Flags registry, whose format is: 6608 Flag Field Name Bit Position Reference 6610 15.6. CAPWAP Control Message Flags 6612 The Flags field in the CAPWAP Control Message header (see 6613 Section 4.5.1.4) is used to identify any special treatment related to 6614 the control message. There are currently eight (8) unused, reserved 6615 bits. These bits whose assignment is managed by IANA and requires a 6616 Expert Review. IANA will create the CAPWAP Control Message Flags 6617 registry, whose format is: 6619 Flag Field Name Bit Position Reference 6621 15.7. CAPWAP Message Element Type 6623 The Type field in the CAPWAP Message Element header (see Section 4.6) 6624 is used to identify the data being transported. The namespace is 16 6625 bits (0-65535), where the value of zero (0) is reserved and must not 6626 be assigned. The values one (1) through 53 are allocated in this 6627 specification, and can be found in Section 4.5.1.1. 6629 The 16 bit namespace is further divided into blocks of addresses that 6630 are reserved for specific CAPWAP wireless bindings. The following 6631 blocks are reserved: 6633 CAPWAP Protocol Message Elements 1 - 1023 6634 IEEE 802.11 Message Elements 1024 - 2047 6635 EPCGlobal Message Elements 3072 - 4095 6637 This namespace is managed by IANA and assignments require a Expert 6638 Review. IANA will create the CAPWAP Message Element Type registry, 6639 whose format is: 6641 CAPWAP Message Element Type Value Reference 6643 15.8. Wireless Binding Identifiers 6645 The Wireless Binding Identifier (WBID) field in the CAPWAP header 6646 (see Section 4.3) is used to identify the wireless technology 6647 associated with the packet. This specification allocates the values 6648 one (1) and three (3). Due to the limited address space available, a 6649 new WBID request requires Expert Review. IANA will create the CAPWAP 6650 Wireless Binding Identifier registry, whose format is: 6652 CAPWAP Wireless Binding Identifier Type Value Reference 6654 15.9. AC Security Types 6656 The Security field in the AC Descriptor message element (see 6657 Section 4.6.1) is 8 bits in length and used to identify the 6658 authentication methods available on the AC. This specification 6659 defines bits five (5) and six (6), while bits zero (0) through four 6660 (4) as well as bit seven (7) are reserved and unused. These reserved 6661 bits are managed by IANA and assignment requires a Standards Action. 6662 IANA will create the AC Security Types registry, whose format is: 6664 AC Security Type Bit Position Reference 6666 15.10. AC DTLS Policy 6668 The DTLS Policy field in the AC Descriptor message element (see 6669 Section 4.6.1) is 8 bits in length and used to identify whether the 6670 CAPWAP Data Channel is to be secured. This specification defines 6671 bits five (5) and six (6), while bits zero (0) through four (4) as 6672 well as bit seven (7) are reserved and unused. These reserved bits 6673 are managed by IANA and assignment requires a Standards Action. IANA 6674 will create the AC DTLS Policy registry, whose format is: 6676 AC DTLS Policy Bit Position Reference 6678 15.11. AC Information Type 6680 The Information Type field in the AC Descriptor message element (see 6681 Section 4.6.1) is used to represent information about the AC. The 6682 namespace is 16 bits (0-65535), where the value of zero (0) is 6683 reserved and must not be assigned. This field, combined with the AC 6684 Information Vendor ID, allows vendors to use a private namespace. 6685 This specification defines the AC Information Type namespace when the 6686 AC Information Vendor ID is set to zero (0), for which the values 6687 four (4) and five (5) are allocated in this specification, and can be 6688 found in Section 4.6.1. This namespace is managed by IANA and 6689 assignments require a Expert Review. IANA will create the AC 6690 Information Type registry, whose format is: 6692 AC Information Type Type Value Reference 6694 15.12. CAPWAP Transport Protocol Types 6696 The Transport field in the CAPWAP Transport Protocol message element 6697 (see Section 4.6.14) is used to identify the transport to use for the 6698 CAPWAP Data Channel. The namespace is 8 bits (0-255), where the 6699 value of zero (0) is reserved and must not be assigned. The values 6700 one (1) and two (2) are allocated in this specification, and can be 6701 found in Section 4.6.14. This namespace is managed by IANA and 6702 assignments require a Expert Review. IANA will create the CAPWAP 6703 Transport Protocol Types registry, whose format is: 6705 CAPWAP Transport Protocol Type Type Value Reference 6707 15.13. Data Transfer Type 6709 The Data Type field in the Data Transfer Data message element (see 6710 Section 4.6.15) and Image Data message element (see Section 4.6.26) 6711 is used to provide information about the data being carried. The 6712 namespace is 8 bits (0-255), where the value of zero (0) is reserved 6713 and must not be assigned. The values one (1), two (2) and five (5) 6714 are allocated in this specification, and can be found in 6715 Section 4.6.15. This namespace is managed by IANA and assignments 6716 require a Expert Review. IANA will create the Data Transfer Type 6717 registry, whose format is: 6719 Data Transfer Type Type Value Reference 6721 15.14. Data Transfer Mode 6723 The Data Mode field in the Data Transfer Data message element (see 6724 Section 4.6.15) and Data Transfer Mode message element (see 6725 Section 15.14) is used to provide information about the data being 6726 carried. The namespace is 8 bits (0-255), where the value of zero 6727 (0) is reserved and must not be assigned. The values one (1) and two 6728 (2) are allocated in this specification, and can be found in 6729 Section 15.14. This namespace is managed by IANA and assignments 6730 require a Expert Review. IANA will create the Data Transfer Mode 6731 registry, whose format is: 6733 Data Transfer Mode Type Value Reference 6735 15.15. Discovery Types 6737 The Discovery Type field in the Discovery Type message element (see 6738 Section 4.6.21) is used by the WTP to indicate to the AC how it was 6739 discovered. The namespace is 8 bits (0-255). The values zero (0) 6740 through four (4) are allocated in this specification, and can be 6741 found in Section 4.6.21. This namespace is managed by IANA and 6742 assignments require a Expert Review. IANA will create the Discovery 6743 Types registry, whose format is: 6745 Discovery Types Type Value Reference 6747 15.16. ECN Support 6749 The ECN Support field in the ECN Support message element (see 6750 Section 4.6.25) is used by the WTP to represent its ECN Support. The 6751 namespace is 8 bits (0-255). The values zero (0) and one (1) are 6752 allocated in this specification, and can be found in Section 4.6.25. 6753 This namespace is managed by IANA and assignments require a Expert 6754 Review. IANA will create the ECN Support registry, whose format is: 6756 ECN Support Type Value Reference 6758 15.17. Radio Admin State 6760 The Radio Admin field in the Radio Administrative State message 6761 element (see Section 4.6.33) is used by the WTP to represent the 6762 state of its radios. The namespace is 8 bits (0-255), where the 6763 value of zero (0) is reserved and must not be assigned. The values 6764 one (1) and two (2) are allocated in this specification, and can be 6765 found in Section 4.6.33. This namespace is managed by IANA and 6766 assignments require a Expert Review. IANA will create the Radio 6767 Admin State registry, whose format is: 6769 Radio Admin State Type Value Reference 6771 15.18. Radio Operational State 6773 The State field in the Radio Operational State message element (see 6774 Section 4.6.34) is used by the WTP to represent the operational state 6775 of its radios. The namespace is 8 bits (0-255), where the value of 6776 zero (0) is reserved and must not be assigned. The values one (1) 6777 and two (2) are allocated in this specification, and can be found in 6778 Section 4.6.34. This namespace is managed by IANA and assignments 6779 require a Expert Review. IANA will create the Radio Operational 6780 State registry, whose format is: 6782 Radio Operational State Type Value Reference 6784 15.19. Radio Failure Causes 6786 The Cause field in the Radio Operational State message element (see 6787 Section 4.6.34) is used by the WTP to represent the reason why a 6788 radio may have failed. The namespace is 8 bits (0-255), where the 6789 value of zero (0) through three (3) are allocated in this 6790 specification, and can be found in Section 4.6.34. This namespace is 6791 managed by IANA and assignments require a Expert Review. IANA will 6792 create the Radio Failure Causes registry, whose format is: 6794 Radio Failure Causes Type Value Reference 6796 15.20. Result Code 6798 The Result Code field in the Result Code message element (see 6799 Section 4.6.35) is used to indicate the success, or failure, of a 6800 CAPWAP control message. The namespace is 32 bits (0-4294967295), 6801 where the value of zero (0) through 22 are allocated in this 6802 specification, and can be found in Section 4.6.35. This namespace is 6803 managed by IANA and assignments require a Expert Review. IANA will 6804 create the Result Code registry, whose format is: 6806 Result Code Type Value Reference 6808 15.21. Returned Message Element Reason 6810 The Reason field in the Returned Message Element message element (see 6811 Section 4.6.36) is used to indicate the reason why a message element 6812 was not processed successfully. The namespace is 8 bits (0-255), 6813 where the value of zero (0) is reserved and must not be assigned. 6814 The values one (1) through four (4) are allocated in this 6815 specification, and can be found in Section 4.6.36. This namespace is 6816 managed by IANA and assignments require a Expert Review. IANA will 6817 create the Returned Message Element Reason registry, whose format is: 6819 Returned Message Element Reason Type Value Reference 6821 15.22. WTP Board Data Type 6823 The Board Data Type field in the WTP Board Data message element (see 6824 Section 4.6.40) is used to represent information about the WTP 6825 hardware. The namespace is 16 bits (0-65535). The WTP Board Data 6826 Type values zero (0) through four (4) are allocated in this 6827 specification, and can be found in Section 4.6.40. This namespace is 6828 managed by IANA and assignments require a Expert Review. IANA will 6829 create the WTP Board Data Type registry, whose format is: 6831 WTP Board Data Type Type Value Reference 6833 15.23. WTP Descriptor Type 6835 The Descriptor Type field in the WTP Descriptor message element (see 6836 Section 4.6.41) is used to represent information about the WTP 6837 software. The namespace is 16 bits (0-65535). This field, combined 6838 with the Descriptor Vendor ID, allows vendors to use a private 6839 namespace. This specification defines the WTP Descriptor Type 6840 namespace when the Descriptor Vendor ID is set to zero (0), for which 6841 the values zero (0) through three (3) are allocated in this 6842 specification, and can be found in Section 4.6.41. This namespace is 6843 managed by IANA and assignments require a Expert Review. IANA will 6844 create the WTP Board Data Type registry, whose format is: 6846 WTP Descriptor Type Type Value Reference 6848 15.24. WTP Fallback Mode 6850 The Mode field in the WTP Fallback message element (see 6851 Section 4.6.42) is used to indicate to the WTP the type of AC 6852 fallback mechanism it should employ. The namespace is 8 bits 6853 (0-255), where the value of zero (0) is reserved and must not be 6854 assigned. The values one (1) and two (2) are allocated in this 6855 specification, and can be found in Section 4.6.42. This namespace is 6856 managed by IANA and assignments require a Expert Review. IANA will 6857 create the WTP Fallback Mode registry, whose format is: 6859 WTP Fallback Mode Type Value Reference 6861 15.25. WTP Frame Tunnel Mode 6863 The Tunnel Type field in the WTP Frame Tunnel Mode message element 6864 (see Section 4.6.43) is 8 bits and is used to indicate the type of 6865 tunneling to use between the WTP and the AC. This specification 6866 defines bits four (4) through six (6), while bits zero (0) through 6867 four (4) as well as bit seven (7) are reserved and unused. These 6868 reserved bits are managed by IANA and assignment requires a Expert 6869 Review. IANA will create the AC DTLS Policy registry, whose format 6870 is: 6872 WTP Frame Tunnel Mode Bit Position Reference 6874 15.26. WTP MAC Type 6876 The MAC Type field in the WTP MAC Type message element (see 6877 Section 4.6.44) is used to indicate the type of MAC to use in 6878 tunneled frames between the WTP and the AC. The namespace is 8 bits 6879 (0-255), where the value of zero (0) through two (2) are allocated in 6880 this specification, and can be found in Section 4.6.44. This 6881 namespace is managed by IANA and assignments require a Expert Review. 6882 IANA will create the WTP MAC Type registry, whose format is: 6884 WTP MAC Type Type Value Reference 6886 15.27. WTP Radio Stats Failure Type 6888 The Last Failure Type field in the WTP Radio Statistics message 6889 element (see Section 4.6.46) is used to indicate the last WTP 6890 failure. The namespace is 8 bits (0-255), where the value of zero 6891 (0) through three (3) as well as the value 255 are allocated in this 6892 specification, and can be found in Section 4.6.46. This namespace is 6893 managed by IANA and assignments require a Expert Review. IANA will 6894 create the WTP Radio Stats Failure Type registry, whose format is: 6896 WTP Radio Stats Failure Type Type Value Reference 6898 15.28. WTP Reboot Stats Failure Type 6900 The Last Failure Type field in the WTP Reboot Statistics message 6901 element (see Section 4.6.47) is used to indicate the last reboot 6902 reason. The namespace is 8 bits (0-255), where the value of zero (0) 6903 through five (5) as well as the value 255 are allocated in this 6904 specification, and can be found in Section 4.6.47. This namespace is 6905 managed by IANA and assignments require a Expert Review. IANA will 6906 create the WTP Reboot Stats Failure Type registry, whose format is: 6908 WTP Reboot Stats Failure Type Type Value Reference 6910 16. Acknowledgments 6912 The following individuals are acknowledged for their contributions to 6913 this protocol specification: Puneet Agarwal, Abhijit Choudhury, Pasi 6914 Eronen, Saravanan Govindan, Peter Nilsson, David Perkins and Yong 6915 Zhang. 6917 Michael Vakulenko contributed text to describe how CAPWAP can be used 6918 over layer 3 (IP/UDP) networks. 6920 17. References 6922 17.1. Normative References 6924 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 6925 November 1990. 6927 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 6928 April 1992. 6930 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 6931 Specification, Implementation", RFC 1305, March 1992. 6933 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 6934 for IP version 6", RFC 1981, August 1996. 6936 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 6937 Requirement Levels", BCP 14, RFC 2119, March 1997. 6939 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 6940 (IPv6) Specification", RFC 2460, December 1998. 6942 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 6943 "Definition of the Differentiated Services Field (DS 6944 Field) in the IPv4 and IPv6 Headers", RFC 2474, 6945 December 1998. 6947 [RFC2598] Jacobson, V., Nichols, K., and K. Poduri, "An Expedited 6948 Forwarding PHB", RFC 2598, June 1999. 6950 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 6951 specifying the location of services (DNS SRV)", RFC 2782, 6952 February 2000. 6954 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 6955 of Explicit Congestion Notification (ECN) to IP", 6956 RFC 3168, September 2001. 6958 [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and 6959 Accounting (AAA) Transport Profile", RFC 3539, June 2003. 6961 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 6962 10646", STD 63, RFC 3629, November 2003. 6964 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 6965 G. Fairhurst, "The Lightweight User Datagram Protocol 6966 (UDP-Lite)", RFC 3828, July 2004. 6968 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 6969 Requirements for Security", BCP 106, RFC 4086, June 2005. 6971 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 6972 for Transport Layer Security (TLS)", RFC 4279, 6973 December 2005. 6975 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 6976 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 6978 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 6979 Security", RFC 4347, April 2006. 6981 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 6982 Discovery", RFC 4821, March 2007. 6984 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 6985 Errors at High Data Rates", RFC 4963, July 2007. 6987 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 6988 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 6989 May 2008. 6991 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 6992 Housley, R., and W. Polk, "Internet X.509 Public Key 6993 Infrastructure Certificate and Certificate Revocation List 6994 (CRL) Profile", RFC 5280, May 2008. 6996 [ISO.9834-1.1993] 6997 International Organization for Standardization, 6998 "Procedures for the operation of OSI registration 6999 authorities - part 1: general procedures", ISO Standard 7000 9834-1, 1993. 7002 [I-D.ietf-capwap-protocol-binding-ieee80211] 7003 Montemurro, M., Stanley, D., and P. Calhoun, "CAPWAP 7004 Protocol Binding for IEEE 802.11", 7005 draft-ietf-capwap-protocol-binding-ieee80211-11 (work in 7006 progress), October 2008. 7008 [I-D.ietf-capwap-dhc-ac-option] 7009 Calhoun, P., "CAPWAP Access Controller DHCP Option", 7010 draft-ietf-capwap-dhc-ac-option-02 (work in progress), 7011 October 2008. 7013 [FRAME-EXT] 7014 IEEE, "IEEE Standard 802.3as-2006", 2005. 7016 17.2. Informational References 7018 [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by 7019 an On-line Database", RFC 3232, January 2002. 7021 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 7022 RFC 3753, June 2004. 7024 [RFC4564] Govindan, S., Cheng, H., Yao, ZH., Zhou, WH., and L. Yang, 7025 "Objectives for Control and Provisioning of Wireless 7026 Access Points (CAPWAP)", RFC 4564, July 2006. 7028 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 7029 Authorization, and Accounting (AAA) Key Management", 7030 BCP 132, RFC 4962, July 2007. 7032 [I-D.ohara-capwap-lwapp] 7033 Calhoun, P., "Light Weight Access Point Protocol", 7034 draft-ohara-capwap-lwapp-04 (work in progress), 7035 March 2007. 7037 [I-D.narasimhan-ietf-slapp] 7038 Narasimhan, P., "SLAPP : Secure Light Access Point 7039 Protocol", draft-narasimhan-ietf-slapp-01 (work in 7040 progress), March 2006. 7042 [DTLS-DESIGN] 7043 Modadugu et al, N., "The Design and Implementation of 7044 Datagram TLS", Feb 2004. 7046 [EUI-48] IEEE, "Guidelines for use of a 48-bit Extended Unique 7047 Identifier", Dec 2005. 7049 [EUI-64] IEEE, "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) 7050 REGISTRATION AUTHORITY". 7052 [EPCGlobal] 7053 "See http://www.epcglobalinc.org/home". 7055 [PacketCable] 7056 "PacketCable Security Specification PKT-SP-SEC-I12- 7057 050812", August 2005, . 7059 [CableLabs] 7060 "OpenCable System Security Specification OC-SP-SEC-I07- 7061 061031", October 2006, . 7063 [WiMAX] "WiMAX Forum X.509 Device Certificate Profile Approved 7064 Specification V1.0.1", April 2008, . 7066 Editors' Addresses 7068 Pat R. Calhoun 7069 Cisco Systems, Inc. 7070 170 West Tasman Drive 7071 San Jose, CA 95134 7073 Phone: +1 408-902-3240 7074 Email: pcalhoun@cisco.com 7076 Michael P. Montemurro 7077 Research In Motion 7078 5090 Commerce Blvd 7079 Mississauga, ON L4W 5M4 7080 Canada 7082 Phone: +1 905-629-4746 x4999 7083 Email: mmontemurro@rim.com 7085 Dorothy Stanley 7086 Aruba Networks 7087 1322 Crossman Ave 7088 Sunnyvale, CA 94089 7090 Phone: +1 630-363-1389 7091 Email: dstanley@arubanetworks.com 7093 Full Copyright Statement 7095 Copyright (C) The IETF Trust (2008). 7097 This document is subject to the rights, licenses and restrictions 7098 contained in BCP 78, and except as set forth therein, the authors 7099 retain all their rights. 7101 This document and the information contained herein are provided on an 7102 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 7103 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 7104 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 7105 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 7106 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 7107 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 7109 Intellectual Property 7111 The IETF takes no position regarding the validity or scope of any 7112 Intellectual Property Rights or other rights that might be claimed to 7113 pertain to the implementation or use of the technology described in 7114 this document or the extent to which any license under such rights 7115 might or might not be available; nor does it represent that it has 7116 made any independent effort to identify any such rights. Information 7117 on the procedures with respect to rights in RFC documents can be 7118 found in BCP 78 and BCP 79. 7120 Copies of IPR disclosures made to the IETF Secretariat and any 7121 assurances of licenses to be made available, or the result of an 7122 attempt made to obtain a general license or permission for the use of 7123 such proprietary rights by implementers or users of this 7124 specification can be obtained from the IETF on-line IPR repository at 7125 http://www.ietf.org/ipr. 7127 The IETF invites any interested party to bring to its attention any 7128 copyrights, patents or patent applications, or other proprietary 7129 rights that may cover technology that may be required to implement 7130 this standard. Please address the information to the IETF at 7131 ietf-ipr@ietf.org.