idnits 2.17.1 draft-ietf-capwap-protocol-specification-14.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 7065. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 7076. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 7083. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 7089. 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 14, 2008) is 5663 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 6905, 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-10 == Outdated reference: A later version (-02) exists of draft-ietf-capwap-dhc-ac-option-01 -- Possible downref: Non-RFC (?) normative reference: ref. 'FRAME-EXT' Summary: 11 errors (**), 0 flaws (~~), 6 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: April 17, 2009 Research In Motion 6 D. Stanley, Editor 7 Aruba Networks 8 October 14, 2008 10 CAPWAP Protocol Specification 11 draft-ietf-capwap-protocol-specification-14 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 17, 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. Image Data . . . . . . . . . . . . . . . . . . . . . 79 110 4.6.26. Image Identifier . . . . . . . . . . . . . . . . . . 79 111 4.6.27. Image Information . . . . . . . . . . . . . . . . . . 80 112 4.6.28. Initiate Download . . . . . . . . . . . . . . . . . . 81 113 4.6.29. Location Data . . . . . . . . . . . . . . . . . . . . 81 114 4.6.30. Maximum Message Length . . . . . . . . . . . . . . . 81 115 4.6.31. MTU Discovery Padding . . . . . . . . . . . . . . . . 82 116 4.6.32. Radio Administrative State . . . . . . . . . . . . . 82 117 4.6.33. Radio Operational State . . . . . . . . . . . . . . . 83 118 4.6.34. Result Code . . . . . . . . . . . . . . . . . . . . . 84 119 4.6.35. Returned Message Element . . . . . . . . . . . . . . 86 120 4.6.36. Session ID . . . . . . . . . . . . . . . . . . . . . 86 121 4.6.37. Statistics Timer . . . . . . . . . . . . . . . . . . 87 122 4.6.38. Vendor Specific Payload . . . . . . . . . . . . . . . 87 123 4.6.39. WTP Board Data . . . . . . . . . . . . . . . . . . . 88 124 4.6.40. WTP Descriptor . . . . . . . . . . . . . . . . . . . 89 125 4.6.41. WTP Fallback . . . . . . . . . . . . . . . . . . . . 92 126 4.6.42. WTP Frame Tunnel Mode . . . . . . . . . . . . . . . . 92 127 4.6.43. WTP MAC Type . . . . . . . . . . . . . . . . . . . . 93 128 4.6.44. WTP Name . . . . . . . . . . . . . . . . . . . . . . 94 129 4.6.45. WTP Radio Statistics . . . . . . . . . . . . . . . . 94 130 4.6.46. WTP Reboot Statistics . . . . . . . . . . . . . . . . 96 131 4.6.47. WTP Static IP Address Information . . . . . . . . . . 97 132 4.7. CAPWAP Protocol Timers . . . . . . . . . . . . . . . . . 98 133 4.7.1. ChangeStatePendingTimer . . . . . . . . . . . . . . . 98 134 4.7.2. DataChannelKeepAlive . . . . . . . . . . . . . . . . 98 135 4.7.3. DataChannelDeadInterval . . . . . . . . . . . . . . . 99 136 4.7.4. DataCheckTimer . . . . . . . . . . . . . . . . . . . 99 137 4.7.5. DiscoveryInterval . . . . . . . . . . . . . . . . . . 99 138 4.7.6. DTLSSessionDelete . . . . . . . . . . . . . . . . . . 99 139 4.7.7. EchoInterval . . . . . . . . . . . . . . . . . . . . 99 140 4.7.8. IdleTimeout . . . . . . . . . . . . . . . . . . . . . 99 141 4.7.9. ImageDataStartTimer . . . . . . . . . . . . . . . . . 99 142 4.7.10. MaxDiscoveryInterval . . . . . . . . . . . . . . . . 100 143 4.7.11. ReportInterval . . . . . . . . . . . . . . . . . . . 100 144 4.7.12. RetransmitInterval . . . . . . . . . . . . . . . . . 100 145 4.7.13. SilentInterval . . . . . . . . . . . . . . . . . . . 100 146 4.7.14. StatisticsTimer . . . . . . . . . . . . . . . . . . . 100 147 4.7.15. WaitDTLS . . . . . . . . . . . . . . . . . . . . . . 100 148 4.7.16. WaitJoin . . . . . . . . . . . . . . . . . . . . . . 101 149 4.8. CAPWAP Protocol Variables . . . . . . . . . . . . . . . 101 150 4.8.1. AdminState . . . . . . . . . . . . . . . . . . . . . 101 151 4.8.2. DiscoveryCount . . . . . . . . . . . . . . . . . . . 101 152 4.8.3. FailedDTLSAuthFailCount . . . . . . . . . . . . . . . 101 153 4.8.4. FailedDTLSSessionCount . . . . . . . . . . . . . . . 101 154 4.8.5. MaxDiscoveries . . . . . . . . . . . . . . . . . . . 101 155 4.8.6. MaxFailedDTLSSessionRetry . . . . . . . . . . . . . . 101 156 4.8.7. MaxRetransmit . . . . . . . . . . . . . . . . . . . . 102 157 4.8.8. RetransmitCount . . . . . . . . . . . . . . . . . . . 102 158 4.8.9. WTPFallBack . . . . . . . . . . . . . . . . . . . . . 102 159 4.9. WTP Saved Variables . . . . . . . . . . . . . . . . . . 102 160 4.9.1. AdminRebootCount . . . . . . . . . . . . . . . . . . 102 161 4.9.2. FrameEncapType . . . . . . . . . . . . . . . . . . . 102 162 4.9.3. LastRebootReason . . . . . . . . . . . . . . . . . . 102 163 4.9.4. MacType . . . . . . . . . . . . . . . . . . . . . . . 102 164 4.9.5. PreferredACs . . . . . . . . . . . . . . . . . . . . 103 165 4.9.6. RebootCount . . . . . . . . . . . . . . . . . . . . . 103 166 4.9.7. Static IP Address . . . . . . . . . . . . . . . . . . 103 167 4.9.8. WTPLinkFailureCount . . . . . . . . . . . . . . . . . 103 168 4.9.9. WTPLocation . . . . . . . . . . . . . . . . . . . . . 103 169 4.9.10. WTPName . . . . . . . . . . . . . . . . . . . . . . . 103 170 5. CAPWAP Discovery Operations . . . . . . . . . . . . . . . . . 104 171 5.1. Discovery Request Message . . . . . . . . . . . . . . . 104 172 5.2. Discovery Response Message . . . . . . . . . . . . . . . 105 173 5.3. Primary Discovery Request Message . . . . . . . . . . . 106 174 5.4. Primary Discovery Response . . . . . . . . . . . . . . . 107 175 6. CAPWAP Join Operations . . . . . . . . . . . . . . . . . . . 109 176 6.1. Join Request . . . . . . . . . . . . . . . . . . . . . . 109 177 6.2. Join Response . . . . . . . . . . . . . . . . . . . . . 110 178 7. Control Channel Management . . . . . . . . . . . . . . . . . 113 179 7.1. Echo Request . . . . . . . . . . . . . . . . . . . . . . 113 180 7.2. Echo Response . . . . . . . . . . . . . . . . . . . . . 113 182 8. WTP Configuration Management . . . . . . . . . . . . . . . . 115 183 8.1. Configuration Consistency . . . . . . . . . . . . . . . 115 184 8.1.1. Configuration Flexibility . . . . . . . . . . . . . . 116 185 8.2. Configuration Status Request . . . . . . . . . . . . . . 116 186 8.3. Configuration Status Response . . . . . . . . . . . . . 117 187 8.4. Configuration Update Request . . . . . . . . . . . . . . 118 188 8.5. Configuration Update Response . . . . . . . . . . . . . 119 189 8.6. Change State Event Request . . . . . . . . . . . . . . . 119 190 8.7. Change State Event Response . . . . . . . . . . . . . . 121 191 8.8. Clear Configuration Request . . . . . . . . . . . . . . 121 192 8.9. Clear Configuration Response . . . . . . . . . . . . . . 121 193 9. Device Management Operations . . . . . . . . . . . . . . . . 123 194 9.1. Firmware Management . . . . . . . . . . . . . . . . . . 123 195 9.1.1. Image Data Request . . . . . . . . . . . . . . . . . 127 196 9.1.2. Image Data Response . . . . . . . . . . . . . . . . . 128 197 9.2. Reset Request . . . . . . . . . . . . . . . . . . . . . 129 198 9.3. Reset Response . . . . . . . . . . . . . . . . . . . . . 130 199 9.4. WTP Event Request . . . . . . . . . . . . . . . . . . . 130 200 9.5. WTP Event Response . . . . . . . . . . . . . . . . . . . 131 201 9.6. Data Transfer . . . . . . . . . . . . . . . . . . . . . 131 202 9.6.1. Data Transfer Request . . . . . . . . . . . . . . . . 132 203 9.6.2. Data Transfer Response . . . . . . . . . . . . . . . 133 204 10. Station Session Management . . . . . . . . . . . . . . . . . 135 205 10.1. Station Configuration Request . . . . . . . . . . . . . 135 206 10.2. Station Configuration Response . . . . . . . . . . . . . 135 207 11. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 137 208 12. Security Considerations . . . . . . . . . . . . . . . . . . . 139 209 12.1. CAPWAP Security . . . . . . . . . . . . . . . . . . . . 139 210 12.1.1. Converting Protected Data into Unprotected Data . . . 140 211 12.1.2. Converting Unprotected Data into Protected Data 212 (Insertion) . . . . . . . . . . . . . . . . . . . . . 140 213 12.1.3. Deletion of Protected Records . . . . . . . . . . . . 140 214 12.1.4. Insertion of Unprotected Records . . . . . . . . . . 140 215 12.1.5. Use of MD5 . . . . . . . . . . . . . . . . . . . . . 140 216 12.1.6. CAPWAP Fragmentation . . . . . . . . . . . . . . . . 140 217 12.2. Session ID Security . . . . . . . . . . . . . . . . . . 141 218 12.3. Discovery or DTLS Setup Attacks . . . . . . . . . . . . 141 219 12.4. Interference with a DTLS Session . . . . . . . . . . . . 142 220 12.5. CAPWAP Pre-Provisioning . . . . . . . . . . . . . . . . 142 221 12.6. Use of Preshared Keys in CAPWAP . . . . . . . . . . . . 143 222 12.7. Use of Certificates in CAPWAP . . . . . . . . . . . . . 144 223 12.8. Use of MAC Address in CN Field . . . . . . . . . . . . . 145 224 12.9. AAA Security . . . . . . . . . . . . . . . . . . . . . . 145 225 12.10. WTP Firmware . . . . . . . . . . . . . . . . . . . . . . 146 226 13. Operational Considerations . . . . . . . . . . . . . . . . . 147 227 14. Transport Considerations . . . . . . . . . . . . . . . . . . 148 228 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 149 229 15.1. IPv4 Multicast Address . . . . . . . . . . . . . . . . . 149 230 15.2. IPv6 Multicast Address . . . . . . . . . . . . . . . . . 149 231 15.3. UDP Port . . . . . . . . . . . . . . . . . . . . . . . . 149 232 15.4. CAPWAP Message Types . . . . . . . . . . . . . . . . . . 150 233 15.5. CAPWAP Header Flags . . . . . . . . . . . . . . . . . . 150 234 15.6. CAPWAP Control Message Flags . . . . . . . . . . . . . . 150 235 15.7. CAPWAP Message Element Type . . . . . . . . . . . . . . 151 236 15.8. Wireless Binding Identifiers . . . . . . . . . . . . . . 151 237 15.9. AC Security Types . . . . . . . . . . . . . . . . . . . 151 238 15.10. AC DTLS Policy . . . . . . . . . . . . . . . . . . . . . 152 239 15.11. AC Information Type . . . . . . . . . . . . . . . . . . 152 240 15.12. CAPWAP Transport Protocol Types . . . . . . . . . . . . 152 241 15.13. Data Transfer Type . . . . . . . . . . . . . . . . . . . 152 242 15.14. Data Transfer Mode . . . . . . . . . . . . . . . . . . . 153 243 15.15. Discovery Types . . . . . . . . . . . . . . . . . . . . 153 244 15.16. Radio Admin State . . . . . . . . . . . . . . . . . . . 153 245 15.17. Radio Operational State . . . . . . . . . . . . . . . . 154 246 15.18. Radio Failure Causes . . . . . . . . . . . . . . . . . . 154 247 15.19. Result Code . . . . . . . . . . . . . . . . . . . . . . 154 248 15.20. Returned Message Element Reason . . . . . . . . . . . . 154 249 15.21. WTP Board Data Type . . . . . . . . . . . . . . . . . . 155 250 15.22. WTP Descriptor Type . . . . . . . . . . . . . . . . . . 155 251 15.23. WTP Fallback Mode . . . . . . . . . . . . . . . . . . . 155 252 15.24. WTP Frame Tunnel Mode . . . . . . . . . . . . . . . . . 155 253 15.25. WTP MAC Type . . . . . . . . . . . . . . . . . . . . . . 156 254 15.26. WTP Radio Stats Failure Type . . . . . . . . . . . . . . 156 255 15.27. WTP Reboot Stats Failure Type . . . . . . . . . . . . . 156 256 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 157 257 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 158 258 17.1. Normative References . . . . . . . . . . . . . . . . . . 158 259 17.2. Informational References . . . . . . . . . . . . . . . . 160 260 Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 162 261 Intellectual Property and Copyright Statements . . . . . . . . . 163 263 1. Introduction 265 This document describes the CAPWAP Protocol, a standard, 266 interoperable protocol which enables an Access Controller (AC) to 267 manage a collection of Wireless Termination Points (WTPs). The 268 CAPWAP protocol is defined to be independent of layer 2 technology, 269 and meets the Objectives for Control and Provisioning of Wireless 270 Access Points (CAPWAP) [RFC4564]. 272 The emergence of centralized IEEE 802.11 Wireless Local Area Network 273 (WLAN) architectures, in which simple IEEE 802.11 WTPs are managed by 274 an Access Controller (AC) suggested that a standards based, 275 interoperable protocol could radically simplify the deployment and 276 management of wireless networks. WTPs require a set of dynamic 277 management and control functions related to their primary task of 278 connecting the wireless and wired mediums. Traditional protocols for 279 managing WTPs are either manual static configuration via HTTP, 280 proprietary Layer 2 specific or non-existent (if the WTPs are self- 281 contained). An IEEE 802.11 binding is defined in 282 [I-D.ietf-capwap-protocol-binding-ieee80211] to support use of the 283 CAPWAP protocol with IEEE 802.11 WLAN networks. 285 CAPWAP assumes a network configuration consisting of multiple WTPs 286 communicating via the Internet Protocol (IP) to an AC. WTPs are 287 viewed as remote RF interfaces controlled by the AC. The CAPWAP 288 protocol supports two modes of operation: Split and Local MAC. In 289 Split MAC mode all L2 wireless data and management frames are 290 encapsulated via the CAPWAP protocol and exchanged between the AC and 291 the WTP. As shown in Figure 1, the wireless frames received from a 292 mobile device, which is referred to in this specification as a 293 Station (STA), are directly encapsulated by the WTP and forwarded to 294 the AC. 296 +-+ wireless frames +-+ 297 | |--------------------------------| | 298 | | +-+ | | 299 | |--------------| |---------------| | 300 | |wireless PHY/ | | CAPWAP | | 301 | | MAC sublayer | | | | 302 +-+ +-+ +-+ 303 STA WTP AC 305 Figure 1: Representative CAPWAP Architecture for Split MAC 307 The Local MAC mode of operation allows for the data frames to be 308 either locally bridged, or tunneled as 802.3 frames. The latter 309 implies that the WTP performs the 802.11 Integration function. In 310 either case the L2 wireless management frames are processed locally 311 by the WTP, and then forwarded to the AC. Figure 2 shows the Local 312 MAC mode, in which a station transmits a wireless frame which is 313 encapsulated in an 802.3 frame and forwarded to the AC. 315 +-+wireless frames +-+ 802.3 frames +-+ 316 | |----------------| |--------------| | 317 | | | | | | 318 | |----------------| |--------------| | 319 | |wireless PHY/ | | CAPWAP | | 320 | | MAC sublayer | | | | 321 +-+ +-+ +-+ 322 STA WTP AC 324 Figure 2: Representative CAPWAP Architecture for Local MAC 326 Provisioning WTPs with security credentials, and managing which WTPs 327 are authorized to provide service are traditionally handled by 328 proprietary solutions. Allowing these functions to be performed from 329 a centralized AC in an interoperable fashion increases manageability 330 and allows network operators to more tightly control their wireless 331 network infrastructure. 333 1.1. Goals 335 The goals for the CAPWAP protocol are listed below: 337 1. To centralize the authentication and policy enforcement functions 338 for a wireless network. The AC may also provide centralized 339 bridging, forwarding, and encryption of user traffic. 340 Centralization of these functions will enable reduced cost and 341 higher efficiency by applying the capabilities of network 342 processing silicon to the wireless network, as in wired LANs. 344 2. To enable shifting of the higher level protocol processing from 345 the WTP. This leaves the time critical applications of wireless 346 control and access in the WTP, making efficient use of the 347 computing power available in WTPs which are the subject to severe 348 cost pressure. 350 3. To provide an extensible protocol that is not bound to a specific 351 wireless technology. Extensibility is provided via a generic 352 encapsulation and transport mechanism, enabling the CAPWAP 353 protocol to be applied to many access point types in the future, 354 via a specific wireless binding. 356 The CAPWAP protocol concerns itself solely with the interface between 357 the WTP and the AC. Inter-AC and station-to AC-communication are 358 strictly outside the scope of this document. 360 1.2. Conventions used in this document 362 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 363 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 364 document are to be interpreted as described in RFC 2119 [RFC2119]. 366 1.3. Contributing Authors 368 This section lists and acknowledges the authors of significant text 369 and concepts included in this specification. 371 The CAPWAP Working Group selected the Lightweight Access Point 372 Protocol (LWAPP) [I-D.ohara-capwap-lwapp] to be used as the basis of 373 the CAPWAP protocol specification. The following people are authors 374 of the LWAPP document: 376 Bob O'Hara 377 Email: bob.ohara@computer.org 379 Pat Calhoun, Cisco Systems, Inc. 380 170 West Tasman Drive, San Jose, CA 95134 381 Phone: +1 408-902-3240, Email: pcalhoun@cisco.com 383 Rohit Suri, Cisco Systems, Inc. 384 170 West Tasman Drive, San Jose, CA 95134 385 Phone: +1 408-853-5548, Email: rsuri@cisco.com 387 Nancy Cam Winget, Cisco Systems, Inc. 388 170 West Tasman Drive, San Jose, CA 95134 389 Phone: +1 408-853-0532, Email: ncamwing@cisco.com 391 Scott Kelly, Aruba Networks 392 1322 Crossman Ave, Sunnyvale, CA 94089 393 Phone: +1 408-754-8408, Email: skelly@arubanetworks.com 395 Michael Glenn Williams, Nokia, Inc. 396 313 Fairchild Drive, Mountain View, CA 94043 397 Phone: +1 650-714-7758, Email: Michael.G.Williams@Nokia.com 399 Sue Hares, Green Hills Software 400 825 Victors Way, Suite 100, Ann Arbor, MI 48108 401 Phone: +1 734 222 1610, Email: shares@ndzh.com 403 Datagram Transport Layer Security (DTLS) [RFC4347] is used as the 404 security solution for the CAPWAP protocol. The following people are 405 authors of significant DTLS-related text included in this document: 407 Scott Kelly, Aruba Networks 408 1322 Crossman Ave, Sunnyvale, CA 94089 409 Phone: +1 408-754-8408, Email: skelly@arubanetworks.com 411 Eric Rescorla, Network Resonance 412 2483 El Camino Real, #212,Palo Alto CA, 94303 413 Email: ekr@networkresonance.com 415 The concept of using DTLS to secure the CAPWAP protocol was part of 416 the Secure Light Access Point Protocol (SLAPP) proposal 417 [I-D.narasimhan-ietf-slapp]. The following people are authors of the 418 SLAPP proposal: 420 Partha Narasimhan, Aruba Networks 421 1322 Crossman Ave, Sunnyvale, CA 94089 422 Phone: +1 408-480-4716, Email: partha@arubanetworks.com 424 Dan Harkins, Tropos Networks 425 555 Del Rey Avenue, Sunnyvale, CA, 95085 426 Phone: +1 408 470 7372, Email: dharkins@tropos.com 428 Subbu Ponnuswamy, Aruba Networks 429 1322 Crossman Ave, Sunnyvale, CA 94089 430 Phone: +1 408-754-1213, Email: subbu@arubanetworks.com 432 The following individuals contributed significant security related 433 text to the draft: 435 T. Charles Clancy, Laboratory for Telecommunications Sciences, 436 8080 Greenmead Drive, College Park, MD 20740 437 Phone: +1 240-373-5069, Email: clancy@ltsnet.net 439 Scott Kelly, Aruba Networks 440 1322 Crossman Ave, Sunnyvale, CA 94089 441 Phone: +1 408-754-8408, Email: skelly@arubanetworks.com 443 1.4. Terminology 445 Access Controller (AC): The network entity that provides WTP access 446 to the network infrastructure in the data plane, control plane, 447 management plane, or a combination therein. 449 CAPWAP Control Channel: A bi-directional flow defined by the AC IP 450 Address, WTP IP Address, AC control port, WTP control port and the 451 transport-layer protocol (UDP or UDP-Lite) over which CAPWAP control 452 packets are sent and received. 454 CAPWAP Data Channel: A bi-directional flow defined by the AC IP 455 Address, WTP IP Address, AC data port, WTP data port, and the 456 transport-layer protocol (UDP or UDP-Lite) over which CAPWAP data 457 packets are sent and received. 459 Station (STA): A device that contains an interface to a wireless 460 medium (WM). 462 Wireless Termination Point (WTP): The physical or network entity that 463 contains an RF antenna and wireless PHY to transmit and receive 464 station traffic for wireless access networks. 466 This document uses additional terminology defined in [RFC3753]. 468 2. Protocol Overview 470 The CAPWAP protocol is a generic protocol defining AC and WTP control 471 and data plane communication via a CAPWAP protocol transport 472 mechanism. CAPWAP control messages, and optionally CAPWAP data 473 messages, are secured using Datagram Transport Layer Security (DTLS) 474 [RFC4347]. DTLS is a standards-track IETF protocol based upon TLS. 475 The underlying security-related protocol mechanisms of TLS have been 476 successfully deployed for many years. 478 The CAPWAP protocol Transport layer carries two types of payload, 479 CAPWAP Data messages and CAPWAP Control messages. CAPWAP Data 480 messages encapsulate forwarded wireless frames. CAPWAP protocol 481 Control messages are management messages exchanged between a WTP and 482 an AC. The CAPWAP Data and Control packets are sent over separate 483 UDP ports. Since both data and control packets can exceed the 484 Maximum Transmission Unit (MTU) length, the payload of a CAPWAP data 485 or control message can be fragmented. The fragmentation behavior is 486 defined in Section 3. 488 The CAPWAP Protocol begins with a discovery phase. The WTPs send a 489 Discovery Request message, causing any Access Controller (AC) 490 receiving the message to respond with a Discovery Response message. 491 From the Discovery Response messages received, a WTP selects an AC 492 with which to establish a secure DTLS session. In order to establish 493 the secure DTLS connection, the WTP will need some amount of pre- 494 provisioning, which is specified in Section 12.5. CAPWAP protocol 495 messages will be fragmented to the maximum length discovered to be 496 supported by the network. 498 Once the WTP and the AC have completed DTLS session establishment, a 499 configuration exchange occurs in which both devices agree on version 500 information. During this exchange the WTP may receive provisioning 501 settings. The WTP is then enabled for operation. 503 When the WTP and AC have completed the version and provision exchange 504 and the WTP is enabled, the CAPWAP protocol is used to encapsulate 505 the wireless data frames sent between the WTP and AC. The CAPWAP 506 protocol will fragment the L2 frames if the size of the encapsulated 507 wireless user data (Data) or protocol control (Management) frames 508 causes the resulting CAPWAP protocol packet to exceed the MTU 509 supported between the WTP and AC. Fragmented CAPWAP packets are 510 reassembled to reconstitute the original encapsulated payload. MTU 511 Discovery and Fragmentation are described in Section 3. 513 The CAPWAP protocol provides for the delivery of commands from the AC 514 to the WTP for the management of stations that are communicating with 515 the WTP. This may include the creation of local data structures in 516 the WTP for the stations and the collection of statistical 517 information about the communication between the WTP and the stations. 518 The CAPWAP protocol provides a mechanism for the AC to obtain 519 statistical information collected by the WTP. 521 The CAPWAP protocol provides for a keep alive feature that preserves 522 the communication channel between the WTP and AC. If the AC fails to 523 appear alive, the WTP will try to discover a new AC. 525 2.1. Wireless Binding Definition 527 The CAPWAP protocol is independent of a specific WTP radio 528 technology, as well its associated wireless link layer protocol. 529 Elements of the CAPWAP protocol are designed to accommodate the 530 specific needs of each wireless technology in a standard way. 531 Implementation of the CAPWAP protocol for a particular wireless 532 technology MUST follow the binding requirements defined for that 533 technology. 535 When defining a binding for wireless technologies, the authors MUST 536 include any necessary definitions for technology-specific messages 537 and all technology-specific message elements for those messages. At 538 a minimum, a binding MUST provide: 540 1. The definition for a binding-specific Statistics message element, 541 carried in the WTP Event Request message 543 2. A message element carried in the Station Configuration Request 544 message to configure station information on the WTP 546 3. A WTP Radio Information message element carried in the Discovery, 547 Primary Discovery and Join Request and Response messages, 548 indicating the binding specific radio types supported at the WTP 549 and AC. 551 If technology specific message elements are required for any of the 552 existing CAPWAP messages defined in this specification, they MUST 553 also be defined in the technology binding document. 555 The naming of binding-specific message elements MUST begin with the 556 name of the technology type, e.g., the binding for IEEE 802.11, 557 provided in [I-D.ietf-capwap-protocol-binding-ieee80211], begins with 558 "IEEE 802.11". 560 The CAPWAP binding concept MUST also be used in any future 561 specification that add functionality to either the base CAPWAP 562 protocol specification, or any published CAPWAP binding 563 specification. A separate WTP Radio Information message element MUST 564 be created to properly advertise support for the specification. This 565 mechanism allows for future protocol extensibility, while providing 566 the necessary capabilities advertisement, through the WTP Radio 567 Information message element, to ensure WTP/AC interoperability. 569 2.2. CAPWAP Session Establishment Overview 571 This section describes the session establishment process message 572 exchanges between a CAPWAP WTP and AC. The annotated ladder diagram 573 shows the AC on the right, the WTP on the left, and assumes the use 574 of certificates for DTLS authentication. The CAPWAP Protocol State 575 Machine is described in detail in Section 2.3. Note that DTLS allows 576 certain messages to be aggregated into a single frame, which is 577 denoted via an asterisk in Figure 3. 579 ============ ============ 580 WTP AC 581 ============ ============ 582 [----------- begin optional discovery ------------] 584 Discover Request 585 ------------------------------------> 586 Discover Response 587 <------------------------------------ 589 [----------- end optional discovery ------------] 591 (-- begin DTLS handshake --) 593 ClientHello 594 ------------------------------------> 595 HelloVerifyRequest (with cookie) 596 <------------------------------------ 598 ClientHello (with cookie) 599 ------------------------------------> 600 ServerHello, 601 Certificate, 602 ServerHelloDone* 603 <------------------------------------ 605 (-- WTP callout for AC authorization --) 607 Certificate (optional), 608 ClientKeyExchange, 609 CertificateVerify (optional), 610 ChangeCipherSpec, 611 Finished* 612 ------------------------------------> 614 (-- AC callout for WTP authorization --) 616 ChangeCipherSpec, 617 Finished* 618 <------------------------------------ 620 (-- DTLS session is established now --) 622 Join Request 623 ------------------------------------> 624 Join Response 625 <------------------------------------ 626 [-- Join State Complete --] 628 (-- assume image is up to date --) 630 Configuration Status Request 631 ------------------------------------> 632 Configuration Status Response 633 <------------------------------------ 634 [-- Configure State Complete --] 636 Change State Event Request 637 ------------------------------------> 638 Change State Event Response 639 <------------------------------------ 640 [-- Data Check State Complete --] 642 (-- enter RUN state --) 644 : 645 : 647 Echo Request 648 ------------------------------------> 649 Echo Response 650 <------------------------------------ 652 : 653 : 655 Event Request 656 ------------------------------------> 657 Event Response 658 <------------------------------------ 659 : 660 : 662 Figure 3: CAPWAP Control Protocol Exchange 664 At the end of the illustrated CAPWAP message exchange, the AC and WTP 665 are securely exchanging CAPWAP control messages. This illustration 666 is provided to clarify protocol operation, and does not include any 667 possible error conditions. Section 2.3 provides a detailed 668 description of the corresponding state machine. 670 2.3. CAPWAP State Machine Definition 672 The following state diagram represents the lifecycle of a WTP-AC 673 session. Use of DTLS by the CAPWAP protocol results in the 674 juxtaposition of two nominally separate yet tightly bound state 675 machines. The DTLS and CAPWAP state machines are coupled through an 676 API consisting of commands (see Section 2.3.2.1) and notifications 677 (see Section 2.3.2.2). Certain transitions in the DTLS state machine 678 are triggered by commands from the CAPWAP state machine, while 679 certain transitions in the CAPWAP state machine are triggered by 680 notifications from the DTLS state machine. 682 /-------------------------------------\ 683 | /-------------------------\| 684 | p| || 685 | q+----------+ r +------------+ || 686 | | Run |-->| Reset |-\|| 687 | +----------+ +------------+ ||| 688 n| o ^ ^ ^ s||| 689 +------------+--------/ | | ||| 690 | Data Check | /-------/ | ||| 691 +------------+<-------\ | | ||| 692 | | | ||| 693 /------------------+--------\ | ||| 694 f| m| h| j v k| ||| 695 +--------+ +-----------+ +--------------+||| 696 | Join |---->| Configure | | Image Data |||| 697 +--------+ n +-----------+ +--------------+||| 698 ^ |g i| l| ||| 699 | | \-------------------\ | ||| 700 | \--------------------------------------\| | ||| 701 \------------------------\ || | ||| 702 /--------------<----------------+---------------\ || | ||| 703 | /------------<----------------+-------------\ | || | ||| 704 | | 4 |d t| | vv v vvv 705 | | +----------------+ +--------------+ +-----------+ 706 | | | DTLS Setup | | DTLS Connect |-->| DTLS TD | 707 /-|-|---+----------------+ +--------------+ e +-----------+ 708 | | | |$ ^ ^ |5 ^6 ^ ^ |w 709 v v v | | | | \-------\ | | | 710 | | | | | | \---------\ | | /-----------/ | 711 | | | | | \--\ | | | | | 712 | | | | | | | | | | | 713 | | | v 3| 1 |% # v | |a |b v 714 | | \->+------+-->+------+ +-----------+ +--------+ 715 | | | Idle | | Disc | | Authorize | | Dead | 716 | | +------+<--+------+ +-----------+ +--------+ 717 | | ^ 0^ 2 |! 718 | | | | | +-------+ 719 *| |u | \---------+---| Start | 720 | | |@ | +-------+ 721 | \->+---------+<------/ 722 \--->| Sulking | 723 +---------+& 725 Figure 4: CAPWAP Integrated State Machine 727 The CAPWAP protocol state machine, depicted above, is used by both 728 the AC and the WTP. In cases where states are not shared (i.e. not 729 implemented in one or the other of the AC or WTP), this is explicitly 730 called out in the transition descriptions below. For every state 731 defined, only certain messages are permitted to be sent and received. 732 The CAPWAP control message definitions specify the state(s) in which 733 each message is valid. 735 Since the WTP only communicates with a single AC, it only has a 736 single instance of the CAPWAP state machine. The state machine works 737 differently on the AC since it communicates with many WTPs. The AC 738 uses the concept of three threads. Note that the term thread used 739 here does not necessarily imply that implementers must use threads, 740 but it is one possible way of implementing the AC's state machine. 742 Listener Thread: The AC's Listener thread handles inbound DTLS 743 session establishment requests, through the DTLSListen command. 744 Upon creation, the Listener thread starts in the DTLS Setup state. 745 Once a DTLS session has been validated, which occurs when the 746 state machine enters the "Authorize" state, the Listener thread 747 creates a WTP session specific Service thread and state context. 748 The state machine transitions in Figure 4 are represented by 749 numerals. It is necessary for the AC to protect itself against 750 various attacks that exist with non-authenticated frames. See 751 Section 12 for more information. 753 Discovery Thread: The AC's Discovery thread is responsible for 754 receiving, and responding to, Discovery Request messages. The 755 state machine transitions in Figure 4 are represented by numerals. 756 Note that the Discovery thread does not maintain any per-WTP 757 specific context information, and a single state context exists. 758 It is necessary for the AC to protect itself against various 759 attacks that exist with non-authenticated frames. See Section 12 760 for more information. 762 Service Thread: The AC's Service thread handles the per-WTP states, 763 and one such thread exists per-WTP connection. This thread is 764 created by the listener thread when the Authorize state is 765 reached. When created, the Service thread inherits a copy of the 766 state machine context from the Listener thread. When 767 communication with the WTP is complete, the Service thread is 768 terminated and all associated resources are released. The state 769 machine transitions in Figure 4 are represented by alphabetic and 770 punctuation characters. 772 2.3.1. CAPWAP Protocol State Transitions 774 This section describes the various state transitions, and the events 775 that cause them. This section does not discuss interactions between 776 DTLS- and CAPWAP-specific states. Those interactions, and DTLS- 777 specific states and transitions, are discussed in Section 2.3.2. 779 Start to Idle (0): This transition occurs once device initialization 780 is complete. 782 WTP: This state transition is used to start the WTP's CAPWAP 783 state machine. 785 AC: The AC creates the Discovery and Listener threads and starts 786 the CAPWAP state machine. 788 Idle to Discovery (1): This transition occurs to support the CAPWAP 789 discovery process . 791 WTP: The WTP enters the Discovery state prior to transmitting the 792 first Discovery Request message (see Section 5.1). Upon 793 entering this state, the WTP sets the DiscoveryInterval timer 794 (see Section 4.7). The WTP resets the DiscoveryCount counter 795 to zero (0) (see Section 4.8). The WTP also clears all 796 information from ACs it may have received during a previous 797 Discovery phase. 799 AC: This state transition is executed by the AC's Discovery 800 thread, and occurs when a Discovery Request message is 801 received. The AC SHOULD respond with a Discovery Response 802 message (see Section 5.2). 804 Discovery to Discovery (#): In the Discovery state, the WTP 805 determines which AC to connect to. 807 WTP: This transition occurs when the DiscoveryInterval timer 808 expires. If the WTP is configured with a list of ACs, it 809 transmits a Discovery Request message to every AC from which it 810 has not received a Discovery Response message. For every 811 transition to this event, the WTP increments the DiscoveryCount 812 counter. See Section 5.1 for more information on how the WTP 813 knows the ACs to which it should transmit the Discovery Request 814 messages. The WTP restarts the DiscoveryInterval timer 815 whenever it transmits Discovery Request messages. 817 AC: This is an invalid state transition for the AC. 819 Discovery to Idle (2): This transition occurs on the AC's Discovery 820 thread when the Discovery processing is complete. 822 WTP: This is an invalid state transition for the WTP. 824 AC: This state transition is executed by the AC's Discovery 825 thread when it has transmitted the Discovery Response, in 826 response to a Discovery Request. 828 Discovery to Sulking (!): This transition occurs on a WTP when AC 829 Discovery fails. 831 WTP: The WTP enters this state when the DiscoveryInterval timer 832 expires and the DiscoveryCount variable is equal to the 833 MaxDiscoveries variable (see Section 4.8). Upon entering this 834 state, the WTP MUST start the SilentInterval timer. While in 835 the Sulking state, all received CAPWAP protocol messages MUST 836 be ignored. 838 AC: This is an invalid state transition for the AC. 840 Sulking to Idle (@): This transition occurs on a WTP when it must 841 restart the discovery phase. 843 WTP: The WTP enters this state when the SilentInterval timer (see 844 Section 4.7) expires. The FailedDTLSSessionCount, 845 DiscoveryCount and FailedDTLSAuthFailCount counters are reset 846 to zero. 848 AC: This is an invalid state transition for the AC. 850 Sulking to Sulking (&): The Sulking state provides the silent 851 period, minimizing the possibility for Denial of Service (DoS) 852 attacks. 854 WTP: All packets received from the AC while in the sulking state 855 are ignored. 857 AC: This is an invalid state transition for the AC. 859 Idle to DTLS Setup (3): This transition occurs to establish a secure 860 DTLS session with the peer. 862 WTP: The WTP initiates this transition by invoking the DTLSStart 863 command(see Section 2.3.2.1), which starts the DTLS session 864 establishment with the chosen AC and the WaitDTLS timer is 865 started (see Section 4.7). When the discovery phase is 866 bypassed, it is assumed the WTP has locally configured ACs. 868 AC: Upon entering the Idle state from the Start state, the newly 869 created Listener thread automatically transitions to the DTLS 870 Setup and invokes the DTLSListen command (see Section 2.3.2.1), 871 and the WaitDTLS timer is started (see Section 4.7). 873 Discovery to DTLS Setup (%): This transition occurs to establish a 874 secure DTLS session with the peer. 876 WTP: The WTP initiates this transition by invoking the DTLSStart 877 command (see Section 2.3.2.1), which starts the DTLS session 878 establishment with the chosen AC. The decision of which AC to 879 connect to is the result of the discovery phase, which is 880 described in Section 3.3. 882 AC: This is an invalid state transition for the AC. 884 DTLS Setup to Idle ($): This transition occurs when the DTLS 885 connection setup fails. 887 WTP: The WTP initiates this state transition when it receives a 888 DTLSEstablishFail notification from DTLS (see Section 2.3.2.2), 889 and the FailedDTLSSessionCount or the FailedDTLSAuthFailCount 890 counter have not reached the value of the 891 MaxFailedDTLSSessionRetry variable (see Section 4.8). This 892 error notification aborts the secure DTLS session 893 establishment. When this notification is received, the 894 FailedDTLSSessionCount counter is incremented. This state 895 transition also occurs if the WaitDTLS timer has expired. 897 AC: This is an invalid state transition for the AC. 899 DTLS Setup to Sulking (*): This transition occurs when repeated 900 attempts to setup the DTLS connection have failed. 902 WTP: The WTP enters this state when the FailedDTLSSessionCount or 903 the FailedDTLSAuthFailCount counter reaches the value of the 904 MaxFailedDTLSSessionRetry variable (see Section 4.8). Upon 905 entering this state, the WTP MUST start the SilentInterval 906 timer. While in the Sulking state, all received CAPWAP and 907 DTLS protocol messages received MUST be ignored. 909 AC: This is an invalid state transition for the AC. 911 DTLS Setup to DTLS Setup (4): This transition occurs when the DTLS 912 Session failed to be established. 914 WTP: This is an invalid state transition for the WTP. 916 AC: The AC's Listener initiates this state transition when it 917 receives a DTLSEstablishFail notification from DTLS (see 918 Section 2.3.2.2). This error notification aborts the secure 919 DTLS session establishment. When this notification is 920 received, the FailedDTLSSessionCount counter is incremented. 922 The Listener thread then invokes the DTLSListen command (see 923 Section 2.3.2.1). 925 DTLS Setup to Authorize (5): This transition occurs when an incoming 926 DTLS session is being established, and the DTLS stack needs 927 authorization to proceed with the session establishment. 929 WTP: This state transition occurs when the WTP receives the 930 DTLSPeerAuthorize notification (see Section 2.3.2.2). Upon 931 entering this state, the WTP performs an authorization check 932 against the AC credentials. See Section 2.4.4 for more 933 information on AC authorization. 935 AC: This state transition is handled by the AC's Listener thread 936 when the DTLS module initiates the DTLSPeerAuthorize 937 notification (see Section 2.3.2.2). The Listener thread forks 938 an instance of the Service thread, along with a copy of the 939 state context. Once created, the Service thread performs an 940 authorization check against the WTP credentials. See 941 Section 2.4.4 for more information on WTP authorization. 943 Authorize to DTLS Setup (6): This transition is executed by the 944 Listener thread to enable it to listen for new incoming sessions. 946 WTP: This is an invalid state transition for the WTP. 948 AC: This state transition occurs when the AC's Listener thread 949 has created the WTP context and the Service thread. The 950 Listener thread then invokes the DTLSListen command (see 951 Section 2.3.2.1). 953 Authorize to DTLS Connect (a): This transition occurs to notify the 954 DTLS stack that the session should be established. 956 WTP: This state transition occurs when the WTP has successfully 957 authorized the AC's credentials (see Section 2.4.4). This is 958 done by invoking the DTLSAccept DTLS command (see 959 Section 2.3.2.1). 961 AC: This state transition occurs when the AC has successfully 962 authorized the WTP's credentials (see Section 2.4.4). This is 963 done by invoking the DTLSAccept DTLS command (see 964 Section 2.3.2.1). 966 Authorize to DTLS Teardown (b): This transition occurs to notify the 967 DTLS stack that the session should be aborted. 969 WTP: This state transition occurs when the WTP was unable to 970 authorize the AC, using the AC credentials. The WTP then 971 aborts the DTLS session by invoking the DTLSAbortSession 972 command (see Section 2.3.2.1). This state transition also 973 occurs if the WaitDTLS timer has expired. The WTP starts the 974 DTLSSessionDelete timer (see Section 4.7.6). 976 AC: This state transition occurs when the AC was unable to 977 authorize the WTP, using the WTP credentials. The AC then 978 aborts the DTLS session by invoking the DTLSAbortSession 979 command (see Section 2.3.2.1). This state transition also 980 occurs if the WaitDTLS timer has expired. The AC starts the 981 DTLSSessionDelete timer (see Section 4.7.6). 983 DTLS Connect to DTLS Teardown (c): This transition occurs when the 984 DTLS Session failed to be established. 986 WTP: This state transition occurs when the WTP receives either a 987 DTLSAborted or DTLSAuthenticateFail notification (see 988 Section 2.3.2.2), indicating that the DTLS session was not 989 successfully established. When this transition occurs due to 990 the DTLSAuthenticateFail notification, the 991 FailedDTLSAuthFailCount is incremented, otherwise the 992 FailedDTLSSessionCount counter is incremented. This state 993 transition also occurs if the WaitDTLS timer has expired. The 994 WTP starts the DTLSSessionDelete timer (see Section 4.7.6). 996 AC: This state transition occurs when the AC receives either a 997 DTLSAborted or DTLSAuthenticateFail notification (see 998 Section 2.3.2.2), indicating that the DTLS session was not 999 successfully established, and both of the 1000 FailedDTLSAuthFailCount and FailedDTLSSessionCount counters 1001 have not reached the value of the MaxFailedDTLSSessionRetry 1002 variable (see Section 4.8). This state transition also occurs 1003 if the WaitDTLS timer has expired. The AC starts the 1004 DTLSSessionDelete timer (see Section 4.7.6). 1006 DTLS Connect to Join (d): This transition occurs when the DTLS 1007 Session is successfully established. 1009 WTP: This state transition occurs when the WTP receives the 1010 DTLSEstablished notification (see Section 2.3.2.2), indicating 1011 that the DTLS session was successfully established. When this 1012 notification is received, the FailedDTLSSessionCount counter is 1013 set to zero. The WTP enters the Join state by transmiting the 1014 Join Request to the AC. The WTP stops the WaitDTLS timer. 1016 AC: This state transition occurs when the AC receives the 1017 DTLSEstablished notification (see Section 2.3.2.2), indicating 1018 that the DTLS session was successfully established. When this 1019 notification is received, the FailedDTLSSessionCount counter is 1020 set to zero. The AC stops the WaitDTLS timer, and starts the 1021 WaitJoin timer. 1023 Join to DTLS Teardown (e): This transition occurs when the join 1024 process failed. 1026 WTP: This state transition occurs when the WTP receives a Join 1027 Response message with a Result Code message element containing 1028 an error, or if the Image Identifier provided by the AC in the 1029 Join Response message differs from the WTP's currently running 1030 firmware version and the WTP has the requested image in its 1031 non-volatile memory. This causes the WTP to initiate the 1032 DTLSShutdown command (see Section 2.3.2.1). This transition 1033 also occurs if the WTP receives one of the following DTLS 1034 notifications: DTLSAborted, DTLSReassemblyFailure or 1035 DTLSPeerDisconnect. The WTP starts the DTLSSessionDelete timer 1036 (see Section 4.7.6). 1038 AC: This state transition occurs either if the WaitJoin timer 1039 expires or if the AC transmits a Join Response message with a 1040 Result Code message element containing an error. This causes 1041 the AC to initiate the DTLSShutdown command (see 1042 Section 2.3.2.1). This transition also occurs if the AC 1043 receives one of the following DTLS notifications: DTLSAborted, 1044 DTLSReassemblyFailure or DTLSPeerDisconnect. The AC starts the 1045 DTLSSessionDelete timer (see Section 4.7.6). 1047 Join to Image Data (f): This state transition is used by the WTP and 1048 the AC to download executable firmware. 1050 WTP: The WTP enters the Image Data state when it receives a 1051 successful Join Response message and determines that the 1052 software version in the Image Identifier message element is not 1053 the same as its currently running image. The WTP also detects 1054 that the requested image version is not currently available in 1055 the WTP's non-volatile storage (see Section 9.1 for a full 1056 description of the firmware download process). The WTP 1057 initializes the EchoInterval timer (see Section 4.7), and 1058 transmits the Image Data Request message (see Section 9.1.1) 1059 requesting the start of the firmware download. 1061 AC: This state transition occurs when the AC receives the Image 1062 Data Request message from the WTP, after having sent its Join 1063 Response to the WTP. The AC stops the WaitJoin timer. The AC 1064 MUST transmit an Image Data Response message (see 1065 Section 9.1.2) to the WTP, which includes a portion of the 1066 firmware. 1068 Join to Configure (g): This state transition is used by the WTP and 1069 the AC to exchange configuration information. 1071 WTP: The WTP enters the Configure state when it receives a 1072 successful Join Response message, and determines that the 1073 included Image Identifier message element is the same as its 1074 currently running image. The WTP transmits the Configuration 1075 Status Request message (see Section 8.2) to the AC with message 1076 elements describing its current configuration. 1078 AC: This state transition occurs when it receives the 1079 Configuration Status Request message from the WTP (see 1080 Section 8.2), which MAY include specific message elements to 1081 override the WTP's configuration. The AC stops the WaitJoin 1082 timer. The AC transmits the Configuration Status Response 1083 message (see Section 8.3) and starts the 1084 ChangeStatePendingTimer timer (see Section 4.7). 1086 Configure to Reset (h): This state transition is used to reset the 1087 connection either due to an error during the configuration phase, 1088 or when the WTP determines it needs to reset in order for the new 1089 configuration to take effect. The CAPWAP Reset command is used to 1090 indicate to the peer that it will initiate a DTLS teardown. 1092 WTP: The WTP enters the Reset state when it receives a 1093 Configuration Status Response message indicating an error or 1094 when it determines that a reset of the WTP is required, due to 1095 the characteristics of a new configuration. 1097 AC: The AC transitions to the Reset state when it receives a 1098 Change State Event message from the WTP that contains an error 1099 for which AC policy does not permit the WTP to provide service. 1100 This state transition also occurs when the AC 1101 ChangeStatePendingTimer timer expires. 1103 Configure to DTLS Teardown (i): This transition occurs when the 1104 configuration process aborts due to a DTLS error. 1106 WTP: The WTP enters this state when it receives one of the 1107 following DTLS notifications: DTLSAborted, 1108 DTLSReassemblyFailure or DTLSPeerDisconnect (see 1109 Section 2.3.2.2). The WTP MAY tear down the DTLS session if it 1110 receives frequent DTLSDecapFailure notifications. The WTP 1111 starts the DTLSSessionDelete timer (see Section 4.7.6). 1113 AC: The AC enters this state when it receives one of the 1114 following DTLS notifications: DTLSAborted, 1115 DTLSReassemblyFailure or DTLSPeerDisconnect (see 1116 Section 2.3.2.2). The AC MAY tear down the DTLS session if it 1117 receives frequent DTLSDecapFailure notifications. The AC 1118 starts the DTLSSessionDelete timer (see Section 4.7.6). 1120 Image Data to Image Data (j): The Image Data state is used by the 1121 WTP and the AC during the firmware download phase. 1123 WTP: The WTP enters the Image Data state when it receives an 1124 Image Data Response message indicating that the AC has more 1125 data to send. This state transition also occurs when the WTP 1126 receives the subsequent Image Data Requests, at which time it 1127 resets the ImageDataStartTimer time to ensure it receives the 1128 next expected Image Data Request from the AC. This state 1129 transition can also occur when the WTP's EchoInterval timer 1130 (see Section 4.7.7) expires, in which case the WTP transmits an 1131 Echo Request message (see Section 7.1), and resets its 1132 EchoInterval timer. The state transition also occurs when the 1133 WTP receives an Echo Response from the AC (see Section 7.2. 1135 AC: This state transition occurs either when the AC receives the 1136 Image Data Response message from the WTP while already in the 1137 Image Data state. This state transition also occurs when the 1138 AC receives an Echo Request (see Section 7.1) from the WTP, in 1139 which case it responds with an Echo Response (see Section 7.2), 1140 and resets its EchoInterval timer (see Section 4.7.7). 1142 Image Data to Reset (k): This state transition is used to reset the 1143 DTLS connection prior to restarting the WTP after an image 1144 download. 1146 WTP: When an image download completes, or if the 1147 ImageDataStartTimer timer expires, the WTP enters the Reset 1148 state. The WTP MAY also transition to this state upon 1149 receiving an Image Data Response message from the AC (see 1150 Section 9.1.2) indicating a failure. 1152 AC: The AC enters the Reset state either when the image transfer 1153 has successfully completed or an error occurs during the image 1154 download process. 1156 Image Data to DTLS Teardown (l): This transition occurs when the 1157 firmware download process aborts due to a DTLS error. 1159 WTP: The WTP enters this state when it receives one of the 1160 following DTLS notifications: DTLSAborted, 1161 DTLSReassemblyFailure or DTLSPeerDisconnect (see 1162 Section 2.3.2.2). The WTP MAY tear down the DTLS session if it 1163 receives frequent DTLSDecapFailure notifications. The WTP 1164 starts the DTLSSessionDelete timer (see Section 4.7.6). 1166 AC: The AC enters this state when it receives one of the 1167 following DTLS notifications: DTLSAborted, 1168 DTLSReassemblyFailure or DTLSPeerDisconnect (see 1169 Section 2.3.2.2). The AC MAY tear down the DTLS session if it 1170 receives frequent DTLSDecapFailure notifications. The AC 1171 starts the DTLSSessionDelete timer (see Section 4.7.6). 1173 Configure to Data Check (m): This state transition occurs when the 1174 WTP and AC confirm the configuration. 1176 WTP: The WTP enters this state when it receives a successful 1177 Configuration Status Response message from the AC. The WTP 1178 transmits the Change State Event Request message (see 1179 Section 8.6). 1181 AC: This state transition occurs when the AC receives the Change 1182 State Event Request message (see Section 8.6) from the WTP. 1183 The AC responds with a Change State Event Response message (see 1184 Section 8.7). The AC MUST start the DataCheckTimer timer and 1185 stops the ChangeStatePendingTimer timer (see Section 4.7). 1187 Data Check to DTLS Teardown (n): This transition occurs when the WTP 1188 does not complete the Data Check exchange. 1190 WTP: This state transition occurs if the WTP does not receive the 1191 Change State Event Response message before a CAPWAP 1192 retransmission timeout occurs. The WTP also transitions to 1193 this state if the underlying reliable transport's 1194 RetransmitCount counter has reached the MaxRetransmit variable 1195 (see Section 4.7). The WTP starts the DTLSSessionDelete timer 1196 (see Section 4.7.6). 1198 AC: The AC enters this state when the DataCheckTimer timer 1199 expires (see Section 4.7). The AC starts the DTLSSessionDelete 1200 timer (see Section 4.7.6). 1202 Data Check to Run (o): This state transition occurs when the linkage 1203 between the control and data channels is established, causing the 1204 WTP and AC to enter their normal state of operation. 1206 WTP: The WTP enters this state when it receives a successful 1207 Change State Event Response message from the AC. The WTP 1208 initiates the data channel, which MAY require the establishment 1209 of a DTLS session, starts the DataChannelKeepAlive timer (see 1210 Section 4.7.2) and transmits a Data Channel Keep Alive packet 1211 (see Section 4.4.1). The WTP then starts the EchoInterval 1212 timer and DataChannelDeadInterval timer (see Section 4.7). 1214 AC: This state transition occurs when the AC receives the Data 1215 Channel Keep Alive packet (see Section 4.4.1), with a Session 1216 ID message element matching that included by the WTP in the 1217 Join Request message. The AC disables the DataCheckTimer 1218 timer. Note that if AC policy is to require the data channel 1219 to be encrypted, this process would also require the 1220 establishment of a data channel DTLS session. Upon receiving 1221 the Data Channel Keep Alive packet, the AC transmits its own 1222 Data Channel Keep Alive packet. 1224 Run to DTLS Teardown (p): This state transition occurs when an error 1225 has occurred in the DTLS stack, causing the DTLS session to be 1226 torn down. 1228 WTP: The WTP enters this state when it receives one of the 1229 following DTLS notifications: DTLSAborted, 1230 DTLSReassemblyFailure or DTLSPeerDisconnect (see 1231 Section 2.3.2.2). The WTP MAY tear down the DTLS session if it 1232 receives frequent DTLSDecapFailure notifications. The WTP also 1233 transitions to this state if the underlying reliable 1234 transport's RetransmitCount counter has reached the 1235 MaxRetransmit variable (see Section 4.7). The WTP starts the 1236 DTLSSessionDelete timer (see Section 4.7.6). 1238 AC: The AC enters this state when it receives one of the 1239 following DTLS notifications: DTLSAborted, 1240 DTLSReassemblyFailure or DTLSPeerDisconnect (see 1241 Section 2.3.2.2). The AC MAY tear down the DTLS session if it 1242 receives frequent DTLSDecapFailure notifications. The AC 1243 transitions to this state if the underlying reliable 1244 transport's RetransmitCount counter has reached the 1245 MaxRetransmit variable (see Section 4.7). This state 1246 transition also occurs when the AC's EchoInterval timer (see 1247 Section 4.7.7) expires. The AC starts the DTLSSessionDelete 1248 timer (see Section 4.7.6). 1250 Run to Run (q): This is the normal state of operation. 1252 WTP: This is the WTP's normal state of operation. The WTP resets 1253 its EchoInterval timer whenever it transmits a request to the 1254 AC. There are many events that result this state transition: 1256 Configuration Update: The WTP receives a Configuration Update 1257 Request message(see Section 8.4). The WTP MUST respond with 1258 a Configuration Update Response message (see Section 8.5). 1260 Change State Event: The WTP receives a Change State Event 1261 Response message, or determines that it must initiate a 1262 Change State Event Request message, as a result of a failure 1263 or change in the state of a radio. 1265 Echo Request: The WTP sends an Echo Request message 1266 (Section 7.1) or receives the corresponding Echo Response 1267 message, (see Section 7.2) from the AC. When the WTP 1268 receives the Echo Response, it resets its EchoInterval timer 1269 (see Section 4.7.7). 1271 Clear Config Request: The WTP receives a Clear Configuration 1272 Request message (see Section 8.8) and MUST generate a 1273 corresponding Clear Configuration Response message (see 1274 Section 8.9). The WTP MUST reset its configuration back to 1275 manufacturer defaults. 1277 WTP Event: The WTP sends a WTP Event Request message, 1278 delivering information to the AC (see Section 9.4). The WTP 1279 receives a WTP Event Response message from the AC (see 1280 Section 9.5). 1282 Data Transfer: The WTP sends a Data Transfer Request or Data 1283 Transfer Response message to the AC (see Section 9.6). The 1284 WTP receives a Data Transfer Request or Data Transfer 1285 Response message from the AC (see Section 9.6). Upon 1286 receipt of a Data Transfer Request, the WTP transmits a Data 1287 Transfer Response to the AC. 1289 Station Configuration Request: The WTP receives a Station 1290 Configuration Request message (see Section 10.1), to which 1291 it MUST respond with a Station Configuration Response 1292 message (see Section 10.2). 1294 AC: This is the AC's normal state of operation. Note that the 1295 receipt of any Request from the WTP causes the AC to reset its 1296 EchoInterval timer (see Section 4.7.7). 1298 Configuration Update: The AC sends a Configuration Update 1299 Request message (see Section 8.4) to the WTP to update its 1300 configuration. The AC receives a Configuration Update 1301 Response message (see Section 8.5) from the WTP. 1303 Change State Event: The AC receives a Change State Event 1304 Request message (see Section 8.6), to which it MUST respond 1305 with the Change State Event Response message (see 1306 Section 8.7). 1308 Echo Request: The AC receives an Echo Request message (see 1309 Section 7.1), to which it MUST respond with an Echo Response 1310 message(see Section 7.2). 1312 Clear Config Response: The AC sends a Clear Configuration 1313 Request message (see Section 8.8) to the WTP to clear its 1314 configuration. The AC receives a Clear Configuration 1315 Response message from the WTP (see Section 8.9). 1317 WTP Event: The AC receives a WTP Event Request message from 1318 the WTP (see Section 9.4) and MUST generate a corresponding 1319 WTP Event Response message (see Section 9.5). 1321 Data Transfer: The AC sends a Data Transfer Request or Data 1322 Transfer Response message to the WTP (see Section 9.6). The 1323 AC receives a Data Transfer Request or Data Transfer 1324 Response message from the WTP (see Section 9.6). Upon 1325 receipt of a Data Transfer Request, the AC transmits a Data 1326 Transfer Response to the WTP. 1328 Station Configuration Request: The AC sends a Station 1329 Configuration Request message (see Section 10.1) or receives 1330 the corresponding Station Configuration Response message 1331 (see Section 10.2) from the WTP. 1333 Run to Reset (r): This state transition is used when either the AC 1334 or WTP tear down the connection. This may occur as part of normal 1335 operation, or due to error conditions. 1337 WTP: The WTP enters the Reset state when it receives a Reset 1338 Request message from the AC. 1340 AC: The AC enters the Reset state when it transmits a Reset 1341 Request message to the WTP. 1343 Reset to DTLS Teardown (s): This transition occurs when the CAPWAP 1344 reset is complete, to terminate the DTLS session. 1346 WTP: This state transition occurs when the WTP transmits a Reset 1347 Response message. The WTP does not invoke the DTLSShutdown 1348 command (see Section 2.3.2.1). The WTP starts the 1349 DTLSSessionDelete timer (see Section 4.7.6). 1351 AC: This state transition occurs when the AC receives a Reset 1352 Response message. This causes the AC to initiate the 1353 DTLSShutdown command (see Section 2.3.2.1). The AC starts the 1354 DTLSSessionDelete timer (see Section 4.7.6). 1356 DTLS Teardown to Idle (t): This transition occurs when the DTLS 1357 session has been shutdown. 1359 WTP: This state transition occurs when the WTP has successfully 1360 cleaned up all resources associated with the control plane DTLS 1361 session, or if the DTLSSessionDelete timer (see Section 4.7.6) 1362 expires. The data plane DTLS session is also shutdown, and all 1363 resources released, if a DTLS session was established for the 1364 data plane. Any timers set for the current instance of the 1365 state machine are also cleared. 1367 AC: This is an invalid state transition for the AC. 1369 DTLS Teardown to Sulking (u): This transition occurs when repeated 1370 attempts to setup the DTLS connection have failed. 1372 WTP: The WTP enters this state when the FailedDTLSSessionCount or 1373 the FailedDTLSAuthFailCount counter reaches the value of the 1374 MaxFailedDTLSSessionRetry variable (see Section 4.8). Upon 1375 entering this state, the WTP MUST start the SilentInterval 1376 timer. While in the Sulking state, all received CAPWAP and 1377 DTLS protocol messages received MUST be ignored. 1379 AC: This is an invalid state transition for the AC. 1381 DTLS Teardown to Dead (w): This transition occurs when the DTLS 1382 session has been shutdown. 1384 WTP: This is an invalid state transition for the WTP. 1386 AC: This state transition occurs when the AC has successfully 1387 cleaned up all resources associated with the control plane DTLS 1388 session , or if the DTLSSessionDelete timer (see Section 4.7.6) 1389 expires. The data plane DTLS session is also shutdown, and all 1390 resources released, if a DTLS session was established for the 1391 data plane. Any timers set for the current instance of the 1392 state machine are also cleared. The AC's Service thread is 1393 terminated. 1395 2.3.2. CAPWAP/DTLS Interface 1397 This section describes the DTLS Commands used by CAPWAP, and the 1398 notifications received from DTLS to the CAPWAP protocol stack. 1400 2.3.2.1. CAPWAP to DTLS Commands 1402 Six commands are defined for the CAPWAP to DTLS API. These 1403 "commands" are conceptual, and may be implemented as one or more 1404 function calls. This API definition is provided to clarify 1405 interactions between the DTLS and CAPWAP components of the integrated 1406 CAPWAP state machine. 1408 Below is a list of the minimal command API: 1410 o DTLSStart is sent to the DTLS component to cause a DTLS session to 1411 be established. Upon invoking the DTLSStart command, the WaitDTLS 1412 timer is started. The WTP initiates this DTLS command, as the AC 1413 does not initiate DTLS sessions. 1415 o DTLSListen is sent to the DTLS component to allow the DTLS 1416 component to listen for incoming DTLS session requests. 1418 o DTLSAccept is sent to the DTLS component to allow the DTLS session 1419 establishment to continue successfully. 1421 o DTLSAbortSession is sent to the DTLS component to cause the 1422 session that is in the process of being established to be aborted. 1423 This command is also sent when the WaitDTLS timer expires. When 1424 this command is executed, the FailedDTLSSessionCount counter is 1425 incremented. 1427 o DTLSShutdown is sent to the DTLS component to cause session 1428 teardown. 1430 o DTLSMtuUpdate is sent by the CAPWAP component to modify the MTU 1431 size used by the DTLS component. See Section 3.5 for more 1432 information on MTU Discovery. The default size is 1468 bytes. 1434 2.3.2.2. DTLS to CAPWAP Notifications 1436 DTLS notifications are defined for the DTLS to CAPWAP API. These 1437 "notifications" are conceptual, and may be implemented in numerous 1438 ways (e.g. as function return values). This API definition is 1439 provided to clarify interactions between the DTLS and CAPWAP 1440 components of the integrated CAPWAP state machine. It is important 1441 to note that the notifications listed below MAY cause the CAPWAP 1442 state machine to jump from one state to another using a state 1443 transition not listed in Section 2.3.1. When a notification listed 1444 below occurs, the target CAPWAP state shown in Figure 4 becomes the 1445 current state. 1447 Below is a list of the API notifications: 1449 o DTLSPeerAuthorize is sent to the CAPWAP component during DTLS 1450 session establishment once the peer's identity has been received. 1451 This notification MAY be used by the CAPWAP component to authorize 1452 the session, based on the peer's identity. The authorization 1453 process will lead to the CAPWAP component initiating either the 1454 DTLSAccept or DTLSAbortSession commands. 1456 o DTLSEstablished is sent to the CAPWAP component to indicate that 1457 that a secure channel now exists, using the parameters provided 1458 during the DTLS initialization process. When this notification is 1459 received, the FailedDTLSSessionCount counter is reset to zero. 1460 When this notification is received, the WaitDTLS timer is stopped. 1462 o DTLSEstablishFail is sent when the DTLS session establishment has 1463 failed, either due to a local error, or due to the peer rejecting 1464 the session establishment. When this notification is received, 1465 the FailedDTLSSessionCount counter is incremented. 1467 o DTLSAuthenticateFail is sent when DTLS session establishment 1468 failed due to an authentication error. When this notification is 1469 received, the FailedDTLSAuthFailCount counter is incremented. 1471 o DTLSAborted is sent to the CAPWAP component to indicate that 1472 session abort (as requested by CAPWAP) is complete; this occurs to 1473 confirm a DTLS session abort, or when the WaitDTLS timer expires. 1474 When this notification is received, the WaitDTLS timer is stopped. 1476 o DTLSReassemblyFailure MAY be sent to the CAPWAP component to 1477 indicate DTLS fragment reassembly failure. 1479 o DTLSDecapFailure MAY be sent to the CAPWAP module to indicate a 1480 decapsulation failure. DTLSDecapFailure MAY be sent to the CAPWAP 1481 module to indicate an encryption/authentication failure. This 1482 notification is intended for informative purposes only, and is not 1483 intended to cause a change in the CAPWAP state machine (see 1484 Section 12.4). 1486 o DTLSPeerDisconnect is sent to the CAPWAP component to indicate the 1487 DTLS session has been torn down. Note that this notification is 1488 only received if the DTLS session has been established. 1490 2.4. Use of DTLS in the CAPWAP Protocol 1492 DTLS is used as a tightly-integrated, secure wrapper for the CAPWAP 1493 protocol. In this document DTLS and CAPWAP are discussed as 1494 nominally distinct entities; however they are very closely coupled, 1495 and may even be implemented inseparably. Since there are DTLS 1496 library implementations currently available, and since security 1497 protocols (e.g. IPsec, TLS) are often implemented in widely 1498 available acceleration hardware, it is both convenient and forward- 1499 looking to maintain a modular distinction in this document. 1501 This section describes a detailed walk-through of the interactions 1502 between the DTLS module and the CAPWAP module, via 'commands' (CAPWAP 1503 to DTLS) and 'notifications' (DTLS to CAPWAP) as they would be 1504 encountered during the normal course of operation. 1506 2.4.1. DTLS Handshake Processing 1508 Details of the DTLS handshake process are specified in [RFC4347]. 1509 This section describes the interactions between the DTLS session 1510 establishment process and the CAPWAP protocol. Note that the 1511 conceptual DTLS state is shown below to help understand the point at 1512 which the DTLS states transition. In the normal case, the DTLS 1513 handshake will proceed as shown in Figure 5. (NOTE: this example 1514 uses certificates, but preshared keys are also supported): 1516 ============ ============ 1517 WTP AC 1518 ============ ============ 1519 ClientHello ------> 1520 <------ HelloVerifyRequest 1521 (with cookie) 1523 ClientHello ------> 1524 (with cookie) 1525 <------ ServerHello 1526 <------ Certificate 1527 <------ ServerHelloDone 1529 (WTP callout for AC authorization 1530 occurs in CAPWAP Auth state) 1532 Certificate* 1533 ClientKeyExchange 1534 CertificateVerify* 1535 ChangeCipherSpec 1536 Finished ------> 1538 (AC callout for WTP authorization 1539 occurs in CAPWAP Auth state) 1541 ChangeCipherSpec 1542 <------ Finished 1544 Figure 5: DTLS Handshake 1546 DTLS, as specified, provides its own retransmit timers with an 1547 exponential back-off. [RFC4347] does not specify how long 1548 retransmissions should continue. Consequently, timing out incomplete 1549 DTLS handshakes is entirely the responsibility of the CAPWAP module. 1551 The DTLS implementation used by CAPWAP MUST support TLS Session 1552 Resumption. Session resumption is typically used to establish the 1553 DTLS session used for the data channel. Since the data channel uses 1554 different port numbers than the control channel, the DTLS 1555 implementation on the WTP MUST provide an interface that allows the 1556 CAPWAP module to request session resumption despite the use of the 1557 different port numbers (TLS implementations usually attempt session 1558 resumption only when connecting to the same IP address and port 1559 number). Note that session resumption is not guaranteed to occur, 1560 and a full DTLS handshake may occur instead. 1562 The DTLS implementation used by CAPWAP MUST use replay detection, per 1563 Section 3.3 of [RFC4347]. Since the CAPWAP protocol handles 1564 retransmissions by re-encrypting lost frames, any duplicate DTLS 1565 frames are either unintentional or malicious, and should be silently 1566 discarded. 1568 2.4.2. DTLS Session Establishment 1570 The WTP, either through the Discovery process, or through pre- 1571 configuration, determines the AC to connect to. The WTP uses the 1572 DTLSStart command to request that a secure connection be established 1573 to the selected AC. Prior to initiation of the DTLS handshake, the 1574 WTP sets the WaitDTLS timer. Upon invoking the DTLSStart or 1575 DTLSListen commands, the WTP and AC, respectively, set the WaitDTLS 1576 timer. If the DTLSEstablished notification is not received prior to 1577 timer expiration, the DTLS session is aborted by issuing the 1578 DTLSAbortSession DTLS command. This notification causes the CAPWAP 1579 module to transition to the Idle state. Upon receiving a 1580 DTLSEstablished notification, the WaitDTLS timer is deactivated. 1582 2.4.3. DTLS Error Handling 1584 If the AC or WTP does not respond to any DTLS handshake messages sent 1585 by its peer, the DTLS specification calls for the message to be 1586 retransmited. Note that during the handshake, when both the AC and 1587 the WTP are expecting additional handshake messages, they both 1588 retransmit if an expected message has not been received (note that 1589 retransmissions for CAPWAP Control messages work differently: all 1590 CAPWAP Control messages are either requests or responses, and the 1591 peer who sent the request is responsible for retransmissions). 1593 If the WTP or the AC does not receive an expected DTLS handshake 1594 message despite of retransmissions, the WaitDTLS timer will 1595 eventually expire, and the session will be terminated. This can 1596 happen if communication between the peers has completely failed, or 1597 if one of the peers sent a DTLS Alert message which was lost in 1598 transit (DTLS does not retransmit Alert messages). 1600 If a cookie fails to validate, this could represent a WTP error, or 1601 it could represent a DoS attack. Hence, AC resource utilization 1602 SHOULD be minimized. The AC MAY log a message indicating the 1603 failure, and SHOULD treat the message as though no cookie were 1604 present. 1606 Since DTLS handshake messages are potentially larger than the maximum 1607 record size, DTLS supports fragmenting of handshake messages across 1608 multiple records. There are several potential causes of re-assembly 1609 errors, including overlapping and/or lost fragments. The DTLS 1610 component MUST send a DTLSReassemblyFailure notification to the 1611 CAPWAP component. Whether precise information is given along with 1612 notification is an implementation issue, and hence is beyond the 1613 scope of this document. Upon receipt of such an error, the CAPWAP 1614 component SHOULD log an appropriate error message. Whether 1615 processing continues or the DTLS session is terminated is 1616 implementation dependent. 1618 DTLS decapsulation errors consist of three types: decryption errors, 1619 authentication errors, and malformed DTLS record headers. Since DTLS 1620 authenticates the data prior to encapsulation, if decryption fails, 1621 it is difficult to detect this without first attempting to 1622 authenticate the packet. If authentication fails, a decryption error 1623 is also likely, but not guaranteed. Rather than attempt to derive 1624 (and require the implementation of) algorithms for detecting 1625 decryption failures, decryption failures are reported as 1626 authentication failures. The DTLS component MUST provide a 1627 DTLSDecapFailure notification to the CAPWAP component when such 1628 errors occur. If a malformed DTLS record header is detected, the 1629 packets SHOULD be silently discarded, and the receiver MAY log an 1630 error message. 1632 There is currently only one encapsulation error defined: MTU 1633 exceeded. As part of DTLS session establishment, the CAPWAP 1634 component informs the DTLS component of the MTU size. This may be 1635 dynamically modified at any time when the CAPWAP component sends the 1636 DTLSMtuUpdate command to the DTLS component (see Section 2.3.2.1). 1637 The value provided to the DTLS stack is the result of the MTU 1638 Discovery process, which is described in Section 3.5. The DTLS 1639 component returns this notification to the CAPWAP component whenever 1640 a transmission request will result in a packet which exceeds the MTU. 1642 2.4.4. DTLS EndPoint Authentication and Authorization 1644 DTLS supports endpoint authentication with certificates or preshared 1645 keys. The TLS algorithm suites for each endpoint authentication 1646 method are described below. 1648 2.4.4.1. Authenticating with Certificates 1650 CAPWAP implementations only use cipher suites that are recommended 1651 for use with DTLS, see [DTLS-DESIGN]. At present, the following 1652 algorithms MUST be supported when using certificates for CAPWAP 1653 authentication: 1655 o TLS_RSA_WITH_AES_128_CBC_SHA [RFC4346] 1657 The following algorithms SHOULD be supported when using certificates: 1659 o TLS_DHE_RSA_WITH_AES_128_CBC_SHA [RFC4346] 1661 The following algorithms MAY be supported when using certificates: 1663 o TLS_RSA_WITH_AES_256_CBC_SHA [RFC4346] 1665 o TLS_DHE_RSA_WITH_AES_256_CBC_SHA [RFC4346] 1667 Additional ciphers MAY be defined in follow on CAPWAP specifications. 1669 2.4.4.2. Authenticating with Preshared Keys 1671 Pre-shared keys present significant challenges from a security 1672 perspective, and for that reason, their use is strongly discouraged. 1673 Several methods for authenticating with preshared keys are defined 1674 [RFC4279], and we focus on the following two: 1676 o Pre-Shared Key (PSK) key exchange algorithm - simplest method, 1677 ciphersuites use only symmetric key algorithms 1679 o DHE_PSK key exchange algorithm - use a PSK to authenticate a 1680 Diffie-Hellman exchange. These ciphersuites give some additional 1681 protection against dictionary attacks and also provide Perfect 1682 Forward Secrecy (PFS). 1684 The first approach (plain PSK) is susceptible to passive dictionary 1685 attacks; hence, while this algorithm MUST be supported, special care 1686 should be taken when choosing that method. In particular, user- 1687 readable passphrases SHOULD NOT be used, and use of short PSKs SHOULD 1688 be strongly discouraged. 1690 The following cryptographic algorithms MUST be supported when using 1691 preshared keys: 1693 o TLS_PSK_WITH_AES_128_CBC_SHA [RFC4346] 1695 o TLS_DHE_PSK_WITH_AES_128_CBC_SHA [RFC4346] 1697 The following algorithms MAY be supported when using preshared keys: 1699 o TLS_PSK_WITH_AES_256_CBC_SHA [RFC4346] 1701 o TLS_DHE_PSK_WITH_AES_256_CBC_SHA [RFC4346] 1703 Additional ciphers MAY be defined in follow on CAPWAP specifications. 1705 2.4.4.3. Certificate Usage 1707 Certificate authorization by the AC and WTP is required so that only 1708 an AC may perform the functions of an AC and that only a WTP may 1709 perform the functions of a WTP. This restriction of functions to the 1710 AC or WTP requires that the certificates used by the AC MUST be 1711 distinguishable from the certificate used by the WTP. To accomplish 1712 this differentiation, the x.509 certificates MUST include the 1713 Extended Key Usage (EKU) certificate extension [RFC5280]. 1715 The EKU field indicates one or more purposes for which a certificate 1716 may be used. It is an essential part in authorization. Its syntax 1717 is described in [RFC5280] and [ISO.9834-1.1993] and is as follows: 1719 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 1721 KeyPurposeId ::= OBJECT IDENTIFIER 1723 Here we define two KeyPurposeId values, one for the WTP and one for 1724 the AC. Inclusion of one of these two values indicates a certificate 1725 is authorized for use by a WTP or AC, respectively. These values are 1726 formatted as id-kp fields. 1728 id-kp OBJECT IDENTIFIER ::= 1729 { iso(1) identified-organization(3) dod(6) internet(1) 1730 security(5) mechanisms(5) pkix(7) 3 } 1732 id-kp-capwapAC OBJECT IDENTIFIER ::= { id-kp 18 } 1734 id-kp-capwapWTP OBJECT IDENTIFIER ::= { id-kp 19 } 1736 All capwap devices MUST support the ExtendedKeyUsage certificate 1737 extension if it is present in a certificate. If the extension is 1738 present, then the certificate MUST have either the id-kp-capwapAC or 1739 the id-kp-anyExtendedKeyUsage keyPurposeID to act as an AC. 1740 Similarly, if the extension is present, a device MUST have the id-kp- 1741 capwapWTP or id-kp-anyExtendedKeyUsage keyPurposeID to act as a WTP. 1743 Part of the CAPWAP certificate validation process includes ensuring 1744 that the proper EKU is included and allowing the CAPWAP session to be 1745 established only if the extension properly represents the device. 1746 For instance, an AC SHOULD NOT accept a connection request from 1747 another AC, and therefore MUST verify that the id-kp-capwapWTP EKU is 1748 present in the certificate. 1750 CAPWAP implementations MUST support certificates where the common 1751 name (CN) for both the WTP and AC is the MAC address of that device. 1753 The MAC address MUST be encoded in the PrintableString format, using 1754 the well recognized MAC address format of 01:23:45:67:89:ab. The CN 1755 field MAY contain either of the EUI-48 [EUI-48] or EUI-64 [EUI-64] 1756 MAC Address formats. This seemingly unconventional use of the CN 1757 field is consistent with other standards that rely on device 1758 certificates that are provisioned during the manufacturing process, 1759 such as Packet Cable [PacketCable], Cable Labs [CableLabs] and WiMAX 1760 [WiMAX]. See Section 12.8 for more information on the use of the MAC 1761 Address in the CN field. 1763 ACs and WTPs MUST authorize (e.g. through access control lists) 1764 certificates of devices to which they are connecting, e.g., based on 1765 the issuer, MAC address, or organizational information specified in 1766 the certificate. The identities specified in the certificates bind a 1767 particular DTLS session to a specific pair of mutually-authenticated 1768 and authorized MAC addresses. The particulars of authorization 1769 filter construction are implementation details which are, for the 1770 most part, not within the scope of this specification. However, at 1771 minimum, all devices MUST verify that the appropriate EKU bit is set 1772 according to the role of the peer device (AC vs. WTP), and that the 1773 issuer of the certificate is appropriate for the domain in question. 1775 2.4.4.4. PSK Usage 1777 When DTLS uses PSK Ciphersuites, the ServerKeyExchange message MUST 1778 contain the "PSK identity hint" field and the ClientKeyExchange 1779 message MUST contain the "PSK identity" field. These fields are used 1780 to help the WTP select the appropriate PSK for use with the AC, and 1781 then indicate to the AC which key is being used. When PSKs are 1782 provisioned to WTPs and ACs, both the PSK Hint and PSK Identity for 1783 the key MUST be specified. 1785 The PSK Hint SHOULD uniquely identify the AC and the PSK Identity 1786 SHOULD uniquely identify the WTP. It is RECOMMENDED that these hints 1787 and identities be the ASCII HEX-formatted MAC addresses of the 1788 respective devices, since each pairwise combination of WTP and AC 1789 SHOULD have a unique PSK. The PSK hint and identity SHOULD be 1790 sufficient to perform authorization, as simply having knowledge of a 1791 PSK does not necessarily imply authorization. 1793 If a single PSK is being used for multiple devices on a CAPWAP 1794 network, which is NOT RECOMMENDED, the PSK Hint and Identity can no 1795 longer be a MAC address, so appropriate hints and identities SHOULD 1796 be selected to identify the group of devices to which the PSK is 1797 provisioned. 1799 3. CAPWAP Transport 1801 Communication between a WTP and an AC is established using the 1802 standard UDP client/server model. The CAPWAP protocol supports both 1803 UDP and UDP-Lite [RFC3828] transport protocols. When run over IPv4, 1804 UDP is used for the CAPWAP control and data channels. 1806 When run over IPv6, the CAPWAP control channel always uses UDP, while 1807 the CAPWAP data channel may use either UDP or UDP-Lite. UDP-Lite is 1808 the default transport protocol for the CAPWAP data channel. However, 1809 if a middlebox or IPv4 to IPv6 gateway has been discovered, UDP is 1810 used for the CAPWAP data channel. 1812 This section describes how the CAPWAP protocol is carried over IP and 1813 UDP/UDP-Lite transport protocols. The CAPWAP Transport Protocol 1814 message element Section 4.6.14 describes the rules to use in 1815 determining which transport protocol is to be used. 1817 In order for CAPWAP to be compatible with potential middleboxes in 1818 the network, CAPWAP implementations MUST send return traffic from the 1819 same port on which it received traffic from a given peer. Further, 1820 any unsolicited requests generated by a CAPWAP node MUST be sent on 1821 the same port. 1823 3.1. UDP Transport 1825 One of the CAPWAP protocol requirements is to allow a WTP to reside 1826 behind a middlebox, firewall and/or Network Address Translation (NAT) 1827 device. Since a CAPWAP session is initiated by the WTP (client) to 1828 the well-known UDP port of the AC (server), the use of UDP is a 1829 logical choice. When CAPWAP is run over IPv4, the UDP checksum field 1830 in CAPWAP packets MUST be set to zero. 1832 CAPWAP protocol control packets sent from the WTP to the AC use the 1833 CAPWAP control channel, as defined in Section 1.4. The CAPWAP 1834 control port at the AC is the well known UDP port 5246. The CAPWAP 1835 control port at the WTP can be any port selected by the WTP. 1837 CAPWAP protocol data packets sent from the WTP to the AC use the 1838 CAPWAP data channel, as defined in Section 1.4. The CAPWAP data port 1839 at the AC is the well known UDP port 5247. If an AC permits the 1840 administrator to change the CAPWAP control port, the CAPWAP data port 1841 MUST be the next consecutive port number. The CAPWAP data port at 1842 the WTP can be any port selected by the WTP. 1844 3.2. UDP-Lite Transport 1846 When CAPWAP is run over IPv6, UDP-Lite is the default transport 1847 protocol, which reduces the checksum processing required for each 1848 packet (compared to the use of UDP over IPv6 [RFC2460]). When UDP- 1849 Lite is used, the checksum field MUST have a coverage of 8 [RFC3828]. 1851 UDP-Lite uses the same port assignments as UDP. 1853 3.3. AC Discovery 1855 The AC discovery phase allows the WTP to determine which ACs are 1856 available, and chose the best AC with which to establish a CAPWAP 1857 session. The discovery phase occurs when the WTP enters the optional 1858 Discovery state. A WTP does not need to complete the AC Discovery 1859 phase if it uses a pre-configured AC. This section details the 1860 mechanism used by a WTP to dynamically discover candidate ACs. 1862 A WTP and an AC will frequently not reside in the same IP subnet 1863 (broadcast domain). When this occurs, the WTP must be capable of 1864 discovering the AC, without requiring that multicast services are 1865 enabled in the network. 1867 When the WTP attempts to establish communication with an AC, it sends 1868 the Discovery Request message and receives the Discovery Response 1869 message from the AC(s). The WTP MUST send the Discovery Request 1870 message to either the limited broadcast IP address (255.255.255.255), 1871 the well known CAPWAP multicast address (xx.xx.xx.xx) or to the 1872 unicast IP address of the AC. For IPv6 networks, since broadcast 1873 does not exist, the use of "All ACs multicast address" is used 1874 instead. Upon receipt of the Discovery Request message, the AC sends 1875 a Discovery Response message to the unicast IP address of the WTP, 1876 regardless of whether the Discovery Request message was sent as a 1877 broadcast, multicast or unicast message. 1879 WTP use of a limited IP broadcast, multicast or unicast IP address is 1880 implementation dependent. ACs, on the other hand, MUST support 1881 broadcast, multicast and unicast discovery. 1883 When a WTP transmits a Discovery Request message to a unicast 1884 address, the WTP must first obtain the IP address of the AC. Any 1885 static configuration of an AC's IP address on the WTP non-volatile 1886 storage is implementation dependent. However, additional dynamic 1887 schemes are possible, for example: 1889 DHCP: See [I-D.ietf-capwap-dhc-ac-option] for more information on 1890 the use of DHCP to discover AC IP addresses. 1892 DNS: The WTP MAY support use of DNS SRV records [RFC2782] to 1893 discover the AC address(es). In this case, the WTP first obtains 1894 (e.g., from local configuration) the correct domain name suffix 1895 (e.g., "example.com") and performs a SRV lookup with Service name 1896 "capwap-control" and Proto "udp". Thus, the name resolved in DNS 1897 would be, e.g., "_capwap-control._udp.example.com". Note that the 1898 SRV record MAY specify a non-default port number for the control 1899 channel; the port number for the data channel is the next port 1900 number (control channel port + 1). 1902 An AC MAY also communicate alternative ACs to the WTP within the 1903 Discovery Response message through the AC IPv4 List (see 1904 Section 4.6.2) and AC IPv6 List (see Section 4.6.2). The addresses 1905 provided in these two message elements are intended to help the WTP 1906 discover additional ACs through means other than those listed above. 1908 The AC Name with Priority message element (see Section 4.6.5), is 1909 used to communicate a list of preferred ACs to the WTP. The WTP 1910 SHOULD attempt to utilize the ACs listed in the order provided by the 1911 AC. The Name to IP Address mapping is handled via the Discovery 1912 message exchange, in which the ACs provide their identity in the AC 1913 Name (see Section 4.6.4) message element in the Discovery Response 1914 message. 1916 Once the WTP has received Discovery Response messages from the 1917 candidate ACs, it MAY use other factors to determine the preferred 1918 AC. For instance, each binding defines a WTP Radio Information 1919 message element (see Section 2.1), which the AC includes in Discovery 1920 Response messages. The presence of one or more of these message 1921 elements is used to identify the CAPWAP bindings supported by the AC. 1922 A WTP MAY connect to an AC based on the supported bindings 1923 advertised. 1925 3.4. Fragmentation/Reassembly 1927 While fragmentation and reassembly services are provided by IP, the 1928 CAPWAP protocol also provides such services. Environments where the 1929 CAPWAP protocol is used involve firewall, NAT and "middle box" 1930 devices, which tend to drop IP fragments to minimize possible DoS 1931 attacks. By providing fragmentation and reassembly at the 1932 application layer, any fragmentation required due to the tunneling 1933 component of the CAPWAP protocol becomes transparent to these 1934 intermediate devices. Consequently, the CAPWAP protocol can be used 1935 in any network topology including firewall, NAT and middlebox 1936 devices. 1938 It is important to note that the fragmentation mechanism employed by 1939 CAPWAP has known limitations and deficiencies, which are similar to 1940 those described in [RFC4963]. The limited size of the Fragment ID 1941 field (see Section 4.3 can cause wrapping of the field, and hence 1942 cause fragments from different datagrams to be incorrectly spliced 1943 together (known as "mis-associated"). For example, a 100Mpbs link 1944 with an MTU of 1500 (causing fragmentation at 1450 bytes) would cause 1945 the Fragment ID field wrap in 8 seconds. Consequently, CAPWAP 1946 implementors are warned to properly size their buffers for reassembly 1947 purposes based on the expected wireless technology throughput. 1949 CAPWAP implementations SHOULD perform MTU Discovery (see 1950 Section 3.5), which can avoid the need for fragmentation. At the 1951 time of writing of this specification, most enterprise switching and 1952 routing infrastructure were capable of supporting "mini-jumbo" frames 1953 (1800 bytes), which eliminates the need for fragmentation (assuming 1954 the station's MTU is 1500 bytes). The need for fragmentation 1955 typically continues to exist when the WTP communicates with the AC 1956 over a Wide Area Network (WAN). Therefore, future versions of the 1957 CAPWAP protocol SHOULD either consider increasing the size of the 1958 Fragment ID field, or provide alternatives extensions. 1960 3.5. MTU Discovery 1962 Once a WTP has discovered the AC it wishes to establish a CAPWAP 1963 session with, it SHOULD perform a Path MTU (PMTU) discovery. One 1964 recommendation for performing PMTU discovery is to have the WTP 1965 transmit Discovery Request (see Section 5.1) messages, and include 1966 the MTU Discovery Padding message element (see Section 4.6.31). The 1967 actual procedures used for PMTU discovery are described in [RFC1191], 1968 for IPv4, or for IPv6 [RFC1981] SHOULD be used. Alternatively, 1969 implementers MAY use the procedures defined in [RFC4821]. The WTP 1970 SHOULD also periodically re-evaluate the PMTU using the guidelines 1971 provided in these two RFCs, using the Primary Discovery Request (see 1972 Section 5.3) along with the MTU Discovery Padding message element 1973 (see Section 4.6.31). When the MTU is initially known, or updated in 1974 the case where an existing session already exists, the discovered 1975 PMTU is used to configure the DTLS component (see Section 2.3.2.1), 1976 while non-DTLS frames need to be fragmented to fit the MTU, defined 1977 in Section 3.4. 1979 4. CAPWAP Packet Formats 1981 This section contains the CAPWAP protocol packet formats. A CAPWAP 1982 protocol packet consists of one or more CAPWAP Transport Layer packet 1983 headers followed by a CAPWAP message. The CAPWAP message can be 1984 either of type Control or Data, where Control packets carry 1985 signaling, and Data packets carry user payloads. The CAPWAP frame 1986 formats for CAPWAP Data packets, and for DTLS encapsulated CAPWAP 1987 Data and Control packets are defined below. 1989 The CAPWAP Control protocol includes two messages that are never 1990 protected by DTLS: the Discovery Request message and the Discovery 1991 Response message. These messages need to be in the clear to allow 1992 the CAPWAP protocol to properly identify and process them. The 1993 format of these packets are as follows: 1995 CAPWAP Control Packet (Discovery Request/Response): 1996 +-------------------------------------------+ 1997 | IP | UDP | CAPWAP | Control | Message | 1998 | Hdr | Hdr | Header | Header | Element(s) | 1999 +-------------------------------------------+ 2001 All other CAPWAP control protocol messages MUST be protected via the 2002 DTLS protocol, which ensures that the packets are both authenticated 2003 and encrypted. These packets include the CAPWAP DTLS Header, which 2004 is described in Section 4.2. The format of these packets is as 2005 follows: 2007 CAPWAP Control Packet (DTLS Security Required): 2008 +------------------------------------------------------------------+ 2009 | IP | UDP | CAPWAP | DTLS | CAPWAP | Control| Message | DTLS | 2010 | Hdr | Hdr | DTLS Hdr | Hdr | Header | Header | Element(s)| Trlr | 2011 +------------------------------------------------------------------+ 2012 \---------- authenticated -----------/ 2013 \------------- encrypted ------------/ 2015 The CAPWAP protocol allows optional protection of data packets, using 2016 DTLS. Use of data packet protection is determined by AC policy. 2017 When DTLS is utilized, the optional CAPWAP DTLS Header is present, 2018 which is described in Section 4.2. The format of CAPWAP data packets 2019 is shown below: 2021 CAPWAP Plain Text Data Packet : 2022 +-------------------------------+ 2023 | IP | UDP | CAPWAP | Wireless | 2024 | Hdr | Hdr | Header | Payload | 2025 +-------------------------------+ 2027 DTLS Secured CAPWAP Data Packet: 2028 +--------------------------------------------------------+ 2029 | IP | UDP | CAPWAP | DTLS | CAPWAP | Wireless | DTLS | 2030 | Hdr | Hdr | DTLS Hdr | Hdr | Hdr | Payload | Trlr | 2031 +--------------------------------------------------------+ 2032 \------ authenticated -----/ 2033 \------- encrypted --------/ 2035 UDP Header: All CAPWAP packets are encapsulated within either UDP, 2036 or UDP-Lite when used over IPv6. Section 3 defines the specific 2037 UDP or UDP-Lite usage. 2039 CAPWAP DTLS Header: All DTLS encrypted CAPWAP protocol packets are 2040 prefixed with the CAPWAP DTLS header (see Section 4.2). 2042 DTLS Header: The DTLS header provides authentication and encryption 2043 services to the CAPWAP payload it encapsulates. This protocol is 2044 defined in RFC 4347 [RFC4347]. 2046 CAPWAP Header: All CAPWAP protocol packets use a common header that 2047 immediately follows the CAPWAP preamble or DTLS header. The 2048 CAPWAP Header is defined in Section 4.3. 2050 Wireless Payload: A CAPWAP protocol packet that contains a wireless 2051 payload is a CAPWAP data packet. The CAPWAP protocol does not 2052 specify the format of the wireless payload, which is defined by 2053 the appropriate wireless standard. Additional information is in 2054 Section 4.4. 2056 Control Header: The CAPWAP protocol includes a signaling component, 2057 known as the CAPWAP control protocol. All CAPWAP control packets 2058 include a Control Header, which is defined in Section 4.5.1. 2059 CAPWAP data packets do not contain a Control Header field. 2061 Message Elements: A CAPWAP Control packet includes one or more 2062 message elements, which are found immediately following the 2063 Control Header. These message elements are in a Type/Length/value 2064 style header, defined in Section 4.6. 2066 A CAPWAP implementation MUST be capable of receiving a reassembled 2067 CAPWAP message of length 4096 bytes. A CAPWAP implementation MAY 2068 indicate that it supports a higher maximum message length, by 2069 including the Maximum Message Length message element, see 2070 Section 4.6.30 in the Join Request message or the Join Response 2071 message. 2073 4.1. CAPWAP Preamble 2075 The CAPWAP preamble is common to all CAPWAP transport headers and is 2076 used to identify the header type that immediately follows. The 2077 reason for this preamble is to avoid needing to perform byte 2078 comparisons in order to guess whether the frame is DTLS encrypted or 2079 not. It also provides an extensibility framework that can be used to 2080 support additional transport types. The format of the preamble is as 2081 follows: 2083 0 2084 0 1 2 3 4 5 6 7 2085 +-+-+-+-+-+-+-+-+ 2086 |Version| Type | 2087 +-+-+-+-+-+-+-+-+ 2089 Version: A 4 bit field which contains the version of CAPWAP used in 2090 this packet. The value for this specification is zero (0). 2092 Type: A 4 bit field which specifies the payload type that follows 2093 the UDP header. The following values are supported: 2095 0 - CAPWAP Header. The CAPWAP Header (see Section 4.3) 2096 immediately follows the UDP header. If the packet is received 2097 on the CAPWAP data channel, the CAPWAP stack MUST treat the 2098 packet as a clear text CAPWAP data packet. If received on the 2099 CAPWAP control channel, the CAPWAP stack MUST treat the packet 2100 as a clear text CAPWAP control packet. If the control packet 2101 is not a Discovery Request or Discovery Response packet, the 2102 packet MUST be dropped. 2104 1 - CAPWAP DTLS Header. The CAPWAP DTLS Header, and DTLS packet, 2105 immediately follows the UDP header (see Section 4.2). 2107 4.2. CAPWAP DTLS Header 2109 The CAPWAP DTLS Header is used to identify the packet as a DTLS 2110 encrypted packet. The first eight bits includes the common CAPWAP 2111 Preamble. The remaining 24 bits are padding to ensure 4 byte 2112 alignment, and MAY be used in a future version of the protocol. The 2113 DTLS packet [RFC4347] always immediately follows this header. The 2114 format of the CAPWAP DTLS Header is as follows: 2116 0 1 2 3 2117 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 2118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2119 |CAPWAP Preamble| Reserved | 2120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2122 CAPWAP Preamble: The CAPWAP Preamble is defined in Section 4.1. The 2123 CAPWAP Preamble's Payload Type field MUST be set to one (1). 2125 Reserved: The 24-bit field is reserved for future use. All 2126 implementations complying with this protocol MUST set to zero any 2127 bits that are reserved in the version of the protocol supported by 2128 that implementation. Receivers MUST ignore all bits not defined 2129 for the version of the protocol they support. 2131 4.3. CAPWAP Header 2133 All CAPWAP protocol messages are encapsulated using a common header 2134 format, regardless of the CAPWAP Control or CAPWAP Data transport 2135 used to carry the messages. However, certain flags are not 2136 applicable for a given transport. Refer to the specific transport 2137 section in order to determine which flags are valid. 2139 Note that the optional fields defined in this section MUST be present 2140 in the precise order shown below. 2142 0 1 2 3 2143 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 2144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2145 |CAPWAP Preamble| HLEN | RID | WBID |T|F|L|W|M|K|Flags| 2146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2147 | Fragment ID | Frag Offset |Rsvd | 2148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2149 | (optional) Radio MAC Address | 2150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2151 | (optional) Wireless Specific Information | 2152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2153 | Payload .... | 2154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2156 CAPWAP Preamble: The CAPWAP Preamble is defined in Section 4.1. The 2157 CAPWAP Preamble's Payload Type field MUST be set to zero (0). If 2158 the CAPWAP DTLS Header is present, the version number in both 2159 CAPWAP Preambles MUST match. The reason for this duplicate field 2160 is to avoid any possible tampering of the version field in the 2161 preamble which is not encrypted or authenticated. 2163 HLEN: A 5 bit field containing the length of the CAPWAP transport 2164 header in 4 byte words (Similar to IP header length). This length 2165 includes the optional headers. 2167 RID: A 5 bit field which contains the Radio ID number for this 2168 packet, whose value is between one (1) and 31. Given that MAC 2169 Addresses are not necessarily unique across physical radios in a 2170 WTP, the Radio Identifier (RID) field is used to indicate which 2171 physical radio the message is associated with. 2173 WBID: A 5 bit field which is the wireless binding identifier. The 2174 identifier will indicate the type of wireless packet associated 2175 with the radio. The following values are defined: 2177 0 - Reserved 2179 1 - IEEE 802.11 2181 2 - Reserved 2183 3 - EPCGlobal [EPCGlobal] 2185 T: The Type 'T' bit indicates the format of the frame being 2186 transported in the payload. When this bit is set to one (1), the 2187 payload has the native frame format indicated by the WBID field. 2188 When this bit is zero (0) the payload is an IEEE 802.3 frame. 2190 F: The Fragment 'F' bit indicates whether this packet is a fragment. 2191 When this bit is one (1), the packet is a fragment and MUST be 2192 combined with the other corresponding fragments to reassemble the 2193 complete information exchanged between the WTP and AC. 2195 L: The Last 'L' bit is valid only if the 'F' bit is set and indicates 2196 whether the packet contains the last fragment of a fragmented 2197 exchange between WTP and AC. When this bit is 1, the packet is 2198 the last fragment. When this bit is 0, the packet is not the last 2199 fragment. 2201 W: The Wireless 'W' bit is used to specify whether the optional 2202 Wireless Specific Information field is present in the header. A 2203 value of one (1) is used to represent the fact that the optional 2204 header is present. 2206 M: The M bit is used to indicate that the Radio MAC Address optional 2207 header is present. This is used to communicate the MAC address of 2208 the receiving radio. 2210 K: The 'Keep-alive' K bit indicates the packet is a Data Channel Keep 2211 Alive packet. This packet is used to map the data channel to the 2212 control channel for the specified Session ID and to maintain 2213 freshness of the data channel. The K bit MUST NOT be set for data 2214 packets containing user data. 2216 Flags: A set of reserved bits for future flags in the CAPWAP header. 2217 All implementations complying with this protocol MUST set to zero 2218 any bits that are reserved in the version of the protocol 2219 supported by that implementation. Receivers MUST ignore all bits 2220 not defined for the version of the protocol they support. 2222 Fragment ID: A 16 bit field whose value is assigned to each group of 2223 fragments making up a complete set. The fragment ID space is 2224 managed individually for each direction for every WTP/AC pair. 2225 The value of Fragment ID is incremented with each new set of 2226 fragments. The Fragment ID wraps to zero after the maximum value 2227 has been used to identify a set of fragments. 2229 Fragment Offset: A 13 bit field that indicates where in the payload 2230 this fragment belongs during re-assembly. This field is valid 2231 when the 'F' bit is set to 1. The fragment offset is measured in 2232 units of 8 octets (64 bits). The first fragment has offset zero. 2233 Note the CAPWAP protocol does not allow for overlapping fragments. 2235 Reserved: The 3-bit field is reserved for future use. All 2236 implementations complying with this protocol MUST set to zero any 2237 bits that are reserved in the version of the protocol supported by 2238 that implementation. Receivers MUST ignore all bits not defined 2239 for the version of the protocol they support. 2241 Radio MAC Address: This optional field contains the MAC address of 2242 the radio receiving the packet. Because the native wireless frame 2243 format to IEEE 802.3 format causes the MAC address of the WTP's 2244 radio to be lost, this field allows the address to be communicated 2245 to the AC. This field is only present if the 'M' bit is set. The 2246 HLEN field assumes 4 byte alignment, and this field MUST be padded 2247 with zeroes (0x00) if it is not 4 byte aligned. 2249 The field contains the basic format: 2251 0 1 2 3 2252 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 2253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2254 | Length | MAC Address 2255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2257 Length: The length of the MAC Address field. The following 2258 formats, and lengths, are supported [EUI-48] and [EUI-64]. 2260 MAC Address: The MAC Address of the receiving radio. 2262 Wireless Specific Information: This optional field contains 2263 technology specific information that may be used to carry per 2264 packet wireless information. This field is only present if the 2265 'W' bit is set. The WBID field in the CAPWAP header is used to 2266 identify the format of the wireless specific information optional 2267 field. The HLEN field assumes 4 byte alignment, and this field 2268 MUST be padded with zeroes (0x00) if it is not 4 byte aligned. 2270 The Wireless Specific Information field uses the following format: 2272 0 1 2 3 2273 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 2274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2275 | Length | Data... 2276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2278 Length: The 8 bit field contains the length of the data field, 2279 with a maximum size of 255. 2281 Data: Wireless specific information, defined by the wireless 2282 specific binding specified in the CAPWAP Header's WBID field. 2284 Payload: This field contains the header for a CAPWAP Data Message or 2285 CAPWAP Control Message, followed by the data contained in the 2286 message. 2288 4.4. CAPWAP Data Messages 2290 There are two different types of CAPWAP data packets, CAPWAP Data 2291 Channel Keep Alive packets and Data Payload packets. The first is 2292 used by the WTP to synchronize the control and data channels, and to 2293 maintain freshness of the data channel. The second is used to 2294 transmit user payloads between the AC and WTP. This section 2295 describes both types of CAPWAP data packet formats. 2297 Both CAPWAP data messages are transmitted on the CAPWAP data channel. 2299 4.4.1. CAPWAP Data Channel Keepalive 2301 The CAPWAP Data Channel Keep Alive packet is used to bind the CAPWAP 2302 control channel with the data channel, and to maintain freshness of 2303 the data channel, ensuring that the channel is still functioning. 2304 The CAPWAP Data Channel Keep Alive packet is transmitted by the WTP 2305 when the DataChannelKeepAlive timer expires (see Section 4.7.2). 2306 When the CAPWAP Data Channel Keep Alive packet is transmitted, the 2307 WTP sets the DataChannelDeadInterval timer. 2309 In the CAPWAP Data Channel Keep Alive packet, all of the fields in 2310 the CAPWAP header, except the HLEN field and the K bit, are set to 2311 zero upon transmission. Upon receiving a CAPWAP Data Channel Keep 2312 Alive packet, the AC transmits a CAPWAP Data Channel Keep Alive 2313 packet back to the WTP. The contents of the transmitted packet are 2314 identical to the contents of the received packet. 2316 Upon receiving a CAPWAP Data Channel Keep Alive packet, the WTP 2317 cancels the DataChannelDeadInterval timer and resets the 2318 DataChannelKeepAlive timer. The CAPWAP Data Channel Keep Alive 2319 packet is retransmitted by the WTP in the same manner as the CAPWAP 2320 control messages. If the DataChannelDeadInterval timer expires, the 2321 WTP tears down the control DTLS session, and the data DTLS session if 2322 one existed. 2324 The CAPWAP Data Channel Keep Alive packet contains the following 2325 payload immediately following the CAPWAP Header (see Section 4.3) 2327 0 1 2 3 2328 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 2329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2330 | Message Element Length | Message Element [0..N] ... 2331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2333 Message Element Length: The 16 bit Length field indicates the 2334 number of bytes following the CAPWAP Header, with a maximum size 2335 of 65535. 2337 Message Element[0..N]: The message element(s) carry the information 2338 pertinent to each of the CAPWAP Data Channel Keepalive message. 2339 The following message elements MUST be present in this CAPWAP 2340 message: 2342 Session ID, see Section 4.6.36 2344 4.4.2. Data Payload 2346 A CAPWAP protocol Data Payload packet encapsulates a forwarded 2347 wireless frame. The CAPWAP protocol defines two different modes of 2348 encapsulation; IEEE 802.3 and native wireless. IEEE 802.3 2349 encapsulation requires that for 802.11 frames, the 802.11 2350 *Integration* function be performed in the WTP. An IEEE 802.3 2351 encapsulated user payload frame has the following format: 2353 +------------------------------------------------------+ 2354 | IP Header | UDP Header | CAPWAP Header | 802.3 Frame | 2355 +------------------------------------------------------+ 2357 The CAPWAP protocol also defines the native wireless encapsulation 2358 mode. The format of the encapsulated CAPWAP data frame is subject to 2359 the rules defined by the specific wireless technology binding. Each 2360 wireless technology binding MUST contain a section entitled "Payload 2361 Encapsulation", which defines the format of the wireless payload that 2362 is encapsulated within CAPWAP Data packets. 2364 For 802.3 payload frames, the 802.3 frame is encapsulated (excluding 2365 the IEEE 802.3 Preamble, Start Frame Delimiter (SFD) and Frame Check 2366 Sequence (FCS) Fields). If the encapsulated frame would exceed the 2367 transport layer's MTU, the sender is responsible for fragmentation of 2368 the frame, as specified in Section 3.4. The CAPWAP protocol can 2369 support IEEE 802.3 frames whose length is defined in the IEEE 802.3as 2370 specification [FRAME-EXT]. 2372 4.4.3. Establishment of a DTLS Data Channel 2374 If the AC and WTP are configured to tunnel the data channel over 2375 DTLS, the proper DTLS session must be initiated. To avoid having to 2376 reauthenticate and reauthorize an AC and WTP, the DTLS data channel 2377 SHOULD be initiated using the TLS session resumption feature 2378 [RFC4346]. 2380 The AC DTLS implementation MUST NOT initiate a data channel session 2381 for a DTLS session for which there is no active control channel 2382 session. 2384 4.5. CAPWAP Control Messages 2386 The CAPWAP Control protocol provides a control channel between the 2387 WTP and the AC. Control messages are divided into the following 2388 message types: 2390 Discovery: CAPWAP Discovery messages are used to identify potential 2391 ACs, their load and capabilities. 2393 Join: CAPWAP Join messages are used by a WTP to request service from 2394 an AC, and for the AC to respond to the WTP. 2396 Control Channel Management: CAPWAP control channel management 2397 messages are used to maintain the control channel. 2399 WTP Configuration Management: The WTP Configuration messages are 2400 used by the AC to deliver a specific configuration to the WTP. 2401 Messages which retrieve statistics from a WTP are also included in 2402 WTP Configuration Management. 2404 Station Session Management: Station Session Management messages are 2405 used by the AC to deliver specific station policies to the WTP. 2407 Device Management Operations: Device management operations are used 2408 to request and deliver a firmware image to the WTP. 2410 Binding Specific CAPWAP Management Messages: Messages in this 2411 category are used by the AC and the WTP to exchange protocol- 2412 specific CAPWAP management messages. These messages may or may 2413 not be used to change the link state of a station. 2415 Discovery, Join, Control Channel Management, WTP Configuration 2416 Management and Station Session Management CAPWAP control messages 2417 MUST be implemented. Device Management Operations messages MAY be 2418 implemented. 2420 CAPWAP control messages sent from the WTP to the AC indicate that the 2421 WTP is operational, providing an implicit keep-alive mechanism for 2422 the WTP. The Control Channel Management Echo Request and Echo 2423 Response messages provide an explicit keep-alive mechanism when other 2424 CAPWAP control messages are not exchanged. 2426 4.5.1. Control Message Format 2428 All CAPWAP control messages are sent encapsulated within the CAPWAP 2429 header (see Section 4.3). Immediately following the CAPWAP header, 2430 is the control header, which has the following format: 2432 0 1 2 3 2433 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 2434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2435 | Message Type | 2436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2437 | Seq Num | Msg Element Length | Flags | 2438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2439 | Msg Element [0..N] ... 2440 +-+-+-+-+-+-+-+-+-+-+-+-+ 2442 4.5.1.1. Message Type 2444 The Message Type field identifies the function of the CAPWAP control 2445 message. To provide extensibility, the Message Type field is 2446 comprised of an IANA Enterprise Number [RFC3232] and an enterprise 2447 specific message type number. The first three octets contain the 2448 IANA Enterprise Number in network byte order, with zero used for 2449 CAPWAP base protocol (this specification) defined message types. The 2450 last octet is the enterprise specific message type number, which has 2451 a range from 0 to 255. 2453 The message type field is defined as: 2455 Message Type = 2456 IANA Enterprise Number * 256 + 2457 Enterprise Specific Message Type Number 2459 The CAPWAP protocol reliability mechanism requires that messages be 2460 defined in pairs, consisting of both a Request and a Response 2461 message. The Response message MUST acknowledge the Request message. 2462 The assignment of CAPWAP control Message Type Values always occurs in 2463 pairs. All Request messages have odd numbered Message Type Values, 2464 and all Response messages have even numbered Message Type Values. 2465 The Request value MUST be assigned first. As an example, assigning a 2466 Message Type Value of 3 for a Request message and 4 for a Response 2467 message is valid, while assigning a Message Type Value of 4 for a 2468 Response message and 5 for the corresponding Request message is 2469 invalid. 2471 When a WTP or AC receives a message with a Message Type Value field 2472 that is not recognized and is an odd number, the number in the 2473 Message Type Value Field is incremented by one, and a Response 2474 message with a Message Type Value field containing the incremented 2475 value and containing the Result Code message element with the value 2476 (Unrecognized Request) is returned to the sender of the received 2477 message. If the unknown message type is even, the message is 2478 ignored. 2480 The valid values for CAPWAP Control Message Types are specified in 2481 the table below: 2483 CAPWAP Control Message Message Type 2484 Value 2485 Discovery Request 1 2486 Discovery Response 2 2487 Join Request 3 2488 Join Response 4 2489 Configuration Status Request 5 2490 Configuration Status Response 6 2491 Configuration Update Request 7 2492 Configuration Update Response 8 2493 WTP Event Request 9 2494 WTP Event Response 10 2495 Change State Event Request 11 2496 Change State Event Response 12 2497 Echo Request 13 2498 Echo Response 14 2499 Image Data Request 15 2500 Image Data Response 16 2501 Reset Request 17 2502 Reset Response 18 2503 Primary Discovery Request 19 2504 Primary Discovery Response 20 2505 Data Transfer Request 21 2506 Data Transfer Response 22 2507 Clear Configuration Request 23 2508 Clear Configuration Response 24 2509 Station Configuration Request 25 2510 Station Configuration Response 26 2512 4.5.1.2. Sequence Number 2514 The Sequence Number Field is an identifier value used to match 2515 Request and Response packets. When a CAPWAP packet with a Request 2516 Message Type Value is received, the value of the Sequence Number 2517 field is copied into the corresponding Response message. 2519 When a CAPWAP control message is sent, the sender's internal sequence 2520 number counter is monotonically incremented, ensuring that no two 2521 pending Request messages have the same Sequence Number. The Sequence 2522 Number field wraps back to zero. 2524 4.5.1.3. Message Element Length 2526 The Length field indicates the number of bytes following the Sequence 2527 Number field. 2529 4.5.1.4. Flags 2531 The Flags field MUST be set to zero. 2533 4.5.1.5. Message Element[0..N] 2535 The message element(s) carry the information pertinent to each of the 2536 control message types. Every control message in this specification 2537 specifies which message elements are permitted. 2539 When a WTP or AC receives a CAPWAP message without a message element 2540 that is specified as mandatory for the CAPWAP message, then the 2541 CAPWAP message is discarded. If the received message was a Request 2542 message for which the corresponding Response message carries message 2543 elements, then a corresponding Response message with a Result Code 2544 message element indicating "Failure - Missing Mandatory Message 2545 Element" is returned to the sender. 2547 When a WTP or AC receives a CAPWAP message with a message element 2548 that the WTP or AC does not recognize, the CAPWAP message is 2549 discarded. If the received message was a Request message for which 2550 the corresponding Response message carries message elements, then a 2551 corresponding Response message with a Result Code message element 2552 indicating "Failure - Unrecognized Message Element" and one or more 2553 Returned Message Element message elements is included, containing the 2554 unrecognized message element(s). 2556 4.5.2. Quality of Service 2558 The CAPWAP base protocol does not provide any Quality of Service 2559 (QoS) recommendations for use with the CAPWAP data messages. Any 2560 wireless specific CAPWAP binding specification that has QoS 2561 requirements MUST define the application of QoS to the CAPWAP data 2562 messages. 2564 The IP header also includes the Explicit Congestion Notification 2565 (ECN) bits [RFC3168]. When packets received from stations are 2566 encapsulated by the WTP, the ECN bits are set to zero (0) in the 2567 outer header. The WTP does not modify the ECN bits in the original 2568 station's packet header. This mode of operation is detailed as the 2569 "limited functionality option" in [RFC3168]. 2571 4.5.2.1. Applying QoS to CAPWAP Control Message 2573 It is recommended that CAPWAP control messages be sent by both the AC 2574 and the WTP with an appropriate Quality of Service precedence value, 2575 ensuring that congestion in the network minimizes occurrences of 2576 CAPWAP control channel disconnects. Therefore, a Quality of Service 2577 enabled CAPWAP device SHOULD use the following values: 2579 802.1Q: The priority tag of 7 SHOULD be used. 2581 DSCP: The CS6 per-hop behavior Service Class SHOULD be used, which 2582 is described in [RFC2474]). 2584 4.5.3. Retransmissions 2586 The CAPWAP control protocol operates as a reliable transport. For 2587 each Request message, a Response message is defined, which is used to 2588 acknowledge receipt of the Request message. In addition, the control 2589 header Sequence Number field is used to pair the Request and Response 2590 messages (see Section 4.5.1). 2592 Response messages are not explicitly acknowledged, therefore if a 2593 Response message is not received, the original Request message is 2594 retransmitted. 2596 Implementations MUST keep track of the Sequence Number of the last 2597 received Request message, and MUST cache the corresponding Response 2598 message. If a retransmission with the same Sequence Number is 2599 received, the cached Response message MUST be retransmitted without 2600 re-processing the Request. If an older Request message is received, 2601 meaning one where the sequence number is smaller, it MUST be ignored. 2602 A newer Request message, meaning one whose sequence number is larger, 2603 is processed as usual. 2605 Note: A sequence number is considered "smaller" when s1 is smaller 2606 than s2 modulo 256 if and only if (s1s2 2607 and (s1-s2)>128) 2609 Both the WTP and the AC can only have a single request outstanding at 2610 any given time. Retransmitted Request messages MUST NOT be altered 2611 by the sender. 2613 After transmitting a Request message, the RetransmitInterval (see 2614 Section 4.7) timer and MaxRetransmit (see Section 4.8) variable are 2615 used to determine if the original Request message needs to be 2616 retransmitted. The RetransmitInterval timer is used the first time 2617 the Request is retransmitted. The timer is then doubled every 2618 subsequent time the same Request message is retransmitted, up to 2619 MaxRetransmit but no more than half the EchoInterval timer (see 2620 Section 4.7.7). Response messages are not subject to these timers. 2622 If the sender stops retransmitting a Request message before reaching 2623 MaxRetransmit retransmissions (which leads to transition to DTLS 2624 Teardown, as described in Section 2.3.1), it cannot know whether the 2625 recipient received and processed the Request or not. In most 2626 situations, the sender SHOULD NOT do this, and instead continue 2627 retransmitting until a Response message is received, or transition to 2628 DTLS Teardown occurs. However, if the sender does decide to continue 2629 the connection with a new or modified Request message, the new 2630 message MUST have a new Sequence Number, and be treated as a new 2631 Request message by the receiver. Note that there is a high chance 2632 that both the WTP and the AC's sequence numbers will become out of 2633 sync. 2635 When a Request message is retransmitted, it MUST be re-encrypted via 2636 the DTLS stack. If the peer had received the Request message, and 2637 the corresponding Response message was lost, it is necessary to 2638 ensure that retransmitted Request messages are not identified as 2639 replays by the DTLS stack. Similarly, any cached Response messages 2640 that are retransmitted as a result of receiving a retransmitted 2641 Request message MUST be re-encrypted via DTLS. 2643 Duplicate Response messages, identified by the Sequence Number field 2644 in the CAPWAP control message header, SHOULD be discarded upon 2645 receipt. 2647 4.6. CAPWAP Protocol Message Elements 2649 This section defines the CAPWAP Protocol message elements which are 2650 included in CAPWAP protocol control messages. 2652 Message elements are used to carry information needed in control 2653 messages. Every message element is identified by the Type Value 2654 field, defined below. The total length of the message elements is 2655 indicated in the message element Length field. 2657 All of the message element definitions in this document use a diagram 2658 similar to the one below in order to depict its format. Note that to 2659 simplify this specification, these diagrams do not include the header 2660 fields (Type and Length). The header field values are defined in the 2661 message element descriptions. 2663 Unless otherwise specified, a control message that lists a set of 2664 supported (or expected) message elements MUST NOT expect the message 2665 elements to be in any specific order. The sender MAY include the 2666 message elements in any order. Unless otherwise noted, one message 2667 element of each type is present in a given control message. 2669 Unless otherwise specified, any configuration information sent by the 2670 AC to the WTP MAY be saved to non-volatile storage (see Section 8.1) 2671 for more information). 2673 Additional message elements may be defined in separate IETF 2674 documents. 2676 The format of a message element uses the TLV format shown here: 2678 0 1 2 3 2679 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 2680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2681 | Type | Length | 2682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2683 | Value ... | 2684 +-+-+-+-+-+-+-+-+ 2686 The 16 bit Type field identifies the information carried in the Value 2687 field and Length (16 bits) indicates the number of bytes in the Value 2688 field. The value of zero (0) is reserved and MUST NOT be used. The 2689 rest of the Type field values are allocated as follows: 2691 Usage Type Values 2693 CAPWAP Protocol Message Elements 1 - 1023 2694 IEEE 802.11 Message Elements 1024 - 2047 2695 Reserved for Future Use 2048 - 3071 2696 EPCGlobal Message Elements 3072 - 4095 2697 Reserved for Future Use 4096 - 65535 2699 The table below lists the CAPWAP protocol Message Elements and their 2700 Type values. 2702 CAPWAP Message Element Type Value 2704 AC Descriptor 1 2705 AC IPv4 List 2 2706 AC IPv6 List 3 2707 AC Name 4 2708 AC Name with Priority 5 2709 AC Timestamp 6 2710 Add MAC ACL Entry 7 2711 Add Station 8 2712 Reserved 9 2713 CAPWAP Control IPV4 Address 10 2714 CAPWAP Control IPV6 Address 11 2715 CAPWAP Local IPV4 Address 30 2716 CAPWAP Local IPV6 Address 50 2717 CAPWAP Timers 12 2718 CAPWAP Transport Protocol 51 2719 Data Transfer Data 13 2720 Data Transfer Mode 14 2721 Decryption Error Report 15 2722 Decryption Error Report Period 16 2723 Delete MAC ACL Entry 17 2724 Delete Station 18 2725 Reserved 19 2726 Discovery Type 20 2727 Duplicate IPv4 Address 21 2728 Duplicate IPv6 Address 22 2729 Idle Timeout 23 2730 Image Data 24 2731 Image Identifier 25 2732 Image Information 26 2733 Initiate Download 27 2734 Location Data 28 2735 Maximum Message Length 29 2736 MTU Discovery Padding 52 2737 Radio Administrative State 31 2738 Radio Operational State 32 2739 Result Code 33 2740 Returned Message Element 34 2741 Session ID 35 2742 Statistics Timer 36 2743 Vendor Specific Payload 37 2744 WTP Board Data 38 2745 WTP Descriptor 39 2746 WTP Fallback 40 2747 WTP Frame Tunnel Mode 41 2748 Reserved 42 2749 Reserved 43 2750 WTP MAC Type 44 2751 WTP Name 45 2752 Unused/Reserved 46 2753 WTP Radio Statistics 47 2754 WTP Reboot Statistics 48 2755 WTP Static IP Address Information 49 2757 4.6.1. AC Descriptor 2759 The AC Descriptor message element is used by the AC to communicate 2760 its current state. The value contains the following fields. 2762 0 1 2 3 2763 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 2764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2765 | Stations | Limit | 2766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2767 | Active WTPs | Max WTPs | 2768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2769 | Security | R-MAC Field | Reserved1 | DTLS Policy | 2770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2771 | AC Information Sub-Element... 2772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2774 Type: 1 for AC Descriptor 2776 Length: >= 12 2778 Stations: The number of stations currently served by the AC 2780 Limit: The maximum number of stations supported by the AC 2782 Active WTPs: The number of WTPs currently attached to the AC 2784 Max WTPs: The maximum number of WTPs supported by the AC 2786 Security: A 8 bit mask specifying the authentication credential 2787 type supported by the AC (See Section 2.4.4). The field has the 2788 following format: 2790 0 1 2 3 4 5 6 7 2791 +-+-+-+-+-+-+-+-+ 2792 |Reserved |S|X|R| 2793 +-+-+-+-+-+-+-+-+ 2795 Reserved: A set of reserved bits for future use. All 2796 implementations complying with this protocol MUST set to zero 2797 any bits that are reserved in the version of the protocol 2798 supported by that implementation. Receivers MUST ignore all 2799 bits not defined for the version of the protocol they support. 2801 S: The AC supports the pre-shared secret authentication, as 2802 described in Section 12.6. 2804 X: The AC supports X.509 Certificate authentication, as 2805 described in Section 12.7. 2807 R: A reserved bit for future use. All implementations complying 2808 with this protocol MUST set to zero any bits that are reserved 2809 in the version of the protocol supported by that 2810 implementation. Receivers MUST ignore all bits not defined for 2811 the version of the protocol they support. 2813 R-MAC Field: The AC supports the optional Radio MAC Address field 2814 in the CAPWAP transport Header (see Section 4.3). The following 2815 enumerated values are supported: 2817 0 - Reserved 2819 1 - Supported 2821 2 - Not Supported 2823 Reserved: A set of reserved bits for future use. All 2824 implementations complying with this protocol MUST set to zero any 2825 bits that are reserved in the version of the protocol supported by 2826 that implementation. Receivers MUST ignore all bits not defined 2827 for the version of the protocol they support. 2829 DTLS Policy: The AC communicates its policy on the use of DTLS for 2830 the CAPWAP data channel. The AC MAY communicate more than one 2831 supported option, represented by the bit field below. The WTP 2832 MUST abide by one of the options communicated by AC. The field 2833 has the following format: 2835 0 1 2 3 4 5 6 7 2836 +-+-+-+-+-+-+-+-+ 2837 |Reserved |D|C|R| 2838 +-+-+-+-+-+-+-+-+ 2840 Reserved: A set of reserved bits for future use. All 2841 implementations complying with this protocol MUST set to zero 2842 any bits that are reserved in the version of the protocol 2843 supported by that implementation. Receivers MUST ignore all 2844 bits not defined for the version of the protocol they support. 2846 D: DTLS Enabled Data Channel Supported 2848 C: Clear Text Data Channel Supported 2850 R: A reserved bit for future use. All implementations complying 2851 with this protocol MUST set to zero any bits that are reserved 2852 in the version of the protocol supported by that 2853 implementation. Receivers MUST ignore all bits not defined for 2854 the version of the protocol they support. 2856 AC Information Sub-Element: The AC Descriptor message element 2857 contains multiple AC Information sub-elements, and defines two 2858 sub-types, each of which MUST be present. The AC Information sub- 2859 element has the following format: 2861 0 1 2 3 2862 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 2863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2864 | AC Information Vendor Identifier | 2865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2866 | AC Information Type | AC Information Length | 2867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2868 | AC Information Data... 2869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2871 AC Information Vendor Identifier: A 32-bit value containing the 2872 IANA assigned "SMI Network Management Private Enterprise Codes" 2874 AC Information Type: Vendor specific encoding of AC information 2875 in the UTF-8 format [RFC3629]. The following enumerated values 2876 are supported. Both the Hardware and Software Version sub- 2877 elements MUST be included in the AC Descriptor message element. 2878 The values listed below are used in conjunction with the AC 2879 Information Vendor Identifier field, whose value MUST be set to 2880 zero (0). This field, combined with the AC Information Vendor 2881 Identifier set to a non-zero (0) value, allows vendors to use a 2882 private namespace. 2884 4 - Hardware Version: The AC's hardware version number. 2886 5 - Software Version: The AC's Software (firmware) version 2887 number. 2889 AC Information Length: Length of vendor specific encoding of AC 2890 information, with a maximum size of 1024. 2892 AC Information Data: Vendor specific encoding of AC information. 2894 4.6.2. AC IPv4 List 2896 The AC IPv4 List message element is used to configure a WTP with the 2897 latest list of ACs available for the WTP to join. 2899 0 1 2 3 2900 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 2901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2902 | AC IP Address[] | 2903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2905 Type: 2 for AC IPv4 List 2907 Length: >= 4 2909 AC IP Address: An array of 32-bit integers containing AC IPv4 2910 Addresses, containing no more than 1024 addresses. 2912 4.6.3. AC IPv6 List 2914 The AC IPv6 List message element is used to configure a WTP with the 2915 latest list of ACs available for the WTP to join. 2917 0 1 2 3 2918 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 2919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2920 | AC IP Address[] | 2921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2922 | AC IP Address[] | 2923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2924 | AC IP Address[] | 2925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2926 | AC IP Address[] | 2927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2929 Type: 3 for AC IPV6 List 2931 Length: >= 16 2933 AC IP Address: An array of 128-bit integers containing AC IPv6 2934 Addresses, containing no more than 1024 addresses. 2936 4.6.4. AC Name 2938 The AC Name message element contains an UTF-8 [RFC3629] 2939 representation of the AC identity. The value is a variable length 2940 byte string. The string is NOT zero terminated. 2942 0 2943 0 1 2 3 4 5 6 7 2944 +-+-+-+-+-+-+-+-+ 2945 | Name ... 2946 +-+-+-+-+-+-+-+-+ 2948 Type: 4 for AC Name 2950 Length: >= 1 2952 Name: A variable length UTF-8 encoded string [RFC3629] containing 2953 the AC's name, whose maximum size MUST NOT exceed 512 bytes. 2955 4.6.5. AC Name with Priority 2957 The AC Name with Priority message element is sent by the AC to the 2958 WTP to configure preferred ACs. The number of instances of this 2959 message element is equal to the number of ACs configured on the WTP. 2960 The WTP also uses this message element to send its configuration to 2961 the AC. 2963 0 1 2964 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2966 | Priority | AC Name... 2967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2969 Type: 5 for AC Name with Priority 2971 Length: >= 2 2973 Priority: A value between 1 and 255 specifying the priority order 2974 of the preferred AC. For instance, the value of one (1) is used 2975 to set the primary AC, the value of two (2) is used to set the 2976 secondary, etc. 2978 AC Name: A variable length UTF-8 encoded string [RFC3629] 2979 containing the AC name, whose maximum size MUST NOT exceed 512 2980 bytes. 2982 4.6.6. AC Timestamp 2984 The AC Timestamp message element is sent by the AC to synchronize the 2985 WTP clock. 2987 0 1 2 3 2988 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 2989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2990 | Timestamp | 2991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2993 Type: 6 for AC Timestamp 2995 Length: 4 2997 Timestamp: The AC's current time, allowing all of the WTPs to be 2998 time synchronized in the format defined by Network Time Protocol 2999 (NTP) in RFC 1305 [RFC1305]. Only the most significant 32 bits of 3000 the NTP time is included in this field. 3002 4.6.7. Add MAC ACL Entry 3004 The Add MAC Access Control List (ACL) Entry message element is used 3005 by an AC to add a MAC ACL list entry on a WTP, ensuring that the WTP 3006 no longer provides service to the MAC addresses provided in the 3007 message. The MAC Addresses provided in this message element are not 3008 expected to be saved in non-volatile memory on the WTP. The MAC ACL 3009 table on the WTP is cleared everytime the WTP establishes a new 3010 session with an AC. 3012 0 1 2 3 3013 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 3014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3015 | Num of Entries| Length | MAC Address ... 3016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3018 Type: 7 for Add MAC ACL Entry 3020 Length: >= 8 3022 Num of Entries: The number of instances of the Length/MAC Addresses 3023 fields in the array. This value MUST NOT exceed 255. 3025 Length: The length of the MAC Address field. The following formats, 3026 and lengths, are supported [EUI-48] and [EUI-64]. 3028 MAC Address: MAC Addresses to add to the ACL. 3030 4.6.8. Add Station 3032 The Add Station message element is used by the AC to inform a WTP 3033 that it should forward traffic for a station. The Add Station 3034 message element is accompanied by technology specific binding 3035 information element(s) which may include security parameters. 3036 Consequently, the security parameters MUST be applied by the WTP for 3037 the station. 3039 After station policy has been delivered to the WTP through the Add 3040 Station message element, an AC MAY change any policies by sending a 3041 modified Add Station message element. When a WTP receives an Add 3042 Station message element for an existing station, it MUST override any 3043 existing state for the station. 3045 0 1 2 3 3046 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 3047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3048 | Radio ID | Length | MAC Address ... 3049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3050 | VLAN Name... 3051 +-+-+-+-+-+-+-+-+ 3053 Type: 8 for Add Station 3055 Length: >= 8 3057 Radio ID: An 8-bit value representing the radio, whose value is 3058 between one (1) and 31. 3060 Length: The length of the MAC Address field. The following formats, 3061 and lengths, are supported [EUI-48] and [EUI-64]. 3063 MAC Address: The station's MAC Address 3065 VLAN Name: An optional variable length UTF-8 encoded 3066 string[RFC3629], with a maximum length of 512 octets, containing 3067 the VLAN Name on which the WTP is to locally bridge user data. 3068 Note this field is only valid with WTPs configured in Local MAC 3069 mode. 3071 4.6.9. CAPWAP Control IPv4 Address 3073 The CAPWAP Control IPv4 Address message element is sent by the AC to 3074 the WTP during the discovery process and is used by the AC to provide 3075 the interfaces available on the AC, and the current number of WTPs 3076 connected. When multiple CAPWAP Control IPV4 Address message 3077 elements are returned, the WTP SHOULD perform load balancing across 3078 the multiple interfaces (see Section 6.1). 3080 0 1 2 3 3081 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 3082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3083 | IP Address | 3084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3085 | WTP Count | 3086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3088 Type: 10 for CAPWAP Control IPv4 Address 3090 Length: 6 3092 IP Address: The IP Address of an interface. 3094 WTP Count: The number of WTPs currently connected to the interface, 3095 with a maximum value of 65535. 3097 4.6.10. CAPWAP Control IPv6 Address 3099 The CAPWAP Control IPv6 Address message element is sent by the AC to 3100 the WTP during the discovery process and is used by the AC to provide 3101 the interfaces available on the AC, and the current number of WTPs 3102 connected. This message element is useful for the WTP to perform 3103 load balancing across multiple interfaces (see Section 6.1). 3105 0 1 2 3 3106 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 3107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3108 | IP Address | 3109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3110 | IP Address | 3111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3112 | IP Address | 3113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3114 | IP Address | 3115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3116 | WTP Count | 3117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3119 Type: 11 for CAPWAP Control IPv6 Address 3121 Length: 18 3123 IP Address: The IP Address of an interface. 3125 WTP Count: The number of WTPs currently connected to the interface, 3126 with a maximum value of 65535. 3128 4.6.11. CAPWAP Local IPv4 Address 3130 The CAPWAP Local IPv4 Address message element is sent by either the 3131 WTP, in the Join Request, or by the AC, in the Join Response. The 3132 CAPWAP Local IPv4 Address message element is used to communicate the 3133 IP Address of the transmitter. The receiver uses this to determine 3134 whether a middlebox exists between the two peers, by comparing the 3135 source IP address of the packet against the value of the message 3136 element. 3138 0 1 2 3 3139 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 3140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3141 | IP Address | 3142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3144 Type: 30 for CAPWAP Local IPv4 Address 3146 Length: 4 3148 IP Address: The IP Address of the sender. 3150 4.6.12. CAPWAP Local IPv6 Address 3152 The CAPWAP Local IPv6 Address message element is sent by either the 3153 WTP, in the Join Request, or by the AC, in the Join Response. The 3154 CAPWAP Local IPv6 Address message element is used to communicate the 3155 IP Address of the transmitter. The receiver uses this to determine 3156 whether a middlebox exists between the two peers, by comparing the 3157 source IP address of the packet against the value of the message 3158 element. 3160 0 1 2 3 3161 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 3162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3163 | IP Address | 3164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3165 | IP Address | 3166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3167 | IP Address | 3168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3169 | IP Address | 3170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3172 Type: 50 for CAPWAP Local IPv6 Address 3174 Length: 16 3176 IP Address: The IP Address of the sender. 3178 4.6.13. CAPWAP Timers 3180 The CAPWAP Timers message element is used by an AC to configure 3181 CAPWAP timers on a WTP. 3183 0 1 3184 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3186 | Discovery | Echo Request | 3187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3189 Type: 12 for CAPWAP Timers 3191 Length: 2 3193 Discovery: The number of seconds between CAPWAP Discovery messages, 3194 when the WTP is in the discovery phase. This value is used to 3195 configure the MaxDiscoveryInterval timer (see Section 4.7.10). 3197 Echo Request: The number of seconds between WTP Echo Request CAPWAP 3198 messages. This value is used to configure the EchoInterval timer 3199 (see Section 4.7.7). The AC sets its EchoInterval timer to this 3200 value, plus the maximum retransmission time as described in 3201 Section 4.5.3. 3203 4.6.14. CAPWAP Transport Protocol 3205 When CAPWAP is run over IPv6, the UDP-Lite or UDP transports MAY be 3206 used (see Section 3). The CAPWAP IPv6 Transport Protocol message 3207 element is used by either the WTP or the AC to signal which transport 3208 protocol is to be used for the CAPWAP data channel. 3210 Upon receiving the Join Request, the AC MAY set the CAPWAP Transport 3211 Protocol to UDP-Lite in the Join Response message if the CAPWAP 3212 message was received over IPv6, and the CAPWAP Local IPv6 Address 3213 message element (see Section 4.6.12) is present and no middlebox was 3214 detected (see Section 11). 3216 Upon receiving the Join Response, the WTP MAY set the CAPWAP 3217 Transport Protocol to UDP-Lite in the Configuration Status Request or 3218 Image Data Request message if the AC advertised support for UDP-Lite, 3219 the message was received over IPv6, the CAPWAP Local IPv6 Address 3220 message element (see Section 4.6.12) and no middlebox was detected 3221 (see Section 11). Upon receiving either the Configuration Status 3222 Request or the Image Data Request, the AC MUST observe the preference 3223 indicated by the WTP in the CAPWAP Transport Protocol, as long as it 3224 is consistent with what the AC advertised in the Join Response. 3226 For any other condition, the CAPWAP Transport Protocol MUST be set to 3227 UDP. 3229 0 3230 0 1 2 3 4 5 6 7 3231 +-+-+-+-+-+-+-+-+ 3232 | Transport | 3233 +-+-+-+-+-+-+-+-+ 3235 Type: 51 for CAPWAP Transport Protocol 3237 Length: 1 3239 Transport: The transport to use for the CAPWAP data channel. The 3240 following enumerated values are supported: 3242 1 - UDP-Lite: The UDP-Lite transport protocol is to be used for 3243 the CAPWAP data channel. Note that this option MUST NOT be 3244 used if the CAPWAP control channel is being used over IPv4. 3246 2 - UDP: The UDP transport protocol is to be used for the CAPWAP 3247 data channel. 3249 4.6.15. Data Transfer Data 3251 The Data Transfer Data message element is used by the WTP to provide 3252 information to the AC for debugging purposes. 3254 0 1 2 3 3255 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 3256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3257 | Data Type | Data Mode | Data Length | 3258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3259 | Data .... 3260 +-+-+-+-+-+-+-+-+ 3262 Type: 13 for Data Transfer Data 3264 Length: >= 5 3266 Data Type: An 8-bit value representing the transfer Data Type. The 3267 following enumerated values are supported: 3269 1 - Transfer data is included 3271 2 - Last Transfer Data Block is included (EOF) 3273 5 - An error occurred. Transfer is aborted 3275 Data Mode: An 8-bit value the type of information being 3276 transmitted. The following enumerated values are supported: 3278 0 - Reserved 3280 1 - WTP Crash Data 3282 2 - WTP Memory Dump 3284 Data Length: Length of data field, with a maximum size of 65535. 3286 Data: Data being transferred from the WTP to the AC, whose type is 3287 identified via the Data Mode field. 3289 4.6.16. Data Transfer Mode 3291 The Data Transfer Mode message element is used by the WTP to indicate 3292 the type of data transfer information it is sending to the AC for 3293 debugging purposes. 3295 0 3296 0 1 2 3 4 5 6 7 3297 +-+-+-+-+-+-+-+-+ 3298 | Data Mode | 3299 +-+-+-+-+-+-+-+-+ 3301 Type: 14 for Data Transfer Mode 3303 Length: 1 3305 Data Mode: An 8-bit value the type of information being requested. 3306 The following enumerated values are supported: 3308 0 - Reserved 3310 1 - WTP Crash Data 3312 2 - WTP Memory Dump 3314 4.6.17. Decryption Error Report 3316 The Decryption Error Report message element value is used by the WTP 3317 to inform the AC of decryption errors that have occurred since the 3318 last report. Note that this error reporting mechanism is not used if 3319 encryption and decryption services are provided in the AC. 3321 0 1 2 3322 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 3323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3324 | Radio ID |Num Of Entries | Length | MAC Address... 3325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3327 Type: 15 for Decryption Error Report 3329 Length: >= 9 3331 Radio ID: The Radio Identifier refers to an interface index on the 3332 WTP, whose value is between one (1) and 31. 3334 Num of Entries: The number of instances of the Length/MAC Addresses 3335 fields in the array. This field MUST NOT exceed the value of 255. 3337 Length: The length of the MAC Address field. The following formats, 3338 and lengths, are supported [EUI-48] and [EUI-64]. 3340 MAC Address: MAC addresses of the station that has caused 3341 decryption errors. 3343 4.6.18. Decryption Error Report Period 3345 The Decryption Error Report Period message element value is used by 3346 the AC to inform the WTP how frequently it should send decryption 3347 error report messages. Note that this error reporting mechanism is 3348 not used if encryption and decryption services are provided in the 3349 AC. 3351 0 1 2 3352 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 3353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3354 | Radio ID | Report Interval | 3355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3357 Type: 16 for Decryption Error Report Period 3359 Length: 3 3361 Radio ID: The Radio Identifier refers to an interface index on the 3362 WTP, whose value is between one (1) and 31. 3364 Report Interval: A 16-bit unsigned integer indicating the time, in 3365 seconds. The default value for this message element can be found 3366 in Section 4.7.11. 3368 4.6.19. Delete MAC ACL Entry 3370 The Delete MAC ACL Entry message element is used by an AC to delete a 3371 MAC ACL entry on a WTP, ensuring that the WTP provides service to the 3372 MAC addresses provided in the message. 3374 0 1 2 3 3375 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 3376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3377 | Num of Entries| Length | MAC Address ... 3378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3380 Type: 17 for Delete MAC ACL Entry 3382 Length: >= 8 3384 Num of Entries: The number of instances of the Length/MAC Addresses 3385 fields in the array. This field MUST NOT exceed the value of 255. 3387 Length: The length of the MAC Address field. The following formats, 3388 and lengths, are supported [EUI-48] and [EUI-64]. 3390 MAC Address: An array of MAC Addresses to delete from the ACL. 3392 4.6.20. Delete Station 3394 The Delete Station message element is used by the AC to inform a WTP 3395 that it should no longer provide service to a particular station. 3396 The WTP MUST terminate service to the station immediately upon 3397 receiving this message element. 3399 The transmission of a Delete Station message element could occur for 3400 various reasons, including for administrative reasons, or if the 3401 station has roamed to another WTP. 3403 The Delete Station message element MAY be sent by the WTP, in the WTP 3404 Event Request message, to inform the AC that a particular station is 3405 no longer being provided service. This could occur as a result of an 3406 Idle Timeout (see section 4.4.43), due to internal resource shortages 3407 or for some other reason. 3409 0 1 2 3 3410 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 3411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3412 | Radio ID | Length | MAC Address... 3413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3415 Type: 18 for Delete Station 3417 Length: >= 8 3419 Radio ID: An 8-bit value representing the radio, whose value is 3420 between one (1) and 31. 3422 Length: The length of the MAC Address field. The following formats, 3423 and lengths, are supported [EUI-48] and [EUI-64]. 3425 MAC Address: The station's MAC Address 3427 4.6.21. Discovery Type 3429 The Discovery Type message element is used by the WTP to indicate how 3430 it has come to know about the existence of the AC to which it is 3431 sending the Discovery Request message. 3433 0 3434 0 1 2 3 4 5 6 7 3435 +-+-+-+-+-+-+-+-+ 3436 | Discovery Type| 3437 +-+-+-+-+-+-+-+-+ 3439 Type: 20 for Discovery Type 3441 Length: 1 3443 Discovery Type: An 8-bit value indicating how the WTP discovered 3444 the AC. The following enumerated values are supported: 3446 0 - Unknown 3448 1 - Static Configuration 3450 2 - DHCP 3452 3 - DNS 3454 4 - AC Referral (used when the AC was configured either through 3455 the AC IPv4 List or AC IPv6 List message element) 3457 4.6.22. Duplicate IPv4 Address 3459 The Duplicate IPv4 Address message element is used by a WTP to inform 3460 an AC that it has detected another IP device using the same IP 3461 address that the WTP is currently using. 3463 The WTP MUST transmit this message element with the status set to 1 3464 after it has detected a duplicate IP address. When the WTP detects 3465 that the duplicate IP address has been cleared, it MUSY send this 3466 message element with the status set to 0. 3468 0 1 2 3 3469 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 3470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3471 | IP Address | 3472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3473 | Status | Length | MAC Address ... 3474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3476 Type: 21 for Duplicate IPv4 Address 3478 Length: >= 12 3480 IP Address: The IP Address currently used by the WTP. 3482 Status: The status of the duplicate IP address. The value MUST be 3483 set to 1 when a duplicate address is detected, and 0 when the 3484 duplicate address has been cleared. 3486 Length: The length of the MAC Address field. The following formats, 3487 and lengths, are supported [EUI-48] and [EUI-64]. 3489 MAC Address: The MAC Address of the offending device. 3491 4.6.23. Duplicate IPv6 Address 3493 The Duplicate IPv6 Address message element is used by a WTP to inform 3494 an AC that it has detected another host using the same IP address 3495 that the WTP is currently using. 3497 The WTP MUST transmit this message element with the status set to 1 3498 after it has detected a duplicate IP address. When the WTP detects 3499 that the duplicate IP address has been cleared, it MUST send this 3500 message element with the status set to 0. 3502 0 1 2 3 3503 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 3504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3505 | IP Address | 3506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3507 | IP Address | 3508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3509 | IP Address | 3510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3511 | IP Address | 3512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3513 | Status | Length | MAC Address ... 3514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3516 Type: 22 for Duplicate IPv6 Address 3518 Length: >= 24 3520 IP Address: The IP Address currently used by the WTP. 3522 Status: The status of the duplicate IP address. The value MUST be 3523 set to 1 when a duplicate address is detected, and 0 when the 3524 duplicate address has been cleared. 3526 Length: The length of the MAC Address field. The following formats, 3527 and lengths, are supported [EUI-48] and [EUI-64]. 3529 MAC Address: The MAC Address of the offending device. 3531 4.6.24. Idle Timeout 3533 The Idle Timeout message element is sent by the AC to the WTP to 3534 provide the idle timeout value that the WTP SHOULD enforce for its 3535 active stations. The value applies to all radios on the WTP. 3537 0 1 2 3 3538 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 3539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3540 | Timeout | 3541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3543 Type: 23 for Idle Timeout 3545 Length: 4 3546 Timeout: The current idle timeout, in seconds, to be enforced by 3547 the WTP. The default value for this message element is specified 3548 in Section 4.7.8. 3550 4.6.25. Image Data 3552 The Image Data message element is present in the Image Data Request 3553 message sent by the AC and contains the following fields. 3555 0 1 2 3 3556 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 3557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3558 | Data Type | Data .... 3559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3561 Type: 24 for Image Data 3563 Length: >= 1 3565 Data Type: An 8-bit value representing the image Data Type. The 3566 following enumerated values are supported: 3568 1 - Image data is included 3570 2 - Last Image Data Block is included (EOF) 3572 5 - An error occurred. Transfer is aborted 3574 Data: The Image Data field contains up to 1024 characters, and its 3575 length is inferred from this message element's length field. If 3576 the block being sent is the last one, the Data Type field is set 3577 to 2. The AC MAY opt to abort the data transfer by setting the 3578 Data Type field to 5. When the Data Type field is 5, the Value 3579 field has a zero length. 3581 4.6.26. Image Identifier 3583 The Image Identifier message element is sent by the AC to the WTP to 3584 indicate the expected active software version that is to be run on 3585 the WTP. The WTP sends the Image Identifier message element in order 3586 to request a specific software version from the AC. The actual 3587 download process is defined in Section 9.1. The value is a variable 3588 length UTF-8 encoded string [RFC3629], which is NOT zero terminated. 3590 0 1 2 3 3591 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 3592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3593 | Vendor Identifier | 3594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3595 | Data... 3596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3598 Type: 25 for Image Identifier 3600 Length: >= 5 3602 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 3603 Network Management Private Enterprise Codes" 3605 Data: A variable length UTF-8 encoded string [RFC3629] containing 3606 the firmware identifier to be run on the WTP, whose length MUST 3607 NOT exceed 1024 octets. The length of this field is inferred from 3608 this message element's length field. 3610 4.6.27. Image Information 3612 The Image Information message element is present in the Image Data 3613 Response message sent by the AC to the WTP and contains the following 3614 fields. 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 | File Size | 3620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3621 | Hash | 3622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3623 | Hash | 3624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3625 | Hash | 3626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3627 | Hash | 3628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3630 Type: 26 for Image Information 3632 Length: 20 3634 File Size: A 32-bit value containing the size of the file, in 3635 bytes, that will be transferred by the AC to the WTP. 3637 Hash: A 16 octet MD5 hash of the image using the procedures defined 3638 in [RFC1321]. 3640 4.6.28. Initiate Download 3642 The Initiate Download message element is used by the WTP to inform 3643 the AC that the AC SHOULD initiate a firmware upgrade. The AC 3644 subsequently transmits an Image Data Request message which includes 3645 the Image Data message element. This message element does not 3646 contain any data. 3648 Type: 27 for Initiate Download 3650 Length: 0 3652 4.6.29. Location Data 3654 The Location Data message element is a variable length byte UTF-8 3655 encoded string [RFC3629] containing user defined location information 3656 (e.g. "Next to Fridge"). This information is configurable by the 3657 network administrator, and allows the WTP location to be determined. 3658 The string is not zero terminated. 3660 0 3661 0 1 2 3 4 5 6 7 3662 +-+-+-+-+-+-+-+-+- 3663 | Location ... 3664 +-+-+-+-+-+-+-+-+- 3666 Type: 28 for Location Data 3668 Length: >= 1 3670 Location: A non-zero terminated UTF-8 encoded string [RFC3629] 3671 containing the WTP location, whose maximum size MUST NOT exceed 3672 1024. 3674 4.6.30. Maximum Message Length 3676 The Maximum Message Length message element is included in the Join 3677 Request message by the WTP to indicate the maximum CAPWAP message 3678 length that it supports to the AC. The Maximum Message Length 3679 message element is optionally included in Join Response message by 3680 the AC to indicate the maximum CAPWAP message length that it supports 3681 to the WTP. 3683 0 1 3684 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3686 | Maximum Message Length | 3687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3689 Type: 29 for Maximum Message Length 3691 Length: 2 3693 Maximum Message Length An 16-bit unsigned integer indicating the 3694 maximum message length. 3696 4.6.31. MTU Discovery Padding 3698 The MTU Discovery Padding message element is used as padding to 3699 perform MTU discovery, and MUST contain octets of value 0xFF, of any 3700 length. 3702 0 3703 0 1 2 3 4 5 6 7 3704 +-+-+-+-+-+-+-+-+ 3705 | Padding... 3706 +-+-+-+-+-+-+-+- 3708 Type: 52 for MTU Discovery Padding 3710 Length: variable 3712 Pad: A variable length pad, filled with the value 0xFF. 3714 4.6.32. Radio Administrative State 3716 The Radio Administrative State message element is used to communicate 3717 the state of a particular radio. The Radio Administrative State 3718 message element is sent by the AC to change the state of the WTP. 3719 The WTP saves the value, to ensure that it remains across WTP resets. 3720 The WTP communicates this message element during the configuration 3721 phase, in the Configuration Status Request message, to ensure that AC 3722 has the WTP radio current administrative state settings. The message 3723 element contains the following fields. 3725 0 1 3726 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3728 | Radio ID | Admin State | 3729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3731 Type: 31 for Radio Administrative State 3733 Length: 2 3735 Radio ID: An 8-bit value representing the radio to configure, whose 3736 value is between one (1) and 31. The Radio ID field MAY also 3737 include the value of 0xff, which is used to identify the WTP. If 3738 an AC wishes to change the administrative state of a WTP, it 3739 includes 0xff in the Radio ID field. 3741 Admin State: An 8-bit value representing the administrative state 3742 of the radio. The default value for the Admin State field is 3743 listed in Section 4.8.1. The following enumerated values are 3744 supported: 3746 0 - Reserved 3748 1 - Enabled 3750 2 - Disabled 3752 4.6.33. Radio Operational State 3754 The Radio Operational State message element is sent by the WTP to the 3755 AC to communicate a radio's operational state. This message element 3756 is included in the Configuration Update Response message by the WTP 3757 if it was requested to change the state of its radio, via the Radio 3758 Administrative State message element, but was unable to comply to the 3759 request. This message element is included in the Change State Event 3760 message when a WTP radio state was changed unexpectedly. This could 3761 occur due to a hardware failure. Note that the operational state 3762 setting is not saved on the WTP, and therefore does not remain across 3763 WTP resets. The value contains three fields, as shown below. 3765 0 1 2 3766 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 3767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3768 | Radio ID | State | Cause | 3769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3771 Type: 32 for Radio Operational State 3773 Length: 3 3774 Radio ID: The Radio Identifier refers to an interface index on the 3775 WTP, whose value is between one (1) and 31. A value of 0xFF is 3776 invalid, as it is not possible to change the WTP's operational 3777 state. 3779 State: An 8-bit boolean value representing the state of the radio. 3780 The following enumerated values are supported: 3782 0 - Reserved 3784 1 - Enabled 3786 2 - Disabled 3788 Cause: When a radio is inoperable, the cause field contains the 3789 reason the radio is out of service. The following enumerated 3790 values are supported: 3792 0 - Normal 3794 1 - Radio Failure 3796 2 - Software Failure 3798 3 - Administratively Set 3800 4.6.34. Result Code 3802 The Result Code message element value is a 32-bit integer value, 3803 indicating the result of the Request message corresponding to the 3804 Sequence Number included in the Response message. 3806 0 1 2 3 3807 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 3808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3809 | Result Code | 3810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3812 Type: 33 for Result Code 3814 Length: 4 3816 Result Code: The following enumerated values are defined: 3818 0 Success 3819 1 Failure (AC List message element MUST be present) 3821 2 Success (NAT detected) 3823 3 Join Failure (unspecified) 3825 4 Join Failure (Resource Depletion) 3827 5 Join Failure (Unknown Source) 3829 6 Join Failure (Incorrect Data) 3831 7 Join Failure (Session ID already in use) 3833 8 Join Failure (WTP Hardware not supported) 3835 9 Join Failure (Binding Not Supported) 3837 10 Reset Failure (Unable to Reset) 3839 11 Reset Failure (Firmware Write Error) 3841 12 Configuration Failure (Unable to Apply Requested Configuration 3842 - Service Provided Anyhow) 3844 13 Configuration Failure (Unable to Apply Requested Configuration 3845 - Service Not Provided) 3847 14 Image Data Error (Invalid Checksum) 3849 15 Image Data Error (Invalid Data Length) 3851 16 Image Data Error (Other Error) 3853 17 Image Data Error (Image Already Present) 3855 18 Message Unexpected (Invalid in current state) 3857 19 Message Unexpected (Unrecognized Request) 3859 20 Failure - Missing Mandatory Message Element 3861 21 Failure - Unrecognized Message Element 3863 22 Data Transfer Error (No Information to Transfer) 3865 4.6.35. Returned Message Element 3867 The Returned Message Element is sent by the WTP in the Change State 3868 Event Request message to communicate to the AC which message elements 3869 in the Configuration Status Response it was unable to apply locally. 3870 The Returned Message Element message element contains a result code 3871 indicating the reason that the configuration could not be applied, 3872 and encapsulates the failed message element. 3874 0 1 2 3 3875 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 3876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3877 | Reason | Length | Message Element... 3878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3880 Type: 34 for Returned Message Element 3882 Length: >= 6 3884 Reason: The reason why the configuration in the offending message 3885 element could not be applied by the WTP. The following enumerated 3886 values are supported: 3888 0 - Reserved 3890 1 - Unknown Message Element 3892 2 - Unsupported Message Element 3894 3 - Unknown Message Element Value 3896 4 - Unsupported Message Element Value 3898 Length: The length of the Message Element field, which MUST NOT 3899 exceed 255 octets. 3901 Message Element: The Message Element field encapsulates the message 3902 element sent by the AC in the Configuration Status Response 3903 message that caused the error. 3905 4.6.36. Session ID 3907 The Session ID message element value contains a randomly generated 3908 unsigned 128-bit integer. 3910 0 1 2 3 3911 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 3912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3913 | Session ID | 3914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3915 | Session ID | 3916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3917 | Session ID | 3918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3919 | Session ID | 3920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3922 Type: 35 for Session ID 3924 Length: 16 3926 Session ID: A 128-bit unsigned integer used as a random session 3927 identifier 3929 4.6.37. Statistics Timer 3931 The Statistics Timer message element value is used by the AC to 3932 inform the WTP of the frequency with which it expects to receive 3933 updated statistics. 3935 0 1 3936 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3938 | Statistics Timer | 3939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3941 Type: 36 for Statistics Timer 3943 Length: 2 3945 Statistics Timer: A 16-bit unsigned integer indicating the time, in 3946 seconds. The default value for this timer is specified in 3947 Section 4.7.14. 3949 4.6.38. Vendor Specific Payload 3951 The Vendor Specific Payload message element is used to communicate 3952 vendor specific information between the WTP and the AC. The Vendor 3953 Specific Payload message element MAY be present in any CAPWAP 3954 message. The exchange of vendor specific data between the MUST NOT 3955 modify the behavior of the base CAPWAP protocol and state machine. 3956 The message element uses the following format: 3958 0 1 2 3 3959 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 3960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3961 | Vendor Identifier | 3962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3963 | Element ID | Data... 3964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3966 Type: 37 for Vendor Specific Payload 3968 Length: >= 7 3970 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 3971 Network Management Private Enterprise Codes" [RFC3232] 3973 Element ID: A 16-bit Element Identifier which is managed by the 3974 vendor. 3976 Data: Variable length vendor specific information, whose contents 3977 and format are proprietary and understood based on the Element ID 3978 field. This field MUST NOT exceed 2048 octets. 3980 4.6.39. WTP Board Data 3982 The WTP Board Data message element is sent by the WTP to the AC and 3983 contains information about the hardware present. 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 | Board Data Sub-Element... 3991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3993 Type: 38 for WTP Board Data 3995 Length: >=14 3997 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 3998 Network Management Private Enterprise Codes", identifying the WTP 3999 hardware manufacturer. The Vendor Identifier field MUST NOT be 4000 set to zero. 4002 Board Data Sub-Element: The WTP Board Data message element contains 4003 multiple Board Data sub-elements, some of which are mandatory and 4004 some are optional, as described below. The Board Data Type values 4005 are not extensible by vendors, and is therefore not coupled along 4006 with the Vendor Identifier field. The Board Data sub-element has 4007 the following format: 4009 0 1 2 3 4010 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 4011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4012 | Board Data Type | Board Data Length | 4013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4014 | Board Data Value... 4015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4017 Board Data Type: The Board Data Type field identifies the data 4018 being encoded. The CAPWAP protocol defines the following 4019 values, and each of these types identify whether their presence 4020 is mandatory or optional: 4022 0 - WTP Model Number: The WTP Model Number MUST be included 4023 in the WTP Board Data message element. 4025 1 - WTP Serial Number: The WTP Serial Number MUST be included 4026 in the WTP Board Data message element. 4028 2 - Board ID: A hardware identifier, which MAY be included in 4029 the WTP Board Data message element. 4031 3 - Board Revision A revision number of the board, which MAY 4032 be included in the WTP Board Data message element. 4034 4 - Base MAC Address The WTP's Base MAC Address, which MAY be 4035 assigned to the primary Ethernet interface. 4037 Board Data Length: The length of the data in the Board Data 4038 Value field, whose length MUST NOT exceed 1024 octets. 4040 Board Data Value: The data associated with the Board Data Type 4041 field for this Board Data sub-element. 4043 4.6.40. WTP Descriptor 4045 The WTP Descriptor message element is used by a WTP to communicate 4046 its current hardware and software (firmware) configuration. The 4047 value contains the following fields. 4049 0 1 2 3 4050 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 4051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4052 | Max Radios | Radios in use | Num Encrypt |Encryp Sub-Elmt| 4053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4054 | Encryption Sub-Element | Descriptor Sub-Element... 4055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4057 Type: 39 for WTP Descriptor 4059 Length: >= 33 4061 Max Radios: An 8-bit value representing the number of radios (where 4062 each radio is identified via the Radio ID field) supported by the 4063 WTP. 4065 Radios in use: An 8-bit value representing the number of radios in 4066 use in the WTP. 4068 Num Encrypt: The number of 3 byte Encryption Sub-Elements that 4069 follow this field. The value of the Num Encrypt field MUST be 4070 between one (1) and 255. 4072 Encryption Sub-Element: The WTP Descriptor message element MUST 4073 contain at least one Encryption sub-element. One sub-element is 4074 present for each binding supported by the WTP. The Encryption 4075 sub-element has the following format: 4077 0 1 2 4078 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4080 |Resvd| WBID | Encryption Capabilities | 4081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4083 Resvd: The 3-bit field is reserved for future use. All 4084 implementations complying with this protocol MUST set to zero 4085 any bits that are reserved in the version of the protocol 4086 supported by that implementation. Receivers MUST ignore all 4087 bits not defined for the version of the protocol they support. 4089 WBID: A 5 bit field which is the wireless binding identifier. 4090 The identifier will indicate the type of wireless packet 4091 associated with the radio. The WBIDs defined in this 4092 specification can be found in Section 4.3 4094 Encryption Capabilities: This 16-bit field is used by the WTP to 4095 communicate its capabilities to the AC. A WTP that does not 4096 have any encryption capabilities sets this field to zero (0). 4097 Refer to the specific wireless binding for further 4098 specification of the Encryption Capabilities field. 4100 Descriptor Sub-Element: The WTP Descriptor message element contains 4101 multiple Descriptor sub-elements, some of which are mandatory and 4102 some are optional, as described below. The Descriptor sub-element 4103 has the following format: 4105 0 1 2 3 4106 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 4107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4108 | Descriptor Vendor Identifier | 4109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4110 | Descriptor Type | Descriptor Length | 4111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4112 | Descriptor Data... 4113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4115 Descriptor Vendor Identifier: A 32-bit value containing the IANA 4116 assigned "SMI Network Management Private Enterprise Codes". 4118 Descriptor Type: The Descriptor Type field identifies the data 4119 being encoded. The format of the data is vendor specific 4120 encoded in the UTF-8 format [RFC3629]. The CAPWAP protocol 4121 defines the following values, and each of these types identify 4122 whether their presence is mandatory or optional. The values 4123 listed below are used in conjunction with the Descriptor Vendor 4124 Identifier field, whose value MUST be set to zero (0). This 4125 field, combined with the Descriptor Vendor Identifier set to a 4126 non-zero (0) value, allows vendors to use a private namespace. 4128 0 - Hardware Version: The WTP hardware version number MUST be 4129 present. 4131 1 - Active Software Version: The WTP running software version 4132 number MUST be present. 4134 2 - Boot Version: The WTP boot loader version number MUST be 4135 present. 4137 3 - Other Software Version: The WTP non-running software 4138 (firmware) version number MAY be present. This type is used 4139 to communicate alternate software versions that are 4140 available on the WTP's non-volatile storage. 4142 Descriptor Length: Length of vendor specific encoding of 4143 Descriptor Data field, whose length MUST NOT exceed 1024 4144 octets. 4146 Descriptor Data: Vendor specific data of WTP information encoded 4147 in the UTF-8 format [RFC3629]. 4149 4.6.41. WTP Fallback 4151 The WTP Fallback message element is sent by the AC to the WTP to 4152 enable or disable automatic CAPWAP fallback in the event that a WTP 4153 detects its preferred AC, and is not currently connected to it. 4155 0 4156 0 1 2 3 4 5 6 7 4157 +-+-+-+-+-+-+-+-+ 4158 | Mode | 4159 +-+-+-+-+-+-+-+-+ 4161 Type: 40 for WTP Fallback 4163 Length: 1 4165 Mode: The 8-bit value indicates the status of automatic CAPWAP 4166 fallback on the WTP. When enabled, if the WTP detects that its 4167 primary AC is available, and that the WTP is not connected to the 4168 primary AC, the WTP SHOULD automatically disconnect from its 4169 current AC and reconnect to its primary AC. If disabled, the WTP 4170 will only reconnect to its primary AC through manual intervention 4171 (e.g., through the Reset Request message). The default value for 4172 this field is specified in Section 4.8.9. The following 4173 enumerated values are supported: 4175 0 - Reserved 4177 1 - Enabled 4179 2 - Disabled 4181 4.6.42. WTP Frame Tunnel Mode 4183 The WTP Frame Tunnel Mode message element allows the WTP to 4184 communicate the tunneling modes of operation which it supports to the 4185 AC. A WTP that advertises support for all types allows the AC to 4186 select which type will be used, based on its local policy. 4188 0 4189 0 1 2 3 4 5 6 7 4190 +-+-+-+-+-+-+-+-+ 4191 |Reservd|N|E|L|U| 4192 +-+-+-+-+-+-+-+-+ 4194 Type: 41 for WTP Frame Tunnel Mode 4196 Length: 1 4198 Reservd: A set of reserved bits for future use. All 4199 implementations complying with this protocol MUST set to zero any 4200 bits that are reserved in the version of the protocol supported by 4201 that implementation. Receivers MUST ignore all bits not defined 4202 for the version of the protocol they support. 4204 N: Native Frame Tunnel mode requires the WTP and AC to encapsulate 4205 all user payloads as native wireless frames, as defined by the 4206 wireless binding (see for example Section 4.4) 4208 E: The 802.3 Frame Tunnel Mode requires the WTP and AC to 4209 encapsulate all user payload as native IEEE 802.3 frames (see 4210 Section 4.4). All user traffic is tunneled to the AC. This value 4211 MUST NOT be used when the WTP MAC Type is set to Split-MAC. 4213 L: When Local Bridging is used, the WTP does not tunnel user 4214 traffic to the AC; all user traffic is locally bridged. This 4215 value MUST NOT be used when the WTP MAC Type is set to Split-MAC. 4217 R: A reserved bit for future use. All implementations complying 4218 with this protocol MUST set to zero any bits that are reserved in 4219 the version of the protocol supported by that implementation. 4220 Receivers MUST ignore all bits not defined for the version of the 4221 protocol they support. 4223 4.6.43. WTP MAC Type 4225 The WTP MAC-Type message element allows the WTP to communicate its 4226 mode of operation to the AC. A WTP that advertises support for both 4227 modes allows the AC to select the mode to use, based on local policy. 4229 0 4230 0 1 2 3 4 5 6 7 4231 +-+-+-+-+-+-+-+-+ 4232 | MAC Type | 4233 +-+-+-+-+-+-+-+-+ 4235 Type: 44 for WTP MAC Type 4237 Length: 1 4239 MAC Type: The MAC mode of operation supported by the WTP. The 4240 following enumerated values are supported: 4242 0 - Local-MAC: Local-MAC is the default mode that MUST be 4243 supported by all WTPs. When tunneling is enabled (see 4244 Section 4.6.42), the encapsulated frames MUST be in the 802.3 4245 format (see Section 4.4.2), unless a wireless management or 4246 control frame which MAY be in its native format. Any CAPWAP 4247 binding needs to specify the format of management and control 4248 wireless frames. 4250 1 - Split-MAC: Split-MAC support is optional, and allows the AC 4251 to receive and process native wireless frames. 4253 2 - Both: WTP is capable of supporting both Local-MAC and Split- 4254 MAC. 4256 4.6.44. WTP Name 4258 The WTP Name message element is a variable length byte UTF-8 encoded 4259 string [RFC3629]. The string is not zero terminated. 4261 0 4262 0 1 2 3 4 5 6 7 4263 +-+-+-+-+-+-+-+-+- 4264 | WTP Name ... 4265 +-+-+-+-+-+-+-+-+- 4267 Type: 45 for WTP Name 4269 Length: >= 1 4271 WTP Name: A non-zero terminated UTF-8 encoded string [RFC3629] 4272 containing the WTP name, whose maximum size MUST NOT exceed 512 4273 bytes. 4275 4.6.45. WTP Radio Statistics 4277 The WTP Radio Statistics message element is sent by the WTP to the AC 4278 to communicate statistics on radio behavior and reasons why the WTP 4279 radio has been reset. These counters are never reset on the WTP, and 4280 will therefore roll over to zero when the maximum size has been 4281 reached. 4283 0 1 2 3 4284 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 4285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4286 | Radio ID | Last Fail Type| Reset Count | 4287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4288 | SW Failure Count | HW Failure Count | 4289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4290 | Other Failure Count | Unknown Failure Count | 4291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4292 | Config Update Count | Channel Change Count | 4293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4294 | Band Change Count | Current Noise Floor | 4295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4297 Type: 47 for WTP Radio Statistics 4299 Length: 20 4301 Radio ID: The radio ID of the radio to which the statistics apply, 4302 whose value is between one (1) and 31. 4304 Last Failure Type: The last WTP failure. The following enumerated 4305 values are supported: 4307 0 - Statistic Not Supported 4309 1 - Software Failure 4311 2 - Hardware Failure 4313 3 - Other Failure 4315 255 - Unknown (e.g., WTP doesn't keep track of info) 4317 Reset Count: The number of times that that the radio has been 4318 reset. 4320 SW Failure Count: The number of times that the radio has failed due 4321 to software related reasons. 4323 HW Failure Count: The number of times that the radio has failed due 4324 to hardware related reasons. 4326 Other Failure Count: The number of times that the radio has failed 4327 due to known reasons, other than software or hardware failure. 4329 Unknown Failure Count: The number of times that the radio has 4330 failed for unknown reasons. 4332 Config Update Count: The number of times that the radio 4333 configuration has been updated. 4335 Channel Change Count: The number of times that the radio channel 4336 has been changed. 4338 Band Change Count: The number of times that the radio has changed 4339 frequency bands. 4341 Current Noise Floor: A signed integer which indicates the noise 4342 floor of the radio receiver in units of dBm. 4344 4.6.46. WTP Reboot Statistics 4346 The WTP Reboot Statistics message element is sent by the WTP to the 4347 AC to communicate reasons why WTP reboots have occurred. These 4348 counters are never reset on the WTP, and will therefore roll over to 4349 zero when the maximum size has been reached. 4351 0 1 2 3 4352 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 4353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4354 | Reboot Count | AC Initiated Count | 4355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4356 | Link Failure Count | SW Failure Count | 4357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4358 | HW Failure Count | Other Failure Count | 4359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4360 | Unknown Failure Count |Last Failure Type| 4361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4363 Type: 48 for WTP Reboot Statistics 4365 Length: 15 4367 Reboot Count: The number of reboots that have occurred due to a WTP 4368 crash. A value of 65535 implies that this information is not 4369 available on the WTP. 4371 AC Initiated Count: The number of reboots that have occurred at the 4372 request of a CAPWAP protocol message, such as a change in 4373 configuration that required a reboot or an explicit CAPWAP 4374 protocol reset request. A value of 65535 implies that this 4375 information is not available on the WTP. 4377 Link Failure Count: The number of times that a CAPWAP protocol 4378 connection with an AC has failed due to link failure. 4380 SW Failure Count: The number of times that a CAPWAP protocol 4381 connection with an AC has failed due to software related reasons. 4383 HW Failure Count: The number of times that a CAPWAP protocol 4384 connection with an AC has failed due to hardware related reasons. 4386 Other Failure Count: The number of times that a CAPWAP protocol 4387 connection with an AC has failed due to known reasons, other than 4388 AC initiated, link, SW or HW failure. 4390 Unknown Failure Count: The number of times that a CAPWAP protocol 4391 connection with an AC has failed for unknown reasons. 4393 Last Failure Type: The failure type of the most recent WTP failure. 4394 The following enumerated values are supported: 4396 0 - Not Supported 4398 1 - AC Initiated (see Section 9.2) 4400 2 - Link Failure 4402 3 - Software Failure 4404 4 - Hardware Failure 4406 5 - Other Failure 4408 255 - Unknown (e.g., WTP doesn't keep track of info) 4410 4.6.47. WTP Static IP Address Information 4412 The WTP Static IP Address Information message element is used by an 4413 AC to configure or clear a previously configured static IP address on 4414 a WTP. IPv6 WTPs are expected to use dynamic addresses. 4416 0 1 2 3 4417 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 4418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4419 | IP Address | 4420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4421 | Netmask | 4422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4423 | Gateway | 4424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4425 | Static | 4426 +-+-+-+-+-+-+-+-+ 4428 Type: 49 for WTP Static IP Address Information 4430 Length: 13 4432 IP Address: The IP Address to assign to the WTP. This field is 4433 only valid if the static field is set to one. 4435 Netmask: The IP Netmask. This field is only valid if the static 4436 field is set to one. 4438 Gateway: The IP address of the gateway. This field is only valid 4439 if the static field is set to one. 4441 Static: An 8-bit boolean stating whether the WTP should use a 4442 static IP address or not. A value of zero disables the static IP 4443 address, while a value of one enables it. 4445 4.7. CAPWAP Protocol Timers 4447 This section contains the definition of the CAPWAP timers. 4449 4.7.1. ChangeStatePendingTimer 4451 The maximum time, in seconds, the AC will wait for the Change State 4452 Event Request from the WTP after having transmitted a successful 4453 Configuration Status Response message. 4455 Default: 25 seconds 4457 4.7.2. DataChannelKeepAlive 4459 The DataChannelKeepAlive timer is used by the WTP to determine the 4460 next opportunity when it must transmit the Data Channel KeepAlive, in 4461 seconds. 4463 Default: 30 seconds 4465 4.7.3. DataChannelDeadInterval 4467 The minimum time, in seconds, a WTP MUST wait without having received 4468 a Data Channel Keep Alive packet before the destination for the Data 4469 Channel Keep Alive packets may be considered dead. The value of this 4470 timer MUST be no less than 2*DataChannelKeepAlive seconds and no 4471 greater that 240 seconds. 4473 Default: 60 4475 4.7.4. DataCheckTimer 4477 The number of seconds the AC will wait for the Data Channel Keep 4478 Alive, which is required by the CAPWAP state machine's Data Check 4479 state. The AC resets the state machine if this timer expires prior 4480 to transitioning to the next state. 4482 Default: 30 4484 4.7.5. DiscoveryInterval 4486 The minimum time, in seconds, that a WTP MUST wait after receiving a 4487 Discovery Response message, before initiating a DTLS handshake. 4489 Default: 5 4491 4.7.6. DTLSSessionDelete 4493 The minimum time, in seconds, a WTP MUST wait for DTLS session 4494 deletion. 4496 Default: 5 4498 4.7.7. EchoInterval 4500 The minimum time, in seconds, between sending Echo Request messages 4501 to the AC with which the WTP has joined. 4503 Default: 30 4505 4.7.8. IdleTimeout 4507 The default Idle Timeout is 300 seconds. 4509 4.7.9. ImageDataStartTimer 4511 The number of seconds the WTP will wait for its peer to transmit the 4512 Image Data Request. 4514 Default: 30 4516 4.7.10. MaxDiscoveryInterval 4518 The maximum time allowed between sending Discovery Request messages, 4519 in seconds. This value MUST be no less than 2 seconds and no greater 4520 than 180 seconds. 4522 Default: 20 seconds. 4524 4.7.11. ReportInterval 4526 The ReportInterval is used by the WTP to determine the interval the 4527 WTP uses between sending the Decryption Error message elements to 4528 inform the AC of decryption errors, in seconds. 4530 The default Report Interval is 120 seconds. 4532 4.7.12. RetransmitInterval 4534 The minimum time, in seconds, in which a non-acknowledged CAPWAP 4535 packet will be retransmitted. 4537 Default: 3 4539 4.7.13. SilentInterval 4541 For a WTP, this is the minimum time, in seconds, a WTP MUST wait 4542 before it MAY again send Discovery Request messages or attempt to a 4543 establish DTLS session. For an AC, this is the minimum time, in 4544 seconds, during which the AC SHOULD ignore all CAPWAP and DTLS 4545 packets received from the WTP that is in the Sulking state. 4547 Default: 30 seconds 4549 4.7.14. StatisticsTimer 4551 The StatisticsTimer is used by the WTP to determine the interval the 4552 WTP uses between the WTP Events Requests it transmits to the AC to 4553 communicate its statistics, in seconds. 4555 Default: 120 seconds 4557 4.7.15. WaitDTLS 4559 The maximum time, in seconds, a WTP MUST wait without having received 4560 a DTLS Handshake message from an AC. This timer MUST be greater than 4561 30 seconds. 4563 Default: 60 4565 4.7.16. WaitJoin 4567 The maximum time, in seconds, an AC will wait after the DTLS session 4568 has been established until it receives the Join Request from the WTP. 4569 This timer MUST be greater than 20 seconds. 4571 Default: 60 4573 4.8. CAPWAP Protocol Variables 4575 This section defines the CAPWAP protocol variables, which are used 4576 for various protocol functions. Some of these variables are 4577 configurable, while others are counters or have a fixed value. For 4578 non counter related variables, default values are specified. 4579 However, when a WTP's variable configuration is explicitly overridden 4580 by an AC, the WTP MUST save the new value. 4582 4.8.1. AdminState 4584 The default Administrative State value is enabled (1). 4586 4.8.2. DiscoveryCount 4588 The number of Discovery Request messages transmitted by a WTP to a 4589 single AC. This is a monotonically increasing counter. 4591 4.8.3. FailedDTLSAuthFailCount 4593 The number of failed DTLS session establishment attempts due to 4594 authentication failures. 4596 4.8.4. FailedDTLSSessionCount 4598 The number of failed DTLS session establishment attempts. 4600 4.8.5. MaxDiscoveries 4602 The maximum number of Discovery Request messages that will be sent 4603 after a WTP boots. 4605 Default: 10 4607 4.8.6. MaxFailedDTLSSessionRetry 4609 The maximum number of failed DTLS session establishment attempts 4610 before the CAPWAP device enters a silent period. 4612 Default: 3. 4614 4.8.7. MaxRetransmit 4616 The maximum number of retransmissions for a given CAPWAP packet 4617 before the link layer considers the peer dead. 4619 Default: 5 4621 4.8.8. RetransmitCount 4623 The number of retransmissions for a given CAPWAP packet. This is a 4624 monotonically increasing counter. 4626 4.8.9. WTPFallBack 4628 The default WTP Fallback value is enabled (1). 4630 4.9. WTP Saved Variables 4632 In addition to the values defined in Section 4.8, the following 4633 values SHOULD be saved on the WTP in non-volatile memory. CAPWAP 4634 wireless bindings MAY define additional values that SHOULD be stored 4635 on the WTP. 4637 4.9.1. AdminRebootCount 4639 The number of times the WTP has rebooted administratively, defined in 4640 Section 4.6.46. 4642 4.9.2. FrameEncapType 4644 For WTPs that support multiple Frame Encapsulation Types, it is 4645 useful to save the value configured by the AC. The Frame 4646 Encapsulation Type is defined in Section 4.6.42. 4648 4.9.3. LastRebootReason 4650 The reason why the WTP last rebooted, defined in Section 4.6.46. 4652 4.9.4. MacType 4654 For WTPs that support multiple MAC Types, it is useful to save the 4655 value configured by the AC. The MACType is defined in 4656 Section 4.6.43. 4658 4.9.5. PreferredACs 4660 The preferred ACs, with the index, defined in Section 4.6.5. 4662 4.9.6. RebootCount 4664 The number of times the WTP has rebooted, defined in Section 4.6.46. 4666 4.9.7. Static IP Address 4668 The static IP Address assigned to the WTP, as configured by the WTP 4669 Static IP Address Information message element (see Section 4.6.47). 4671 4.9.8. WTPLinkFailureCount 4673 The number of times the link to the AC has failed, see 4674 Section 4.6.46. 4676 4.9.9. WTPLocation 4678 The WTP Location, defined in Section 4.6.29. 4680 4.9.10. WTPName 4682 The WTP Name, defined in Section 4.6.44. 4684 5. CAPWAP Discovery Operations 4686 The Discovery messages are used by a WTP to determine which ACs are 4687 available to provide service, and the capabilities and load of the 4688 ACs. 4690 5.1. Discovery Request Message 4692 The Discovery Request message is used by the WTP to automatically 4693 discover potential ACs available in the network. The Discovery 4694 Request message provides ACs with the primary capabilities of the 4695 WTP. A WTP must exchange this information to ensure subsequent 4696 exchanges with the ACs are consistent with the WTP's functional 4697 characteristics. 4699 Discovery Request messages MUST be sent by a WTP in the Discover 4700 state after waiting for a random delay less than 4701 MaxDiscoveryInterval, after a WTP first comes up or is 4702 (re)initialized. A WTP MUST send no more than the maximum of 4703 MaxDiscoveries Discovery Request messages, waiting for a random delay 4704 less than MaxDiscoveryInterval between each successive message. 4706 This is to prevent an explosion of WTP Discovery Request messages. 4707 An example of this occurring is when many WTPs are powered on at the 4708 same time. 4710 If a Discovery Response message is not received after sending the 4711 maximum number of Discovery Request messages, the WTP enters the 4712 Sulking state and MUST wait for an interval equal to SilentInterval 4713 before sending further Discovery Request messages. 4715 Upon receiving a Discovery Request message, the AC will respond with 4716 a Discovery Response message sent to the address in the source 4717 address of the received Discovery Request message. Once a Discovery 4718 Response has been received, if the WTP decides to establish a session 4719 with the responding AC, it SHOULD perform an MTU discovery, using the 4720 process described in Section 3.5. 4722 It is possible for the AC to receive a cleartext Discovery Request 4723 message while a DTLS session is already active with the WTP. This is 4724 most likely the case if the WTP has rebooted, perhaps due to a 4725 software or power failure, but could also be caused by a DoS attack. 4726 In such cases, any WTP state, including the state machine instance, 4727 MUST NOT be cleared until another DTLS session has been successfully 4728 established, communicated via the DTLSSessionEstablished DTLS 4729 notification (see Section 2.3.2.2). 4731 The binding specific WTP Radio Information message element (see 4732 Section 2.1) is included in the Discovery Request message to 4733 advertise WTP support for one or more CAPWAP bindings. 4735 The Discovery Request message is sent by the WTP when in the 4736 Discovery State. The AC does not transmit this message. 4738 The following message elements MUST be included in the Discovery 4739 Request message: 4741 o Discovery Type, see Section 4.6.21 4743 o WTP Board Data, see Section 4.6.39 4745 o WTP Descriptor, see Section 4.6.40 4747 o WTP Frame Tunnel Mode, see Section 4.6.42 4749 o WTP MAC Type, see Section 4.6.43 4751 o WTP Radio Information message element(s)that the WTP supports; 4752 These are defined by the individual link layer CAPWAP Binding 4753 Protocols (see Section 2.1). 4755 The following message elements MAY be included in the Discovery 4756 Request message: 4758 o MTU Discovery Padding, see Section 4.6.31 4760 o Vendor Specific Payload, see Section 4.6.38 4762 5.2. Discovery Response Message 4764 The Discovery Response message provides a mechanism for an AC to 4765 advertise its services to requesting WTPs. 4767 When a WTP receives a Discovery Response message, it MUST wait for an 4768 interval not less than DiscoveryInterval for receipt of additional 4769 Discovery Response messages. After the DiscoveryInterval elapses, 4770 the WTP enters the DTLS-Init state and selects one of the ACs that 4771 sent a Discovery Response message and send a DTLS Handshake to that 4772 AC. 4774 One or more binding specific WTP Radio Information message elements 4775 (see Section 2.1) are included in the Discovery Request message to 4776 advertise AC support for the CAPWAP bindings. The AC MAY include 4777 only the bindings it shares in common with the WTP, known through the 4778 WTP Radio Information message elements received in the Discovery 4779 Request message, or it MAY include all of the bindings supported. 4781 The WTP MAY use the supported bindings in its AC decision process. 4782 Note that if the WTP joins an AC that does not support a specific 4783 CAPWAP binding, service for that binding MUST NOT be provided by the 4784 WTP. 4786 The Discovery Response message is sent by the AC when in the Idle 4787 State. The WTP does not transmit this message. 4789 The following message elements MUST be included in the Discovery 4790 Response Message: 4792 o AC Descriptor, see Section 4.6.1 4794 o AC Name, see Section 4.6.4 4796 o WTP Radio Information message element(s)that the AC supports; 4797 These are defined by the individual link layer CAPWAP Binding 4798 Protocols (see Section 2.1 for more information). 4800 o One of the following message elements MUST be included in the 4801 Discovery Response Message: 4803 * CAPWAP Control IPv4 Address, see Section 4.6.9 4805 * CAPWAP Control IPv6 Address, see Section 4.6.10 4807 The following message elements MAY be included in the Discovery 4808 Response message: 4810 o Vendor Specific Payload, see Section 4.6.38 4812 5.3. Primary Discovery Request Message 4814 The Primary Discovery Request message is sent by the WTP to determine 4815 whether its preferred (or primary) AC is available or to perform a 4816 Path MTU Discovery (see section Section 3.5. 4818 A Primary Discovery Request message is sent by a WTP when it has a 4819 primary AC configured, and is connected to another AC. This 4820 generally occurs as a result of a failover, and is used by the WTP as 4821 a means to discover when its primary AC becomes available. Since the 4822 WTP only has a single instance of the CAPWAP state machine, the 4823 Primary Discovery Request is sent by the WTP when in the Run State. 4824 The AC does not transmit this message. 4826 The frequency of the Primary Discovery Request messages should be no 4827 more often than the sending of the Echo Request message. 4829 Upon receipt of a Primary Discovery Request message, the AC responds 4830 with a Primary Discovery Response message sent to the address in the 4831 source address of the received Primary Discovery Request message. 4833 The following message elements MUST be included in the Primary 4834 Discovery Request message. 4836 o Discovery Type, see Section 4.6.21 4838 o WTP Board Data, see Section 4.6.39 4840 o WTP Descriptor, see Section 4.6.40 4842 o WTP Frame Tunnel Mode, see Section 4.6.42 4844 o WTP MAC Type, see Section 4.6.43 4846 o WTP Radio Information message element(s)that the WTP supports; 4847 These are defined by the individual link layer CAPWAP Binding 4848 Protocols (see Section 2.1 for more information). 4850 The following message elements MAY be included in the Primary 4851 Discovery Request message: 4853 o MTU Discovery Padding, see Section 4.6.31 4855 o Vendor Specific Payload, see Section 4.6.38 4857 5.4. Primary Discovery Response 4859 The Primary Discovery Response message enables an AC to advertise its 4860 availability and services to requesting WTPs that are configured to 4861 have the AC as its primary AC. 4863 The Primary Discovery Response message is sent by an AC after 4864 receiving a Primary Discovery Request message. 4866 When a WTP receives a Primary Discovery Response message, it may 4867 establish a CAPWAP protocol connection to its primary AC, based on 4868 the configuration of the WTP Fallback Status message element on the 4869 WTP. 4871 The Primary Discovery Response message is sent by the AC when in the 4872 Idle State. The WTP does not transmit this message. 4874 The following message elements MUST be included in the Primary 4875 Discovery Response message. 4877 o AC Descriptor, see Section 4.6.1 4879 o AC Name, see Section 4.6.4 4881 o WTP Radio Information message element(s)that the AC supports; 4882 These are defined by the individual link layer CAPWAP Binding 4883 Protocols (see Section 2.1 for more information). 4885 One of the following message elements MUST be included in the 4886 Discovery Response Message: 4888 o CAPWAP Control IPv4 Address, see Section 4.6.9 4890 o CAPWAP Control IPv6 Address, see Section 4.6.10 4892 The following message elements MAY be included in the Primary 4893 Discovery Response message: 4895 o Vendor Specific Payload, see Section 4.6.38 4897 6. CAPWAP Join Operations 4899 The Join Request message is used by a WTP to request service from an 4900 AC after a DTLS connection is established to that AC. The Join 4901 Response message is used by the AC to indicate that it will or will 4902 not provide service. 4904 6.1. Join Request 4906 The Join Request message is used by a WTP to request service through 4907 the AC. If the WTP is performing the optional AC discovery process 4908 (see Section 3.3), the join process occurs after the WTP has received 4909 one or more Discovery Response messages. During the discovery 4910 process, an AC MAY return more than one CAPWAP Control IPv4 Address 4911 or CAPWAP Control IPv6 Address message elements. When more than one 4912 such message element is returned, the WTP SHOULD perform "load 4913 balancing" by choosing the interface that is servicing the least 4914 number of WTPs (known through the WTP Count field of the message 4915 element). Note, however, that other load balancing algorithms are 4916 also permitted. Once the WTP has determined its preferred AC, and 4917 its associated interface, to connect to, it establishes the DTLS 4918 session, and transmits the Join Request over the secured control 4919 channel. When an AC receives a Join Request message it responds with 4920 a Join Response message. 4922 Upon completion of the DTLS handshake, and receiving the 4923 DTLSEstablished notification, the WTP sends the Join Request message 4924 to the AC. When the AC is notified of the DTLS session 4925 establishment, it does not clear the WaitDTLS timer until it has 4926 received the Join Request message, at which time it sends a Join 4927 Response message to the WTP, indicating success or failure. 4929 One or more WTP Radio Information message elements (see Section 2.1) 4930 are included in the Join Request to request service for the CAPWAP 4931 bindings by the AC. Including a binding that is unsupported by the 4932 AC will result in a failed Join Response. 4934 If the AC rejects the Join Request, it sends a Join Response message 4935 with a failure indication and initiates an abort of the DTLS session 4936 via the DTLSAbort command. 4938 If an invalid (i.e. malformed) Join Request message is received, the 4939 message MUST be silently discarded by the AC. No response is sent to 4940 the WTP. The AC SHOULD log this event. 4942 The Join Request is sent by the WTP when in the Join State. The AC 4943 does not transmit this message. 4945 The following message elements MUST be included in the Join Request 4946 message. 4948 o Location Data, see Section 4.6.29 4950 o WTP Board Data, see Section 4.6.39 4952 o WTP Descriptor, see Section 4.6.40 4954 o WTP Name, see Section 4.6.44 4956 o Session ID, see Section 4.6.36 4958 o WTP Frame Tunnel Mode, see Section 4.6.42 4960 o WTP MAC Type, see Section 4.6.43 4962 o WTP Radio Information message element(s)that the WTP supports; 4963 These are defined by the individual link layer CAPWAP Binding 4964 Protocols (see Section 2.1 for more information). 4966 At least one of the following message element MUST be included in the 4967 Join Request message. 4969 o CAPWAP Local IPv4 Address, see Section 4.6.11 4971 o CAPWAP Local IPv6 Address, see Section 4.6.12 4973 The following message element MAY be included in the Join Request 4974 message. 4976 o CAPWAP Transport Protocol, see Section 4.6.14 4978 o Maximum Message Length, see Section 4.6.30 4980 o WTP Reboot Statistics, see Section 4.6.46 4982 o Vendor Specific Payload, see Section 4.6.38 4984 6.2. Join Response 4986 The Join Response message is sent by the AC to indicate to a WTP that 4987 it is capable and willing to provide service to the WTP. 4989 The WTP, receiving a Join Response message, checks for success or 4990 failure. If the message indicates success, the WTP clears the 4991 WaitDTLS timer for the session and proceeds to the Configure state. 4993 If the WaitDTLS Timer expires prior to reception of the Join Response 4994 message, the WTP MUST terminate the handshake, deallocate session 4995 state and initiate the DTLSAbort command. 4997 If an invalid (malformed) Join Response message is received, the WTP 4998 SHOULD log an informative message detailing the error. This error 4999 MUST be treated in the same manner as AC non-responsiveness. The 5000 WaitDTLS timer will eventually expire, and the WTP MAY (if it is so 5001 configured) attempts to join a new AC. 5003 If one of the WTP Radio Information message elements (see 5004 Section 2.1) in the Join Request message requested support for a 5005 CAPWAP binding which the AC does not support, the AC sets the Result 5006 Code message element to "Binding Not Supported". 5008 The AC includes the Image Identifier message element to indicate the 5009 software version it expects the WTP to run. This information is used 5010 to determine whether the WTP MUST either change its currently running 5011 firmware image, or download a new version (see Section 9.1.1). 5013 The Join Response message is sent by the AC when in the Join State. 5014 The WTP does not transmit this message. 5016 The following message elements MUST be included in the Join Response 5017 message. 5019 o Result Code, see Section 4.6.34 5021 o AC Descriptor, see Section 4.6.1 5023 o AC Name, see Section 4.6.4 5025 o WTP Radio Information message element(s)that the AC supports; 5026 These are defined by the individual link layer CAPWAP Binding 5027 Protocols (see Section 2.1). 5029 One of the following message elements MUST be included in the Join 5030 Response Message: 5032 o CAPWAP Control IPv4 Address, see Section 4.6.9 5034 o CAPWAP Control IPv6 Address, see Section 4.6.10 5036 One of the following message elements MUST be included in the Join 5037 Response Message: 5039 o CAPWAP Local IPv4 Address, see Section 4.6.11 5040 o CAPWAP Local IPv6 Address, see Section 4.6.12 5042 The following message elements MAY be included in the Join Response 5043 message. 5045 o AC IPv4 List, see Section 4.6.2 5047 o AC IPv6 List, see Section 4.6.3 5049 o CAPWAP Transport Protocol, see Section 4.6.14 5051 o Image Identifier, see Section 4.6.26 5053 o Maximum Message Length, see Section 4.6.30 5055 o Vendor Specific Payload, see Section 4.6.38 5057 7. Control Channel Management 5059 The Control Channel Management messages are used by the WTP and AC to 5060 maintain a control communication channel. CAPWAP control messages, 5061 such as the WTP Event Request message sent from the WTP to the AC 5062 indicate to the AC that the WTP is operational. When such control 5063 messages are not being sent, the Echo Request and Echo Response 5064 messages are used to maintain the control communication channel. 5066 7.1. Echo Request 5068 The Echo Request message is a keep-alive mechanism for CAPWAP control 5069 messages. 5071 Echo Request messages are sent periodically by a WTP in the Image 5072 Data or Run state (see Section 2.3) to determine the state of the 5073 control connection between the WTP and the AC. The Echo Request 5074 message is sent by the WTP when the EchoInterval timer expires. 5076 The Echo Request message is sent by the WTP when in the Run State. 5077 The AC does not transmit this message. 5079 The following message elements MAY be included in the Echo Request 5080 message: 5082 o Vendor Specific Payload, see Section 4.6.38 5084 When an AC receives an Echo Request message it responds with an Echo 5085 Response message. 5087 7.2. Echo Response 5089 The Echo Response message acknowledges the Echo Request message. 5091 An Echo Response message is sent by an AC after receiving an Echo 5092 Request message. After transmitting the Echo Response message, the 5093 AC SHOULD reset its EchoInterval timer (see Section 4.7.7. If 5094 another Echo Request message or other control message is not received 5095 by the AC when the timer expires, the AC SHOULD consider the WTP to 5096 be no longer reachable. 5098 The Echo Response message is sent by the AC when in the Run State. 5099 The WTP does not transmit this message. 5101 The following message elements MAY be included in the Echo Response 5102 message: 5104 o Vendor Specific Payload, see Section 4.6.38 5106 When a WTP receives an Echo Response message it initializes the 5107 EchoInterval to the configured value. 5109 8. WTP Configuration Management 5111 WTP Configuration messages are used to exchange configuration 5112 information between the AC and the WTP. 5114 8.1. Configuration Consistency 5116 The CAPWAP protocol provides flexibility in how WTP configuration is 5117 managed. A WTP can behave in one of two ways, which is 5118 implementation specific: 5120 1. The WTP retains no configuration and accepts the configuration 5121 provided by the AC. 5123 2. The WTP saves the configuration of parameters provided by the AC 5124 that are non-default values into local non-volatile memory, and 5125 are enforced during the WTP's power up initialization phase. 5127 If the WTP opts to save configuration locally, the CAPWAP protocol 5128 state machine defines the Configure state, which allows for 5129 configuration exchange. In the Configure state, the WTP sends its 5130 current configuration overrides to the AC via the Configuration 5131 Status Request message. A configuration override is a non-default 5132 parameter. As an example, in the CAPWAP protocol, the default 5133 antenna configuration is internal omni antenna. A WTP that either 5134 has no internal antennas, or has been explicitly configured by the AC 5135 to use external antennas, sends its antenna configuration during the 5136 configure phase, allowing the AC to become aware of the WTP's current 5137 configuration. 5139 Once the WTP has provided its configuration to the AC, the AC sends 5140 its configuration to the WTP. This allows the WTP to receive 5141 configuration and policies from the AC. 5143 The AC maintains a copy of each active WTP configuration. There is 5144 no need for versioning or other means to identify configuration 5145 changes. If a WTP becomes inactive, the AC MAY delete the inactive 5146 WTP configuration. If a WTP fails, and connects to a new AC, the WTP 5147 provides its overridden configuration parameters, allowing the new AC 5148 to be aware of the WTP configuration. 5150 This model allows for resiliency in case of an AC failure, ensuring 5151 another AC can provide service to the WTP. A new AC would be 5152 automatically updated with WTP configuration changes, eliminating the 5153 need for inter-AC communication and the need for all ACs to be aware 5154 of the configuration of all WTPs in the network. 5156 Once the CAPWAP protocol enters the Run state, the WTPs begin to 5157 provide service. It is common for administrators to require that 5158 configuration changes be made while the network is operational. 5159 Therefore, the Configuration Update Request is sent by the AC to the 5160 WTP to make these changes at run-time. 5162 8.1.1. Configuration Flexibility 5164 The CAPWAP protocol provides the flexibility to configure and manage 5165 WTPs of varying design and functional characteristics. When a WTP 5166 first discovers an AC, it provides primary functional information 5167 relating to its type of MAC and to the nature of frames to be 5168 exchanged. The AC configures the WTP appropriately. The AC also 5169 establishes corresponding internal state for the WTP. 5171 8.2. Configuration Status Request 5173 The Configuration Status Request message is sent by a WTP to deliver 5174 its current configuration to the AC. 5176 The Configuration Status Request message carries binding specific 5177 message elements. Refer to the appropriate binding for the 5178 definition of this structure. 5180 When an AC receives a Configuration Status Request message it acts 5181 upon the content of the message and responds to the WTP with a 5182 Configuration Status Response message. 5184 The Configuration Status Request message includes multiple Radio 5185 Administrative State message elements, one for the WTP, and one for 5186 each radio in the WTP. 5188 The Configuration Status Request message is sent by the WTP when in 5189 the Configure State. The AC does not transmit this message. 5191 The following message elements MUST be included in the Configuration 5192 Status Request message. 5194 o AC Name, see Section 4.6.4 5196 o Radio Administrative State, see Section 4.6.32 5198 o Statistics Timer, see Section 4.6.37 5200 o WTP Reboot Statistics, see Section 4.6.46 5202 The following message elements MAY be included in the Configuration 5203 Status Request message. 5205 o AC Name with Priority, see Section 4.6.5 5207 o CAPWAP Transport Protocol, see Section 4.6.14 5209 o WTP Static IP Address Information, see Section 4.6.47 5211 o Vendor Specific Payload, see Section 4.6.38 5213 8.3. Configuration Status Response 5215 The Configuration Status Response message is sent by an AC and 5216 provides a mechanism for the AC to override a WTP's requested 5217 configuration. 5219 A Configuration Status Response message is sent by an AC after 5220 receiving a Configuration Status Request message. 5222 The Configuration Status Response message carries binding specific 5223 message elements. Refer to the appropriate binding for the 5224 definition of this structure. 5226 When a WTP receives a Configuration Status Response message it acts 5227 upon the content of the message, as appropriate. If the 5228 Configuration Status Response message includes a Radio Operational 5229 State message element that causes a change in the operational state 5230 of one of the radios, the WTP transmits a Change State Event to the 5231 AC, as an acknowledgement of the change in state. 5233 The Configuration Status Response message is sent by the AC when in 5234 the Configure State. The WTP does not transmit this message. 5236 The following message elements MUST be included in the Configuration 5237 Status Response message. 5239 o CAPWAP Timers, see Section 4.6.13 5241 o Decryption Error Report Period, see Section 4.6.18 5243 o Idle Timeout, see Section 4.6.24 5245 o WTP Fallback, see Section 4.6.41 5247 One or both of the following message elements MUST be included in the 5248 Configuration Status Response Message: 5250 o AC IPv4 List, see Section 4.6.2 5251 o AC IPv6 List, see Section 4.6.3 5253 The following message element MAY be included in the Configuration 5254 Status Response message. 5256 o WTP Static IP Address Information, see Section 4.6.47 5258 o Vendor Specific Payload, see Section 4.6.38 5260 8.4. Configuration Update Request 5262 Configuration Update Request messages are sent by the AC to provision 5263 the WTP while in the Run state. This is used to modify the 5264 configuration of the WTP while it is operational. 5266 When a WTP receives a Configuration Update Request message, it 5267 responds with a Configuration Update Response message, with a Result 5268 Code message element indicating the result of the configuration 5269 request. 5271 The AC includes the Image Identifier message element (see 5272 Section 4.6.26) to force the WTP to update its firmware while in the 5273 Run state. The WTP MAY proceed to download the requested firmware if 5274 it determines the version specified in the Image Identifier message 5275 element is not in its non-volatile storage by transmitting an Image 5276 Data Request (see Section 9.1.1) that includes the Initiate Download 5277 message element (see Section 4.6.28). 5279 The Configuration Update Request is sent by the AC when in the Run 5280 State. The WTP does not transmit this message. 5282 One or more of the following message elements MAY be included in the 5283 Configuration Update message. 5285 o AC Name with Priority, see Section 4.6.5 5287 o AC Timestamp, see Section 4.6.6 5289 o Add MAC ACL Entry, see Section 4.6.7 5291 o CAPWAP Timers, see Section 4.6.13 5293 o Decryption Error Report Period, see Section 4.6.18 5295 o Delete MAC ACL Entry, see Section 4.6.19 5297 o Idle Timeout, see Section 4.6.24 5298 o Location Data, see Section 4.6.29 5300 o Radio Administrative State, see Section 4.6.32 5302 o Statistics Timer, see Section 4.6.37 5304 o WTP Fallback, see Section 4.6.41 5306 o WTP Name, see Section 4.6.44 5308 o WTP Static IP Address Information, see Section 4.6.47 5310 o Image Identifier, see Section 4.6.26 5312 o Vendor Specific Payload, see Section 4.6.38 5314 8.5. Configuration Update Response 5316 The Configuration Update Response message is the acknowledgement 5317 message for the Configuration Update Request message. 5319 The Configuration Update Response message is sent by a WTP after 5320 receiving a Configuration Update Request message. 5322 When an AC receives a Configuration Update Response message the 5323 result code indicates if the WTP successfully accepted the 5324 configuration. 5326 The Configuration Update Response message is sent by the WTP when in 5327 the Run State. The AC does not transmit this message. 5329 The following message element MUST be present in the Configuration 5330 Update message. 5332 Result Code, see Section 4.6.34 5334 The following message elements MAY be present in the Configuration 5335 Update Response message. 5337 o Radio Operational State, see Section 4.6.33 5339 o Vendor Specific Payload, see Section 4.6.38 5341 8.6. Change State Event Request 5343 The Change State Event Request message is used by the WTP for two 5344 main purposes: 5346 o When sent by the WTP following the reception of a Configuration 5347 Status Response message from the AC, the WTP uses the Change State 5348 Event Request message to provide an update on the WTP radio's 5349 operational state and to confirm that the configuration provided 5350 by the AC was successfully applied. 5352 o When sent during the Run state, the WTP uses the Change State 5353 Event Request message to notify the AC of an unexpected change in 5354 the WTP's radio operational state. 5356 When an AC receives a Change State Event Request message it responds 5357 with a Change State Event Response message and modifies its data 5358 structures for the WTP as needed. The AC MAY decide not to provide 5359 service to the WTP if it receives an error, based on local policy, 5360 and to transition to the Reset state. 5362 The Change State Event Request message is sent by a WTP to 5363 acknowledge or report an error condition to the AC for a requested 5364 configuration in the Configuration Status Response message. The 5365 Change State Event Request message includes the Result Code message 5366 element, which indicates whether the configuration was successfully 5367 applied. If the WTP is unable to apply a specific configuration 5368 request, it indicates the failure by including one or more Returned 5369 Message Element message elements (see Section 4.6.35). 5371 The Change State Event Request message is sent by the WTP in the 5372 Configure or Run State. The AC does not transmit this message. 5374 The WTP MAY save its configuration to persistent storage prior to 5375 transmitting the response. However, this is implementation specific 5376 and is not required. 5378 The following message elements MUST be present in the Change State 5379 Event Request message. 5381 o Radio Operational State, see Section 4.6.33 5383 o Result Code, see Section 4.6.34 5385 One or more of the following message elements MAY be present in the 5386 Change State Event Request message. 5388 o Returned Message Element(s), see Section 4.6.35 5390 o Vendor Specific Payload, see Section 4.6.38 5392 8.7. Change State Event Response 5394 The Change State Event Response message acknowledges the Change State 5395 Event Request message. 5397 A Change State Event Response message is sent by an AC in response to 5398 a Change State Event Request message. 5400 The Change State Event Response message is sent by the AC when in the 5401 Configure or Run state. The WTP does not transmit this message. 5403 The following message elements MAY be included in the Change State 5404 Event Response message: 5406 o Vendor Specific Payload, see Section 4.6.38 5408 The WTP does not take any action upon receipt of the Change State 5409 Event Response message. 5411 8.8. Clear Configuration Request 5413 The Clear Configuration Request message is used to reset the WTP 5414 configuration. 5416 The Clear Configuration Request message is sent by an AC to request 5417 that a WTP reset its configuration to the manufacturing default 5418 configuration. The Clear Config Request message is sent while in the 5419 Run state. 5421 The Clear Configuration Request is sent by the AC when in the Run 5422 State. The WTP does not transmit this message. 5424 The following message elements MAY be included in the Clear 5425 Configuration Request message: 5427 o Vendor Specific Payload, see Section 4.6.38 5429 When a WTP receives a Clear Configuration Request message it resets 5430 its configuration to the manufacturing default configuration. 5432 8.9. Clear Configuration Response 5434 The Clear Configuration Response message is sent by the WTP after 5435 receiving a Clear Configuration Request message and resetting its 5436 configuration parameters to the manufacturing default values. 5438 The Clear Configuration Response is sent by the WTP when in the Run 5439 State. The AC does not transmit this message. 5441 The Clear Configuration Response message MUST include the following 5442 message element. 5444 o Result Code, see Section 4.6.34 5446 The following message elements MAY be included in the Clear 5447 Configuration Request message: 5449 o Vendor Specific Payload, see Section 4.6.38 5451 9. Device Management Operations 5453 This section defines CAPWAP operations responsible for debugging, 5454 gathering statistics, logging, and firmware management. The 5455 management operations defined in this section are used by the AC to 5456 either push/pull information to/from the WTP, or request that the WTP 5457 reboot. This section does not deal with the management of the AC per 5458 se, and assumes that the AC is operational and configured. 5460 9.1. Firmware Management 5462 This section describes the firmware download procedures used by the 5463 CAPWAP protocol. Firmware download can occur during the Image Data 5464 or Run state. The former allows the download to occur at boot time, 5465 while the latter is used to trigger the download while an active 5466 CAPWAP session exists. It is important to note that the CAPWAP 5467 protocol does not provide the ability for the AC to identify whether 5468 the firmware information provided by the WTP is correct, nor whether 5469 the WTP is properly storing the firmware (see Section 12.10 for more 5470 information. 5472 Figure 6 provides an example of a WTP that performs a firmware 5473 upgrade while in the Image Data state. In this example, the WTP does 5474 not already have the requested firmware (Image Identifier = x), and 5475 downloads the image from the AC. 5477 WTP AC 5479 Join Request 5480 --------------------------------------------------------> 5482 Join Response (Image Identifier = x) 5483 <------------------------------------------------------ 5485 Image Data Request (Image Identifier = x, 5486 Initiate Download) 5487 --------------------------------------------------------> 5489 Image Data Response (Result Code = Success, 5490 Image Information = {size,hash}) 5491 <------------------------------------------------------ 5493 Image Data Request (Image Data = Data) 5494 <------------------------------------------------------ 5496 Image Data Response (Result Code = Success) 5497 --------------------------------------------------------> 5499 ..... 5501 Image Data Request (Image Data = EOF) 5502 <------------------------------------------------------ 5504 Image Data Response (Result Code = Success) 5505 --------------------------------------------------------> 5507 (WTP enters the Reset State) 5509 Figure 6: WTP Firmware Download Case 1 5511 Figure 7 provides an example in which the WTP has the image specified 5512 by the AC in its non-volative storage, but is not its current running 5513 image. In this case, the WTP opts to NOT download the firmware and 5514 immediately reset to the requested image. 5516 WTP AC 5518 Join Request 5519 --------------------------------------------------------> 5521 Join Response (Image Identifier = x) 5522 <------------------------------------------------------ 5524 (WTP enters the Reset State) 5526 Figure 7: WTP Firmware Download Case 2 5528 Figure 8 provides an example of a WTP that performs a firmware 5529 upgrade while in the Run state. This mode of firmware upgrade allows 5530 the WTP to download its image while continuing to provide service. 5531 The WTP will not automatically reset until it is notified by the AC, 5532 with a Reset Request message. 5534 WTP AC 5536 Configuration Update Request (Image Identifier = x) 5537 <------------------------------------------------------ 5539 Configuration Update Response (Result Code = Success) 5540 --------------------------------------------------------> 5542 Image Data Request (Image Identifier = x, 5543 Initiate Download) 5544 --------------------------------------------------------> 5546 Image Data Response (Result Code = Success, 5547 Image Information = {size,hash}) 5548 <------------------------------------------------------ 5550 Image Data Request (Image Data = Data) 5551 <------------------------------------------------------ 5553 Image Data Response (Result Code = Success) 5554 --------------------------------------------------------> 5556 ..... 5558 Image Data Request (Image Data = EOF) 5559 <------------------------------------------------------ 5561 Image Data Response (Result Code = Success) 5562 --------------------------------------------------------> 5564 ..... 5566 (administratively requested reboot request) 5567 Reset Request (Image Identifier = x) 5568 <------------------------------------------------------ 5570 Reset Response (Result Code = Success) 5571 --------------------------------------------------------> 5573 Figure 8: WTP Firmware Download Case 3 5575 Figure 9 provides another example of the firmware download while in 5576 the Run state. In this example, the WTP already has the image 5577 specified by the AC in its non-volative storage. The WTP opts to NOT 5578 download the firmware. The WTP resets upon receipt of a Reset 5579 Request message from the AC. 5581 WTP AC 5583 Configuration Update Request (Image Identifier = x) 5584 <------------------------------------------------------ 5586 Configuration Update Response (Result Code = Already Have Image) 5587 --------------------------------------------------------> 5589 ..... 5591 (administratively requested reboot request) 5592 Reset Request (Image Identifier = x) 5593 <------------------------------------------------------ 5595 Reset Response (Result Code = Success) 5596 --------------------------------------------------------> 5598 Figure 9: WTP Firmware Download Case 4 5600 9.1.1. Image Data Request 5602 The Image Data Request message is used to update firmware on the WTP. 5603 This message and its companion Response message are used by the AC to 5604 ensure that the image being run on each WTP is appropriate. 5606 Image Data Request messages are exchanged between the WTP and the AC 5607 to download a new firmware image to the WTP. When a WTP or AC 5608 receives an Image Data Request message it responds with an Image Data 5609 Response message. The message elements contained within the Image 5610 Data Request message are required to determine the intent of the 5611 request. 5613 The decision that new firmware is to be downloaded to the WTP can 5614 occur in one of two ways: 5616 When the WTP joins the AC, the Join Response message includes the 5617 Image Identifier message element, which informs the WTP of the 5618 firmware it is expected to run. if the WTP does not currently have 5619 the requested firmware version, it transmits an Image Data Request 5620 message, with the appropriate Image Identifier message element. 5621 If the WTP already has the requested firmware in its non-volatile 5622 flash, but is not its currently running image, it simply resets to 5623 run the proper firmware. 5625 Once the WTP is in the Run state, it is possible for the AC to 5626 cause the WTP to initiate a firmware download by sending an 5627 Configuration Update Request message with the Image Identifier 5628 message elements. This will cause the WTP to transmit an Image 5629 Data Request with the Image Identifier and the Initiate Download 5630 message elements. Note that when the firmware is downloaded in 5631 this way, the WTP does not automatically reset after the download 5632 is complete. The WTP will only reset when it receives a Reset 5633 Request message from the AC. If the WTP already had the requested 5634 firmware version in its non-volatile storage, the WTP does not 5635 transmit the Image Data Request message and responds with a 5636 Configuration Update Response message with the Result Code set to 5637 Image Already Present. 5639 Regardless of how the download was initiated, once the AC receives an 5640 Image Data Request message with the Image Identifier message element, 5641 it begins the transfer process by transmitting an Image Data Request 5642 message that includes the Image Data message element. This continues 5643 until the firmware image has been transferred. 5645 The Image Data Request message is sent by the WTP or the AC when in 5646 the Image Data or Run State. 5648 The following message elements MAY be included in the Image Data 5649 Request message. 5651 o CAPWAP Transport Protocol, see Section 4.6.14 5653 o Image Data, see Section 4.6.25 5655 o Vendor Specific Payload, see Section 4.6.38 5657 The following message elements MAY be included in the Image Data 5658 Request message when sent by the WTP. 5660 o Image Identifier, see Section 4.6.26 5662 o Initiate Download, see Section 4.6.28 5664 9.1.2. Image Data Response 5666 The Image Data Response message acknowledges the Image Data Request 5667 message. 5669 An Image Data Response message is sent in response to a received 5670 Image Data Request message. Its purpose is to acknowledge the 5671 receipt of the Image Data Request message. The Result Code is 5672 included to indicate whether a previously sent Image Data Request 5673 message was invalid. 5675 The Image Data Response message is sent by the WTP or the AC when in 5676 the Image Data or Run State. 5678 The following message element MUST be included in the Image Data 5679 Response message. 5681 o Result Code, see Section 4.6.34 5683 The following message elements MAY be included in the Image Data 5684 Response message. 5686 o Vendor Specific Payload, see Section 4.6.38 5688 The following message elements MAY be included in the Image Data 5689 Response message when sent by the AC. 5691 o Image Information, see Section 4.6.27 5693 Upon receiving an Image Data Response message indicating an error, 5694 the WTP MAY retransmit a previous Image Data Request message, or 5695 abandon the firmware download to the WTP by transitioning to the 5696 Reset state. 5698 9.2. Reset Request 5700 The Reset Request message is used to cause a WTP to reboot. 5702 A Reset Request message is sent by an AC to cause a WTP to 5703 reinitialize its operation. If the AC includes the Image Identifier 5704 message element (see Section 4.6.26), it indicates to the WTP that it 5705 SHOULD use that version of software upon reboot. 5707 The Reset Request is sent by the AC when in the Run State. The WTP 5708 does not transmit this message. 5710 The following message elements MUST be included in the Reset Request 5711 message. 5713 o Image Identifier, see Section 4.6.26 5715 The following message elements MAY be included in the Reset Request 5716 message: 5718 o Vendor Specific Payload, see Section 4.6.38 5720 When a WTP receives a Reset Request message, it responds with a Reset 5721 Response message indicating success and then reinitialize itself. If 5722 the WTP is unable to write to its non-volatile storage, to ensure 5723 that it runs the requested software version indicated in the Image 5724 Identifier message element, it MAY send the appropriate Result Code 5725 message element, but MUST reboot. If the WTP is unable to reset, 5726 including a hardware reset, it sends a Reset Response message to the 5727 AC with a Result Code message element indicating failure. The AC no 5728 longer provides service to the WTP. 5730 9.3. Reset Response 5732 The Reset Response message acknowledges the Reset Request message. 5734 A Reset Response message is sent by the WTP after receiving a Reset 5735 Request message. 5737 The Reset Response is sent by the WTP when in the Run State. The AC 5738 does not transmit this message. 5740 The following message element MAY be included in the Reset Response 5741 message. 5743 o Result Code, see Section 4.6.34 5745 o Vendor Specific Payload, see Section 4.6.38 5747 When an AC receives a successful Reset Response message, it is 5748 notified that the WTP will reinitialize its operation. An AC that 5749 receives a Reset Response message indicating failure may opt to no 5750 longer provide service to the WTP. 5752 9.4. WTP Event Request 5754 The WTP Event Request message is used by a WTP to send information to 5755 its AC. The WTP Event Request message MAY be sent periodically, or 5756 sent in response to an asynchronous event on the WTP. For example, a 5757 WTP MAY collect statistics and use the WTP Event Request message to 5758 transmit the statistics to the AC. 5760 When an AC receives a WTP Event Request message it will respond with 5761 a WTP Event Response message. 5763 The presence of the Delete Station message element is used by the WTP 5764 to inform the AC that it is no longer providing service to the 5765 station. This could be the result of an Idle Timeout (see 5766 Section 4.6.24), due to resource shortages, or some other reason. 5768 The WTP Event Request message is sent by the WTP when in the Run 5769 State. The AC does not transmit this message. 5771 The WTP Event Request message MUST contain one of the message 5772 elements listed below, or a message element that is defined for a 5773 specific wireless technology. More than one of each message element 5774 listed MAY be included in the WTP Event Request message. 5776 o Decryption Error Report, see Section 4.6.17 5778 o Duplicate IPv4 Address, see Section 4.6.22 5780 o Duplicate IPv6 Address, see Section 4.6.23 5782 o WTP Radio Statistics, see Section 4.6.45 5784 o WTP Reboot Statistics, see Section 4.6.46 5786 o Delete Station, see Section 4.6.20 5788 o Vendor Specific Payload, see Section 4.6.38 5790 9.5. WTP Event Response 5792 The WTP Event Response message acknowledges receipt of the WTP Event 5793 Request message. 5795 A WTP Event Response message is sent by an AC after receiving a WTP 5796 Event Request message. 5798 The WTP Event Response message is sent by the AC when in the Run 5799 State. The WTP does not transmit this message. 5801 The following message elements MAY be included in the WTP Event 5802 Response message: 5804 o Vendor Specific Payload, see Section 4.6.38 5806 9.6. Data Transfer 5808 This section describes the data transfer procedures used by the 5809 CAPWAP protocol. The data transfer mechanism is used to upload 5810 information available at the WTP to the AC, such as crash or debug 5811 information. The data transfer messages can only be exchanged while 5812 in the Run state. 5814 Figure 10 provides an example of an AC that requests that the WTP 5815 transfer its latest crash file. Once the WTP acknowledges that it 5816 has information to send, via the Data Transfer Response, it transmits 5817 its own Data Transfer Request. Upon receipt, the AC responds with a 5818 Data Transfer Response, and the exchange continues until the WTP 5819 transmits a Data Transfer Data message element that indicates an End 5820 of File (EOF). 5822 WTP AC 5824 Data Transfer Request (Data Transfer Mode = Crash Data) 5825 <------------------------------------------------------ 5827 Data Transfer Response (Result Code = Success) 5828 --------------------------------------------------------> 5830 Data Transfer Request (Data Transfer Data = Data) 5831 --------------------------------------------------------> 5833 Data Transfer Response (Result Code = Success) 5834 <------------------------------------------------------ 5836 ..... 5838 Data Transfer Request (Data Transfer Data = EOF) 5839 --------------------------------------------------------> 5841 Data Transfer Response (Result Code = Success) 5842 <------------------------------------------------------ 5844 Figure 10: WTP Data Transfer Case 1 5846 Figure 11 provides an example of an AC that requests that the WTP 5847 transfer its latest crash file. However, in this example, the WTP 5848 does not have any crash information to send, and therefore sends a 5849 Data Transfer Response with a Result Code indicating the error. 5851 WTP AC 5853 Data Transfer Request (Data Transfer Mode = Crash Data) 5854 <------------------------------------------------------ 5856 Data Transfer Response (Result Code = Data Transfer 5857 Error (No Information to Transfer)) 5858 --------------------------------------------------------> 5860 Figure 11: WTP Data Transfer Case 2 5862 9.6.1. Data Transfer Request 5864 The Data Transfer Request message is used to deliver debug 5865 information from the WTP to the AC. 5867 The Data Transfer Request messages can be sent either by the AC or 5868 the WTP. When sent by the AC, it is used to request that data be 5869 transmitted from the WTP to the AC, and includes the Data Transfer 5870 Mode message element, which specifies the information desired by the 5871 AC. The Data Transfer Request is sent by the WTP in order to 5872 transfer actual data to the AC, through the Data Transfer Data 5873 message element. 5875 Given that the CAPWAP protocol minimizes the need for WTPs to be 5876 directly managed, the Data Transfer Request is an important 5877 troubleshooting tool used by the AC to retrieve information that may 5878 be available on the WTP. For instance, some WTPs implementations may 5879 store crash information to help manufacturers identify software 5880 faults. The Data Transfer Request message can be used to send such 5881 information from the WTP to the AC. Another possible use would be to 5882 allow a remote debugger function in the WTP to use the Data Transfer 5883 Request message to send console output to the AC for debugging 5884 purposes. 5886 When the WTP or AC receives a Data Transfer Request message it 5887 responds to the WTP with a Data Transfer Response message. The AC 5888 MAY log the information received through the Data Transfer Data 5889 message element. 5891 The Data Transfer Request message is sent by the WTP or AC when in 5892 the Run State. 5894 When sent by the AC, the Data Transfer Request message MUST contain 5895 the following message elements: 5897 o Data Transfer Mode, see Section 4.6.16 5899 When sent by the WTP, the Data Transfer Request message MUST contain 5900 the following message elements: 5902 o Data Transfer Data, see Section 4.6.15 5904 Regardless of whether the Data Transfer Request is sent by the AC or 5905 WTP, the following message elements MAY be included in the Data 5906 Transfer Request message: 5908 o Vendor Specific Payload, see Section 4.6.38 5910 9.6.2. Data Transfer Response 5912 The Data Transfer Response message acknowledges the Data Transfer 5913 Request message. 5915 A Data Transfer Response message is sent in response to a received 5916 Data Transfer Request message. Its purpose is to acknowledge receipt 5917 of the Data Transfer Request message. When sent by the WTP, the 5918 Result Code message element is used to indicate whether the data 5919 transfer requested by the AC can be completed. When sent by the AC, 5920 the Result Code message element is used to indicate receipt of the 5921 data transfered in the Data Transfer Request message. 5923 The Data Transfer Response message is sent by the WTP or AC when in 5924 the Run State. 5926 The following message element MUST be included in the Data Transfer 5927 Response message. 5929 o Result Code, see Section 4.6.34 5931 The following message elements MAY be included in the Data Transfer 5932 Response message: 5934 o Vendor Specific Payload, see Section 4.6.38 5936 Upon receipt of a Data Transfer Response message, the WTP transmits 5937 more information, if more information is available. 5939 10. Station Session Management 5941 Messages in this section are used by the AC to create, modify or 5942 delete station session state on the WTPs. 5944 10.1. Station Configuration Request 5946 The Station Configuration Request message is used to create, modify 5947 or delete station session state on a WTP. The message is sent by the 5948 AC to the WTP, and MAY contain one or more message elements. The 5949 message elements for this CAPWAP control message include information 5950 that is generally highly technology specific. Refer to the 5951 appropriate binding document for definitions of the messages elements 5952 that are included in this control message. 5954 The Station Configuration Request message is sent by the AC when in 5955 the Run State. The WTP does not transmit this message. 5957 The following CAPWAP Control message elements MAY be included in the 5958 Station Configuration Request message. More than one of each message 5959 element listed MAY be included in the Station Configuration Request 5960 message. 5962 o Add Station, see Section 4.6.8 5964 o Delete Station, see Section 4.6.20 5966 o Vendor Specific Payload, see Section 4.6.38 5968 10.2. Station Configuration Response 5970 The Station Configuration Response message is used to acknowledge a 5971 previously received Station Configuration Request message. 5973 The Station Configuration Response message is sent by the WTP when in 5974 the Run State. The AC does not transmit this message. 5976 The following message element MUST be present in the Station 5977 Configuration Response message. 5979 o Result Code, see Section 4.6.34 5981 The following message elements MAY be included in the Station 5982 Configuration Response message: 5984 o Vendor Specific Payload, see Section 4.6.38 5986 The Result Code message element indicates that the requested 5987 configuration was successfully applied, or that an error related to 5988 processing of the Station Configuration Request message occurred on 5989 the WTP. 5991 11. NAT Considerations 5993 There are three specific situations in which a NAT deployment may be 5994 used in conjunction with a CAPWAP-enabled deployment. The first 5995 consists of a configuration in which a single WTP is behind a NAT 5996 system. Since all communication is initiated by the WTP, and all 5997 communication is performed over IP using two UDP ports, the protocol 5998 easily traverses NAT systems in this configuration. 6000 In the second case, two or more WTPs are deployed behind the same NAT 6001 system. Here, the AC would receive multiple connection requests from 6002 the same IP address, and therefore cannot use the WTP's IP address 6003 alone to bind the CAPWAP control and data channel. The CAPWAP Data 6004 Check state, which establishes the data plane connection and 6005 communicates the CAPWAP Data Channel Keepalive, includes the Session 6006 Identifier message element, which is used to bind the control and 6007 data plane. Use of the Session Identifier message element enables 6008 the AC to match the control and data plane flows from multiple WTPs 6009 behind the same NAT system (multiple WTPs sharing the same IP 6010 address). CAPWAP implementations MUST also use DTLS session 6011 information on any encrypted CAPWAP channel to validate the source of 6012 both the control and data plane, as described in Section 12.2. 6014 In the third configuration, the AC is deployed behind a NAT. In this 6015 case, the AC is not reachable by the WTP unless a specific rule has 6016 been configured on the NAT to translate the address and redirect 6017 CAPWAP messages to the AC. This deployment presents two issues. 6018 First, an AC communicates its interfaces and corresponding WTP load 6019 using the CAPWAP Control IPv4 Address and CAPWAP Control IPv6 Address 6020 message elements. This message element is mandatory, but contains IP 6021 addresses that are only valid in the private address space used by 6022 the AC, which is not reachable by the WTP. The WTP MUST NOT utilize 6023 the information in these message elements if it detects a NAT (as 6024 described in the CAPWAP Transport Protocol message element in 6025 Section 4.6.14). Second, since the addresses cannot be used by the 6026 WTP, this effectively disables the load balancing capabilities (see 6027 Section 6.1) of the CAPWAP protocol. Alternatively, the AC could 6028 have a configured NAT'ed address, which it would include in either of 6029 the two control address message elements, and the NAT would need to 6030 be configured accordingly. 6032 In order for a CAPWAP WTP or AC to detect whether a middlebox is 6033 present, both the Join Request (see Section 6.1) and the Join 6034 Response (see Section 6.2) include either the CAPWAP Local IPv4 6035 Address (see Section 4.6.11), or the CAPWAP Local IPv6 Address (see 6036 Section 4.6.12) message element. Upon receiving one of these 6037 messages, if the packet's source IP address differs from the address 6038 found in either one of these message elements, it indicates that a 6039 middlebox is present. 6041 In order for CAPWAP to be compatible with potential middleboxes in 6042 the network, CAPWAP implementations MUST send return traffic from the 6043 same port on which it received traffic from a given peer. Further, 6044 any unsolicited requests generated by a CAPWAP node MUST be sent on 6045 the same port. 6047 Note that this middlebox detection technique is not foolproof. If 6048 the public IP address assigned to the NAT is identical to the private 6049 IP address used by the AC, detection by the WTP would fail. This 6050 failure can lead to various protocol errors, so it is therefore 6051 necessary for deployments to ensure that the NAT's IP address is not 6052 the same as the ACs. 6054 The CAPWAP protocol allows for all of the AC identities supporting a 6055 group of WTPs to be communicated through the AC List message element. 6056 This feature MUST be ignored by the WTP when it detects the AC is 6057 behind a middlebox. 6059 The CAPWAP protocol allows an AC to configure a static IP address on 6060 a WTP using the WTP Static IP Address Information message element. 6061 This message element SHOULD NOT be used in NAT'ed environments, 6062 unless the administrator is familiar with the internal IP addressing 6063 scheme within the WTP's private network, and does not rely on the 6064 public address seen by the AC. 6066 When a WTP detects the duplicate address condition, it generates a 6067 message to the AC, which includes the Duplicate IP Address message 6068 element. The IP Address embedded within this message element is 6069 different from the public IP address seen by the AC. 6071 12. Security Considerations 6073 This section describes security considerations for the CAPWAP 6074 protocol. It also provides security recommendations for protocols 6075 used in conjunction with CAPWAP. 6077 12.1. CAPWAP Security 6079 As it is currently specified, the CAPWAP protocol sits between the 6080 security mechanisms specified by the wireless link layer protocol 6081 (e.g.IEEE 802.11i) and AAA. One goal of CAPWAP is to bootstrap trust 6082 between the STA and WTP using a series of preestablished trust 6083 relationships: 6085 STA WTP AC AAA 6086 ============================================== 6088 DTLS Cred AAA Cred 6089 <------------><-------------> 6091 EAP Credential 6092 <------------------------------------------> 6094 wireless link layer 6095 (e.g.802.11 PTK) 6096 <--------------> or 6097 <---------------------------> 6098 (derived) 6100 Figure 12: STA Session Setup 6102 Within CAPWAP, DTLS is used to secure the link between the WTP and 6103 AC. In addition to securing control messages, it's also a link in 6104 this chain of trust for establishing link layer keys. Consequently, 6105 much rests on the security of DTLS. 6107 In some CAPWAP deployment scenarios, there are two channels between 6108 the WTP and AC: the control channel, carrying CAPWAP control 6109 messages, and the data channel, over which client data packets are 6110 tunneled between the AC and WTP. Typically, the control channel is 6111 secured by DTLS, while the data channel is not. 6113 The use of parallel protected and unprotected channels deserves 6114 special consideration, but does not create a threat. There are two 6115 potential concerns: attempting to convert protected data into un- 6116 protected data and attempting to convert un-protected data into 6117 protected data. These concerns are addressed below. 6119 12.1.1. Converting Protected Data into Unprotected Data 6121 Since CAPWAP does not support authentication-only ciphers (i.e. all 6122 supported ciphersuites include encryption and authentication), it is 6123 not possible to convert protected data into unprotected data. Since 6124 encrypted data is (ideally) indistinguishable from random data, the 6125 probability of an encrypted packet passing for a well-formed packet 6126 is effectively zero. 6128 12.1.2. Converting Unprotected Data into Protected Data (Insertion) 6130 The use of message authentication makes it impossible for the 6131 attacker to forge protected records. This makes conversion of 6132 unprotected records to protected records impossible. 6134 12.1.3. Deletion of Protected Records 6136 An attacker could remove protected records from the stream, though 6137 not undetectably so, due the built-in reliability of the underlying 6138 CAPWAP protocol. In the worst case, the attacker would remove the 6139 same record repeatedly, resulting in a CAPWAP session timeout and 6140 restart. This is effectively a DoS attack, and could be accomplished 6141 by a man in the middle regardless of the CAPWAP protocol security 6142 mechanisms chosen. 6144 12.1.4. Insertion of Unprotected Records 6146 An attacker could inject packets into the unprotected channel, but 6147 this may become evident if sequence number desynchronization occurs 6148 as a result. Only if the attacker is a MiM can packets be inserted 6149 undetectably. This is a consequence of that channel's lack of 6150 protection, and not a new threat resulting from the CAPWAP security 6151 mechanism. 6153 12.1.5. Use of MD5 6155 The Image Information Section 4.6.27) message element makes use of 6156 MD5 to compute the hash field. The authenticity and integrity of the 6157 image file is protected by DTLS, and in this context, MD5 is not used 6158 as a cryptographically secure hash, but just as a basic checksum. 6159 Therefore, the use of MD5 is not considered a security vulnerability, 6160 and no mechanisms for algorithm agility are provided. 6162 12.1.6. CAPWAP Fragmentation 6164 RFC 4963 [RFC4963] describes a possible security vulnerability where 6165 a malicious entity can "corrupt" a flow by injecting fragments. By 6166 sending "high" fragments (those with offset greater than zero) with a 6167 forged source address, the attacker can deliberately cause 6168 corruption. The use of DTLS on the CAPWAP Data channel can be used 6169 to avoid this possible vulnerability. 6171 12.2. Session ID Security 6173 Since DTLS does not export a unique session identifier, there can be 6174 no explicit protocol binding between the DTLS layer and CAPWAP layer. 6175 As a result, implementations MUST provide a mechanism for performing 6176 this binding. For example, an AC MUST NOT associate decrypted DTLS 6177 control packets with a particular WTP session based solely on the 6178 Session ID in the packet header. Instead, identification should be 6179 done based on which DTLS session decrypted the packet. Otherwise one 6180 authenticated WTP could spoof another authenticated WTP by altering 6181 the Session ID in the encrypted CAPWAP header. 6183 It should be noted that when the CAPWAP data channel is unencrypted, 6184 the WTP Session ID is exposed and possibly known to adversaries and 6185 other WTPs. This would allow the forgery of the source of data- 6186 channel traffic. This, however, should not be a surprise for 6187 unencrypted data channels. When the data channel is encrypted, the 6188 Session ID is not exposed, and therefore can safely be used to 6189 associate a data and control channel. The 128-bit length of the 6190 Session ID mitigates online guessing attacks where an adversarial, 6191 authenticated WTP tries to correlate his own data channel with 6192 another WTP's control channel. Note that for encrypted data 6193 channels, the Session ID should only be used for correlation for the 6194 first packet immediately after the initial DTLS handshake. Future 6195 correlation should instead be done via identification of a packet's 6196 DTLS session. 6198 12.3. Discovery or DTLS Setup Attacks 6200 Since the Discovery Request messages are sent in the clear, it is 6201 important that AC implementations NOT assume that receiving a 6202 Discovery Request message from a WTP implies that the WTP has 6203 rebooted, and consequently tear down any active DTLS sessions. 6204 Discovery Request messages can easily be spoofed by malicious 6205 devices, so it is important that the AC maintain two separate sets of 6206 states for the WTP until the DTLSSessionEstablished notification is 6207 received, indicating that the WTP was authenticated. Once a new DTLS 6208 session is successfully established, any state referring to the old 6209 session can be cleared. 6211 Similarly, entering the DTLS Setup phase SHOULD NOT assume that the 6212 WTP has reset, and therefore should not discard active state until 6213 the DTLS session has been successfully established. While the 6214 HelloVerifyRequest provides some protection against denial of service 6215 (DoS) attacks on the AC, an adversary capable of receiving packets at 6216 a valid address (or a malfunctioning or misconfigured WTP) may 6217 repeatedly attempt DTLS handshakes with the AC, potentially creating 6218 a resource shortage. If either the FailedDTLSSessionCount or the 6219 FailedDTLSAuthFailCount counter reaches the value of 6220 MaxFailedDTLSSessionRetry variable (see Section 4.8), implementations 6221 MAY choose to rate-limit new DTLS handshakes for some period of time. 6222 It is RECOMMENDED that implementations choosing to implement rate 6223 limiting use a random discard technique, rather than mimicking the 6224 WTP's sulking behavior. This will ensure that messages from valid 6225 WTPs will have some probability of eliciting a response, even in the 6226 face of a significant DoS attack. 6228 Some CAPWAP implementations may wish to restrict the DTLS setup 6229 process to only those peers that have been configured in the access 6230 control list, authorizing only those clients to initiate a DTLS 6231 handshake. Note that the impact of this on mitigating denial of 6232 service attacks against the DTLS layer is minimal, because DTLS 6233 already uses client-side cookies to minimize processor consumption 6234 attacks. 6236 12.4. Interference with a DTLS Session 6238 If a WTP or AC repeatedly receives packets which fail DTLS 6239 authentication or decryption, this could indicate a DTLS 6240 desynchronization between the AC and WTP, a link prone to 6241 undetectable bit errors, or an attacker trying to disrupt a DTLS 6242 session. 6244 In the state machine (section 2.3), transitions to the DTLS tear down 6245 state can be triggered by frequently receiving DTLS packets with 6246 authentication or decryption errors. The threshold or technique for 6247 deciding when to move to the tear down state should be chosen 6248 carefully. Being able to easily transition to DTLS TD allows easy 6249 detection of malfunctioning devices, but allows for denial of service 6250 attacks. Making it difficult to transition to DTLS TD prevents 6251 denial of service attacks, but makes it more difficult to detect and 6252 reset a malfunctioning session. Implementers should set this policy 6253 with care. 6255 12.5. CAPWAP Pre-Provisioning 6257 In order for CAPWAP to establish a secure communication with a peer, 6258 some level of pre-provisioning on both the WTP and AC is necessary. 6259 This section will detail the minimal number of configuration 6260 parameters. 6262 When using preshared keys, it is necessary to configure the preshared 6263 key for each possible peer with which a DTLS session may be 6264 established. To support this mode of operation, one or more entries 6265 of the following table may be configured on either the AC or WTP: 6267 o Identity: The identity of the peering AC or WTP. This format MAY 6268 be either in the form of an IP address or host name (the latter of 6269 which needs to be resolved to an IP address using DNS). 6271 o Key: The pre-shared key for use with the peer when establishing 6272 the DTLS session (see Section 12.6 for more information). 6274 o PSK Identity: Identity hint associated with the provisioned key 6275 (see Section 2.4.4.4 for more information). 6277 When using certificates, the following items need to be pre- 6278 provisioned: 6280 o Device Certificate: The local device's certificate (see 6281 Section 12.7 for more information) 6283 o Trust Anchor: Trusted root certificate chain used to validate any 6284 certificate received from CAPWAP peers. Note that one or more 6285 root certificate MAY be configured on a given device. 6287 Regardless of the authentication method, the following items need to 6288 be pre-provisioned: 6290 o Access Control List: The access control list table contains the 6291 identities of one or more CAPWAP peers, along with a rule. The 6292 rule is used to determine whether communication with the peer is 6293 permitted (see Section 2.4.4.3 for more information). 6295 12.6. Use of Preshared Keys in CAPWAP 6297 While use of preshared keys may provide deployment and provisioning 6298 advantages not found in public key based deployments, it also 6299 introduces a number of operational and security concerns. In 6300 particular, because the keys must typically be entered manually, it 6301 is common for people to base them on memorable words or phrases. 6302 These are referred to as "low entropy passwords/passphrases". 6304 Use of low-entropy preshared keys, coupled with the fact that the 6305 keys are often not frequently updated, tends to significantly 6306 increase exposure. For these reasons, the following recommendations 6307 are made: 6309 o When DTLS is used with a preshared-key (PSK) ciphersuite, each WTP 6310 SHOULD have a unique PSK. Since WTPs will likely be widely 6311 deployed, their physical security is not guaranteed. If PSKs are 6312 not unique for each WTP, key reuse would allow the compromise of 6313 one WTP to result in the compromise of others 6315 o Generating PSKs from low entropy passwords is NOT RECOMMENDED. 6317 o It is RECOMMENDED that implementations that allow the 6318 administrator to manually configure the PSK also provide a 6319 capability for generation of new random PSKs, taking RFC 4086 6320 [RFC4086] into account. 6322 o Preshared keys SHOULD be periodically updated. Implementations 6323 MAY facilitate this by providing an administrative interface for 6324 automatic key generation and periodic update, or it MAY be 6325 accomplished manually instead. 6327 Every pairwise combination of WTP and AC on the network SHOULD have a 6328 unique PSK. This prevents the domino effect (see Guidance for AAA 6329 Key Management [RFC4962]). If PSKs are tied to specific WTPs, then 6330 knowledge of the PSK implies a binding to a specified identity that 6331 can be authorized. 6333 If PSKs are shared, this binding between device and identity is no 6334 longer possible. Compromise of one WTP can yield compromise of 6335 another WTP, violating the CAPWAP security hierarchy. Consequently, 6336 sharing keys between WTPs is NOT RECOMMENDED. 6338 12.7. Use of Certificates in CAPWAP 6340 For public-key-based DTLS deployments, each device SHOULD have unique 6341 credentials, with an extended key usage authorizing the device to act 6342 as either a WTP or AC. If devices do not have unique credentials, it 6343 is possible that by compromising one device, any other device using 6344 the same credential may also be considered to be compromised. 6346 Certificate validation involves checking a large variety of things. 6347 Since the necessary things to validate are often environment- 6348 specific, many are beyond the scope of this document. In this 6349 section, we provide some basic guidance on certificate validation. 6351 Each device is responsible for authenticating and authorizing devices 6352 with which they communicate. Authentication entails validation of 6353 the chain of trust leading to the peer certificate, followed by the 6354 peer certificate itself. Implementations SHOULD also provide a 6355 secure method for verifying that the credential in question has not 6356 been revoked. 6358 Note that if the WTP relies on the AC for network connectivity (e.g. 6360 the AC is a layer 2 switch to which the WTP is directly connected), 6361 the WTP may not be able to contact an OCSP server or otherwise obtain 6362 an up to date CRL if a compromised AC doesn't explicitly permit this. 6363 This cannot be avoided, except through effective physical security 6364 and monitoring measures at the AC. 6366 Proper validation of certificates typically requires checking to 6367 ensure the certificate has not yet expired. If devices have a real- 6368 time clock, they SHOULD verify the certificate validity dates. If no 6369 real-time clock is available, the device SHOULD make a best-effort 6370 attempt to validate the certificate validity dates through other 6371 means. Failure to check a certificate's temporal validity can make a 6372 device vulnerable to man-in-the-middle attacks launched using 6373 compromised, expired certificates, and therefore devices should make 6374 every effort to perform this validation. 6376 12.8. Use of MAC Address in CN Field 6378 The CAPWAP protocol is an evolution of an existing protocol 6379 [I-D.ohara-capwap-lwapp] which is implemented on a large number of 6380 already deployed ACs and WTPs. Everyone of these devices have an 6381 existing X.509 certificate, which is provisioned at manufacturing 6382 time. These X.509 certificates use the device's MAC Address in the 6383 Common Name (CN) field. It is well understood that encoding the MAC 6384 Address in the CN field is less than optimal, and using the 6385 SubjectAltName field would be preferable. However, at the time of 6386 publication, there is no URN specification that allows for the MAC 6387 Address to be used in the SubjectAltName field. As such a 6388 specification is published by the IETF, future versions of the CAPWAP 6389 protocol MAY require support for the new URN scheme. 6391 12.9. AAA Security 6393 The AAA protocol is used to distribute EAP keys to the ACs, and 6394 consequently its security is important to the overall system 6395 security. When used with TLS or IPsec, security guidelines specified 6396 in RFC 3539 [RFC3539] SHOULD be followed. 6398 In general, the link between the AC and AAA server SHOULD be secured 6399 using a strong ciphersuite keyed with mutually authenticated session 6400 keys. Implementations SHOULD NOT rely solely on Basic RADIUS shared 6401 secret authentication as it is often vulnerable to dictionary 6402 attacks, but rather SHOULD use stronger underlying security 6403 mechanisms. 6405 12.10. WTP Firmware 6407 The CAPWAP protocol defines a mechanism by which the AC downloads new 6408 firmware to the WTP. During the session establishment process, the 6409 WTP provides information about its current firmware to the AC. The 6410 AC then decides whether the WTP's firmware needs to be updated. It 6411 is important to note that the CAPWAP specification makes the explicit 6412 assumption that the WTP is providing the correct firmware version to 6413 the AC, and is therefore not lying. Fruther, during the firmware 6414 download process, the CAPWAP protocol does not provide any mechanisms 6415 to recognize whether the WTP is actually storing the firmware for 6416 future use. 6418 13. Operational Considerations 6420 The CAPWAP protocol assumes that it is the only configuration 6421 interface to the WTP to configure parameters that are specified in 6422 the CAPWAP specifications. While the use of a separate management 6423 protocol MAY be used for the purposes of monitoring the WTP directly, 6424 configuring the WTP through a separate management interface is not 6425 recommended. Configuring the WTP through a separate protocol, such 6426 as via a CLI or SNMP, could lead to the AC state being out of sync 6427 with the WTP. 6429 The CAPWAP protocol does not deal with the management of the ACs. 6430 The AC is assumed to be configured through some separate management 6431 interface, which could be via a proprietary CLI, SNMP, NETCONF or 6432 some other management protocol. 6434 The CAPWAP protocol's control channel is fairly light weight from a 6435 traffic perspective. Once the WTP has been configured, the WTP sends 6436 periodic statistics. Further, the specification calls for a 6437 keepalive packet to be sent on the protocol's data channel to make 6438 sure that any possible middleboxes (e.g., NAT) maintain their UDP 6439 state. The overhead associated with the control and data channel is 6440 not expected to impact network traffic. That said, the CAPWAP 6441 protocol does allow for the frequency of these packets to be modified 6442 through the DataChannelKeepAlive and StatisticsTimer (see 6443 Section 4.7.2 and Section 4.7.14, respectively). 6445 14. Transport Considerations 6447 The CAPWAP WG carefully considered the congestion control 6448 requirements of the CAPWAP protocol, both for the CAPWAP control and 6449 data channels. 6451 CAPWAP specifies a single-threaded command/response protocol to be 6452 used on the control channel, and we have specified that an 6453 exponential back-off algorithm should be used when commands are 6454 retransmitted. When CAPWAP runs in its default mode (Local MAC), the 6455 control channel is the only CAPWAP channel. 6457 However, CAPWAP can also be run in Split MAC mode, in which case 6458 there will be a DTLS-encrypted data channel between each WTP and the 6459 AC. The WG discussed various options for providing congestion 6460 control on this channel. However, due to performance problems with 6461 TCP when it is run over another congestion control mechanism and the 6462 fact that the vast majority of traffic run over the CAPWAP data 6463 channel is likely to be congestion-controlled IP traffic, the CAPWAP 6464 WG felt that specifying a congestion control mechanism for the CAPWAP 6465 data channel would be more likely to cause problems than to resolve 6466 any. 6468 Because there is no congestion control mechanism specified for the 6469 CAPWAP data channel, it is RECOMMENDED that non-congestion-controlled 6470 traffic not be tunneled over CAPWAP. When a significant amount of 6471 non-congestion-controlled traffic is expected to be present on a 6472 WLAN, the CAPWAP connection between the AC and the WTP for that LAN 6473 should be configured to remain in Local MAC mode with Distribution 6474 function at the WTP. 6476 The lock step nature of the CAPWAP protocol's control channel can 6477 cause the firmware download process to take some time, depending upon 6478 the RTT. This is not expected to be a problem since the CAPWAP 6479 protocol allows firmware to be downloaded while the WTP provides 6480 service to wireless clients/devices. 6482 It is necessary for the WTP and AC to configure their MTU based on 6483 the capabilities of the path. See Section 3.5 for more information. 6485 The CAPWAP protocol supports Explicit Congestion Notification (ECN) 6486 through mode of operation named "limited functionality option", 6487 detailed in [RFC3168]. Future versions of the CAPWAP protocol should 6488 consider supporting the "full functionality option", which may 6489 require some explicit signalling within the CAPWAP control protocol. 6491 15. IANA Considerations 6493 This section details the actions to be taken by IANA during the 6494 publication of the specification. There are numerous registries that 6495 need to be created, and the contents, document action (see [RFC5226], 6496 and registry format are all included below. Note that in cases where 6497 bit fields are referred to, the bit numbering is left to right, where 6498 the leftmost bit is labelled as bit zero (0). 6500 For registration requests where an Expert Review is required, a 6501 Designated Expert should be consulted, which is appointed by the 6502 responsible IESG area director. The intention is that any allocation 6503 will be accompanied by a published RFC, but given that other SDOs may 6504 want to create standards built on top of CAPWAP, a document the 6505 Designated Expert can review is also acceptable. IANA should allow 6506 for allocation of values prior to documents being approved for 6507 publication, so the Designated Expert can approve allocations once it 6508 seems clear that publication will occur. The Designated expert will 6509 post a request to the CAPWAP WG mailing list (or a successor 6510 designated by the Area Director) for comment and review. Before a 6511 period of 30 days has passed, the Designated Expert will either 6512 approve or deny the registration request and publish a notice of the 6513 decision to the CAPWAP WG mailing list or its successor, as well as 6514 informing IANA. A denial notice must be justified by an explanation, 6515 and in the cases where it is possible, concrete suggestions on how 6516 the request can be modified so as to become acceptable should be 6517 provided. 6519 15.1. IPv4 Multicast Address 6521 This document requires a new IPv4 multicast address called 6522 "capwap-ac" from the Local Network Control Block IPv4 multicast 6523 address registry [to be removed upon publication 6524 http://www.iana.org/assignments/multicast-addresses]. The new 6525 multicast address is to replace the text xx.xx.xx.xx in Section 3.3. 6527 15.2. IPv6 Multicast Address 6529 This document requires a new organization local multicast address 6530 called the "All ACs multicast address" from the Variable Scope IPv6 6531 multicast address registry [to be removed upon publication 6532 http://www.iana.org/assignments/ipv6-multicast-addresses]. The new 6533 multicast address is to be inserted in Section 3.3. 6535 15.3. UDP Port 6537 This document requires a two UDP Ports organization local multicast 6538 address from the registered port numbers registry [to be removed upon 6539 publication http://www.iana.org/assignments/port-numbers]. The new 6540 UDP Ports numbers have already been assigned and can be found in 6541 Section 3.1. The following values are being registered: 6543 Keyword Decimal Description References 6544 ------- ------- ----------- ---------- 6545 capwap-control 5246/udp CAPWAP Control Protocol This Document 6546 capwap-data 5247/udp CAPWAP Data Protocol This Document 6548 15.4. CAPWAP Message Types 6550 The Message Type field in the CAPWAP header (see Section 4.5.1.1) is 6551 used to identify the operation performed by the message. There are 6552 multiple namespaces, which is identified via the first three octets 6553 of the field containing the IANA Enterprise Number [RFC5226]. 6555 IANA will create and maintain the CAPWAP Message Types registry for 6556 all message types whose Enterprise Number is set to zero (0). The 6557 namespace is 32 bits (0-4294967295), where the value of zero (0) is 6558 reserved and must not be assigned. The values one (1) through 26 are 6559 allocated in this specification, and can be found in Section 4.5.1.1. 6560 Any new assignments of a CAPWAP Message Type, whose Enterprise Number 6561 is set to zero (0) requires a Expert Review. The format of the 6562 registry to be maintained by IANA has the following format: 6564 CAPWAP Control Message Message Type Reference 6565 Value 6567 15.5. CAPWAP Header Flags 6569 The Flags field in the CAPWAP header (see Section 4.3) is 9 bits in 6570 length and is used to identify any special treatment related to the 6571 message. This specification defines bits zero (0) through five (5), 6572 while bits six (6) through eight (8) are reserved. There are 6573 currently three unused, reserved bits which are managed by IANA and 6574 whose assignment requires a Expert Review. IANA will create the 6575 CAPWAP Header Flags registry, whose format is: 6577 Flag Field Name Bit Position Reference 6579 15.6. CAPWAP Control Message Flags 6581 The Flags field in the CAPWAP Control Message header (see 6582 Section 4.5.1.4) is used to identify any special treatment related to 6583 the control message. There are currently eight (8) unused, reserved 6584 bits. These bits whose assignment is managed by IANA and requires a 6585 Expert Review. IANA will create the CAPWAP Control Message Flags 6586 registry, whose format is: 6588 Flag Field Name Bit Position Reference 6590 15.7. CAPWAP Message Element Type 6592 The Type field in the CAPWAP Message Element header (see Section 4.6) 6593 is used to identify the data being transported. The namespace is 16 6594 bits (0-65535), where the value of zero (0) is reserved and must not 6595 be assigned. The values one (1) through 52 are allocated in this 6596 specification, and can be found in Section 4.5.1.1. 6598 The 16 bit namespace is further divided into blocks of addresses that 6599 are reserved for specific CAPWAP wireless bindings. The following 6600 blocks are reserved: 6602 CAPWAP Protocol Message Elements 1 - 1023 6603 IEEE 802.11 Message Elements 1024 - 2047 6604 EPCGlobal Message Elements 3072 - 4095 6606 This namespace is managed by IANA and assignments require a Expert 6607 Review. IANA will create the CAPWAP Message Element Type registry, 6608 whose format is: 6610 CAPWAP Message Element Type Value Reference 6612 15.8. Wireless Binding Identifiers 6614 The Wireless Binding Identifier (WBID) field in the CAPWAP header 6615 (see Section 4.3) is used to identify the wireless technology 6616 associated with the packet. This specification allocates the values 6617 one (1) and three (3). Due to the limited address space available, a 6618 new WBID request requires Expert Review. IANA will create the CAPWAP 6619 Wireless Binding Identifier registry, whose format is: 6621 CAPWAP Wireless Binding Identifier Type Value Reference 6623 15.9. AC Security Types 6625 The Security field in the AC Descriptor message element (see 6626 Section 4.6.1) is 8 bits in length and used to identify the 6627 authentication methods available on the AC. This specification 6628 defines bits five (5) and six (6), while bits zero (0) through four 6629 (4) as well as bit seven (7) are reserved and unused. These reserved 6630 bits are managed by IANA and assignment requires a Standards Action. 6631 IANA will create the AC Security Types registry, whose format is: 6633 AC Security Type Bit Position Reference 6635 15.10. AC DTLS Policy 6637 The DTLS Policy field in the AC Descriptor message element (see 6638 Section 4.6.1) is 8 bits in length and used to identify whether the 6639 CAPWAP Data Channel is to be secured. This specification defines 6640 bits five (5) and six (6), while bits zero (0) through four (4) as 6641 well as bit seven (7) are reserved and unused. These reserved bits 6642 are managed by IANA and assignment requires a Standards Action. IANA 6643 will create the AC DTLS Policy registry, whose format is: 6645 AC DTLS Policy Bit Position Reference 6647 15.11. AC Information Type 6649 The Information Type field in the AC Descriptor message element (see 6650 Section 4.6.1) is used to represent information about the AC. The 6651 namespace is 16 bits (0-65535), where the value of zero (0) is 6652 reserved and must not be assigned. This field, combined with the AC 6653 Information Vendor ID, allows vendors to use a private namespace. 6654 This specification defines the AC Information Type namespace when the 6655 AC Information Vendor ID is set to zero (0), for which the values 6656 four (4) and five (5) are allocated in this specification, and can be 6657 found in Section 4.6.1. This namespace is managed by IANA and 6658 assignments require a Expert Review. IANA will create the AC 6659 Information Type registry, whose format is: 6661 AC Information Type Type Value Reference 6663 15.12. CAPWAP Transport Protocol Types 6665 The Transport field in the CAPWAP Transport Protocol message element 6666 (see Section 4.6.14) is used to identify the transport to use for the 6667 CAPWAP Data Channel. The namespace is 8 bits (0-255), where the 6668 value of zero (0) is reserved and must not be assigned. The values 6669 one (1) and two (2) are allocated in this specification, and can be 6670 found in Section 4.6.14. This namespace is managed by IANA and 6671 assignments require a Expert Review. IANA will create the CAPWAP 6672 Transport Protocol Types registry, whose format is: 6674 CAPWAP Transport Protocol Type Type Value Reference 6676 15.13. Data Transfer Type 6678 The Data Type field in the Data Transfer Data message element (see 6679 Section 4.6.15) and Image Data message element (see Section 4.6.25) 6680 is used to provide information about the data being carried. The 6681 namespace is 8 bits (0-255), where the value of zero (0) is reserved 6682 and must not be assigned. The values one (1), two (2) and five (5) 6683 are allocated in this specification, and can be found in 6684 Section 4.6.15. This namespace is managed by IANA and assignments 6685 require a Expert Review. IANA will create the Data Transfer Type 6686 registry, whose format is: 6688 Data Transfer Type Type Value Reference 6690 15.14. Data Transfer Mode 6692 The Data Mode field in the Data Transfer Data message element (see 6693 Section 4.6.15) and Data Transfer Mode message element (see 6694 Section 15.14) is used to provide information about the data being 6695 carried. The namespace is 8 bits (0-255), where the value of zero 6696 (0) is reserved and must not be assigned. The values one (1) and two 6697 (2) are allocated in this specification, and can be found in 6698 Section 15.14. This namespace is managed by IANA and assignments 6699 require a Expert Review. IANA will create the Data Transfer Mode 6700 registry, whose format is: 6702 Data Transfer Mode Type Value Reference 6704 15.15. Discovery Types 6706 The Discovery Type field in the Discovery Type message element (see 6707 Section 4.6.21) is used by the WTP to indicate to the AC how it was 6708 discovered. The namespace is 8 bits (0-255). The values zero (0) 6709 through four (4) are allocated in this specification, and can be 6710 found in Section 4.6.21. This namespace is managed by IANA and 6711 assignments require a Expert Review. IANA will create the Discovery 6712 Types registry, whose format is: 6714 Discovery Types Type Value Reference 6716 15.16. Radio Admin State 6718 The Radio Admin field in the Radio Administrative State message 6719 element (see Section 4.6.32) is used by the WTP to represent the 6720 state of its radios. The namespace is 8 bits (0-255), where the 6721 value of zero (0) is reserved and must not be assigned. The values 6722 one (1) and two (2) are allocated in this specification, and can be 6723 found in Section 4.6.32. This namespace is managed by IANA and 6724 assignments require a Expert Review. IANA will create the Radio 6725 Admin State registry, whose format is: 6727 Radio Admin State Type Value Reference 6729 15.17. Radio Operational State 6731 The State field in the Radio Operational State message element (see 6732 Section 4.6.33) is used by the WTP to represent the operational state 6733 of its radios. The namespace is 8 bits (0-255), where the value of 6734 zero (0) is reserved and must not be assigned. The values one (1) 6735 and two (2) are allocated in this specification, and can be found in 6736 Section 4.6.33. This namespace is managed by IANA and assignments 6737 require a Expert Review. IANA will create the Radio Operational 6738 State registry, whose format is: 6740 Radio Operational State Type Value Reference 6742 15.18. Radio Failure Causes 6744 The Cause field in the Radio Operational State message element (see 6745 Section 4.6.33) is used by the WTP to represent the reason why a 6746 radio may have failed. The namespace is 8 bits (0-255), where the 6747 value of zero (0) through three (3) are allocated in this 6748 specification, and can be found in Section 4.6.33. This namespace is 6749 managed by IANA and assignments require a Expert Review. IANA will 6750 create the Radio Failure Causes registry, whose format is: 6752 Radio Failure Causes Type Value Reference 6754 15.19. Result Code 6756 The Result Code field in the Result Code message element (see 6757 Section 4.6.34) is used to indicate the success, or failure, of a 6758 CAPWAP control message. The namespace is 32 bits (0-4294967295), 6759 where the value of zero (0) through 22 are allocated in this 6760 specification, and can be found in Section 4.6.34. This namespace is 6761 managed by IANA and assignments require a Expert Review. IANA will 6762 create the Result Code registry, whose format is: 6764 Result Code Type Value Reference 6766 15.20. Returned Message Element Reason 6768 The Reason field in the Returned Message Element message element (see 6769 Section 4.6.35) is used to indicate the reason why a message element 6770 was not processed successfully. The namespace is 8 bits (0-255), 6771 where the value of zero (0) is reserved and must not be assigned. 6772 The values one (1) through four (4) are allocated in this 6773 specification, and can be found in Section 4.6.35. This namespace is 6774 managed by IANA and assignments require a Expert Review. IANA will 6775 create the Returned Message Element Reason registry, whose format is: 6777 Returned Message Element Reason Type Value Reference 6779 15.21. WTP Board Data Type 6781 The Board Data Type field in the WTP Board Data message element (see 6782 Section 4.6.39) is used to represent information about the WTP 6783 hardware. The namespace is 16 bits (0-65535). The WTP Board Data 6784 Type values zero (0) through four (4) are allocated in this 6785 specification, and can be found in Section 4.6.39. This namespace is 6786 managed by IANA and assignments require a Expert Review. IANA will 6787 create the WTP Board Data Type registry, whose format is: 6789 WTP Board Data Type Type Value Reference 6791 15.22. WTP Descriptor Type 6793 The Descriptor Type field in the WTP Descriptor message element (see 6794 Section 4.6.40) is used to represent information about the WTP 6795 software. The namespace is 16 bits (0-65535). This field, combined 6796 with the Descriptor Vendor ID, allows vendors to use a private 6797 namespace. This specification defines the WTP Descriptor Type 6798 namespace when the Descriptor Vendor ID is set to zero (0), for which 6799 the values zero (0) through three (3) are allocated in this 6800 specification, and can be found in Section 4.6.40. This namespace is 6801 managed by IANA and assignments require a Expert Review. IANA will 6802 create the WTP Board Data Type registry, whose format is: 6804 WTP Descriptor Type Type Value Reference 6806 15.23. WTP Fallback Mode 6808 The Mode field in the WTP Fallback message element (see 6809 Section 4.6.41) is used to indicate to the WTP the type of AC 6810 fallback mechanism it should employ. The namespace is 8 bits 6811 (0-255), where the value of zero (0) is reserved and must not be 6812 assigned. The values one (1) and two (2) are allocated in this 6813 specification, and can be found in Section 4.6.41. This namespace is 6814 managed by IANA and assignments require a Expert Review. IANA will 6815 create the WTP Fallback Mode registry, whose format is: 6817 WTP Fallback Mode Type Value Reference 6819 15.24. WTP Frame Tunnel Mode 6821 The Tunnel Type field in the WTP Frame Tunnel Mode message element 6822 (see Section 4.6.42) is 8 bits and is used to indicate the type of 6823 tunneling to use between the WTP and the AC. This specification 6824 defines bits four (4) through six (6), while bits zero (0) through 6825 four (4) as well as bit seven (7) are reserved and unused. These 6826 reserved bits are managed by IANA and assignment requires a Expert 6827 Review. IANA will create the AC DTLS Policy registry, whose format 6828 is: 6830 WTP Frame Tunnel Mode Bit Position Reference 6832 15.25. WTP MAC Type 6834 The MAC Type field in the WTP MAC Type message element (see 6835 Section 4.6.43) is used to indicate the type of MAC to use in 6836 tunneled frames between the WTP and the AC. The namespace is 8 bits 6837 (0-255), where the value of zero (0) through two (2) are allocated in 6838 this specification, and can be found in Section 4.6.43. This 6839 namespace is managed by IANA and assignments require a Expert Review. 6840 IANA will create the WTP MAC Type registry, whose format is: 6842 WTP MAC Type Type Value Reference 6844 15.26. WTP Radio Stats Failure Type 6846 The Last Failure Type field in the WTP Radio Statistics message 6847 element (see Section 4.6.45) is used to indicate the last WTP 6848 failure. The namespace is 8 bits (0-255), where the value of zero 6849 (0) through three (3) as well as the value 255 are allocated in this 6850 specification, and can be found in Section 4.6.45. This namespace is 6851 managed by IANA and assignments require a Expert Review. IANA will 6852 create the WTP Radio Stats Failure Type registry, whose format is: 6854 WTP Radio Stats Failure Type Type Value Reference 6856 15.27. WTP Reboot Stats Failure Type 6858 The Last Failure Type field in the WTP Reboot Statistics message 6859 element (see Section 4.6.46) is used to indicate the last reboot 6860 reason. The namespace is 8 bits (0-255), where the value of zero (0) 6861 through five (5) as well as the value 255 are allocated in this 6862 specification, and can be found in Section 4.6.46. This namespace is 6863 managed by IANA and assignments require a Expert Review. IANA will 6864 create the WTP Reboot Stats Failure Type registry, whose format is: 6866 WTP Reboot Stats Failure Type Type Value Reference 6868 16. Acknowledgments 6870 The following individuals are acknowledged for their contributions to 6871 this protocol specification: Puneet Agarwal, Abhijit Choudhury, Pasi 6872 Eronen, Saravanan Govindan, Peter Nilsson, David Perkins and Yong 6873 Zhang. 6875 Michael Vakulenko contributed text to describe how CAPWAP can be used 6876 over layer 3 (IP/UDP) networks. 6878 17. References 6880 17.1. Normative References 6882 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 6883 November 1990. 6885 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 6886 April 1992. 6888 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 6889 Specification, Implementation", RFC 1305, March 1992. 6891 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 6892 for IP version 6", RFC 1981, August 1996. 6894 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 6895 Requirement Levels", BCP 14, RFC 2119, March 1997. 6897 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 6898 (IPv6) Specification", RFC 2460, December 1998. 6900 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 6901 "Definition of the Differentiated Services Field (DS 6902 Field) in the IPv4 and IPv6 Headers", RFC 2474, 6903 December 1998. 6905 [RFC2598] Jacobson, V., Nichols, K., and K. Poduri, "An Expedited 6906 Forwarding PHB", RFC 2598, June 1999. 6908 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 6909 specifying the location of services (DNS SRV)", RFC 2782, 6910 February 2000. 6912 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 6913 of Explicit Congestion Notification (ECN) to IP", 6914 RFC 3168, September 2001. 6916 [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and 6917 Accounting (AAA) Transport Profile", RFC 3539, June 2003. 6919 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 6920 10646", STD 63, RFC 3629, November 2003. 6922 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 6923 G. Fairhurst, "The Lightweight User Datagram Protocol 6924 (UDP-Lite)", RFC 3828, July 2004. 6926 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 6927 Requirements for Security", BCP 106, RFC 4086, June 2005. 6929 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 6930 for Transport Layer Security (TLS)", RFC 4279, 6931 December 2005. 6933 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 6934 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 6936 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 6937 Security", RFC 4347, April 2006. 6939 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 6940 Discovery", RFC 4821, March 2007. 6942 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 6943 Errors at High Data Rates", RFC 4963, July 2007. 6945 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 6946 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 6947 May 2008. 6949 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 6950 Housley, R., and W. Polk, "Internet X.509 Public Key 6951 Infrastructure Certificate and Certificate Revocation List 6952 (CRL) Profile", RFC 5280, May 2008. 6954 [ISO.9834-1.1993] 6955 International Organization for Standardization, 6956 "Procedures for the operation of OSI registration 6957 authorities - part 1: general procedures", ISO Standard 6958 9834-1, 1993. 6960 [I-D.ietf-capwap-protocol-binding-ieee80211] 6961 Montemurro, M., Stanley, D., and P. Calhoun, "CAPWAP 6962 Protocol Binding for IEEE 802.11", 6963 draft-ietf-capwap-protocol-binding-ieee80211-10 (work in 6964 progress), September 2008. 6966 [I-D.ietf-capwap-dhc-ac-option] 6967 Calhoun, P., "CAPWAP Access Controller DHCP Option", 6968 draft-ietf-capwap-dhc-ac-option-01 (work in progress), 6969 March 2008. 6971 [FRAME-EXT] 6972 IEEE, "IEEE Standard 802.3as-2006", 2005. 6974 17.2. Informational References 6976 [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by 6977 an On-line Database", RFC 3232, January 2002. 6979 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 6980 RFC 3753, June 2004. 6982 [RFC4564] Govindan, S., Cheng, H., Yao, ZH., Zhou, WH., and L. Yang, 6983 "Objectives for Control and Provisioning of Wireless 6984 Access Points (CAPWAP)", RFC 4564, July 2006. 6986 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 6987 Authorization, and Accounting (AAA) Key Management", 6988 BCP 132, RFC 4962, July 2007. 6990 [I-D.ohara-capwap-lwapp] 6991 Calhoun, P., "Light Weight Access Point Protocol", 6992 draft-ohara-capwap-lwapp-04 (work in progress), 6993 March 2007. 6995 [I-D.narasimhan-ietf-slapp] 6996 Narasimhan, P., "SLAPP : Secure Light Access Point 6997 Protocol", draft-narasimhan-ietf-slapp-01 (work in 6998 progress), March 2006. 7000 [DTLS-DESIGN] 7001 Modadugu et al, N., "The Design and Implementation of 7002 Datagram TLS", Feb 2004. 7004 [EUI-48] IEEE, "Guidelines for use of a 48-bit Extended Unique 7005 Identifier", Dec 2005. 7007 [EUI-64] IEEE, "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) 7008 REGISTRATION AUTHORITY". 7010 [EPCGlobal] 7011 "See http://www.epcglobalinc.org/home". 7013 [PacketCable] 7014 "PacketCable Security Specification PKT-SP-SEC-I12- 7015 050812", August 2005, . 7017 [CableLabs] 7018 "OpenCable System Security Specification OC-SP-SEC-I07- 7019 061031", October 2006, . 7021 [WiMAX] "WiMAX Forum X.509 Device Certificate Profile Approved 7022 Specification V1.0.1", April 2008, . 7024 Editors' Addresses 7026 Pat R. Calhoun 7027 Cisco Systems, Inc. 7028 170 West Tasman Drive 7029 San Jose, CA 95134 7031 Phone: +1 408-902-3240 7032 Email: pcalhoun@cisco.com 7034 Michael P. Montemurro 7035 Research In Motion 7036 5090 Commerce Blvd 7037 Mississauga, ON L4W 5M4 7038 Canada 7040 Phone: +1 905-629-4746 x4999 7041 Email: mmontemurro@rim.com 7043 Dorothy Stanley 7044 Aruba Networks 7045 1322 Crossman Ave 7046 Sunnyvale, CA 94089 7048 Phone: +1 630-363-1389 7049 Email: dstanley@arubanetworks.com 7051 Full Copyright Statement 7053 Copyright (C) The IETF Trust (2008). 7055 This document is subject to the rights, licenses and restrictions 7056 contained in BCP 78, and except as set forth therein, the authors 7057 retain all their rights. 7059 This document and the information contained herein are provided on an 7060 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 7061 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 7062 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 7063 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 7064 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 7065 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 7067 Intellectual Property 7069 The IETF takes no position regarding the validity or scope of any 7070 Intellectual Property Rights or other rights that might be claimed to 7071 pertain to the implementation or use of the technology described in 7072 this document or the extent to which any license under such rights 7073 might or might not be available; nor does it represent that it has 7074 made any independent effort to identify any such rights. Information 7075 on the procedures with respect to rights in RFC documents can be 7076 found in BCP 78 and BCP 79. 7078 Copies of IPR disclosures made to the IETF Secretariat and any 7079 assurances of licenses to be made available, or the result of an 7080 attempt made to obtain a general license or permission for the use of 7081 such proprietary rights by implementers or users of this 7082 specification can be obtained from the IETF on-line IPR repository at 7083 http://www.ietf.org/ipr. 7085 The IETF invites any interested party to bring to its attention any 7086 copyrights, patents or patent applications, or other proprietary 7087 rights that may cover technology that may be required to implement 7088 this standard. Please address the information to the IETF at 7089 ietf-ipr@ietf.org.