idnits 2.17.1 draft-ietf-capwap-protocol-specification-12.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 6821. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 6832. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 6839. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 6845. 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. 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 (September 9, 2008) is 5708 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) ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) == Outdated reference: A later version (-12) exists of draft-ietf-capwap-protocol-binding-ieee80211-07 == 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: 9 errors (**), 0 flaws (~~), 4 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: March 13, 2009 Research In Motion 6 D. Stanley, Editor 7 Aruba Networks 8 September 9, 2008 10 CAPWAP Protocol Specification 11 draft-ietf-capwap-protocol-specification-12 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 March 13, 2009. 38 Abstract 40 This specification defines the Control And Provisioning of Wireless 41 Access Points (CAPWAP) Protocol. The CAPWAP protocol meets the 42 Objectives for Control and Provisioning of Wireless Access Points 43 (CAPWAP). The CAPWAP protocol is designed to be flexible, allowing 44 it to be used for a variety of wireless technologies. This document 45 describes the base CAPWAP protocol, while separate binding extensions 46 will enable its use with additional wireless technologies. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 51 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . 8 52 1.2. Conventions used in this document . . . . . . . . . . . 9 53 1.3. Contributing Authors . . . . . . . . . . . . . . . . . . 9 54 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . 10 55 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12 56 2.1. Wireless Binding Definition . . . . . . . . . . . . . . 13 57 2.2. CAPWAP Session Establishment Overview . . . . . . . . . 14 58 2.3. CAPWAP State Machine Definition . . . . . . . . . . . . 16 59 2.3.1. CAPWAP Protocol State Transitions . . . . . . . . . . 18 60 2.3.2. CAPWAP/DTLS Interface . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 41 69 3.3. AC Discovery . . . . . . . . . . . . . . . . . . . . . . 42 70 3.4. Fragmentation/Reassembly . . . . . . . . . . . . . . . . 43 71 3.5. MTU Discovery . . . . . . . . . . . . . . . . . . . . . 43 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. Control Message Quality of Service . . . . . . . . . 57 83 4.5.3. Retransmissions . . . . . . . . . . . . . . . . . . . 57 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 . . . . . . . . . . . . . . . . . . . . 64 88 4.6.4. AC Name . . . . . . . . . . . . . . . . . . . . . . . 65 89 4.6.5. AC Name with Index . . . . . . . . . . . . . . . . . 65 90 4.6.6. AC Timestamp . . . . . . . . . . . . . . . . . . . . 66 91 4.6.7. Add MAC ACL Entry . . . . . . . . . . . . . . . . . . 66 92 4.6.8. Add Station . . . . . . . . . . . . . . . . . . . . . 67 93 4.6.9. CAPWAP Control IPv4 Address . . . . . . . . . . . . . 68 94 4.6.10. CAPWAP Control IPv6 Address . . . . . . . . . . . . . 68 95 4.6.11. CAPWAP Local IPv4 Address . . . . . . . . . . . . . . 69 96 4.6.12. CAPWAP Local IPv6 Address . . . . . . . . . . . . . . 69 97 4.6.13. CAPWAP Timers . . . . . . . . . . . . . . . . . . . . 70 98 4.6.14. CAPWAP Transport Protocol . . . . . . . . . . . . . . 70 99 4.6.15. Data Transfer Data . . . . . . . . . . . . . . . . . 71 100 4.6.16. Data Transfer Mode . . . . . . . . . . . . . . . . . 72 101 4.6.17. Decryption Error Report . . . . . . . . . . . . . . . 73 102 4.6.18. Decryption Error Report Period . . . . . . . . . . . 73 103 4.6.19. Delete MAC ACL Entry . . . . . . . . . . . . . . . . 74 104 4.6.20. Delete Station . . . . . . . . . . . . . . . . . . . 74 105 4.6.21. Discovery Type . . . . . . . . . . . . . . . . . . . 75 106 4.6.22. Duplicate IPv4 Address . . . . . . . . . . . . . . . 76 107 4.6.23. Duplicate IPv6 Address . . . . . . . . . . . . . . . 77 108 4.6.24. Idle Timeout . . . . . . . . . . . . . . . . . . . . 77 109 4.6.25. Image Data . . . . . . . . . . . . . . . . . . . . . 78 110 4.6.26. Image Identifier . . . . . . . . . . . . . . . . . . 79 111 4.6.27. Image Information . . . . . . . . . . . . . . . . . . 79 112 4.6.28. Initiate Download . . . . . . . . . . . . . . . . . . 80 113 4.6.29. Location Data . . . . . . . . . . . . . . . . . . . . 80 114 4.6.30. Maximum Message Length . . . . . . . . . . . . . . . 81 115 4.6.31. MTU Discovery Padding . . . . . . . . . . . . . . . . 81 116 4.6.32. Radio Administrative State . . . . . . . . . . . . . 81 117 4.6.33. Radio Operational State . . . . . . . . . . . . . . . 82 118 4.6.34. Result Code . . . . . . . . . . . . . . . . . . . . . 83 119 4.6.35. Returned Message Element . . . . . . . . . . . . . . 85 120 4.6.36. Session ID . . . . . . . . . . . . . . . . . . . . . 86 121 4.6.37. Statistics Timer . . . . . . . . . . . . . . . . . . 86 122 4.6.38. Vendor Specific Payload . . . . . . . . . . . . . . . 87 123 4.6.39. WTP Board Data . . . . . . . . . . . . . . . . . . . 87 124 4.6.40. WTP Descriptor . . . . . . . . . . . . . . . . . . . 89 125 4.6.41. WTP Fallback . . . . . . . . . . . . . . . . . . . . 91 126 4.6.42. WTP Frame Tunnel Mode . . . . . . . . . . . . . . . . 91 127 4.6.43. WTP MAC Type . . . . . . . . . . . . . . . . . . . . 92 128 4.6.44. WTP Name . . . . . . . . . . . . . . . . . . . . . . 93 129 4.6.45. WTP Radio Statistics . . . . . . . . . . . . . . . . 93 130 4.6.46. WTP Reboot Statistics . . . . . . . . . . . . . . . . 95 131 4.6.47. WTP Static IP Address Information . . . . . . . . . . 96 132 4.7. CAPWAP Protocol Timers . . . . . . . . . . . . . . . . . 97 133 4.7.1. ChangeStatePendingTimer . . . . . . . . . . . . . . . 97 134 4.7.2. DataChannelKeepAlive . . . . . . . . . . . . . . . . 97 135 4.7.3. DataChannelDeadInterval . . . . . . . . . . . . . . . 98 136 4.7.4. DataCheckTimer . . . . . . . . . . . . . . . . . . . 98 137 4.7.5. DiscoveryInterval . . . . . . . . . . . . . . . . . . 98 138 4.7.6. DTLSSessionDelete . . . . . . . . . . . . . . . . . . 98 139 4.7.7. EchoInterval . . . . . . . . . . . . . . . . . . . . 98 140 4.7.8. IdleTimeout . . . . . . . . . . . . . . . . . . . . . 98 141 4.7.9. ImageDataStartTimer . . . . . . . . . . . . . . . . . 98 142 4.7.10. MaxDiscoveryInterval . . . . . . . . . . . . . . . . 99 143 4.7.11. ReportInterval . . . . . . . . . . . . . . . . . . . 99 144 4.7.12. RetransmitInterval . . . . . . . . . . . . . . . . . 99 145 4.7.13. SilentInterval . . . . . . . . . . . . . . . . . . . 99 146 4.7.14. StatisticsTimer . . . . . . . . . . . . . . . . . . . 99 147 4.7.15. WaitDTLS . . . . . . . . . . . . . . . . . . . . . . 99 148 4.7.16. WaitJoin . . . . . . . . . . . . . . . . . . . . . . 100 149 4.8. CAPWAP Protocol Variables . . . . . . . . . . . . . . . 100 150 4.8.1. AdminState . . . . . . . . . . . . . . . . . . . . . 100 151 4.8.2. DiscoveryCount . . . . . . . . . . . . . . . . . . . 100 152 4.8.3. FailedDTLSAuthFailCount . . . . . . . . . . . . . . . 100 153 4.8.4. FailedDTLSSessionCount . . . . . . . . . . . . . . . 100 154 4.8.5. MaxDiscoveries . . . . . . . . . . . . . . . . . . . 100 155 4.8.6. MaxFailedDTLSSessionRetry . . . . . . . . . . . . . . 100 156 4.8.7. MaxRetransmit . . . . . . . . . . . . . . . . . . . . 101 157 4.8.8. RetransmitCount . . . . . . . . . . . . . . . . . . . 101 158 4.8.9. WTPFallBack . . . . . . . . . . . . . . . . . . . . . 101 159 4.9. WTP Saved Variables . . . . . . . . . . . . . . . . . . 101 160 4.9.1. AdminRebootCount . . . . . . . . . . . . . . . . . . 101 161 4.9.2. FrameEncapType . . . . . . . . . . . . . . . . . . . 101 162 4.9.3. LastRebootReason . . . . . . . . . . . . . . . . . . 101 163 4.9.4. MacType . . . . . . . . . . . . . . . . . . . . . . . 101 164 4.9.5. PreferredACs . . . . . . . . . . . . . . . . . . . . 102 165 4.9.6. RebootCount . . . . . . . . . . . . . . . . . . . . . 102 166 4.9.7. Static IP Address . . . . . . . . . . . . . . . . . . 102 167 4.9.8. WTPLinkFailureCount . . . . . . . . . . . . . . . . . 102 168 4.9.9. WTPLocation . . . . . . . . . . . . . . . . . . . . . 102 169 4.9.10. WTPName . . . . . . . . . . . . . . . . . . . . . . . 102 170 5. CAPWAP Discovery Operations . . . . . . . . . . . . . . . . . 103 171 5.1. Discovery Request Message . . . . . . . . . . . . . . . 103 172 5.2. Discovery Response Message . . . . . . . . . . . . . . . 104 173 5.3. Primary Discovery Request Message . . . . . . . . . . . 105 174 5.4. Primary Discovery Response . . . . . . . . . . . . . . . 106 175 6. CAPWAP Join Operations . . . . . . . . . . . . . . . . . . . 108 176 6.1. Join Request . . . . . . . . . . . . . . . . . . . . . . 108 177 6.2. Join Response . . . . . . . . . . . . . . . . . . . . . 109 178 7. Control Channel Management . . . . . . . . . . . . . . . . . 112 179 7.1. Echo Request . . . . . . . . . . . . . . . . . . . . . . 112 180 7.2. Echo Response . . . . . . . . . . . . . . . . . . . . . 112 182 8. WTP Configuration Management . . . . . . . . . . . . . . . . 114 183 8.1. Configuration Consistency . . . . . . . . . . . . . . . 114 184 8.1.1. Configuration Flexibility . . . . . . . . . . . . . . 115 185 8.2. Configuration Status Request . . . . . . . . . . . . . . 115 186 8.3. Configuration Status Response . . . . . . . . . . . . . 116 187 8.4. Configuration Update Request . . . . . . . . . . . . . . 117 188 8.5. Configuration Update Response . . . . . . . . . . . . . 118 189 8.6. Change State Event Request . . . . . . . . . . . . . . . 118 190 8.7. Change State Event Response . . . . . . . . . . . . . . 120 191 8.8. Clear Configuration Request . . . . . . . . . . . . . . 120 192 8.9. Clear Configuration Response . . . . . . . . . . . . . . 120 193 9. Device Management Operations . . . . . . . . . . . . . . . . 122 194 9.1. Firmware Management . . . . . . . . . . . . . . . . . . 122 195 9.1.1. Image Data Request . . . . . . . . . . . . . . . . . 126 196 9.1.2. Image Data Response . . . . . . . . . . . . . . . . . 127 197 9.2. Reset Request . . . . . . . . . . . . . . . . . . . . . 128 198 9.3. Reset Response . . . . . . . . . . . . . . . . . . . . . 129 199 9.4. WTP Event Request . . . . . . . . . . . . . . . . . . . 129 200 9.5. WTP Event Response . . . . . . . . . . . . . . . . . . . 130 201 9.6. Data Transfer . . . . . . . . . . . . . . . . . . . . . 130 202 9.6.1. Data Transfer Request . . . . . . . . . . . . . . . . 131 203 9.6.2. Data Transfer Response . . . . . . . . . . . . . . . 132 204 10. Station Session Management . . . . . . . . . . . . . . . . . 134 205 10.1. Station Configuration Request . . . . . . . . . . . . . 134 206 10.2. Station Configuration Response . . . . . . . . . . . . . 134 207 11. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 136 208 12. Security Considerations . . . . . . . . . . . . . . . . . . . 138 209 12.1. CAPWAP Security . . . . . . . . . . . . . . . . . . . . 138 210 12.1.1. Converting Protected Data into Unprotected Data . . . 139 211 12.1.2. Converting Unprotected Data into Protected Data 212 (Insertion) . . . . . . . . . . . . . . . . . . . . . 139 213 12.1.3. Deletion of Protected Records . . . . . . . . . . . . 139 214 12.1.4. Insertion of Unprotected Records . . . . . . . . . . 139 215 12.1.5. Use of MD5 . . . . . . . . . . . . . . . . . . . . . 139 216 12.2. Session ID Security . . . . . . . . . . . . . . . . . . 139 217 12.3. Discovery or DTLS Setup Attacks . . . . . . . . . . . . 140 218 12.4. Interference with a DTLS Session . . . . . . . . . . . . 141 219 12.5. CAPWAP Pre-Provisioning . . . . . . . . . . . . . . . . 141 220 12.6. Use of Preshared Keys in CAPWAP . . . . . . . . . . . . 142 221 12.7. Use of Certificates in CAPWAP . . . . . . . . . . . . . 143 222 12.8. AAA Security . . . . . . . . . . . . . . . . . . . . . . 144 223 13. Operational Considerations . . . . . . . . . . . . . . . . . 145 224 14. Transport Considerations . . . . . . . . . . . . . . . . . . 146 225 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 147 226 15.1. Multicast Address . . . . . . . . . . . . . . . . . . . 147 227 15.2. UDP Port . . . . . . . . . . . . . . . . . . . . . . . . 147 228 15.3. CAPWAP Message Types . . . . . . . . . . . . . . . . . . 148 229 15.4. CAPWAP Header Flags . . . . . . . . . . . . . . . . . . 148 230 15.5. CAPWAP Control Message Flags . . . . . . . . . . . . . . 148 231 15.6. CAPWAP Message Element Type . . . . . . . . . . . . . . 148 232 15.7. Wireless Binding Identifiers . . . . . . . . . . . . . . 149 233 15.8. AC Security Types . . . . . . . . . . . . . . . . . . . 149 234 15.9. AC DTLS Policy . . . . . . . . . . . . . . . . . . . . . 149 235 15.10. AC Information Type . . . . . . . . . . . . . . . . . . 149 236 15.11. CAPWAP Transport Protocol Types . . . . . . . . . . . . 150 237 15.12. Data Transfer Type . . . . . . . . . . . . . . . . . . . 150 238 15.13. Data Transfer Mode . . . . . . . . . . . . . . . . . . . 150 239 15.14. Discovery Types . . . . . . . . . . . . . . . . . . . . 151 240 15.15. Radio Admin State . . . . . . . . . . . . . . . . . . . 151 241 15.16. Radio Operational State . . . . . . . . . . . . . . . . 151 242 15.17. Radio Failure Causes . . . . . . . . . . . . . . . . . . 151 243 15.18. Result Code . . . . . . . . . . . . . . . . . . . . . . 152 244 15.19. Returned Message Element Reason . . . . . . . . . . . . 152 245 15.20. WTP Board Data Type . . . . . . . . . . . . . . . . . . 152 246 15.21. WTP Descriptor Type . . . . . . . . . . . . . . . . . . 152 247 15.22. WTP Fallback Mode . . . . . . . . . . . . . . . . . . . 153 248 15.23. WTP Frame Tunnel Mode . . . . . . . . . . . . . . . . . 153 249 15.24. WTP MAC Type . . . . . . . . . . . . . . . . . . . . . . 153 250 15.25. WTP Radio Stats Failure Type . . . . . . . . . . . . . . 154 251 15.26. WTP Reboot Stats Failure Type . . . . . . . . . . . . . 154 252 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 155 253 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 156 254 17.1. Normative References . . . . . . . . . . . . . . . . . . 156 255 17.2. Informational References . . . . . . . . . . . . . . . . 157 256 Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 159 257 Intellectual Property and Copyright Statements . . . . . . . . . 160 259 1. Introduction 261 This document describes the CAPWAP Protocol, a standard, 262 interoperable protocol which enables an Access Controller (AC) to 263 manage a collection of Wireless Termination Points (WTPs). The 264 CAPWAP protocol is defined to be independent of layer 2 technology, 265 and meets the Objectives for Control and Provisioning of Wireless 266 Access Points (CAPWAP) [RFC4564]. 268 The emergence of centralized IEEE 802.11 Wireless Local Area Network 269 (WLAN) architectures, in which simple IEEE 802.11 WTPs are managed by 270 an Access Controller (AC) suggested that a standards based, 271 interoperable protocol could radically simplify the deployment and 272 management of wireless networks. WTPs require a set of dynamic 273 management and control functions related to their primary task of 274 connecting the wireless and wired mediums. Traditional protocols for 275 managing WTPs are either manual static configuration via HTTP, 276 proprietary Layer 2 specific or non-existent (if the WTPs are self- 277 contained). An IEEE 802.11 binding is defined in 278 [I-D.ietf-capwap-protocol-binding-ieee80211] to support use of the 279 CAPWAP protocol with IEEE 802.11 WLAN networks. 281 CAPWAP assumes a network configuration consisting of multiple WTPs 282 communicating via the Internet Protocol (IP) to an AC. WTPs are 283 viewed as remote RF interfaces controlled by the AC. The CAPWAP 284 protocol supports two modes of operation: Split and Local MAC. In 285 Split MAC mode all L2 wireless data and management frames are 286 encapsulated via the CAPWAP protocol and exchanged between the AC and 287 the WTP. As shown in Figure 1, the wireless frames received from a 288 mobile device, which is referred to in this specification as a 289 Station (STA), are directly encapsulated by the WTP and forwarded to 290 the AC. 292 +-+ wireless frames +-+ 293 | |--------------------------------| | 294 | | +-+ | | 295 | |--------------| |---------------| | 296 | |wireless PHY/ | | CAPWAP | | 297 | | MAC sublayer | | | | 298 +-+ +-+ +-+ 299 STA WTP AC 301 Figure 1: Representative CAPWAP Architecture for Split MAC 303 The Local MAC mode of operation allows for the data frames to be 304 either locally bridged, or tunneled as 802.3 frames. The latter 305 implies that the WTP performs the 802.11 Integration function. In 306 either case the L2 wireless management frames are processed locally 307 by the WTP, and then forwarded to the AC. Figure 2 shows the Local 308 MAC mode, in which a station transmits a wireless frame which is 309 encapsulated in an 802.3 frame and forwarded to the AC. 311 +-+wireless frames +-+ 802.3 frames +-+ 312 | |----------------| |--------------| | 313 | | | | | | 314 | |----------------| |--------------| | 315 | |wireless PHY/ | | CAPWAP | | 316 | | MAC sublayer | | | | 317 +-+ +-+ +-+ 318 STA WTP AC 320 Figure 2: Representative CAPWAP Architecture for Local MAC 322 Provisioning WTPs with security credentials, and managing which WTPs 323 are authorized to provide service are traditionally handled by 324 proprietary solutions. Allowing these functions to be performed from 325 a centralized AC in an interoperable fashion increases manageability 326 and allows network operators to more tightly control their wireless 327 network infrastructure. 329 1.1. Goals 331 The goals for the CAPWAP protocol are listed below: 333 1. To centralize the authentication and policy enforcement functions 334 for a wireless network. The AC may also provide centralized 335 bridging, forwarding, and encryption of user traffic. 336 Centralization of these functions will enable reduced cost and 337 higher efficiency by applying the capabilities of network 338 processing silicon to the wireless network, as in wired LANs. 340 2. To enable shifting of the higher level protocol processing from 341 the WTP. This leaves the time critical applications of wireless 342 control and access in the WTP, making efficient use of the 343 computing power available in WTPs which are the subject to severe 344 cost pressure. 346 3. To provide an extensible protocol that is not bound to a specific 347 wireless technology. Extensibility is provided via a generic 348 encapsulation and transport mechanism, enabling the CAPWAP 349 protocol to be applied to many access point types in the future, 350 via a specific wireless binding. 352 The CAPWAP protocol concerns itself solely with the interface between 353 the WTP and the AC. Inter-AC and station-to AC-communication are 354 strictly outside the scope of this document. 356 1.2. Conventions used in this document 358 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 359 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 360 document are to be interpreted as described in RFC 2119 [RFC2119]. 362 1.3. Contributing Authors 364 This section lists and acknowledges the authors of significant text 365 and concepts included in this specification. 367 The CAPWAP Working Group selected the Lightweight Access Point 368 Protocol (LWAPP) [I-D.ohara-capwap-lwapp] to be used as the basis of 369 the CAPWAP protocol specification. The following people are authors 370 of the LWAPP document: 372 Bob O'Hara 373 Email: bob.ohara@computer.org 375 Pat Calhoun, Cisco Systems, Inc. 376 170 West Tasman Drive, San Jose, CA 95134 377 Phone: +1 408-902-3240, Email: pcalhoun@cisco.com 379 Rohit Suri, Cisco Systems, Inc. 380 170 West Tasman Drive, San Jose, CA 95134 381 Phone: +1 408-853-5548, Email: rsuri@cisco.com 383 Nancy Cam Winget, Cisco Systems, Inc. 384 170 West Tasman Drive, San Jose, CA 95134 385 Phone: +1 408-853-0532, Email: ncamwing@cisco.com 387 Scott Kelly, Aruba Networks 388 1322 Crossman Ave, Sunnyvale, CA 94089 389 Phone: +1 408-754-8408, Email: skelly@arubanetworks.com 391 Michael Glenn Williams, Nokia, Inc. 392 313 Fairchild Drive, Mountain View, CA 94043 393 Phone: +1 650-714-7758, Email: Michael.G.Williams@Nokia.com 395 Sue Hares, Green Hills Software 396 825 Victors Way, Suite 100, Ann Arbor, MI 48108 397 Phone: +1 734 222 1610, Email: shares@ndzh.com 399 Datagram Transport Layer Security (DTLS) [RFC4347] is used as the 400 security solution for the CAPWAP protocol. The following people are 401 authors of significant DTLS-related text included in this document: 403 Scott Kelly, Aruba Networks 404 1322 Crossman Ave, Sunnyvale, CA 94089 405 Phone: +1 408-754-8408, Email: skelly@arubanetworks.com 407 Eric Rescorla, Network Resonance 408 2483 El Camino Real, #212,Palo Alto CA, 94303 409 Email: ekr@networkresonance.com 411 The concept of using DTLS to secure the CAPWAP protocol was part of 412 the Secure Light Access Point Protocol (SLAPP) proposal 413 [I-D.narasimhan-ietf-slapp]. The following people are authors of the 414 SLAPP proposal: 416 Partha Narasimhan, Aruba Networks 417 1322 Crossman Ave, Sunnyvale, CA 94089 418 Phone: +1 408-480-4716, Email: partha@arubanetworks.com 420 Dan Harkins, Tropos Networks 421 555 Del Rey Avenue, Sunnyvale, CA, 95085 422 Phone: +1 408 470 7372, Email: dharkins@tropos.com 424 Subbu Ponnuswamy, Aruba Networks 425 1322 Crossman Ave, Sunnyvale, CA 94089 426 Phone: +1 408-754-1213, Email: subbu@arubanetworks.com 428 The following individuals contributed significant security related 429 text to the draft: 431 T. Charles Clancy, Laboratory for Telecommunications Sciences, 432 8080 Greenmead Drive, College Park, MD 20740 433 Phone: +1 240-373-5069, Email: clancy@ltsnet.net 435 Scott Kelly, Aruba Networks 436 1322 Crossman Ave, Sunnyvale, CA 94089 437 Phone: +1 408-754-8408, Email: skelly@arubanetworks.com 439 1.4. Terminology 441 Access Controller (AC): The network entity that provides WTP access 442 to the network infrastructure in the data plane, control plane, 443 management plane, or a combination therein. 445 CAPWAP Control Channel: A bi-directional flow defined by the AC IP 446 Address, WTP IP Address, AC control port, WTP control port and the 447 transport-layer protocol (UDP or UDP-Lite) over which CAPWAP control 448 packets are sent and received. 450 CAPWAP Data Channel: A bi-directional flow defined by the AC IP 451 Address, WTP IP Address, AC data port, WTP data port, and the 452 transport-layer protocol (UDP or UDP-Lite) over which CAPWAP data 453 packets are sent and received. 455 Station (STA): A device that contains an interface to a wireless 456 medium (WM). 458 Wireless Termination Point (WTP): The physical or network entity that 459 contains an RF antenna and wireless PHY to transmit and receive 460 station traffic for wireless access networks. 462 This document uses additional terminology defined in [RFC3753]. 464 2. Protocol Overview 466 The CAPWAP protocol is a generic protocol defining AC and WTP control 467 and data plane communication via a CAPWAP protocol transport 468 mechanism. CAPWAP control messages, and optionally CAPWAP data 469 messages, are secured using Datagram Transport Layer Security (DTLS) 470 [RFC4346]. DTLS is a standards-track IETF protocol based upon TLS. 471 The underlying security-related protocol mechanisms of TLS have been 472 successfully deployed for many years. 474 The CAPWAP protocol Transport layer carries two types of payload, 475 CAPWAP Data messages and CAPWAP Control messages. CAPWAP Data 476 messages encapsulate forwarded wireless frames. CAPWAP protocol 477 Control messages are management messages exchanged between a WTP and 478 an AC. The CAPWAP Data and Control packets are sent over separate 479 UDP ports. Since both data and control packets can exceed the 480 Maximum Transmission Unit (MTU) length, the payload of a CAPWAP data 481 or control message can be fragmented. The fragmentation behavior is 482 defined in Section 3. 484 The CAPWAP Protocol begins with a discovery phase. The WTPs send a 485 Discovery Request message, causing any Access Controller (AC) 486 receiving the message to respond with a Discovery Response message. 487 From the Discovery Response messages received, a WTP selects an AC 488 with which to establish a secure DTLS session. In order to establish 489 the secure DTLS connection, the WTP will need some amount of pre- 490 provisioning, which is specified in Section 12.5. CAPWAP protocol 491 messages will be fragmented to the maximum length discovered to be 492 supported by the network. 494 Once the WTP and the AC have completed DTLS session establishment, a 495 configuration exchange occurs in which both devices agree on version 496 information. During this exchange the WTP may receive provisioning 497 settings. The WTP is then enabled for operation. 499 When the WTP and AC have completed the version and provision exchange 500 and the WTP is enabled, the CAPWAP protocol is used to encapsulate 501 the wireless data frames sent between the WTP and AC. The CAPWAP 502 protocol will fragment the L2 frames if the size of the encapsulated 503 wireless user data (Data) or protocol control (Management) frames 504 causes the resulting CAPWAP protocol packet to exceed the MTU 505 supported between the WTP and AC. Fragmented CAPWAP packets are 506 reassembled to reconstitute the original encapsulated payload. MTU 507 Discovery and Fragmentation are described in Section 3. 509 The CAPWAP protocol provides for the delivery of commands from the AC 510 to the WTP for the management of stations that are communicating with 511 the WTP. This may include the creation of local data structures in 512 the WTP for the stations and the collection of statistical 513 information about the communication between the WTP and the stations. 514 The CAPWAP protocol provides a mechanism for the AC to obtain 515 statistical information collected by the WTP. 517 The CAPWAP protocol provides for a keep alive feature that preserves 518 the communication channel between the WTP and AC. If the AC fails to 519 appear alive, the WTP will try to discover a new AC. 521 2.1. Wireless Binding Definition 523 The CAPWAP protocol is independent of a specific WTP radio 524 technology, as well its associated wireless link layer protocol. 525 Elements of the CAPWAP protocol are designed to accommodate the 526 specific needs of each wireless technology in a standard way. 527 Implementation of the CAPWAP protocol for a particular wireless 528 technology MUST follow the binding requirements defined for that 529 technology. 531 When defining a binding for wireless technologies, the authors MUST 532 include any necessary definitions for technology-specific messages 533 and all technology-specific message elements for those messages. At 534 a minimum, a binding MUST provide: 536 1. The definition for a binding-specific Statistics message element, 537 carried in the WTP Event Request message 539 2. A message element carried in the Station Configuration Request 540 message to configure station information on the WTP 542 3. A WTP Radio Information message element carried in the Discovery, 543 Primary Discovery and Join Request and Response messages, 544 indicating the binding specific radio types supported at the WTP 545 and AC. 547 If technology specific message elements are required for any of the 548 existing CAPWAP messages defined in this specification, they MUST 549 also be defined in the technology binding document. 551 The naming of binding-specific message elements MUST begin with the 552 name of the technology type, e.g., the binding for IEEE 802.11, 553 provided in [I-D.ietf-capwap-protocol-binding-ieee80211], begins with 554 "IEEE 802.11". 556 The CAPWAP binding concept MUST also be used in any future 557 specification that add functionality to either the base CAPWAP 558 protocol specification, or any published CAPWAP binding 559 specification. A separate WTP Radio Information message element MUST 560 be created to properly advertise support for the specification. This 561 mechanism allows for future protocol extensibility, while providing 562 the necessary capabilities advertisement, through the WTP Radio 563 Information message element, to ensure WTP/AC interoperability. 565 2.2. CAPWAP Session Establishment Overview 567 This section describes the session establishment process message 568 exchanges between a CAPWAP WTP and AC. The annotated ladder diagram 569 shows the AC on the right, the WTP on the left, and assumes the use 570 of certificates for DTLS authentication. The CAPWAP Protocol State 571 Machine is described in detail in Section 2.3. Note that DTLS allows 572 certain messages to be aggregated into a single frame, which is 573 denoted via an asterisk in Figure 3. 575 ============ ============ 576 WTP AC 577 ============ ============ 578 [----------- begin optional discovery ------------] 580 Discover Request 581 ------------------------------------> 582 Discover Response 583 <------------------------------------ 585 [----------- end optional discovery ------------] 587 (-- begin DTLS handshake --) 589 ClientHello 590 ------------------------------------> 591 HelloVerifyRequest (with cookie) 592 <------------------------------------ 594 ClientHello (with cookie) 595 ------------------------------------> 596 ServerHello, 597 Certificate, 598 ServerHelloDone* 599 <------------------------------------ 601 (-- WTP callout for AC authorization --) 603 Certificate (optional), 604 ClientKeyExchange, 605 CertificateVerify (optional), 606 ChangeCipherSpec, 607 Finished* 608 ------------------------------------> 610 (-- AC callout for WTP authorization --) 612 ChangeCipherSpec, 613 Finished* 614 <------------------------------------ 616 (-- DTLS session is established now --) 618 Join Request 619 ------------------------------------> 620 Join Response 621 <------------------------------------ 622 [-- Join State Complete --] 624 (-- assume image is up to date --) 626 Configuration Status Request 627 ------------------------------------> 628 Configuration Status Response 629 <------------------------------------ 630 [-- Configure State Complete --] 632 Change State Event Request 633 ------------------------------------> 634 Change State Event Response 635 <------------------------------------ 636 [-- Data Check State Complete --] 638 (-- enter RUN state --) 640 : 641 : 643 Echo Request 644 ------------------------------------> 645 Echo Response 646 <------------------------------------ 648 : 649 : 651 Event Request 652 ------------------------------------> 653 Event Response 654 <------------------------------------ 655 : 656 : 658 Figure 3: CAPWAP Control Protocol Exchange 660 At the end of the illustrated CAPWAP message exchange, the AC and WTP 661 are securely exchanging CAPWAP control messages. This illustration 662 is provided to clarify protocol operation, and does not include any 663 possible error conditions. Section 2.3 provides a detailed 664 description of the corresponding state machine. 666 2.3. CAPWAP State Machine Definition 668 The following state diagram represents the lifecycle of a WTP-AC 669 session. Use of DTLS by the CAPWAP protocol results in the 670 juxtaposition of two nominally separate yet tightly bound state 671 machines. The DTLS and CAPWAP state machines are coupled through an 672 API consisting of commands (see Section 2.3.2.1) and notifications 673 (see Section 2.3.2.2). Certain transitions in the DTLS state machine 674 are triggered by commands from the CAPWAP state machine, while 675 certain transitions in the CAPWAP state machine are triggered by 676 notifications from the DTLS state machine. 678 /-------------------------------------\ 679 | /-------------------------\| 680 | p| || 681 | q+----------+ r +------------+ || 682 | | Run |-->| Reset |-\|| 683 | +----------+ +------------+ ||| 684 n| o ^ ^ ^ s||| 685 +------------+--------/ | | ||| 686 | Data Check | /-------/ | ||| 687 +------------+<-------\ | | ||| 688 | | | ||| 689 /------------------+--------\ | ||| 690 f| m| h| j v k| ||| 691 +--------+ +-----------+ +--------------+||| 692 | Join |---->| Configure | | Image Data |||| 693 +--------+ n +-----------+ +--------------+||| 694 ^ |g i| l| ||| 695 | | \-------------------\ | ||| 696 | \--------------------------------------\| | ||| 697 \------------------------\ || | ||| 698 /--------------<----------------+---------------\ || | ||| 699 | /------------<----------------+-------------\ | || | ||| 700 | | 4 |d t| | vv v vvv 701 | | +----------------+ +--------------+ +-----------+ 702 | | | DTLS Setup | | DTLS Connect |-->| DTLS TD | 703 /-|-|---+----------------+ +--------------+ e +-----------+ 704 | | | |$ ^ ^ |5 ^6 ^ ^ |w 705 v v v | | | | \-------\ | | | 706 | | | | | | \---------\ | | /-----------/ | 707 | | | | | \--\ | | | | | 708 | | | | | | | | | | | 709 | | | v 3| 1 |% # v | |a |b v 710 | | \->+------+-->+------+ +-----------+ +--------+ 711 | | | Idle | | Disc | | Authorize | | Dead | 712 | | +------+<--+------+ +-----------+ +--------+ 713 | | ^ 0^ 2 |! 714 | | | | | +-------+ 715 *| |u | \---------+---| Start | 716 | | |@ | +-------+ 717 | \->+---------+<------/ 718 \--->| Sulking | 719 +---------+& 721 Figure 4: CAPWAP Integrated State Machine 723 The CAPWAP protocol state machine, depicted above, is used by both 724 the AC and the WTP. In cases where states are not shared (i.e. not 725 implemented in one or the other of the AC or WTP), this is explicitly 726 called out in the transition descriptions below. For every state 727 defined, only certain messages are permitted to be sent and received. 728 The CAPWAP control message definitions specify the state(s) in which 729 each message is valid. 731 Since the WTP only communicates with a single AC, it only has a 732 single instance of the CAPWAP state machine. The state machine works 733 differently on the AC since it communicates with many WTPs. The AC 734 uses the concept of three threads. Note that the term thread used 735 here does not necessarily imply that implementers must use threads, 736 but it is one possible way of implementing the AC's state machine. 738 Listener Thread: The AC's Listener thread handles inbound DTLS 739 session establishment requests, through the DTLSListen command. 740 Upon creation, the Listener thread starts in the DTLS Setup state. 741 Once a DTLS session has been validated, which occurs when the 742 state machine enters the "Authorize" state, the Listener thread 743 creates a WTP session specific Service thread and state context. 744 The state machine transitions in Figure 4 are represented by 745 numerals. It is necessary for the AC to protect itself against 746 various attacks that exist with non-authenticated frames. See 747 Section 12 for more information. 749 Discovery Thread: The AC's Discovery thread is responsible for 750 receiving, and responding to, Discovery Request messages. The 751 state machine transitions in Figure 4 are represented by numerals. 752 Note that the Discovery thread does not maintain any per-WTP 753 specific context information, and a single state context exists. 754 It is necessary for the AC to protect itself against various 755 attacks that exist with non-authenticated frames. See Section 12 756 for more information. 758 Service Thread: The AC's Service thread handles the per-WTP states, 759 and one such thread exists per-WTP connection. This thread is 760 created by the listener thread when the Authorize state is 761 reached. When created, the Service thread inherits a copy of the 762 state machine context from the Listener thread. When 763 communication with the WTP is complete, the Service thread is 764 terminated and all associated resources are released. The state 765 machine transitions in Figure 4 are represented by alphabetic and 766 punctuation characters. 768 2.3.1. CAPWAP Protocol State Transitions 770 This section describes the various state transitions, and the events 771 that cause them. This section does not discuss interactions between 772 DTLS- and CAPWAP-specific states. Those interactions, and DTLS- 773 specific states and transitions, are discussed in Section 2.3.2. 775 Start to Idle (0): This transition occurs once device initialization 776 is complete. 778 WTP: This state transition is used to start the WTP's CAPWAP 779 state machine. 781 AC: The AC creates the Discovery and Listener threads and starts 782 the CAPWAP state machine. 784 Idle to Discovery (1): This transition occurs to support the CAPWAP 785 discovery process . 787 WTP: The WTP enters the Discovery state prior to transmitting the 788 first Discovery Request message (see Section 5.1). Upon 789 entering this state, the WTP sets the DiscoveryInterval timer 790 (see Section 4.7). The WTP resets the DiscoveryCount counter 791 to zero (0) (see Section 4.8). The WTP also clears all 792 information from ACs it may have received during a previous 793 Discovery phase. 795 AC: This state transition is executed by the AC's Discovery 796 thread, and occurs when a Discovery Request message is 797 received. The AC SHOULD respond with a Discovery Response 798 message (see Section 5.2). 800 Discovery to Discovery (#): In the Discovery state, the WTP 801 determines which AC to connect to. 803 WTP: This transition occurs when the DiscoveryInterval timer 804 expires. If the WTP is configured with a list of ACs, it 805 transmits a Discovery Request message to every AC from which it 806 has not received a Discovery Response message. For every 807 transition to this event, the WTP increments the DiscoveryCount 808 counter. See Section 5.1 for more information on how the WTP 809 knows the ACs to which it should transmit the Discovery Request 810 messages. The WTP restarts the DiscoveryInterval timer 811 whenever it transmits Discovery Request messages. 813 AC: This is an invalid state transition for the AC. 815 Discovery to Idle (2): This transition occurs on the AC's Discovery 816 thread when the Discovery processing is complete. 818 WTP: This is an invalid state transition for the WTP. 820 AC: This state transition is executed by the AC's Discovery 821 thread when it has transmitted the Discovery Response, in 822 response to a Discovery Request. 824 Discovery to Sulking (!): This transition occurs on a WTP when AC 825 Discovery fails. 827 WTP: The WTP enters this state when the DiscoveryInterval timer 828 expires and the DiscoveryCount variable is equal to the 829 MaxDiscoveries variable (see Section 4.8). Upon entering this 830 state, the WTP MUST start the SilentInterval timer. While in 831 the Sulking state, all received CAPWAP protocol messages MUST 832 be ignored. 834 AC: This is an invalid state transition for the AC. 836 Sulking to Idle (@): This transition occurs on a WTP when it must 837 restart the discovery phase. 839 WTP: The WTP enters this state when the SilentInterval timer (see 840 Section 4.7) expires. The FailedDTLSSessionCount, 841 DiscoveryCount and FailedDTLSAuthFailCount counters are reset 842 to zero. 844 AC: This is an invalid state transition for the AC. 846 Sulking to Sulking (&): The Sulking state provides the silent 847 period, minimizing the possibility for Denial of Service (DoS) 848 attacks. 850 WTP: All packets received from the AC while in the sulking state 851 are ignored. 853 AC: This is an invalid state transition for the AC. 855 Idle to DTLS Setup (3): This transition occurs to establish a secure 856 DTLS session with the peer. 858 WTP: The WTP initiates this transition by invoking the DTLSStart 859 command(see Section 2.3.2.1), which starts the DTLS session 860 establishment with the chosen AC and the WaitDTLS timer is 861 started (see Section 4.7). When the discovery phase is 862 bypassed, it is assumed the WTP has locally configured ACs. 864 AC: Upon entering the Idle state from the Start state, the newly 865 created Listener thread automatically transitions to the DTLS 866 Setup and invokes the DTLSListen command (see Section 2.3.2.1), 867 and the WaitDTLS timer is started (see Section 4.7). 869 Discovery to DTLS Setup (%): This transition occurs to establish a 870 secure DTLS session with the peer. 872 WTP: The WTP initiates this transition by invoking the DTLSStart 873 command (see Section 2.3.2.1), which starts the DTLS session 874 establishment with the chosen AC. The decision of which AC to 875 connect to is the result of the discovery phase, which is 876 described in Section 3.3. 878 AC: This is an invalid state transition for the AC. 880 DTLS Setup to Idle ($): This transition occurs when the DTLS 881 connection setup fails. 883 WTP: The WTP initiates this state transition when it receives a 884 DTLSEstablishFail notification from DTLS (see Section 2.3.2.2), 885 and the FailedDTLSSessionCount or the FailedDTLSAuthFailCount 886 counter have not reached the value of the 887 MaxFailedDTLSSessionRetry variable (see Section 4.8). This 888 error notification aborts the secure DTLS session 889 establishment. When this notification is received, the 890 FailedDTLSSessionCount counter is incremented. This state 891 transition also occurs if the WaitDTLS timer has expired. 893 AC: This is an invalid state transition for the AC. 895 DTLS Setup to Sulking (*): This transition occurs when repeated 896 attempts to setup the DTLS connection have failed. 898 WTP: The WTP enters this state when the FailedDTLSSessionCount or 899 the FailedDTLSAuthFailCount counter reaches the value of the 900 MaxFailedDTLSSessionRetry variable (see Section 4.8). Upon 901 entering this state, the WTP MUST start the SilentInterval 902 timer. While in the Sulking state, all received CAPWAP and 903 DTLS protocol messages received MUST be ignored. 905 AC: This is an invalid state transition for the AC. 907 DTLS Setup to DTLS Setup (4): This transition occurs when the DTLS 908 Session failed to be established. 910 WTP: This is an invalid state transition for the WTP. 912 AC: The AC's Listener initiates this state transition when it 913 receives a DTLSEstablishFail notification from DTLS (see 914 Section 2.3.2.2). This error notification aborts the secure 915 DTLS session establishment. When this notification is 916 received, the FailedDTLSSessionCount counter is incremented. 918 The Listener thread then invokes the DTLSListen command (see 919 Section 2.3.2.1). 921 DTLS Setup to Authorize (5): This transition occurs when an incoming 922 DTLS session is being established, and the DTLS stack needs 923 authorization to proceed with the session establishment. 925 WTP: This state transition occurs when the WTP receives the 926 DTLSPeerAuthorize notification (see Section 2.3.2.2). Upon 927 entering this state, the WTP performs an authorization check 928 against the AC credentials. See Section 2.4.4 for more 929 information on AC authorization. 931 AC: This state transition is handled by the AC's Listener thread 932 when the DTLS module initiates the DTLSPeerAuthorize 933 notification (see Section 2.3.2.2). The Listener thread forks 934 an instance of the Service thread, along with a copy of the 935 state context. Once created, the Service thread performs an 936 authorization check against the WTP credentials. See 937 Section 2.4.4 for more information on WTP authorization. 939 Authorize to DTLS Setup (6): This transition is executed by the 940 Listener thread to enable it to listen for new incoming sessions. 942 WTP: This is an invalid state transition for the WTP. 944 AC: This state transition occurs when the AC's Listener thread 945 has created the WTP context and the Service thread. The 946 Listener thread then invokes the DTLSListen command (see 947 Section 2.3.2.1). 949 Authorize to DTLS Connect (a): This transition occurs to notify the 950 DTLS stack that the session should be established. 952 WTP: This state transition occurs when the WTP has successfully 953 authorized the AC's credentials (see Section 2.4.4). This is 954 done by invoking the DTLSAccept DTLS command (see 955 Section 2.3.2.1). 957 AC: This state transition occurs when the AC has successfully 958 authorized the WTP's credentials (see Section 2.4.4). This is 959 done by invoking the DTLSAccept DTLS command (see 960 Section 2.3.2.1). 962 Authorize to DTLS Teardown (b): This transition occurs to notify the 963 DTLS stack that the session should be aborted. 965 WTP: This state transition occurs when the WTP was unable to 966 authorize the AC, using the AC credentials. The WTP then 967 aborts the DTLS session by invoking the DTLSAbortSession 968 command (see Section 2.3.2.1). This state transition also 969 occurs if the WaitDTLS timer has expired. The WTP starts the 970 DTLSSessionDelete timer (see Section 4.7.6). 972 AC: This state transition occurs when the AC was unable to 973 authorize the WTP, using the WTP credentials. The AC then 974 aborts the DTLS session by invoking the DTLSAbortSession 975 command (see Section 2.3.2.1). This state transition also 976 occurs if the WaitDTLS timer has expired. The AC starts the 977 DTLSSessionDelete timer (see Section 4.7.6). 979 DTLS Connect to DTLS Teardown (c): This transition occurs when the 980 DTLS Session failed to be established. 982 WTP: This state transition occurs when the WTP receives either a 983 DTLSAborted or DTLSAuthenticateFail notification (see 984 Section 2.3.2.2), indicating that the DTLS session was not 985 successfully established. When this transition occurs due to 986 the DTLSAuthenticateFail notification, the 987 FailedDTLSAuthFailCount is incremented, otherwise the 988 FailedDTLSSessionCount counter is incremented. This state 989 transition also occurs if the WaitDTLS timer has expired. The 990 WTP starts the DTLSSessionDelete timer (see Section 4.7.6). 992 AC: This state transition occurs when the AC receives either a 993 DTLSAborted or DTLSAuthenticateFail notification (see 994 Section 2.3.2.2), indicating that the DTLS session was not 995 successfully established, and both of the 996 FailedDTLSAuthFailCount and FailedDTLSSessionCount counters 997 have not reached the value of the MaxFailedDTLSSessionRetry 998 variable (see Section 4.8). This state transition also occurs 999 if the WaitDTLS timer has expired. The AC starts the 1000 DTLSSessionDelete timer (see Section 4.7.6). 1002 DTLS Connect to Join (d): This transition occurs when the DTLS 1003 Session is successfully established. 1005 WTP: This state transition occurs when the WTP receives the 1006 DTLSEstablished notification (see Section 2.3.2.2), indicating 1007 that the DTLS session was successfully established. When this 1008 notification is received, the FailedDTLSSessionCount counter is 1009 set to zero. The WTP enters the Join state by transmiting the 1010 Join Request to the AC. The WTP stops the WaitDTLS timer. 1012 AC: This state transition occurs when the AC receives the 1013 DTLSEstablished notification (see Section 2.3.2.2), indicating 1014 that the DTLS session was successfully established. When this 1015 notification is received, the FailedDTLSSessionCount counter is 1016 set to zero. The AC stops the WaitDTLS timer, and starts the 1017 WaitJoin timer. 1019 Join to DTLS Teardown (e): This transition occurs when the join 1020 process failed. 1022 WTP: This state transition occurs when the WTP receives a Join 1023 Response message with a Result Code message element containing 1024 an error, or if the Image Identifier provided by the AC in the 1025 Join Response message differs from the WTP's currently running 1026 firmware version and the WTP has the requested image in its 1027 non-volatile memory. This causes the WTP to initiate the 1028 DTLSShutdown command (see Section 2.3.2.1). This transition 1029 also occurs if the WTP receives one of the following DTLS 1030 notifications: DTLSAborted, DTLSReassemblyFailure or 1031 DTLSPeerDisconnect. The WTP starts the DTLSSessionDelete timer 1032 (see Section 4.7.6). 1034 AC: This state transition occurs either if the WaitJoin timer 1035 expires or if the AC transmits a Join Response message with a 1036 Result Code message element containing an error. This causes 1037 the AC to initiate the DTLSShutdown command (see 1038 Section 2.3.2.1). This transition also occurs if the AC 1039 receives one of the following DTLS notifications: DTLSAborted, 1040 DTLSReassemblyFailure or DTLSPeerDisconnect. The AC starts the 1041 DTLSSessionDelete timer (see Section 4.7.6). 1043 Join to Image Data (f): This state transition is used by the WTP and 1044 the AC to download executable firmware. 1046 WTP: The WTP enters the Image Data state when it receives a 1047 successful Join Response message and determines that the 1048 software version in the Image Identifier message element is not 1049 the same as its currently running image. The WTP also detects 1050 that the requested image version is not currently available in 1051 the WTP's non-volatile storage (see Section 9.1 for a full 1052 description of the firmware download process). The WTP 1053 initializes the EchoInterval timer (see Section 4.7), and 1054 transmits the Image Data Request message (see Section 9.1.1) 1055 requesting the start of the firmware download. 1057 AC: This state transition occurs when the AC receives the Image 1058 Data Request message from the WTP, after having sent its Join 1059 Response to the WTP. The AC stops the WaitJoin timer. The AC 1060 MUST transmit an Image Data Response message (see 1061 Section 9.1.2) to the WTP, which includes a portion of the 1062 firmware. The AC MUST start the ImageDataStartTimer timer (see 1063 Section 4.7). 1065 Join to Configure (g): This state transition is used by the WTP and 1066 the AC to exchange configuration information. 1068 WTP: The WTP enters the Configure state when it receives a 1069 successful Join Response message, and determines that the 1070 included Image Identifier message element is the same as its 1071 currently running image. The WTP transmits the Configuration 1072 Status Request message (see Section 8.2) to the AC with message 1073 elements describing its current configuration. 1075 AC: This state transition occurs when it receives the 1076 Configuration Status Request message from the WTP (see 1077 Section 8.2), which MAY include specific message elements to 1078 override the WTP's configuration. The AC stops the WaitJoin 1079 timer. The AC transmits the Configuration Status Response 1080 message (see Section 8.3) and starts the 1081 ChangeStatePendingTimer timer (see Section 4.7). 1083 Configure to Reset (h): This state transition is used to reset the 1084 connection either due to an error during the configuration phase, 1085 or when the WTP determines it needs to reset in order for the new 1086 configuration to take effect. The CAPWAP Reset command is used to 1087 indicate to the peer that it will initiate a DTLS teardown. 1089 WTP: The WTP enters the Reset state when it receives a 1090 Configuration Status Response message indicating an error or 1091 when it determines that a reset of the WTP is required, due to 1092 the characteristics of a new configuration. 1094 AC: The AC transitions to the Reset state when it receives a 1095 Change State Event message from the WTP that contains an error 1096 for which AC policy does not permit the WTP to provide service. 1097 This state transition also occurs when the AC 1098 ChangeStatePendingTimer timer expires. 1100 Configure to DTLS Teardown (i): This transition occurs when the 1101 configuration process aborts due to a DTLS error. 1103 WTP: The WTP enters this state when it receives one of the 1104 following DTLS notifications: DTLSAborted, 1105 DTLSReassemblyFailure or DTLSPeerDisconnect (see 1106 Section 2.3.2.2). The WTP MAY tear down the DTLS session if it 1107 receives frequent DTLSDecapFailure notifications. The WTP 1108 starts the DTLSSessionDelete timer (see Section 4.7.6). 1110 AC: The AC enters this state when it receives one of the 1111 following DTLS notifications: DTLSAborted, 1112 DTLSReassemblyFailure or DTLSPeerDisconnect (see 1113 Section 2.3.2.2). The AC MAY tear down the DTLS session if it 1114 receives frequent DTLSDecapFailure notifications. The AC 1115 starts the DTLSSessionDelete timer (see Section 4.7.6). 1117 Image Data to Image Data (j): The Image Data state is used by the 1118 WTP and the AC during the firmware download phase. 1120 WTP: The WTP enters the Image Data state when it receives an 1121 Image Data Response message indicating that the AC has more 1122 data to send. This state transition also occurs when the WTP 1123 receives the subsequent Image Data Requests, at which time it 1124 resets the ImageDataStartTimer time to ensure it receives the 1125 next expected Image Data Request from the AC. 1127 AC: This state transition occurs when the AC receives the Image 1128 Data Response message from the WTP while already in the Image 1129 Data state. The AC disables the ImageDataStartTimer timer. 1131 Image Data to Reset (k): This state transition is used to reset the 1132 DTLS connection prior to restarting the WTP after an image 1133 download. 1135 WTP: When an image download completes, or if the 1136 ImageDataStartTimer timer expires, the WTP enters the Reset 1137 state. The WTP MAY also transition to this state upon 1138 receiving an Image Data Response message from the AC (see 1139 Section 9.1.2) indicating a failure. 1141 AC: The AC enters the Reset state either when the image transfer 1142 has successfully completed, an error occurs during the image 1143 download process or if the ImageDataStartTimer timer expires. 1145 Image Data to DTLS Teardown (l): This transition occurs when the 1146 firmware download process aborts due to a DTLS error. 1148 WTP: The WTP enters this state when it receives one of the 1149 following DTLS notifications: DTLSAborted, 1150 DTLSReassemblyFailure or DTLSPeerDisconnect (see 1151 Section 2.3.2.2). The WTP MAY tear down the DTLS session if it 1152 receives frequent DTLSDecapFailure notifications. The WTP 1153 starts the DTLSSessionDelete timer (see Section 4.7.6). 1155 AC: The AC enters this state when it receives one of the 1156 following DTLS notifications: DTLSAborted, 1157 DTLSReassemblyFailure or DTLSPeerDisconnect (see 1158 Section 2.3.2.2). The AC MAY tear down the DTLS session if it 1159 receives frequent DTLSDecapFailure notifications. The AC 1160 starts the DTLSSessionDelete timer (see Section 4.7.6). 1162 Configure to Data Check (m): This state transition occurs when the 1163 WTP and AC confirm the configuration. 1165 WTP: The WTP enters this state when it receives a successful 1166 Configuration Status Response message from the AC. The WTP 1167 initializes the EchoInterval timer (see Section 4.7), and 1168 transmits the Change State Event Request message (see 1169 Section 8.6). 1171 AC: This state transition occurs when the AC receives the Change 1172 State Event Request message (see Section 8.6) from the WTP. 1173 The AC responds with a Change State Event Response message (see 1174 Section 8.7). The AC MUST start the DataCheckTimer timer and 1175 stops the ChangeStatePendingTimer timer (see Section 4.7). 1177 Data Check to DTLS Teardown (n): This transition occurs when the WTP 1178 does not complete the Data Check exchange. 1180 WTP: This state transition occurs if the WTP does not receive the 1181 Change State Event Response message before a CAPWAP 1182 retransmission timeout occurs. The WTP also transitions to 1183 this state if the underlying reliable transport's 1184 RetransmitCount counter has reached the MaxRetransmit variable 1185 (see Section 4.7). The WTP starts the DTLSSessionDelete timer 1186 (see Section 4.7.6). 1188 AC: The AC enters this state when the DataCheckTimer timer 1189 expires (see Section 4.7). The AC starts the DTLSSessionDelete 1190 timer (see Section 4.7.6). 1192 Data Check to Run (o): This state transition occurs when the linkage 1193 between the control and data channels is established, causing the 1194 WTP and AC to enter their normal state of operation. 1196 WTP: The WTP enters this state when it receives a successful 1197 Change State Event Response message from the AC. The WTP 1198 initiates the data channel, which MAY require the establishment 1199 of a DTLS session, starts the DataChannelKeepAlive timer (see 1200 Section 4.7.2) and transmits a Data Channel Keep Alive packet 1201 (see Section 4.4.1). The WTP then starts the 1202 DataChannelDeadInterval timer (see Section 4.7). 1204 AC: This state transition occurs when the AC receives the Data 1205 Channel Keep Alive packet (see Section 4.4.1), with a Session 1206 ID message element matching that included by the WTP in the 1207 Join Request message. The AC disables the DataCheckTimer 1208 timer. Note that if AC policy is to require the data channel 1209 to be encrypted, this process would also require the 1210 establishment of a data channel DTLS session. Upon receiving 1211 the Data Channel Keep Alive packet, the AC transmits its own 1212 Data Channel Keep Alive packet. 1214 Run to DTLS Teardown (p): This state transition occurs when an error 1215 has occurred in the DTLS stack, causing the DTLS session to be 1216 torn down. 1218 WTP: The WTP enters this state when it receives one of the 1219 following DTLS notifications: DTLSAborted, 1220 DTLSReassemblyFailure or DTLSPeerDisconnect (see 1221 Section 2.3.2.2). The WTP MAY tear down the DTLS session if it 1222 receives frequent DTLSDecapFailure notifications. The WTP also 1223 transitions to this state if the underlying reliable 1224 transport's RetransmitCount counter has reached the 1225 MaxRetransmit variable (see Section 4.7). The WTP starts the 1226 DTLSSessionDelete timer (see Section 4.7.6). 1228 AC: The AC 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 AC MAY tear down the DTLS session if it 1232 receives frequent DTLSDecapFailure notifications. The AC 1233 transitions to this state if the underlying reliable 1234 transport's RetransmitCount counter has reached the 1235 MaxRetransmit variable (see Section 4.7). This state 1236 transition also occurs when the AC's EchoInterval timer (see 1237 Section 4.7.7) expires. The AC starts the DTLSSessionDelete 1238 timer (see Section 4.7.6). 1240 Run to Run (q): This is the normal state of operation. 1242 WTP: This is the WTP's normal state of operation. The WTP resets 1243 its EchoInterval timer whenever it transmits a request to the 1244 AC. There are many events that result this state transition: 1246 Configuration Update: The WTP receives a Configuration Update 1247 Request message(see Section 8.4). The WTP MUST respond with 1248 a Configuration Update Response message (see Section 8.5). 1250 Change State Event: The WTP receives a Change State Event 1251 Response message, or determines that it must initiate a 1252 Change State Event Request message, as a result of a failure 1253 or change in the state of a radio. 1255 Echo Request: The WTP sends an Echo Request message 1256 (Section 7.1) or receives the corresponding Echo Response 1257 message, (see Section 7.2) from the AC. When the WTP 1258 receives the Echo Response, it resets its EchoInterval timer 1259 (see Section 4.7.7). 1261 Clear Config Request: The WTP receives a Clear Configuration 1262 Request message (see Section 8.8) and MUST generate a 1263 corresponding Clear Configuration Response message (see 1264 Section 8.9). The WTP MUST reset its configuration back to 1265 manufacturer defaults. 1267 WTP Event: The WTP sends a WTP Event Request message, 1268 delivering information to the AC (see Section 9.4). The WTP 1269 receives a WTP Event Response message from the AC (see 1270 Section 9.5). 1272 Data Transfer: The WTP sends a Data Transfer Request or Data 1273 Transfer Response message to the AC (see Section 9.6). The 1274 WTP receives a Data Transfer Request or Data Transfer 1275 Response message from the AC (see Section 9.6). Upon 1276 receipt of a Data Transfer Request, the WTP transmits a Data 1277 Transfer Response to the AC. 1279 Station Configuration Request: The WTP receives a Station 1280 Configuration Request message (see Section 10.1), to which 1281 it MUST respond with a Station Configuration Response 1282 message (see Section 10.2). 1284 AC: This is the AC's normal state of operation. Note that the 1285 receipt of any Request from the WTP causes the AC to reset its 1286 EchoInterval timer (see Section 4.7.7). 1288 Configuration Update: The AC sends a Configuration Update 1289 Request message (see Section 8.4) to the WTP to update its 1290 configuration. The AC receives a Configuration Update 1291 Response message (see Section 8.5) from the WTP. 1293 Change State Event: The AC receives a Change State Event 1294 Request message (see Section 8.6), to which it MUST respond 1295 with the Change State Event Response message (see 1296 Section 8.7). 1298 Echo Request: The AC receives an Echo Request message (see 1299 Section 7.1), to which it MUST respond with an Echo Response 1300 message(see Section 7.2). 1302 Clear Config Response: The AC sends a Clear Configuration 1303 Request message (see Section 8.8) to the WTP to clear its 1304 configuration. The AC receives a Clear Configuration 1305 Response message from the WTP (see Section 8.9). 1307 WTP Event: The AC receives a WTP Event Request message from 1308 the WTP (see Section 9.4) and MUST generate a corresponding 1309 WTP Event Response message (see Section 9.5). 1311 Data Transfer: The AC sends a Data Transfer Request or Data 1312 Transfer Response message to the WTP (see Section 9.6). The 1313 AC receives a Data Transfer Request or Data Transfer 1314 Response message from the WTP (see Section 9.6). Upon 1315 receipt of a Data Transfer Request, the AC transmits a Data 1316 Transfer Response to the WTP. 1318 Station Configuration Request: The AC sends a Station 1319 Configuration Request message (see Section 10.1) or receives 1320 the corresponding Station Configuration Response message 1321 (see Section 10.2) from the WTP. 1323 Run to Reset (r): This state transition is used when either the AC 1324 or WTP tear down the connection. This may occur as part of normal 1325 operation, or due to error conditions. 1327 WTP: The WTP enters the Reset state when it receives a Reset 1328 Request message from the AC. 1330 AC: The AC enters the Reset state when it transmits a Reset 1331 Request message to the WTP. 1333 Reset to DTLS Teardown (s): This transition occurs when the CAPWAP 1334 reset is complete, to terminate the DTLS session. 1336 WTP: This state transition occurs when the WTP transmits a Reset 1337 Response message. The WTP does not invoke the DTLSShutdown 1338 command (see Section 2.3.2.1). The WTP starts the 1339 DTLSSessionDelete timer (see Section 4.7.6). 1341 AC: This state transition occurs when the AC receives a Reset 1342 Response message. This causes the AC to initiate the 1343 DTLSShutdown command (see Section 2.3.2.1). The AC starts the 1344 DTLSSessionDelete timer (see Section 4.7.6). 1346 DTLS Teardown to Idle (t): This transition occurs when the DTLS 1347 session has been shutdown. 1349 WTP: This state transition occurs when the WTP has successfully 1350 cleaned up all resources associated with the control plane DTLS 1351 session, or if the DTLSSessionDelete timer (see Section 4.7.6) 1352 expires. The data plane DTLS session is also shutdown, and all 1353 resources released, if a DTLS session was established for the 1354 data plane. Any timers set for the current instance of the 1355 state machine are also cleared. 1357 AC: This is an invalid state transition for the AC. 1359 DTLS Teardown to Sulking (u): This transition occurs when repeated 1360 attempts to setup the DTLS connection have failed. 1362 WTP: The WTP enters this state when the FailedDTLSSessionCount or 1363 the FailedDTLSAuthFailCount counter reaches the value of the 1364 MaxFailedDTLSSessionRetry variable (see Section 4.8). Upon 1365 entering this state, the WTP MUST start the SilentInterval 1366 timer. While in the Sulking state, all received CAPWAP and 1367 DTLS protocol messages received MUST be ignored. 1369 AC: This is an invalid state transition for the AC. 1371 DTLS Teardown to Dead (w): This transition occurs when the DTLS 1372 session has been shutdown. 1374 WTP: This is an invalid state transition for the WTP. 1376 AC: This state transition occurs when the AC has successfully 1377 cleaned up all resources associated with the control plane DTLS 1378 session , or if the DTLSSessionDelete timer (see Section 4.7.6) 1379 expires. The data plane DTLS session is also shutdown, and all 1380 resources released, if a DTLS session was established for the 1381 data plane. Any timers set for the current instance of the 1382 state machine are also cleared. The AC's Service thread is 1383 terminated. 1385 2.3.2. CAPWAP/DTLS Interface 1387 This section describes the DTLS Commands used by CAPWAP, and the 1388 notifications received from DTLS to the CAPWAP protocol stack. 1390 2.3.2.1. CAPWAP to DTLS Commands 1392 Six commands are defined for the CAPWAP to DTLS API. These 1393 "commands" are conceptual, and may be implemented as one or more 1394 function calls. This API definition is provided to clarify 1395 interactions between the DTLS and CAPWAP components of the integrated 1396 CAPWAP state machine. 1398 Below is a list of the minimal command API: 1400 o DTLSStart is sent to the DTLS component to cause a DTLS session to 1401 be established. Upon invoking the DTLSStart command, the WaitDTLS 1402 timer is started. The WTP initiates this DTLS command, as the AC 1403 does not initiate DTLS sessions. 1405 o DTLSListen is sent to the DTLS component to allow the DTLS 1406 component to listen for incoming DTLS session requests. 1408 o DTLSAccept is sent to the DTLS component to allow the DTLS session 1409 establishment to continue successfully. 1411 o DTLSAbortSession is sent to the DTLS component to cause the 1412 session that is in the process of being established to be aborted. 1413 This command is also sent when the WaitDTLS timer expires. When 1414 this command is executed, the FailedDTLSSessionCount counter is 1415 incremented. 1417 o DTLSShutdown is sent to the DTLS component to cause session 1418 teardown. 1420 o DTLSMtuUpdate is sent by the CAPWAP component to modify the MTU 1421 size used by the DTLS component. See Section 3.5 for more 1422 information on MTU Discovery. The default size is 1468 bytes. 1424 2.3.2.2. DTLS to CAPWAP Notifications 1426 DTLS notifications are defined for the DTLS to CAPWAP API. These 1427 "notifications" are conceptual, and may be implemented in numerous 1428 ways (e.g. as function return values). This API definition is 1429 provided to clarify interactions between the DTLS and CAPWAP 1430 components of the integrated CAPWAP state machine. It is important 1431 to note that the notifications listed below MAY cause the CAPWAP 1432 state machine to jump from one state to another using a state 1433 transition not listed in Section 2.3.1. When a notification listed 1434 below occurs, the target CAPWAP state shown in Figure 4 becomes the 1435 current state. 1437 Below is a list of the API notifications: 1439 o DTLSPeerAuthorize is sent to the CAPWAP component during DTLS 1440 session establishment once the peer's identity has been received. 1441 This notification MAY be used by the CAPWAP component to authorize 1442 the session, based on the peer's identity. The authorization 1443 process will lead to the CAPWAP component initiating either the 1444 DTLSAccept or DTLSAbortSession commands. 1446 o DTLSEstablished is sent to the CAPWAP component to indicate that 1447 that a secure channel now exists, using the parameters provided 1448 during the DTLS initialization process. When this notification is 1449 received, the FailedDTLSSessionCount counter is reset to zero. 1450 When this notification is received, the WaitDTLS timer is stopped. 1452 o DTLSEstablishFail is sent when the DTLS session establishment has 1453 failed, either due to a local error, or due to the peer rejecting 1454 the session establishment. When this notification is received, 1455 the FailedDTLSSessionCount counter is incremented. 1457 o DTLSAuthenticateFail is sent when DTLS session establishment 1458 failed due to an authentication error. When this notification is 1459 received, the FailedDTLSAuthFailCount counter is incremented. 1461 o DTLSAborted is sent to the CAPWAP component to indicate that 1462 session abort (as requested by CAPWAP) is complete; this occurs to 1463 confirm a DTLS session abort, or when the WaitDTLS timer expires. 1464 When this notification is received, the WaitDTLS timer is stopped. 1466 o DTLSReassemblyFailure MAY be sent to the CAPWAP component to 1467 indicate DTLS fragment reassembly failure. 1469 o DTLSDecapFailure MAY be sent to the CAPWAP module to indicate a 1470 decapsulation failure. DTLSDecapFailure MAY be sent to the CAPWAP 1471 module to indicate an encryption/authentication failure. This 1472 notification is intended for informative purposes only, and is not 1473 intended to cause a change in the CAPWAP state machine (see 1474 Section 12.4). 1476 o DTLSPeerDisconnect is sent to the CAPWAP component to indicate the 1477 DTLS session has been torn down. Note that this notification is 1478 only received if the DTLS session has been established. 1480 2.4. Use of DTLS in the CAPWAP Protocol 1482 DTLS is used as a tightly-integrated, secure wrapper for the CAPWAP 1483 protocol. In this document DTLS and CAPWAP are discussed as 1484 nominally distinct entities; however they are very closely coupled, 1485 and may even be implemented inseparably. Since there are DTLS 1486 library implementations currently available, and since security 1487 protocols (e.g. IPsec, TLS) are often implemented in widely 1488 available acceleration hardware, it is both convenient and forward- 1489 looking to maintain a modular distinction in this document. 1491 This section describes a detailed walk-through of the interactions 1492 between the DTLS module and the CAPWAP module, via 'commands' (CAPWAP 1493 to DTLS) and 'notifications' (DTLS to CAPWAP) as they would be 1494 encountered during the normal course of operation. 1496 2.4.1. DTLS Handshake Processing 1498 Details of the DTLS handshake process are specified in [RFC4347]. 1499 This section describes the interactions between the DTLS session 1500 establishment process and the CAPWAP protocol. Note that the 1501 conceptual DTLS state is shown below to help understand the point at 1502 which the DTLS states transition. In the normal case, the DTLS 1503 handshake will proceed as shown in Figure 5. (NOTE: this example 1504 uses certificates, but preshared keys are also supported): 1506 ============ ============ 1507 WTP AC 1508 ============ ============ 1509 ClientHello ------> 1510 <------ HelloVerifyRequest 1511 (with cookie) 1513 ClientHello ------> 1514 (with cookie) 1515 <------ ServerHello 1516 <------ Certificate 1517 <------ ServerHelloDone 1519 (WTP callout for AC authorization 1520 occurs in CAPWAP Auth state) 1522 Certificate* 1523 ClientKeyExchange 1524 CertificateVerify* 1525 ChangeCipherSpec 1526 Finished ------> 1528 (AC callout for WTP authorization 1529 occurs in CAPWAP Auth state) 1531 ChangeCipherSpec 1532 <------ Finished 1534 Figure 5: DTLS Handshake 1536 DTLS, as specified, provides its own retransmit timers with an 1537 exponential back-off. [RFC4347] does not specify how long 1538 retransmissions should continue. Consequently, timing out incomplete 1539 DTLS handshakes is entirely the responsibility of the CAPWAP module. 1541 The DTLS implementation used by CAPWAP MUST support TLS Session 1542 Resumption. Session resumption is used to establish the DTLS session 1543 used for the data channel. The DTLS implementation on the WTP MUST 1544 return some unique identifier to the CAPWAP module to enable 1545 subsequent establishment of a DTLS-encrypted data channel, if 1546 necessary. 1548 The DTLS implementation used by CAPWAP MUST use replay detection, per 1549 Section 3.3 of [RFC4347]. Since the CAPWAP protocol handles 1550 retransmissions by re-encrypting lost frames, any duplicate DTLS 1551 frames are either unintentional or malicious, and should be silently 1552 discarded. 1554 2.4.2. DTLS Session Establishment 1556 The WTP, either through the Discovery process, or through pre- 1557 configuration, determines the AC to connect to. The WTP uses the 1558 DTLSStart command to request that a secure connection be established 1559 to the selected AC. Prior to initiation of the DTLS handshake, the 1560 WTP sets the WaitDTLS timer. Upon invoking the DTLSStart or 1561 DTLSListen commands, the WTP and AC, respectively, set the WaitDTLS 1562 timer. If the DTLSEstablished notification is not received prior to 1563 timer expiration, the DTLS session is aborted by issuing the 1564 DTLSAbortSession DTLS command. This notification causes the CAPWAP 1565 module to transition to the Idle state. Upon receiving a 1566 DTLSEstablished notification, the WaitDTLS timer is deactivated. 1568 2.4.3. DTLS Error Handling 1570 If the AC or WTP does not respond to any DTLS handshake messages sent 1571 by its peer, the DTLS specification calls for the message to be 1572 retransmited. Note that during the handshake, when both the AC and 1573 the WTP are expecting additional handshake messages, they both 1574 retransmit if an expected message has not been received (note that 1575 retransmissions for CAPWAP Control messages work differently: all 1576 CAPWAP Control messages are either requests or responses, and the 1577 peer who sent the request is responsible for retransmissions). 1579 If the WTP or the AC does not receive an expected DTLS handshake 1580 message despite of retransmissions, the WaitDTLS timer will 1581 eventually expire, and the session will be terminated. This can 1582 happen if communication between the peers has completely failed, or 1583 if one of the peers sent a DTLS Alert message which was lost in 1584 transit (DTLS does not retransmit Alert messages). 1586 If a cookie fails to validate, this could represent a WTP error, or 1587 it could represent a DoS attack. Hence, AC resource utilization 1588 SHOULD be minimized. The AC MAY log a message indicating the 1589 failure, and SHOULD treat the message as though no cookie were 1590 present. 1592 Since DTLS handshake messages are potentially larger than the maximum 1593 record size, DTLS supports fragmenting of handshake messages across 1594 multiple records. There are several potential causes of re-assembly 1595 errors, including overlapping and/or lost fragments. The DTLS 1596 component MUST send a DTLSReassemblyFailure notification to the 1597 CAPWAP component. Whether precise information is given along with 1598 notification is an implementation issue, and hence is beyond the 1599 scope of this document. Upon receipt of such an error, the CAPWAP 1600 component SHOULD log an appropriate error message. Whether 1601 processing continues or the DTLS session is terminated is 1602 implementation dependent. 1604 DTLS decapsulation errors consist of three types: decryption errors, 1605 authentication errors, and malformed DTLS record headers. Since DTLS 1606 authenticates the data prior to encapsulation, if decryption fails, 1607 it is difficult to detect this without first attempting to 1608 authenticate the packet. If authentication fails, a decryption error 1609 is also likely, but not guaranteed. Rather than attempt to derive 1610 (and require the implementation of) algorithms for detecting 1611 decryption failures, decryption failures are reported as 1612 authentication failures. The DTLS component MUST provide a 1613 DTLSDecapFailure notification to the CAPWAP component when such 1614 errors occur. If a malformed DTLS record header is detected, the 1615 packets SHOULD be silently discarded, and the receiver MAY log an 1616 error message. 1618 There is currently only one encapsulation error defined: MTU 1619 exceeded. As part of DTLS session establishment, the CAPWAP 1620 component informs the DTLS component of the MTU size. This may be 1621 dynamically modified at any time when the CAPWAP component sends the 1622 DTLSMtuUpdate command to the DTLS component (see Section 2.3.2.1). 1623 The value provided to the DTLS stack is the result of the MTU 1624 Discovery process, which is described in Section 3.5. The DTLS 1625 component returns this notification to the CAPWAP component whenever 1626 a transmission request will result in a packet which exceeds the MTU. 1628 2.4.4. DTLS EndPoint Authentication and Authorization 1630 DTLS supports endpoint authentication with certificates or preshared 1631 keys. The TLS algorithm suites for each endpoint authentication 1632 method are described below. 1634 2.4.4.1. Authenticating with Certificates 1636 CAPWAP implementations only use cipher suites that are recommended 1637 for use with DTLS, see [DTLS-DESIGN]. At present, the following 1638 algorithms MUST be supported when using certificates for CAPWAP 1639 authentication: 1641 o TLS_RSA_WITH_AES_128_CBC_SHA [RFC4346] 1643 The following algorithms SHOULD be supported when using certificates: 1645 o TLS_DHE_RSA_WITH_AES_128_CBC_SHA [RFC4346] 1647 The following algorithms MAY be supported when using certificates: 1649 o TLS_RSA_WITH_AES_256_CBC_SHA [RFC4346] 1651 o TLS_DHE_RSA_WITH_AES_256_CBC_SHA [RFC4346] 1653 Additional ciphers MAY be defined in follow on CAPWAP specifications. 1655 2.4.4.2. Authenticating with Preshared Keys 1657 Pre-shared keys present significant challenges from a security 1658 perspective, and for that reason, their use is strongly discouraged. 1659 Several methods for authenticating with preshared keys are defined 1660 [RFC4279], and we focus on the following two: 1662 o Pre-Shared Key (PSK) key exchange algorithm - simplest method, 1663 ciphersuites use only symmetric key algorithms 1665 o DHE_PSK key exchange algorithm - use a PSK to authenticate a 1666 Diffie-Hellman exchange. These ciphersuites give some additional 1667 protection against dictionary attacks and also provide Perfect 1668 Forward Secrecy (PFS). 1670 The first approach (plain PSK) is susceptible to passive dictionary 1671 attacks; hence, while this algorithm MUST be supported, special care 1672 should be taken when choosing that method. In particular, user- 1673 readable passphrases SHOULD NOT be used, and use of short PSKs SHOULD 1674 be strongly discouraged. 1676 The following cryptographic algorithms MUST be supported when using 1677 preshared keys: 1679 o TLS_PSK_WITH_AES_128_CBC_SHA [RFC4346] 1681 o TLS_DHE_PSK_WITH_AES_128_CBC_SHA [RFC4346] 1683 The following algorithms MAY be supported when using preshared keys: 1685 o TLS_PSK_WITH_AES_256_CBC_SHA [RFC4346] 1687 o TLS_DHE_PSK_WITH_AES_256_CBC_SHA [RFC4346] 1689 Additional ciphers MAY be defined in follow on CAPWAP specifications. 1691 2.4.4.3. Certificate Usage 1693 Certificate authorization by the AC and WTP is required so that only 1694 an AC may perform the functions of an AC and that only a WTP may 1695 perform the functions of a WTP. This restriction of functions to the 1696 AC or WTP requires that the certificates used by the AC MUST be 1697 distinguishable from the certificate used by the WTP. To accomplish 1698 this differentiation, the x.509 certificates MUST include the 1699 Extended Key Usage (EKU) certificate extension [RFC5280]. 1701 The EKU field indicates one or more purposes for which a certificate 1702 may be used. It is an essential part in authorization. Its syntax 1703 is as follows: 1705 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 1707 KeyPurposeId ::= OBJECT IDENTIFIER 1709 Here we define two KeyPurposeId values, one for the WTP and one for 1710 the AC. Inclusion of one of these two values indicates a certificate 1711 is authorized for use by a WTP or AC, respectively. These values are 1712 formatted as id-kp fields. 1714 id-kp OBJECT IDENTIFIER ::= 1715 { iso(1) identified-organization(3) dod(6) internet(1) 1716 security(5) mechanisms(5) pkix(7) 3 } 1718 id-kp-capwapAC OBJECT IDENTIFIER ::= { id-kp 18 } 1720 id-kp-capwapWTP OBJECT IDENTIFIER ::= { id-kp 19 } 1722 All capwap devices MUST support the ExtendedKeyUsage certificate 1723 extension if it is present in a certificate. If the extension is 1724 present, then the certificate MUST have either the id-kp-capwapAC or 1725 the id-kp-anyExtendedKeyUsage keyPurposeID to act as an AC. 1726 Similarly, if the extension is present, a device MUST have the id-kp- 1727 capwapWTP or id-kp-anyExtendedKeyUsage keyPurposeID to act as a WTP. 1729 Part of the CAPWAP certificate validation process includes ensuring 1730 that the proper EKU is included and allowing the CAPWAP session to be 1731 established only if the extension properly represents the device. 1732 For instance, an AC SHOULD NOT accept a connection request from 1733 another AC, and therefore MUST verify that the id-kp-capwapWTP EKU is 1734 present in the certificate. 1736 CAPWAP implementations MUST support certificates where the common 1737 name (CN) for both the WTP and AC is the MAC address of that device. 1738 The MAC address MUST be formatted as ASCII HEX, e.g. 1739 01:23:45:67:89:ab. Note that the CN field MAY contain either of the 1740 EUI-48 [EUI-48] or EUI-64 [EUI-64] MAC Address formats. 1742 ACs and WTPs MUST authorize (e.g. through access control lists) 1743 certificates of devices to which they are connecting, e.g., based on 1744 the issuer, MAC address, or organizational information specified in 1745 the certificate. The identities specified in the certificates bind a 1746 particular DTLS session to a specific pair of mutually-authenticated 1747 and authorized MAC addresses. The particulars of authorization 1748 filter construction are implementation details which are, for the 1749 most part, not within the scope of this specification. However, at 1750 minimum, all devices MUST verify that the appropriate EKU bit is set 1751 according to the role of the peer device (AC vs. WTP), and that the 1752 issuer of the certificate is appropriate for the domain in question. 1754 2.4.4.4. PSK Usage 1756 When DTLS uses PSK Ciphersuites, the ServerKeyExchange message MUST 1757 contain the "PSK identity hint" field and the ClientKeyExchange 1758 message MUST contain the "PSK identity" field. These fields are used 1759 to help the WTP select the appropriate PSK for use with the AC, and 1760 then indicate to the AC which key is being used. When PSKs are 1761 provisioned to WTPs and ACs, both the PSK Hint and PSK Identity for 1762 the key MUST be specified. 1764 The PSK Hint SHOULD uniquely identify the AC and the PSK Identity 1765 SHOULD uniquely identify the WTP. It is RECOMMENDED that these hints 1766 and identities be the ASCII HEX-formatted MAC addresses of the 1767 respective devices, since each pairwise combination of WTP and AC 1768 SHOULD have a unique PSK. The PSK hint and identity SHOULD be 1769 sufficient to perform authorization, as simply having knowledge of a 1770 PSK does not necessarily imply authorization. 1772 If a single PSK is being used for multiple devices on a CAPWAP 1773 network, which is NOT RECOMMENDED, the PSK Hint and Identity can no 1774 longer be a MAC address, so appropriate hints and identities SHOULD 1775 be selected to identify the group of devices to which the PSK is 1776 provisioned. 1778 3. CAPWAP Transport 1780 Communication between a WTP and an AC is established using the 1781 standard UDP client/server model. The CAPWAP protocol supports both 1782 UDP and UDP-Lite [RFC3828] transport protocols. When run over IPv4, 1783 UDP is used for the CAPWAP control and data channels. 1785 When run over IPv6, the CAPWAP control channel always uses UDP, while 1786 the CAPWAP data channel may use either UDP or UDP-Lite. UDP-Lite is 1787 the default transport protocol for the CAPWAP data channel. However, 1788 if a middlebox or IPv4 to IPv6 gateway has been discovered, UDP is 1789 used for the CAPWAP data channel. 1791 This section describes how the CAPWAP protocol is carried over IP and 1792 UDP/UDP-Lite transport protocols. The CAPWAP Transport Protocol 1793 message element Section 4.6.14 describes the rules to use in 1794 determining which transport protocol is to be used. 1796 3.1. UDP Transport 1798 One of the CAPWAP protocol requirements is to allow a WTP to reside 1799 behind a middlebox, firewall and/or Network Address Translation (NAT) 1800 device. Since a CAPWAP session is initiated by the WTP (client) to 1801 the well-known UDP port of the AC (server), the use of UDP is a 1802 logical choice. The UDP checksum field in CAPWAP packets MUST be set 1803 to zero. 1805 CAPWAP protocol control packets sent from the WTP to the AC use the 1806 CAPWAP control channel, as defined in Section 1.4. The CAPWAP 1807 control port at the AC is the well known UDP port 5246. The CAPWAP 1808 control port at the WTP can be any port selected by the WTP. 1810 CAPWAP protocol data packets sent from the WTP to the AC use the 1811 CAPWAP data channel, as defined in Section 1.4. The CAPWAP data port 1812 at the AC is the well known UDP port 5247. If an AC permits the 1813 administrator to change the CAPWAP control port, the CAPWAP data port 1814 MUST be the next consecutive port number. The CAPWAP data port at 1815 the WTP can be any port selected by the WTP. 1817 3.2. UDP-Lite Transport 1819 When CAPWAP is run over IPv6, UDP-Lite is the default transport 1820 protocol, which reduces the checksum processing required for each 1821 packet (compared to the use of UDP over IPv6 [RFC2460]). When UDP- 1822 Lite is used, the checksum field MUST have a coverage of 8 [RFC3828]. 1824 UDP-Lite uses the same port assignments as UDP. 1826 3.3. AC Discovery 1828 The AC discovery phase allows the WTP to determine which ACs are 1829 available, and chose the best AC with which to establish a CAPWAP 1830 session. The discovery phase occurs when the WTP enters the optional 1831 Discovery state. A WTP does not need to complete the AC Discovery 1832 phase if it uses a pre-configured AC. This section details the 1833 mechanism used by a WTP to dynamically discover candidate ACs. 1835 A WTP and an AC will frequently not reside in the same IP subnet 1836 (broadcast domain). When this occurs, the WTP must be capable of 1837 discovering the AC, without requiring that multicast services are 1838 enabled in the network. 1840 When the WTP attempts to establish communication with an AC, it sends 1841 the Discovery Request message and receives the Discovery Response 1842 message from the AC(s). The WTP MUST send the Discovery Request 1843 message to either the limited broadcast IP address (255.255.255.255), 1844 a well known multicast address or to the unicast IP address of the 1845 AC. For IPv6 networks, since broadcast does not exist, the use of 1846 "All ACs multicast address" is used instead. Upon receipt of the 1847 Discovery Request message, the AC sends a Discovery Response message 1848 to the unicast IP address of the WTP, regardless of whether the 1849 Discovery Request message was sent as a broadcast, multicast or 1850 unicast message. 1852 WTP use of a limited IP broadcast, multicast or unicast IP address is 1853 implementation dependent. 1855 When a WTP transmits a Discovery Request message to a unicast 1856 address, the WTP must first obtain the IP address of the AC. Any 1857 static configuration of an AC's IP address on the WTP non-volatile 1858 storage is implementation dependent. However, additional dynamic 1859 schemes are possible, for example: 1861 DHCP: See [I-D.ietf-capwap-dhc-ac-option] for more information on 1862 the use of DHCP to discover AC IP addresses. 1864 DNS: The WTP MAY support use of DNS SRV records [RFC2782] to 1865 discover the AC address(es). In this case, the WTP first obtains 1866 (e.g., from local configuration) the correct domain name suffix 1867 (e.g., "example.com") and performs a SRV lookup with Service name 1868 "capwap-control" and Proto "udp". Thus, the name resolved in DNS 1869 would be, e.g., "_capwap-control._udp.example.com". Note that the 1870 SRV record MAY specify a non-default port number for the control 1871 channel; the port number for the data channel is the next port 1872 number (control channel port + 1). 1874 An AC MAY also communicate alternative ACs to the WTP within the 1875 Discovery Response message through the AC IPv4 List (see 1876 Section 4.6.2) and AC IPv6 List (see Section 4.6.2). The addresses 1877 provided in these two message elements are intended to help the WTP 1878 discover additional ACs through means other than those listed above. 1880 The AC Name with Index message element (see Section 4.6.5), is used 1881 to communicate a list of preferred ACs to the WTP. The WTP SHOULD 1882 attempt to utilize the ACs listed in the order provided by the AC. 1883 The Name to IP Address mapping is handled via the Discovery message 1884 exchange, in which the ACs provide their identity in the AC Name (see 1885 Section 4.6.4) message element in the Discovery Response message. 1887 Once the WTP has received Discovery Response messages from the 1888 candidate ACs, it MAY use other factors to determine the preferred 1889 AC. For instance, each binding defines a WTP Radio Information 1890 message element (see Section 2.1), which the AC includes in Discovery 1891 Response messages. The presence of one or more of these message 1892 elements is used to identify the CAPWAP bindings supported by the AC. 1893 A WTP MAY connect to an AC based on the supported bindings 1894 advertised. 1896 3.4. Fragmentation/Reassembly 1898 While fragmentation and reassembly services are provided by IP, the 1899 CAPWAP protocol also provides such services. Environments where the 1900 CAPWAP protocol is used involve firewall, NAT and "middle box" 1901 devices, which tend to drop IP fragments to minimize possible DoS 1902 attacks. By providing fragmentation and reassembly at the 1903 application layer, any fragmentation required due to the tunneling 1904 component of the CAPWAP protocol becomes transparent to these 1905 intermediate devices. Consequently, the CAPWAP protocol can be used 1906 in any network topology including firewall, NAT and middlebox 1907 devices. 1909 3.5. MTU Discovery 1911 Once a WTP has discovered the AC it wishes to establish a CAPWAP 1912 session with, it SHOULD perform a Path MTU (PMTU) discovery. One 1913 recommendation for performing PMTU discovery is to have the WTP 1914 transmit Discovery Request (see Section 5.1) messages, and include 1915 the MTU Discovery Padding message element (see Section 4.6.31). The 1916 actual procedures used for PMTU discovery are described in [RFC1191], 1917 for IPv4, or for IPv6 [RFC1981] SHOULD be used. Alternatively, 1918 implementers MAY use the procedures defined in [RFC4821]. The WTP 1919 SHOULD also periodically re-evaluate the PMTU using the guidelines 1920 provided in these two RFCs, using the Primary Discovery Request (see 1921 Section 5.3) along with the MTU Discovery Padding message element 1922 (see Section 4.6.31). When the MTU is initially known, or updated in 1923 the case where an existing session already exists, the discovered 1924 PMTU is used to configure the DTLS component (see Section 2.3.2.1), 1925 while non-DTLS frames need to be fragmented to fit the MTU, defined 1926 in Section 3.4. 1928 4. CAPWAP Packet Formats 1930 This section contains the CAPWAP protocol packet formats. A CAPWAP 1931 protocol packet consists of one or more CAPWAP Transport Layer packet 1932 headers followed by a CAPWAP message. The CAPWAP message can be 1933 either of type Control or Data, where Control packets carry 1934 signaling, and Data packets carry user payloads. The CAPWAP frame 1935 formats for CAPWAP Data packets, and for DTLS encapsulated CAPWAP 1936 Data and Control packets are defined below. 1938 The CAPWAP Control protocol includes two messages that are never 1939 protected by DTLS: the Discovery Request message and the Discovery 1940 Response message. These messages need to be in the clear to allow 1941 the CAPWAP protocol to properly identify and process them. The 1942 format of these packets are as follows: 1944 CAPWAP Control Packet (Discovery Request/Response): 1945 +-------------------------------------------+ 1946 | IP | UDP | CAPWAP | Control | Message | 1947 | Hdr | Hdr | Header | Header | Element(s) | 1948 +-------------------------------------------+ 1950 All other CAPWAP control protocol messages MUST be protected via the 1951 DTLS protocol, which ensures that the packets are both authenticated 1952 and encrypted. These packets include the CAPWAP DTLS Header, which 1953 is described in Section 4.2. The format of these packets is as 1954 follows: 1956 CAPWAP Control Packet (DTLS Security Required): 1957 +------------------------------------------------------------------+ 1958 | IP | UDP | CAPWAP | DTLS | CAPWAP | Control| Message | DTLS | 1959 | Hdr | Hdr | DTLS Hdr | Hdr | Header | Header | Element(s)| Trlr | 1960 +------------------------------------------------------------------+ 1961 \---------- authenticated -----------/ 1962 \------------- encrypted ------------/ 1964 The CAPWAP protocol allows optional protection of data packets, using 1965 DTLS. Use of data packet protection is determined by AC policy. 1966 When DTLS is utilized, the optional CAPWAP DTLS Header is present, 1967 which is described in Section 4.2. The format of CAPWAP data packets 1968 is shown below: 1970 CAPWAP Plain Text Data Packet : 1971 +-------------------------------+ 1972 | IP | UDP | CAPWAP | Wireless | 1973 | Hdr | Hdr | Header | Payload | 1974 +-------------------------------+ 1976 DTLS Secured CAPWAP Data Packet: 1977 +--------------------------------------------------------+ 1978 | IP | UDP | CAPWAP | DTLS | CAPWAP | Wireless | DTLS | 1979 | Hdr | Hdr | DTLS Hdr | Hdr | Hdr | Payload | Trlr | 1980 +--------------------------------------------------------+ 1981 \------ authenticated -----/ 1982 \------- encrypted --------/ 1984 UDP Header: All CAPWAP packets are encapsulated within either UDP, 1985 or UDP-Lite when used over IPv6. Section 3 defines the specific 1986 UDP or UDP-Lite usage. 1988 CAPWAP DTLS Header: All DTLS encrypted CAPWAP protocol packets are 1989 prefixed with the CAPWAP DTLS header (see Section 4.2). 1991 DTLS Header: The DTLS header provides authentication and encryption 1992 services to the CAPWAP payload it encapsulates. This protocol is 1993 defined in RFC 4347 [RFC4347]. 1995 CAPWAP Header: All CAPWAP protocol packets use a common header that 1996 immediately follows the CAPWAP preamble or DTLS header. The 1997 CAPWAP Header is defined in Section 4.3. 1999 Wireless Payload: A CAPWAP protocol packet that contains a wireless 2000 payload is a CAPWAP data packet. The CAPWAP protocol does not 2001 specify the format of the wireless payload, which is defined by 2002 the appropriate wireless standard. Additional information is in 2003 Section 4.4. 2005 Control Header: The CAPWAP protocol includes a signaling component, 2006 known as the CAPWAP control protocol. All CAPWAP control packets 2007 include a Control Header, which is defined in Section 4.5.1. 2008 CAPWAP data packets do not contain a Control Header field. 2010 Message Elements: A CAPWAP Control packet includes one or more 2011 message elements, which are found immediately following the 2012 Control Header. These message elements are in a Type/Length/value 2013 style header, defined in Section 4.6. 2015 A CAPWAP implementation MUST be capable of receiving a reassembled 2016 CAPWAP message of length 4096 bytes. A CAPWAP implementation MAY 2017 indicate that it supports a higher maximum message length, by 2018 including the Maximum Message Length message element, see 2019 Section 4.6.30 in the Join Request message or the Join Response 2020 message. 2022 4.1. CAPWAP Preamble 2024 The CAPWAP preamble is common to all CAPWAP transport headers and is 2025 used to identify the header type that immediately follows. The 2026 reason for this preamble is to avoid needing to perform byte 2027 comparisons in order to guess whether the frame is DTLS encrypted or 2028 not. It also provides an extensibility framework that can be used to 2029 support additional transport types. The format of the preamble is as 2030 follows: 2032 0 2033 0 1 2 3 4 5 6 7 2034 +-+-+-+-+-+-+-+-+ 2035 |Version| Type | 2036 +-+-+-+-+-+-+-+-+ 2038 Version: A 4 bit field which contains the version of CAPWAP used in 2039 this packet. The value for this specification is zero (0). 2041 Payload Type: A 4 bit field which specifies the payload type that 2042 follows the UDP header. The following values are supported: 2044 0 - CAPWAP Header. The CAPWAP Header (see Section 4.3) 2045 immediately follows the UDP header. If the packet is received 2046 on the CAPWAP data channel, the CAPWAP stack MUST treat the 2047 packet as a clear text CAPWAP data packet. If received on the 2048 CAPWAP control channel, the CAPWAP stack MUST treat the packet 2049 as a clear text CAPWAP control packet. If the control packet 2050 is not a Discovery Request or Discovery Response packet, the 2051 packet MUST be dropped. 2053 1 - CAPWAP DTLS Header. The CAPWAP DTLS Header, and DTLS packet, 2054 immediately follows the UDP header (see Section 4.2). 2056 4.2. CAPWAP DTLS Header 2058 The CAPWAP DTLS Header is used to identify the packet as a DTLS 2059 encrypted packet. The first eight bits includes the common CAPWAP 2060 Preamble. The remaining 24 bits are padding to ensure 4 byte 2061 alignment, and MAY be used in a future version of the protocol. The 2062 DTLS packet [RFC4347] always immediately follows this header. The 2063 format of the CAPWAP DTLS Header is as follows: 2065 0 1 2 3 2066 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2068 |CAPWAP Preamble| Reserved | 2069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2071 CAPWAP Preamble: The CAPWAP Preamble is defined in Section 4.1. The 2072 CAPWAP Preamble's Payload Type field MUST be set to one (1). 2074 Reserved: The 24-bit field is reserved for future use. All 2075 implementations complying with this protocol MUST set to zero any 2076 bits that are reserved in the version of the protocol supported by 2077 that implementation. Receivers MUST ignore all bits not defined 2078 for the version of the protocol they support. 2080 4.3. CAPWAP Header 2082 All CAPWAP protocol messages are encapsulated using a common header 2083 format, regardless of the CAPWAP Control or CAPWAP Data transport 2084 used to carry the messages. However, certain flags are not 2085 applicable for a given transport. Refer to the specific transport 2086 section in order to determine which flags are valid. 2088 Note that the optional fields defined in this section MUST be present 2089 in the precise order shown below. 2091 0 1 2 3 2092 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 2093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2094 |CAPWAP Preamble| HLEN | RID | WBID |T|F|L|W|M|K|Flags| 2095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2096 | Fragment ID | Frag Offset |Rsvd | 2097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2098 | (optional) Radio MAC Address | 2099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2100 | (optional) Wireless Specific Information | 2101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2102 | Payload .... | 2103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2105 CAPWAP Preamble: The CAPWAP Preamble is defined in Section 4.1. The 2106 CAPWAP Preamble's Payload Type field MUST be set to zero (0). If 2107 the CAPWAP DTLS Header is present, the version number in both 2108 CAPWAP Preambles MUST match. The reason for this duplicate field 2109 is to avoid any possible tampering of the version field in the 2110 preamble which is not encrypted or authenticated. 2112 HLEN: A 5 bit field containing the length of the CAPWAP transport 2113 header in 4 byte words (Similar to IP header length). This length 2114 includes the optional headers. 2116 RID: A 5 bit field which contains the Radio ID number for this 2117 packet. Given that MAC Addresses are not necessarily unique 2118 across physical radios in a WTP, the Radio Identifier (RID) field 2119 is used to indicate which physical radio the message is associated 2120 with. 2122 WBID: A 5 bit field which is the wireless binding identifier. The 2123 identifier will indicate the type of wireless packet associated 2124 with the radio. The following values are defined: 2126 0 - Reserved 2128 1 - IEEE 802.11 2130 2 - Reserved 2132 3 - EPCGlobal [EPCGlobal] 2134 T: The Type 'T' bit indicates the format of the frame being 2135 transported in the payload. When this bit is set to one (1), the 2136 payload has the native frame format indicated by the WBID field. 2137 When this bit is zero (0) the payload is an IEEE 802.3 frame. 2139 F: The Fragment 'F' bit indicates whether this packet is a fragment. 2140 When this bit is one (1), the packet is a fragment and MUST be 2141 combined with the other corresponding fragments to reassemble the 2142 complete information exchanged between the WTP and AC. 2144 L: The Last 'L' bit is valid only if the 'F' bit is set and indicates 2145 whether the packet contains the last fragment of a fragmented 2146 exchange between WTP and AC. When this bit is 1, the packet is 2147 the last fragment. When this bit is 0, the packet is not the last 2148 fragment. 2150 W: The Wireless 'W' bit is used to specify whether the optional 2151 Wireless Specific Information field is present in the header. A 2152 value of one (1) is used to represent the fact that the optional 2153 header is present. 2155 M: The M bit is used to indicate that the Radio MAC Address optional 2156 header is present. This is used to communicate the MAC address of 2157 the receiving radio. 2159 K: The 'Keep-alive' K bit indicates the packet is a Data Channel Keep 2160 Alive packet. This packet is used to map the data channel to the 2161 control channel for the specified Session ID and to maintain 2162 freshness of the data channel. The K bit MUST NOT be set for data 2163 packets containing user data. 2165 Flags: A set of reserved bits for future flags in the CAPWAP header. 2166 All implementations complying with this protocol MUST set to zero 2167 any bits that are reserved in the version of the protocol 2168 supported by that implementation. Receivers MUST ignore all bits 2169 not defined for the version of the protocol they support. 2171 Fragment ID: A 16 bit field whose value is assigned to each group of 2172 fragments making up a complete set. The fragment ID space is 2173 managed individually for every WTP/AC pair. The value of Fragment 2174 ID is incremented with each new set of fragments. The Fragment ID 2175 wraps to zero after the maximum value has been used to identify a 2176 set of fragments. 2178 Fragment Offset: A 13 bit field that indicates where in the payload 2179 this fragment belongs during re-assembly. This field is valid 2180 when the 'F' bit is set to 1. The fragment offset is measured in 2181 units of 8 octets (64 bits). The first fragment has offset zero. 2182 Note the CAPWAP protocol does not allow for overlapping fragments. 2184 Reserved: The 3-bit field is reserved for future use. All 2185 implementations complying with this protocol MUST set to zero any 2186 bits that are reserved in the version of the protocol supported by 2187 that implementation. Receivers MUST ignore all bits not defined 2188 for the version of the protocol they support. 2190 Radio MAC Address: This optional field contains the MAC address of 2191 the radio receiving the packet. Because the native wireless frame 2192 format to IEEE 802.3 format causes the MAC address of the WTP's 2193 radio to be lost, this field allows the address to be communicated 2194 to the AC. This field is only present if the 'M' bit is set. The 2195 HLEN field assumes 4 byte alignment, and this field MUST be padded 2196 with zeroes (0x00) if it is not 4 byte aligned. 2198 The field contains the basic format: 2200 0 1 2 3 2201 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 2202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2203 | Length | MAC Address 2204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2206 Length: The length of the MAC Address field. The following 2207 formats, and lengths, are supported [EUI-48] and [EUI-64]. 2209 MAC Address: The MAC Address of the receiving radio. 2211 Wireless Specific Information: This optional field contains 2212 technology specific information that may be used to carry per 2213 packet wireless information. This field is only present if the 2214 'W' bit is set. The WBID field in the CAPWAP header is used to 2215 identify the format of the wireless specific information optional 2216 field. The HLEN field assumes 4 byte alignment, and this field 2217 MUST be padded with zeroes (0x00) if it is not 4 byte aligned. 2219 The Wireless Specific Information field uses the following format: 2221 0 1 2 3 2222 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2224 | Length | Data... 2225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2227 Length: The 8 bit field contains the length of the data field, 2228 with a maximum size of 255. 2230 Data: Wireless specific information, defined by the wireless 2231 specific binding specified in the CAPWAP Header's WBID field. 2233 Payload: This field contains the header for a CAPWAP Data Message or 2234 CAPWAP Control Message, followed by the data contained in the 2235 message. 2237 4.4. CAPWAP Data Messages 2239 There are two different types of CAPWAP data packets, CAPWAP Data 2240 Channel Keep Alive packets and Data Payload packets. The first is 2241 used by the WTP to synchronize the control and data channels, and to 2242 maintain freshness of the data channel. The second is used to 2243 transmit user payloads between the AC and WTP. This section 2244 describes both types of CAPWAP data packet formats. 2246 Both CAPWAP data messages are transmitted on the CAPWAP data channel. 2248 4.4.1. CAPWAP Data Channel Keepalive 2250 The CAPWAP Data Channel Keep Alive packet is used to bind the CAPWAP 2251 control channel with the data channel, and to maintain freshness of 2252 the data channel, ensuring that the channel is still functioning. 2253 The CAPWAP Data Channel Keep Alive packet is transmitted by the WTP 2254 when the DataChannelKeepAlive timer expires (see Section 4.7.2). 2255 When the CAPWAP Data Channel Keep Alive packet is transmitted, the 2256 WTP sets the DataChannelDeadInterval timer. 2258 In the CAPWAP Data Channel Keep Alive packet, all of the fields in 2259 the CAPWAP header, except the HLEN field and the K bit, are set to 2260 zero upon transmission. Upon receiving a CAPWAP Data Channel Keep 2261 Alive packet, the AC transmits a CAPWAP Data Channel Keep Alive 2262 packet back to the WTP. The contents of the transmitted packet are 2263 identical to the contents of the received packet. 2265 Upon receiving a CAPWAP Data Channel Keep Alive packet, the WTP 2266 cancels the DataChannelDeadInterval timer and resets the 2267 DataChannelKeepAlive timer. The CAPWAP Data Channel Keep Alive 2268 packet is retransmitted by the WTP in the same manner as the CAPWAP 2269 control messages. If the DataChannelDeadInterval timer expires, the 2270 WTP tears down the control DTLS session, and the data DTLS session if 2271 one existed. 2273 The CAPWAP Data Channel Keep Alive packet contains the following 2274 payload immediately following the CAPWAP Header (see Section 4.3) 2276 0 1 2 3 2277 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2279 | Message Element Length | Message Element [0..N] ... 2280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2282 Message Element Length: The 16 bit Length field indicates the 2283 number of bytes following the CAPWAP Header, with a maximum size 2284 of 65535. 2286 Message Element[0..N]: The message element(s) carry the information 2287 pertinent to each of the CAPWAP Data Channel Keepalive message. 2288 The following message elements MUST be present in this CAPWAP 2289 message: 2291 Session ID, see Section 4.6.36 2293 4.4.2. Data Payload 2295 A CAPWAP protocol Data Payload packet encapsulates a forwarded 2296 wireless frame. The CAPWAP protocol defines two different modes of 2297 encapsulation; IEEE 802.3 and native wireless. IEEE 802.3 2298 encapsulation requires that for 802.11 frames, the 802.11 2299 *Integration* function be performed in the WTP. An IEEE 802.3 2300 encapsulated user payload frame has the following format: 2302 +------------------------------------------------------+ 2303 | IP Header | UDP Header | CAPWAP Header | 802.3 Frame | 2304 +------------------------------------------------------+ 2306 The CAPWAP protocol also defines the native wireless encapsulation 2307 mode. The format of the encapsulated CAPWAP data frame is subject to 2308 the rules defined by the specific wireless technology binding. Each 2309 wireless technology binding MUST contain a section entitled "Payload 2310 Encapsulation", which defines the format of the wireless payload that 2311 is encapsulated within CAPWAP Data packets. 2313 For 802.3 payload frames, the 802.3 frame is encapsulated (excluding 2314 the IEEE 802.3 Preamble, Start Frame Delimiter (SFD) and Frame Check 2315 Sequence (FCS) Fields). If the encapsulated frame would exceed the 2316 transport layer's MTU, the sender is responsible for fragmentation of 2317 the frame, as specified in Section 3.4. The CAPWAP protocol can 2318 support IEEE 802.3 frames whose length is defined in the IEEE 802.3as 2319 specification [FRAME-EXT]. 2321 4.4.3. Establishment of a DTLS Data Channel 2323 If the AC and WTP are configured to tunnel the data channel over 2324 DTLS, the proper DTLS session must be initiated. To avoid having to 2325 reauthenticate and reauthorize an AC and WTP, the DTLS data channel 2326 SHOULD be initiated using the TLS session resumption feature 2327 [RFC4346]. 2329 The AC DTLS implementation MUST NOT initiate a data channel session 2330 for a DTLS session for which there is no active control channel 2331 session. 2333 4.5. CAPWAP Control Messages 2335 The CAPWAP Control protocol provides a control channel between the 2336 WTP and the AC. Control messages are divided into the following 2337 message types: 2339 Discovery: CAPWAP Discovery messages are used to identify potential 2340 ACs, their load and capabilities. 2342 Join: CAPWAP Join messages are used by a WTP to request service from 2343 an AC, and for the AC to respond to the WTP. 2345 Control Channel Management: CAPWAP control channel management 2346 messages are used to maintain the control channel. 2348 WTP Configuration Management: The WTP Configuration messages are 2349 used by the AC to deliver a specific configuration to the WTP. 2350 Messages which retrieve statistics from a WTP are also included in 2351 WTP Configuration Management. 2353 Station Session Management: Station Session Management messages are 2354 used by the AC to deliver specific station policies to the WTP. 2356 Device Management Operations: Device management operations are used 2357 to request and deliver a firmware image to the WTP. 2359 Binding Specific CAPWAP Management Messages: Messages in this 2360 category are used by the AC and the WTP to exchange protocol- 2361 specific CAPWAP management messages. These messages may or may 2362 not be used to change the link state of a station. 2364 Discovery, Join, Control Channel Management, WTP Configuration 2365 Management and Station Session Management CAPWAP control messages 2366 MUST be implemented. Device Management Operations messages MAY be 2367 implemented. 2369 CAPWAP control messages sent from the WTP to the AC indicate that the 2370 WTP is operational, providing an implicit keep-alive mechanism for 2371 the WTP. The Control Channel Management Echo Request and Echo 2372 Response messages provide an explicit keep-alive mechanism when other 2373 CAPWAP control messages are not exchanged. 2375 4.5.1. Control Message Format 2377 All CAPWAP control messages are sent encapsulated within the CAPWAP 2378 header (see Section 4.3). Immediately following the CAPWAP header, 2379 is the control header, which has the following format: 2381 0 1 2 3 2382 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 2383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2384 | Message Type | 2385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2386 | Seq Num | Msg Element Length | Flags | 2387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2388 | Msg Element [0..N] ... 2389 +-+-+-+-+-+-+-+-+-+-+-+-+ 2391 4.5.1.1. Message Type 2393 The Message Type field identifies the function of the CAPWAP control 2394 message. To provide extensibility, the Message Type field is 2395 comprised of an IANA Enterprise Number [RFC3232] and an enterprise 2396 specific message type number. The first three octets contain the 2397 IANA Enterprise Number in network byte order, with zero used for 2398 CAPWAP base protocol (this specification) defined message types. The 2399 last octet is the enterprise specific message type number, which has 2400 a range from 0 to 255. 2402 The message type field is defined as: 2404 Message Type = 2405 IANA Enterprise Number * 256 + 2406 Enterprise Specific Message Type Number 2408 The CAPWAP protocol reliability mechanism requires that messages be 2409 defined in pairs, consisting of both a Request and a Response 2410 message. The Response message MUST acknowledge the Request message. 2411 The assignment of CAPWAP control Message Type Values always occurs in 2412 pairs. All Request messages have odd numbered Message Type Values, 2413 and all Response messages have even numbered Message Type Values. 2414 The Request value MUST be assigned first. As an example, assigning a 2415 Message Type Value of 3 for a Request message and 4 for a Response 2416 message is valid, while assigning a Message Type Value of 4 for a 2417 Response message and 5 for the corresponding Request message is 2418 invalid. 2420 When a WTP or AC receives a message with a Message Type Value field 2421 that is not recognized and is an odd number, the number in the 2422 Message Type Value Field is incremented by one, and a Response 2423 message with a Message Type Value field containing the incremented 2424 value and containing the Result Code message element with the value 2425 (Unrecognized Request) is returned to the sender of the received 2426 message. If the unknown message type is even, the message is 2427 ignored. 2429 The valid values for CAPWAP Control Message Types are specified in 2430 the table below: 2432 CAPWAP Control Message Message Type 2433 Value 2434 Discovery Request 1 2435 Discovery Response 2 2436 Join Request 3 2437 Join Response 4 2438 Configuration Status Request 5 2439 Configuration Status Response 6 2440 Configuration Update Request 7 2441 Configuration Update Response 8 2442 WTP Event Request 9 2443 WTP Event Response 10 2444 Change State Event Request 11 2445 Change State Event Response 12 2446 Echo Request 13 2447 Echo Response 14 2448 Image Data Request 15 2449 Image Data Response 16 2450 Reset Request 17 2451 Reset Response 18 2452 Primary Discovery Request 19 2453 Primary Discovery Response 20 2454 Data Transfer Request 21 2455 Data Transfer Response 22 2456 Clear Configuration Request 23 2457 Clear Configuration Response 24 2458 Station Configuration Request 25 2459 Station Configuration Response 26 2461 4.5.1.2. Sequence Number 2463 The Sequence Number Field is an identifier value used to match 2464 Request and Response packets. When a CAPWAP packet with a Request 2465 Message Type Value is received, the value of the Sequence Number 2466 field is copied into the corresponding Response message. 2468 When a CAPWAP control message is sent, the sender's internal sequence 2469 number counter is monotonically incremented, ensuring that no two 2470 pending Request messages have the same Sequence Number. The Sequence 2471 Number field wraps back to zero. 2473 4.5.1.3. Message Element Length 2475 The Length field indicates the number of bytes following the Sequence 2476 Number field. 2478 4.5.1.4. Flags 2480 The Flags field MUST be set to zero. 2482 4.5.1.5. Message Element[0..N] 2484 The message element(s) carry the information pertinent to each of the 2485 control message types. Every control message in this specification 2486 specifies which message elements are permitted. 2488 When a WTP or AC receives a CAPWAP message without a message element 2489 that is specified as mandatory for the CAPWAP message, then the 2490 CAPWAP message is discarded. If the received message was a Request 2491 message for which the corresponding Response message carries message 2492 elements, then a corresponding Response message with a Result Code 2493 message element indicating "Failure - Missing Mandatory Message 2494 Element" is returned to the sender. 2496 When a WTP or AC receives a CAPWAP message with a message element 2497 that the WTP or AC does not recognize, the CAPWAP message is 2498 discarded. If the received message was a Request message for which 2499 the corresponding Response message carries message elements, then a 2500 corresponding Response message with a Result Code message element 2501 indicating "Failure - Unrecognized Message Element" and one or more 2502 Returned Message Element message elements is included, containing the 2503 unrecognized message element(s). 2505 4.5.2. Control Message Quality of Service 2507 It is recommended that CAPWAP control messages be sent by both the AC 2508 and the WTP with an appropriate Quality of Service precedence value, 2509 ensuring that congestion in the network minimizes occurrences of 2510 CAPWAP control channel disconnects. Therefore, a Quality of Service 2511 enabled CAPWAP device SHOULD use the following values: 2513 802.1Q: The priority tag of 7 SHOULD be used. 2515 DSCP: The DSCP value of 46 SHOULD be used. 2517 4.5.3. Retransmissions 2519 The CAPWAP control protocol operates as a reliable transport. For 2520 each Request message, a Response message is defined, which is used to 2521 acknowledge receipt of the Request message. In addition, the control 2522 header Sequence Number field is used to pair the Request and Response 2523 messages (see Section 4.5.1). 2525 Response messages are not explicitly acknowledged, therefore if a 2526 Response message is not received, the original Request message is 2527 retransmitted. 2529 Implementations MUST keep track of the Sequence Number of the last 2530 received Request message, and MUST cache the corresponding Response 2531 message. If a retransmission with the same Sequence Number is 2532 received, the cached Response message MUST be retransmitted without 2533 re-processing the Request. If an older Request message (with smaller 2534 Sequence Number modulo 32) is received, it MUST be ignored. A newer 2535 Request message (with larger Sequence Number modulo 32) is processed 2536 as usual. 2538 Both the WTP and the AC can only have a single request outstanding at 2539 any given time. Retransmitted Request messages MUST NOT be altered 2540 by the sender. 2542 After transmitting a Request message, the RetransmitInterval (see 2543 Section 4.7) timer and MaxRetransmit (see Section 4.8) variable are 2544 used to determine if the original Request message needs to be 2545 retransmitted. The RetransmitInterval timer is used the first time 2546 the Request is retransmitted. The timer is then doubled every 2547 subsequent time the same Request message is retransmitted, up to 2548 MaxRetransmit but no more than half the EchoInterval timer (see 2549 Section 4.7.7). Response messages are not subject to these timers. 2551 If the sender stops retransmitting a Request message before reaching 2552 MaxRetransmit retransmissions (which leads to transition to DTLS 2553 Teardown, as described in Section 2.3.1), it cannot know whether the 2554 recipient received and processed the Request or not. In most 2555 situations, the sender SHOULD NOT do this, and instead continue 2556 retransmitting until a Response message is received, or transition to 2557 DTLS Teardown occurs. However, if the sender does decide to continue 2558 the connection with a new or modified Request message, the new 2559 message MUST have a new Sequence Number, and be treated as a new 2560 Request message by the receiver. 2562 When a Request message is retransmitted, it MUST be re-encrypted via 2563 the DTLS stack. If the peer had received the Request message, and 2564 the corresponding Response message was lost, it is necessary to 2565 ensure that retransmitted Request messages are not identified as 2566 replays by the DTLS stack. Similarly, any cached Response messages 2567 that are retransmitted as a result of receiving a retransmitted 2568 Request message MUST be re-encrypted via DTLS. 2570 Duplicate Response messages, identified by the Sequence Number field 2571 in the CAPWAP control message header, SHOULD be discarded upon 2572 receipt. 2574 4.6. CAPWAP Protocol Message Elements 2576 This section defines the CAPWAP Protocol message elements which are 2577 included in CAPWAP protocol control messages. 2579 Message elements are used to carry information needed in control 2580 messages. Every message element is identified by the Type Value 2581 field, defined below. The total length of the message elements is 2582 indicated in the message element Length field. 2584 All of the message element definitions in this document use a diagram 2585 similar to the one below in order to depict its format. Note that to 2586 simplify this specification, these diagrams do not include the header 2587 fields (Type and Length). The header field values are defined in the 2588 message element descriptions. 2590 Unless otherwise specified, a control message that lists a set of 2591 supported (or expected) message elements MUST NOT expect the message 2592 elements to be in any specific order. The sender MAY include the 2593 message elements in any order. Unless otherwise noted, one message 2594 element of each type is present in a given control message. 2596 Unless otherwise specified, any configuration information sent by the 2597 AC to the WTP MAY be saved to non-volatile storage (see Section 8.1) 2598 for more information). 2600 Additional message elements may be defined in separate IETF 2601 documents. 2603 The format of a message element uses the TLV format shown here: 2605 0 1 2 3 2606 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 2607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2608 | Type | Length | 2609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2610 | Value ... | 2611 +-+-+-+-+-+-+-+-+ 2613 The 16 bit Type field identifies the information carried in the Value 2614 field and Length (16 bits) indicates the number of bytes in the Value 2615 field. Type field values are allocated as follows: 2617 Usage Type Values 2619 CAPWAP Protocol Message Elements 1 - 1023 2620 IEEE 802.11 Message Elements 1024 - 2047 2621 Reserved for Future Use 2048 - 3071 2622 EPCGlobal Message Elements 3072 - 4095 2623 Reserved for Future Use 4096 - 65024 2625 The table below lists the CAPWAP protocol Message Elements and their 2626 Type values. 2628 CAPWAP Message Element Type Value 2630 AC Descriptor 1 2631 AC IPv4 List 2 2632 AC IPv6 List 3 2633 AC Name 4 2634 AC Name with Index 5 2635 AC Timestamp 6 2636 Add MAC ACL Entry 7 2637 Add Station 8 2638 Reserved 9 2639 CAPWAP Control IPV4 Address 10 2640 CAPWAP Control IPV6 Address 11 2641 CAPWAP Local IPV4 Address 30 2642 CAPWAP Local IPV6 Address 50 2643 CAPWAP Timers 12 2644 CAPWAP Transport Protocol 51 2645 Data Transfer Data 13 2646 Data Transfer Mode 14 2647 Decryption Error Report 15 2648 Decryption Error Report Period 16 2649 Delete MAC ACL Entry 17 2650 Delete Station 18 2651 Reserved 19 2652 Discovery Type 20 2653 Duplicate IPv4 Address 21 2654 Duplicate IPv6 Address 22 2655 Idle Timeout 23 2656 Image Data 24 2657 Image Identifier 25 2658 Image Information 26 2659 Initiate Download 27 2660 Location Data 28 2661 Maximum Message Length 29 2662 MTU Discovery Padding 52 2663 Radio Administrative State 31 2664 Radio Operational State 32 2665 Result Code 33 2666 Returned Message Element 34 2667 Session ID 35 2668 Statistics Timer 36 2669 Vendor Specific Payload 37 2670 WTP Board Data 38 2671 WTP Descriptor 39 2672 WTP Fallback 40 2673 WTP Frame Tunnel Mode 41 2674 Reserved 42 2675 Reserved 43 2676 WTP MAC Type 44 2677 WTP Name 45 2678 Unused/Reserved 46 2679 WTP Radio Statistics 47 2680 WTP Reboot Statistics 48 2681 WTP Static IP Address Information 49 2683 4.6.1. AC Descriptor 2685 The AC Descriptor message element is used by the AC to communicate 2686 its current state. The value contains the following fields. 2688 0 1 2 3 2689 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 2690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2691 | Stations | Limit | 2692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2693 | Active WTPs | Max WTPs | 2694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2695 | Security | R-MAC Field | Reserved1 | DTLS Policy | 2696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2697 | AC Information Sub-Element... 2698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2700 Type: 1 for AC Descriptor 2702 Length: >= 12 2704 Stations: The number of stations currently served by the AC 2706 Limit: The maximum number of stations supported by the AC 2708 Active WTPs: The number of WTPs currently attached to the AC 2709 Max WTPs: The maximum number of WTPs supported by the AC 2711 Security: A 8 bit mask specifying the authentication credential 2712 type supported by the AC (See Section 2.4.4). The field has the 2713 following format: 2715 0 1 2 3 4 5 6 7 2716 +-+-+-+-+-+-+-+-+ 2717 |Reserved |S|X|U| 2718 +-+-+-+-+-+-+-+-+ 2720 Reserved: A set of reserved bits for future use. All 2721 implementations complying with this protocol MUST set to zero 2722 any bits that are reserved in the version of the protocol 2723 supported by that implementation. Receivers MUST ignore all 2724 bits not defined for the version of the protocol they support. 2726 S: The AC supports the pre-shared secret authentication, as 2727 described in Section 12.6. 2729 X: The AC supports X.509 Certificate authentication, as 2730 described in Section 12.7. 2732 U: This bit is set to zero and is unused. 2734 R-MAC Field: The AC supports the optional Radio MAC Address field 2735 in the CAPWAP transport Header (see Section 4.3). The following 2736 enumerated values are supported: 2738 0 - Reserved 2740 1 - Supported 2742 2 - Not Supported 2744 Reserved: A set of reserved bits for future use. All 2745 implementations complying with this protocol MUST set to zero any 2746 bits that are reserved in the version of the protocol supported by 2747 that implementation. Receivers MUST ignore all bits not defined 2748 for the version of the protocol they support. 2750 DTLS Policy: The AC communicates its policy on the use of DTLS for 2751 the CAPWAP data channel. The AC MAY communicate more than one 2752 supported option, represented by the bit field below. The WTP 2753 MUST abide by one of the options communicated by AC. The field 2754 has the following format: 2756 0 1 2 3 4 5 6 7 2757 +-+-+-+-+-+-+-+-+ 2758 |Reserved |D|C|U| 2759 +-+-+-+-+-+-+-+-+ 2761 Reserved: A set of reserved bits for future use. All 2762 implementations complying with this protocol MUST set to zero 2763 any bits that are reserved in the version of the protocol 2764 supported by that implementation. Receivers MUST ignore all 2765 bits not defined for the version of the protocol they support. 2767 D: DTLS Enabled Data Channel Supported 2769 C: Clear Text Data Channel Supported 2771 U: This bit is set to zero and is unused. 2773 AC Information Sub-Element: The AC Descriptor message element 2774 contains multiple AC Information sub-elements, and defines two 2775 sub-types, each of which MUST be present. The AC Information sub- 2776 element has the following format: 2778 0 1 2 3 2779 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 2780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2781 | AC Information Vendor Identifier | 2782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2783 | AC Information Type | AC Information Length | 2784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2785 | AC Information Data... 2786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2788 AC Information Vendor Identifier: A 32-bit value containing the 2789 IANA assigned "SMI Network Management Private Enterprise Codes" 2791 AC Information Type: Vendor specific encoding of AC information. 2792 The following enumerated values are supported. Both the 2793 Hardware and Software Version sub-elements MUST be included in 2794 the AC Descriptor message element. The values listed below are 2795 used in conjunction with the AC Information Vendor Identifier 2796 field, whose value MUST be set to zero (0). 2798 4 - Hardware Version: The AC's hardware version number. 2800 5 - Software Version: The AC's Software (firmware) version 2801 number. 2803 AC Information Length: Length of vendor specific encoding of AC 2804 information, with a maximum size of 1024. 2806 AC Information Data: Vendor specific encoding of AC information. 2808 4.6.2. AC IPv4 List 2810 The AC IPv4 List message element is used to configure a WTP with the 2811 latest list of ACs available for the WTP to join. 2813 0 1 2 3 2814 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 2815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2816 | AC IP Address[] | 2817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2819 Type: 2 for AC IPv4 List 2821 Length: >= 4 2823 AC IP Address: An array of 32-bit integers containing AC IPv4 2824 Addresses, containing no more than 1024 addresses. 2826 4.6.3. AC IPv6 List 2828 The AC IPv6 List message element is used to configure a WTP with the 2829 latest list of ACs available for the WTP to join. 2831 0 1 2 3 2832 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 2833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2834 | AC IP Address[] | 2835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2836 | AC IP Address[] | 2837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2838 | AC IP Address[] | 2839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2840 | AC IP Address[] | 2841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2843 Type: 3 for AC IPV6 List 2844 Length: >= 16 2846 AC IP Address: An array of 128-bit integers containing AC IPv6 2847 Addresses, containing no more than 1024 addresses. 2849 4.6.4. AC Name 2851 The AC Name message element contains an UTF-8 [RFC3629] 2852 representation of the AC identity. The value is a variable length 2853 byte string. The string is NOT zero terminated. 2855 0 2856 0 1 2 3 4 5 6 7 2857 +-+-+-+-+-+-+-+-+ 2858 | Name ... 2859 +-+-+-+-+-+-+-+-+ 2861 Type: 4 for AC Name 2863 Length: >= 1 2865 Name: A variable length UTF-8 encoded string [RFC3629] containing 2866 the AC's name, whose maximum size MUST NOT exceed 512 bytes. 2868 4.6.5. AC Name with Index 2870 The AC Name with Index message element is sent by the AC to the WTP 2871 to configure preferred ACs. The number of instances of this message 2872 element is equal to the number of ACs configured on the WTP. The WTP 2873 also uses this message element to send its configuration to the AC. 2875 0 1 2876 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2878 | Priority | AC Name... 2879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2881 Type: 5 for AC Name with Index 2883 Length: >= 2 2885 Priority: A value between 1 and 255 specifying the priority order 2886 of the preferred AC. For instance, the value of one (1) is used 2887 to set the primary AC, the value of two (2) is used to set the 2888 secondary, etc. 2890 AC Name: A variable length UTF-8 encoded string [RFC3629] 2891 containing the AC name, whose maximum size MUST NOT exceed 512 2892 bytes. 2894 4.6.6. AC Timestamp 2896 The AC Timestamp message element is sent by the AC to synchronize the 2897 WTP clock. 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 | Timestamp | 2903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2905 Type: 6 for AC Timestamp 2907 Length: 4 2909 Timestamp: The AC's current time, allowing all of the WTPs to be 2910 time synchronized in the format defined by Network Time Protocol 2911 (NTP) in RFC 1305 [RFC1305]. Only the most significant 32 bits of 2912 the NTP time is included in this field. 2914 4.6.7. Add MAC ACL Entry 2916 The Add MAC Access Control List (ACL) Entry message element is used 2917 by an AC to add a MAC ACL list entry on a WTP, ensuring that the WTP 2918 no longer provides service to the MAC addresses provided in the 2919 message. The MAC Addresses provided in this message element are not 2920 expected to be saved in non-volatile memory on the WTP. The MAC ACL 2921 table on the WTP is cleared everytime the WTP establishes a new 2922 session with an AC. 2924 0 1 2 3 2925 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 2926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2927 | Num of Entries| Length | MAC Address ... 2928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2930 Type: 7 for Add MAC ACL Entry 2932 Length: >= 8 2934 Num of Entries: The number of instances of the Length/MAC Addresses 2935 fields in the array. This value MUST NOT exceed 255. 2937 Length: The length of the MAC Address field. The following formats, 2938 and lengths, are supported [EUI-48] and [EUI-64]. 2940 MAC Address: MAC Addresses to add to the ACL. 2942 4.6.8. Add Station 2944 The Add Station message element is used by the AC to inform a WTP 2945 that it should forward traffic for a station. The Add Station 2946 message element is accompanied by technology specific binding 2947 information element(s) which may include security parameters. 2948 Consequently, the security parameters MUST be applied by the WTP for 2949 the station. 2951 After station policy has been delivered to the WTP through the Add 2952 Station message element, an AC MAY change any policies by sending a 2953 modified Add Station message element. When a WTP receives an Add 2954 Station message element for an existing station, it MUST override any 2955 existing state for the station. 2957 0 1 2 3 2958 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 2959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2960 | Radio ID | Length | MAC Address ... 2961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2962 | VLAN Name... 2963 +-+-+-+-+-+-+-+-+ 2965 Type: 8 for Add Station 2967 Length: >= 8 2969 Radio ID: An 8-bit value representing the radio 2971 Length: The length of the MAC Address field. The following formats, 2972 and lengths, are supported [EUI-48] and [EUI-64]. 2974 MAC Address: The station's MAC Address 2976 VLAN Name: An optional variable length UTF-8 encoded 2977 string[RFC3629], with a maximum length of 512 octets, containing 2978 the VLAN Name on which the WTP is to locally bridge user data. 2979 Note this field is only valid with WTPs configured in Local MAC 2980 mode. 2982 4.6.9. CAPWAP Control IPv4 Address 2984 The CAPWAP Control IPv4 Address message element is sent by the AC to 2985 the WTP during the discovery process and is used by the AC to provide 2986 the interfaces available on the AC, and the current number of WTPs 2987 connected. When multiple CAPWAP Control IPV4 Address message 2988 elements are returned, the WTP SHOULD perform load balancing across 2989 the multiple interfaces. 2991 0 1 2 3 2992 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 2993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2994 | IP Address | 2995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2996 | WTP Count | 2997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2999 Type: 10 for CAPWAP Control IPv4 Address 3001 Length: 6 3003 IP Address: The IP Address of an interface. 3005 WTP Count: The number of WTPs currently connected to the interface, 3006 with a maximum value of 65535. 3008 4.6.10. CAPWAP Control IPv6 Address 3010 The CAPWAP Control IPv6 Address message element is sent by the AC to 3011 the WTP during the discovery process and is used by the AC to provide 3012 the interfaces available on the AC, and the current number of WTPs 3013 connected. This message element is useful for the WTP to perform 3014 load balancing across multiple interfaces. 3016 0 1 2 3 3017 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 3018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3019 | IP Address | 3020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3021 | IP Address | 3022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3023 | IP Address | 3024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3025 | IP Address | 3026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3027 | WTP Count | 3028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3030 Type: 11 for CAPWAP Control IPv6 Address 3032 Length: 18 3034 IP Address: The IP Address of an interface. 3036 WTP Count: The number of WTPs currently connected to the interface, 3037 with a maximum value of 65535. 3039 4.6.11. CAPWAP Local IPv4 Address 3041 The CAPWAP Local IPv4 Address message element is sent by either the 3042 WTP, in the Join Request, or by the AC, in the Join Response. The 3043 CAPWAP Local IPv4 Address message element is used to communicate the 3044 IP Address of the transmitter. The receiver uses this to determine 3045 whether a middlebox exists between the two peers, by comparing the 3046 source IP address of the packet against the value of the message 3047 element. 3049 0 1 2 3 3050 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 3051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3052 | IP Address | 3053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3055 Type: 30 for CAPWAP Local IPv4 Address 3057 Length: 4 3059 IP Address: The IP Address of the sender. 3061 4.6.12. CAPWAP Local IPv6 Address 3063 The CAPWAP Local IPv6 Address message element is sent by either the 3064 WTP, in the Join Request, or by the AC, in the Join Response. The 3065 CAPWAP Local IPv6 Address message element is used to communicate the 3066 IP Address of the transmitter. The receiver uses this to determine 3067 whether a middlebox exists between the two peers, by comparing the 3068 source IP address of the packet against the value of the message 3069 element. 3071 0 1 2 3 3072 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 3073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3074 | IP Address | 3075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3076 | IP Address | 3077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3078 | IP Address | 3079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3080 | IP Address | 3081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3083 Type: 50 for CAPWAP Local IPv6 Address 3085 Length: 16 3087 IP Address: The IP Address of the sender. 3089 4.6.13. CAPWAP Timers 3091 The CAPWAP Timers message element is used by an AC to configure 3092 CAPWAP timers on a WTP. 3094 0 1 3095 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3097 | Discovery | Echo Request | 3098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3100 Type: 12 for CAPWAP Timers 3102 Length: 2 3104 Discovery: The number of seconds between CAPWAP Discovery messages, 3105 when the WTP is in the discovery phase. This value is used to 3106 configure the MaxDiscoveryInterval timer (see Section 4.7.10). 3108 Echo Request: The number of seconds between WTP Echo Request CAPWAP 3109 messages. This value is used to configure the EchoInterval timer 3110 (see Section 4.7.7). The AC sets its EchoInterval timer to this 3111 value, plus the maximum retransmission time as described in 3112 Section 4.5.3. 3114 4.6.14. CAPWAP Transport Protocol 3116 When CAPWAP is run over IPv6, the UDP-Lite or UDP transports MAY be 3117 used (see Section 3). The CAPWAP IPv6 Transport Protocol message 3118 element is used by either the WTP or the AC to signal which transport 3119 protocol is to be used for the CAPWAP data channel. 3121 Upon receiving the Join Request, the AC MAY set the CAPWAP Transport 3122 Protocol to UDP-Lite in the Join Response message if the CAPWAP 3123 message was received over IPv6, and the CAPWAP Local IPv6 Address 3124 message element (see Section 4.6.12) is present and no middlebox was 3125 detected (see Section 11). 3127 Upon receiving the Join Response, the WTP MAY set the CAPWAP 3128 Transport Protocol to UDP-Lite in the Configuration Status Request or 3129 Image Data Request message if the AC advertised support for UDP-Lite, 3130 the message was received over IPv6, the CAPWAP Local IPv6 Address 3131 message element (see Section 4.6.12) and no middlebox was detected 3132 (see Section 11). Upon receiving either the Configuration Status 3133 Request or the Image Data Request, the AC MUST observe the preference 3134 indicated by the WTP in the CAPWAP Transport Protocol, as long as it 3135 is consistent with what the AC advertised in the Join Response. 3137 For any other condition, the CAPWAP Transport Protocol MUST be set to 3138 UDP. 3140 0 3141 0 1 2 3 4 5 6 7 3142 +-+-+-+-+-+-+-+-+ 3143 | Transport | 3144 +-+-+-+-+-+-+-+-+ 3146 Type: 51 for CAPWAP Transport Protocol 3148 Length: 1 3150 Transport: The transport to use for the CAPWAP data channel. The 3151 following enumerated values are supported: 3153 1 - UDP-Lite: The UDP-Lite transport protocol is to be used for 3154 the CAPWAP data channel. Note that this option is illegal is 3155 either the WTP or the AC uses IPv4. 3157 2 - UDP: The UDP transport protocol is to be used for the CAPWAP 3158 data channel. 3160 4.6.15. Data Transfer Data 3162 The Data Transfer Data message element is used by the WTP to provide 3163 information to the AC for debugging purposes. 3165 0 1 2 3 3166 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 3167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3168 | Data Type | Data Mode | Data Length | 3169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3170 | Data .... 3171 +-+-+-+-+-+-+-+-+ 3173 Type: 13 for Data Transfer Data 3175 Length: >= 5 3177 Data Type: An 8-bit value representing the transfer Data Type. The 3178 following enumerated values are supported: 3180 1 - Transfer data is included 3182 2 - Last Transfer Data Block is included (EOF) 3184 5 - An error occurred. Transfer is aborted 3186 Data Mode: An 8-bit value the type of information being 3187 transmitted. The following enumerated values are supported: 3189 0 - Reserved 3191 1 - WTP Crash Data 3193 2 - WTP Memory Dump 3195 Data Length: Length of data field, with a maximum size of 65535. 3197 Data: Data being transferred from the WTP to the AC, whose type is 3198 identified via the Data Mode field. 3200 4.6.16. Data Transfer Mode 3202 The Data Transfer Mode message element is used by the WTP to indicate 3203 the type of data transfer information it is sending to the AC for 3204 debugging purposes. 3206 0 3207 0 1 2 3 4 5 6 7 3208 +-+-+-+-+-+-+-+-+ 3209 | Data Mode | 3210 +-+-+-+-+-+-+-+-+ 3212 Type: 14 for Data Transfer Mode 3214 Length: 1 3216 Data Mode: An 8-bit value the type of information being requested. 3217 The following enumerated values are supported: 3219 0 - Reserved 3221 1 - WTP Crash Data 3223 2 - WTP Memory Dump 3225 4.6.17. Decryption Error Report 3227 The Decryption Error Report message element value is used by the WTP 3228 to inform the AC of decryption errors that have occurred since the 3229 last report. Note that this error reporting mechanism is not used if 3230 encryption and decryption services are provided in the AC. 3232 0 1 2 3233 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 3234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3235 | Radio ID |Num Of Entries | Length | MAC Address... 3236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3238 Type: 15 for Decryption Error Report 3240 Length: >= 9 3242 Radio ID: The Radio Identifier refers to an interface index on the 3243 WTP. 3245 Num of Entries: The number of instances of the Length/MAC Addresses 3246 fields in the array. This field MUST NOT exceed the value of 255. 3248 Length: The length of the MAC Address field. The following formats, 3249 and lengths, are supported [EUI-48] and [EUI-64]. 3251 MAC Address: MAC addresses of the station that has caused 3252 decryption errors. 3254 4.6.18. Decryption Error Report Period 3256 The Decryption Error Report Period message element value is used by 3257 the AC to inform the WTP how frequently it should send decryption 3258 error report messages. Note that this error reporting mechanism is 3259 not used if encryption and decryption services are provided in the 3260 AC. 3262 0 1 2 3263 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 3264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3265 | Radio ID | Report Interval | 3266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3268 Type: 16 for Decryption Error Report Period 3270 Length: 3 3272 Radio ID: The Radio Identifier refers to an interface index on the 3273 WTP. 3275 Report Interval: A 16-bit unsigned integer indicating the time, in 3276 seconds. The default value for this message element can be found 3277 in Section 4.7.11. 3279 4.6.19. Delete MAC ACL Entry 3281 The Delete MAC ACL Entry message element is used by an AC to delete a 3282 MAC ACL entry on a WTP, ensuring that the WTP provides service to the 3283 MAC addresses provided in the message. 3285 0 1 2 3 3286 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 3287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3288 | Num of Entries| Length | MAC Address ... 3289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3291 Type: 17 for Delete MAC ACL Entry 3293 Length: >= 8 3295 Num of Entries: The number of instances of the Length/MAC Addresses 3296 fields in the array. This field MUST NOT exceed the value of 255. 3298 Length: The length of the MAC Address field. The following formats, 3299 and lengths, are supported [EUI-48] and [EUI-64]. 3301 MAC Address: An array of MAC Addresses to delete from the ACL. 3303 4.6.20. Delete Station 3305 The Delete Station message element is used by the AC to inform a WTP 3306 that it should no longer provide service to a particular station. 3307 The WTP MUST terminate service to the station immediately upon 3308 receiving this message element. 3310 The transmission of a Delete Station message element could occur for 3311 various reasons, including for administrative reasons, or if the 3312 station has roamed to another WTP. 3314 The Delete Station message element MAY be sent by the WTP, in the WTP 3315 Event Request message, to inform the AC that a particular station is 3316 no longer being provided service. This could occur as a result of an 3317 Idle Timeout (see section 4.4.43), due to internal resource shortages 3318 or for some other reason. 3320 0 1 2 3 3321 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 3322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3323 | Radio ID | Length | MAC Address... 3324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3326 Type: 18 for Delete Station 3328 Length: >= 8 3330 Radio ID: An 8-bit value representing the radio 3332 Length: The length of the MAC Address field. The following formats, 3333 and lengths, are supported [EUI-48] and [EUI-64]. 3335 MAC Address: The station's MAC Address 3337 4.6.21. Discovery Type 3339 The Discovery Type message element is used by the WTP to indicate how 3340 it has come to know about the existence of the AC to which it is 3341 sending the Discovery Request message. 3343 0 3344 0 1 2 3 4 5 6 7 3345 +-+-+-+-+-+-+-+-+ 3346 | Discovery Type| 3347 +-+-+-+-+-+-+-+-+ 3349 Type: 20 for Discovery Type 3351 Length: 1 3352 Discovery Type: An 8-bit value indicating how the WTP discovered 3353 the AC. The following enumerated values are supported: 3355 0 - Unknown 3357 1 - Static Configuration 3359 2 - DHCP 3361 3 - DNS 3363 4 - AC Referral (used when the AC was configured either through 3364 the AC IPv4 List or AC IPv6 List message element) 3366 4.6.22. Duplicate IPv4 Address 3368 The Duplicate IPv4 Address message element is used by a WTP to inform 3369 an AC that it has detected another IP device using the same IP 3370 address that the WTP is currently using. 3372 The WTP MUST transmit this message element with the status set to 1 3373 after it has detected a duplicate IP address. When the WTP detects 3374 that the duplicate IP address has been cleared, it MUSY send this 3375 message element with the status set to 0. 3377 0 1 2 3 3378 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3380 | IP Address | 3381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3382 | Status | Length | MAC Address ... 3383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3385 Type: 21 for Duplicate IPv4 Address 3387 Length: >= 12 3389 IP Address: The IP Address currently used by the WTP. 3391 Status: The status of the duplicate IP address. The value MUST be 3392 set to 1 when a duplicate address is detected, and 0 when the 3393 duplicate address has been cleared. 3395 Length: The length of the MAC Address field. The following formats, 3396 and lengths, are supported [EUI-48] and [EUI-64]. 3398 MAC Address: The MAC Address of the offending device. 3400 4.6.23. Duplicate IPv6 Address 3402 The Duplicate IPv6 Address message element is used by a WTP to inform 3403 an AC that it has detected another host using the same IP address 3404 that the WTP is currently using. 3406 The WTP MUST transmit this message element with the status set to 1 3407 after it has detected a duplicate IP address. When the WTP detects 3408 that the duplicate IP address has been cleared, it MUST send this 3409 message element with the status set to 0. 3411 0 1 2 3 3412 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 3413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3414 | IP Address | 3415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3416 | IP Address | 3417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3418 | IP Address | 3419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3420 | IP Address | 3421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3422 | Status | Length | MAC Address ... 3423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3425 Type: 22 for Duplicate IPv6 Address 3427 Length: >= 24 3429 IP Address: The IP Address currently used by the WTP. 3431 Status: The status of the duplicate IP address. The value MUST be 3432 set to 1 when a duplicate address is detected, and 0 when the 3433 duplicate address has been cleared. 3435 Length: The length of the MAC Address field. The following formats, 3436 and lengths, are supported [EUI-48] and [EUI-64]. 3438 MAC Address: The MAC Address of the offending device. 3440 4.6.24. Idle Timeout 3442 The Idle Timeout message element is sent by the AC to the WTP to 3443 provide the idle timeout value that the WTP SHOULD enforce for its 3444 active stations. The value applies to all radios on the WTP. 3446 0 1 2 3 3447 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 3448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3449 | Timeout | 3450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3452 Type: 23 for Idle Timeout 3454 Length: 4 3456 Timeout: The current idle timeout, in seconds, to be enforced by 3457 the WTP. The default value for this message element is specified 3458 in Section 4.7.8. 3460 4.6.25. Image Data 3462 The Image Data message element is present in the Image Data Request 3463 message sent by the AC and contains the following fields. 3465 0 1 2 3 3466 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 3467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3468 | Data Type | Data .... 3469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3471 Type: 24 for Image Data 3473 Length: >= 1 3475 Data Type: An 8-bit value representing the image Data Type. The 3476 following enumerated values are supported: 3478 1 - Image data is included 3480 2 - Last Image Data Block is included (EOF) 3482 5 - An error occurred. Transfer is aborted 3484 Data: The Image Data field contains up to 1024 characters, and its 3485 length is inferred from this message element's length field. If 3486 the block being sent is the last one, the Opcode is set to 2. The 3487 AC MAY opt to abort the data transfer by setting the Opcode to 5. 3488 When the Opcode is 5, the Value field has a zero length. 3490 4.6.26. Image Identifier 3492 The Image Identifier message element is sent by the AC to the WTP to 3493 indicate the expected active software version that is to be run on 3494 the WTP. The WTP sends the Image Identifier message element in order 3495 to request a specific software version from the AC. The actual 3496 download process is defined in Section 9.1. The value is a variable 3497 length UTF-8 encoded string [RFC3629], which is NOT zero terminated. 3499 0 1 2 3 3500 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 3501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3502 | Vendor Identifier | 3503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3504 | Data... 3505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3507 Type: 25 for Image Identifier 3509 Length: >= 5 3511 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 3512 Network Management Private Enterprise Codes" 3514 Data: A variable length UTF-8 encoded string [RFC3629] containing 3515 the firmware identifier to be run on the WTP, whose length MUST 3516 NOT exceed 1024 octets. The length of this field is inferred from 3517 this message element's length field. 3519 4.6.27. Image Information 3521 The Image Information message element is present in the Image Data 3522 Response message sent by the AC to the WTP and contains the following 3523 fields. 3525 0 1 2 3 3526 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 3527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3528 | File Size | 3529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3530 | Hash | 3531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3532 | Hash | 3533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3534 | Hash | 3535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3536 | Hash | 3537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3539 Type: 26 for Image Information 3541 Length: 20 3543 File Size: A 32-bit value containing the size of the file, in 3544 bytes, that will be transferred by the AC to the WTP. 3546 Hash: A 16 octet MD5 hash of the image using the procedures defined 3547 in [RFC1321]. 3549 4.6.28. Initiate Download 3551 The Initiate Download message element is used by the WTP to inform 3552 the AC that the AC SHOULD initiate a firmware upgrade. The AC 3553 subsequently transmits an Image Data Request message which includes 3554 the Image Data message element. This message element does not 3555 contain any data. 3557 Type: 27 for Initiate Download 3559 Length: 0 3561 4.6.29. Location Data 3563 The Location Data message element is a variable length byte UTF-8 3564 encoded string [RFC3629] containing user defined location information 3565 (e.g. "Next to Fridge"). This information is configurable by the 3566 network administrator, and allows the WTP location to be determined. 3567 The string is not zero terminated. 3569 0 3570 0 1 2 3 4 5 6 7 3571 +-+-+-+-+-+-+-+-+- 3572 | Location ... 3573 +-+-+-+-+-+-+-+-+- 3575 Type: 28 for Location Data 3577 Length: >= 1 3579 Location: A non-zero terminated UTF-8 encoded string [RFC3629] 3580 containing the WTP location, whose maximum size MUST NOT exceed 3581 1024. 3583 4.6.30. Maximum Message Length 3585 The Maximum Message Length message element is included in the Join 3586 Request message by the WTP to indicate the maximum CAPWAP message 3587 length that it supports to the AC. The Maximum Message Length 3588 message element is optionally included in Join Response message by 3589 the AC to indicate the maximum CAPWAP message length that it supports 3590 to the WTP. 3592 0 1 3593 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3595 | Maximum Message Length | 3596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3598 Type: 29 for Maximum Message Length 3600 Length: 2 3602 Maximum Message Length An 16-bit unsigned integer indicating the 3603 maximum message length. 3605 4.6.31. MTU Discovery Padding 3607 The MTU Discovery Padding message element is used as padding to 3608 perform MTU discovery, and MUST contain octets of value 0xFF, of any 3609 length. 3611 0 3612 0 1 2 3 4 5 6 7 3613 +-+-+-+-+-+-+-+-+ 3614 | Padding... 3615 +-+-+-+-+-+-+-+- 3617 Type: 52 for MTU Discovery Padding 3619 Length: variable 3621 Pad: A variable length pad, filled with the value 0xFF. 3623 4.6.32. Radio Administrative State 3625 The Radio Administrative State message element is used to communicate 3626 the state of a particular radio. The Radio Administrative State 3627 message element is sent by the AC to change the state of the WTP. 3628 The WTP saves the value, to ensure that it remains across WTP resets. 3630 The WTP communicates this message element during the configuration 3631 phase, in the Configuration Status Request message, to ensure that AC 3632 has the WTP radio current administrative state settings. The message 3633 element contains the following fields. 3635 0 1 3636 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3638 | Radio ID | Admin State | 3639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3641 Type: 31 for Radio Administrative State 3643 Length: 2 3645 Radio ID: An 8-bit value representing the radio to configure. The 3646 Radio ID field MAY also include the value of 0xff, which is used 3647 to identify the WTP. If an AC wishes to change the administrative 3648 state of a WTP, it includes 0xff in the Radio ID field. 3650 Admin State: An 8-bit value representing the administrative state 3651 of the radio. The default value for the Admin State field is 3652 listed in Section 4.8.1. The following enumerated values are 3653 supported: 3655 0 - Reserved 3657 1 - Enabled 3659 2 - Disabled 3661 4.6.33. Radio Operational State 3663 The Radio Operational State message element is sent by the WTP to the 3664 AC to communicate a radio's operational state. This message element 3665 is included in the Configuration Update Response message by the WTP 3666 if it was requested to change the state of its radio, via the Radio 3667 Administrative State message element, but was unable to comply to the 3668 request. This message element is included in the Change State Event 3669 message when a WTP radio state was changed unexpectedly. This could 3670 occur due to a hardware failure. Note that the operational state 3671 setting is not saved on the WTP, and therefore does not remain across 3672 WTP resets. The value contains three fields, as shown below. 3674 0 1 2 3675 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 3676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3677 | Radio ID | State | Cause | 3678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3680 Type: 32 for Radio Operational State 3682 Length: 3 3684 Radio ID: The Radio Identifier refers to an interface index on the 3685 WTP. A value of 0xFF is invalid, as it is not possible to change 3686 the WTP's operational state. 3688 State: An 8-bit boolean value representing the state of the radio. 3689 The following enumerated values are supported: 3691 0 - Reserved 3693 1 - Enabled 3695 2 - Disabled 3697 Cause: When a radio is inoperable, the cause field contains the 3698 reason the radio is out of service. The following enumerated 3699 values are supported: 3701 0 - Normal 3703 1 - Radio Failure 3705 2 - Software Failure 3707 3 - Administratively Set 3709 4.6.34. Result Code 3711 The Result Code message element value is a 32-bit integer value, 3712 indicating the result of the Request message corresponding to the 3713 Sequence Number included in the Response message. 3715 0 1 2 3 3716 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 3717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3718 | Result Code | 3719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3721 Type: 33 for Result Code 3722 Length: 4 3724 Result Code: The following enumerated values are defined: 3726 0 Success 3728 1 Failure (AC List message element MUST be present) 3730 2 Success (NAT detected) 3732 3 Join Failure (unspecified) 3734 4 Join Failure (Resource Depletion) 3736 5 Join Failure (Unknown Source) 3738 6 Join Failure (Incorrect Data) 3740 7 Join Failure (Session ID already in use) 3742 8 Join Failure (WTP Hardware not supported) 3744 9 Join Failure (Binding Not Supported) 3746 10 Reset Failure (Unable to Reset) 3748 11 Reset Failure (Firmware Write Error) 3750 12 Configuration Failure (Unable to Apply Requested Configuration 3751 - Service Provided Anyhow) 3753 13 Configuration Failure (Unable to Apply Requested Configuration 3754 - Service Not Provided) 3756 14 Image Data Error (Invalid Checksum) 3758 15 Image Data Error (Invalid Data Length) 3760 16 Image Data Error (Other Error) 3762 17 Image Data Error (Image Already Present) 3764 18 Message Unexpected (Invalid in current state) 3766 19 Message Unexpected (Unrecognized Request) 3767 20 Failure - Missing Mandatory Message Element 3769 21 Failure - Unrecognized Message Element 3771 22 Data Transfer Error (No Information to Transfer) 3773 4.6.35. Returned Message Element 3775 The Returned Message Element is sent by the WTP in the Change State 3776 Event Request message to communicate to the AC which message elements 3777 in the Configuration Status Response it was unable to apply locally. 3778 The Returned Message Element message element contains a result code 3779 indicating the reason that the configuration could not be applied, 3780 and encapsulates the failed message element. 3782 0 1 2 3 3783 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 3784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3785 | Reason | Length | Message Element... 3786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3788 Type: 34 for Returned Message Element 3790 Length: >= 6 3792 Reason: The reason why the configuration in the offending message 3793 element could not be applied by the WTP. The following enumerated 3794 values are supported: 3796 0 - Reserved 3798 1 - Unknown Message Element 3800 2 - Unsupported Message Element 3802 3 - Unknown Message Element Value 3804 4 - Unsupported Message Element Value 3806 Length: The length of the Message Element field, which MUST NOT 3807 exceed 65535 octets. 3809 Message Element: The Message Element field encapsulates the message 3810 element sent by the AC in the Configuration Status Response 3811 message that caused the error. 3813 4.6.36. Session ID 3815 The Session ID message element value contains a randomly generated 3816 unsigned 32-bit integer. 3818 0 1 2 3 3819 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 3820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3821 | Session ID | 3822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3823 | Session ID | 3824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3825 | Session ID | 3826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3827 | Session ID | 3828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3830 Type: 35 for Session ID 3832 Length: 32 3834 Session ID: A 32-bit unsigned integer used as a random session 3835 identifier 3837 4.6.37. Statistics Timer 3839 The Statistics Timer message element value is used by the AC to 3840 inform the WTP of the frequency with which it expects to receive 3841 updated statistics. 3843 0 1 3844 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3846 | Statistics Timer | 3847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3849 Type: 36 for Statistics Timer 3851 Length: 2 3853 Statistics Timer: A 16-bit unsigned integer indicating the time, in 3854 seconds. The default value for this timer is specified in 3855 Section 4.7.14. 3857 4.6.38. Vendor Specific Payload 3859 The Vendor Specific Payload message element is used to communicate 3860 vendor specific information between the WTP and the AC. The Vendor 3861 Specific Payload message element MAY be present in any CAPWAP 3862 message. The message element uses the following format: 3864 0 1 2 3 3865 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 3866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3867 | Vendor Identifier | 3868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3869 | Element ID | Data... 3870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3872 Type: 37 for Vendor Specific Payload 3874 Length: >= 7 3876 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 3877 Network Management Private Enterprise Codes" [RFC3232] 3879 Element ID: A 16-bit Element Identifier which is managed by the 3880 vendor. 3882 Data: Variable length vendor specific information, whose contents 3883 and format are proprietary and understood based on the Element ID 3884 field. This field MUST NOT exceed 2048 octets. 3886 4.6.39. WTP Board Data 3888 The WTP Board Data message element is sent by the WTP to the AC and 3889 contains information about the hardware present. 3891 0 1 2 3 3892 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 3893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3894 | Vendor Identifier | 3895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3896 | Board Data Sub-Element... 3897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3899 Type: 38 for WTP Board Data 3900 Length: >=14 3902 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 3903 Network Management Private Enterprise Codes", identifying the WTP 3904 hardware manufacturer. 3906 Board Data Sub-Element: The WTP Board Data message element contains 3907 multiple Board Data sub-elements, some of which are mandatory and 3908 some are optional, as described below. The Board Data sub-element 3909 has the following format: 3911 0 1 2 3 3912 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3914 | Board Data Type | Board Data Length | 3915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3916 | Board Data Value... 3917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3919 Board Data Type: The Board Data Type field identifies the data 3920 being encoded. The CAPWAP protocol defines the following 3921 values, and each of these types identify whether their presence 3922 is mandatory or optional: 3924 0 - WTP Model Number: The WTP Model Number MUST be included 3925 in the WTP Board Data message element. 3927 1 - WTP Serial Number: The WTP Serial Number MUST be included 3928 in the WTP Board Data message element. 3930 2 - Board ID: A hardware identifier, which MAY be included in 3931 the WTP Board Data message element. 3933 3 - Board Revision A revision number of the board, which MAY 3934 be included in the WTP Board Data message element. 3936 4 - Base MAC Address The WTP's Base MAC Address, which MAY be 3937 assigned to the primary Ethernet interface. 3939 Board Data Length: The length of the data in the Board Data 3940 Value field, whose length MUST NOT exceed 1024 octets. 3942 Board Data Value: The data associated with the Board Data Type 3943 field for this Board Data sub-element. 3945 4.6.40. WTP Descriptor 3947 The WTP Descriptor message element is used by a WTP to communicate 3948 its current hardware and software (firmware) configuration. The 3949 value contains the following fields. 3951 0 1 2 3 3952 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 3953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3954 | Max Radios | Radios in use | Encryption Sub-Element | 3955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3956 | Descriptor Sub-Element... 3957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3959 Type: 39 for WTP Descriptor 3961 Length: >= 31 3963 Max Radios: An 8-bit value representing the number of radios (where 3964 each radio is identified via the Radio ID field) supported by the 3965 WTP. 3967 Radios in use: An 8-bit value representing the number of radios in 3968 use in the WTP. 3970 Encryption Sub-Element: The WTP Descriptor message element MUST 3971 contain at least one Encryption sub-element. One sub-element is 3972 present for each binding supported by the WTP. The Encryption 3973 sub-element has the following format: 3975 0 1 2 3976 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 3977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3978 |Resvd| WBID | Encryption Capabilities | 3979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3981 Resvd: The 3-bit field is reserved for future use. All 3982 implementations complying with this protocol MUST set to zero 3983 any bits that are reserved in the version of the protocol 3984 supported by that implementation. Receivers MUST ignore all 3985 bits not defined for the version of the protocol they support. 3987 WBID: A 5 bit field which is the wireless binding identifier. 3988 The identifier will indicate the type of wireless packet 3989 associated with the radio. The WBIDs defined in this 3990 specification can be found in Section 4.3 3992 Encryption Capabilities: This 16-bit field is used by the WTP to 3993 communicate its capabilities to the AC. A WTP that does not 3994 have any encryption capabilities sets this field to zero (0). 3995 Refer to the specific wireless binding for further 3996 specification of the Encryption Capabilities field. 3998 Descriptor Sub-Element: The WTP Descriptor message element contains 3999 multiple Descriptor sub-elements, some of which are mandatory and 4000 some are optional, as described below. The Descriptor sub-element 4001 has the following format: 4003 0 1 2 3 4004 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 4005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4006 | Descriptor Vendor Identifier | 4007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4008 | Descriptor Type | Descriptor Length | 4009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4010 | Descriptor Data... 4011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4013 Descriptor Vendor Identifier: A 32-bit value containing the IANA 4014 assigned "SMI Network Management Private Enterprise Codes". 4016 Descriptor Type: The Descriptor Type field identifies the data 4017 being encoded. The CAPWAP protocol defines the following 4018 values, and each of these types identify whether their presence 4019 is mandatory or optional. The values listed below are used in 4020 conjunction with the Descriptor Vendor Identifier field, whose 4021 value MUST be set to zero (0). 4023 0 - Hardware Version: The WTP hardware version number MUST be 4024 present. 4026 1 - Active Software Version: The WTP running software version 4027 number MUST be present. 4029 2 - Boot Version: The WTP boot loader version number MUST be 4030 present. 4032 3 - Other Software Version: The WTP non-running software 4033 (firmware) version number MAY be present. This type is used 4034 to communicate alternate software versions that are 4035 available on the WTP's non-volatile storage. 4037 Descriptor Length: Length of vendor specific encoding of 4038 Descriptor Data field, whose length MUST NOT exceed 1024 4039 octets. 4041 Descriptor Data: Vendor specific data of WTP information encoded 4042 in the UTF-8 format [RFC3629]. 4044 4.6.41. WTP Fallback 4046 The WTP Fallback message element is sent by the AC to the WTP to 4047 enable or disable automatic CAPWAP fallback in the event that a WTP 4048 detects its preferred AC, and is not currently connected to it. 4050 0 4051 0 1 2 3 4 5 6 7 4052 +-+-+-+-+-+-+-+-+ 4053 | Mode | 4054 +-+-+-+-+-+-+-+-+ 4056 Type: 40 for WTP Fallback 4058 Length: 1 4060 Mode: The 8-bit value indicates the status of automatic CAPWAP 4061 fallback on the WTP. When enabled, if the WTP detects that its 4062 primary AC is available, and that the WTP is not connected to the 4063 primary AC, the WTP SHOULD automatically disconnect from its 4064 current AC and reconnect to its primary AC. If disabled, the WTP 4065 will only reconnect to its primary AC through manual intervention 4066 (e.g., through the Reset Request message). The default value for 4067 this field is specified in Section 4.8.9. The following 4068 enumerated values are supported: 4070 0 - Reserved 4072 1 - Enabled 4074 2 - Disabled 4076 4.6.42. WTP Frame Tunnel Mode 4078 The WTP Frame Tunnel Mode message element allows the WTP to 4079 communicate the tunneling modes of operation which it supports to the 4080 AC. A WTP that advertises support for all types allows the AC to 4081 select which type will be used, based on its local policy. 4083 0 4084 0 1 2 3 4 5 6 7 4085 +-+-+-+-+-+-+-+-+ 4086 |Reservd|N|E|L|U| 4087 +-+-+-+-+-+-+-+-+ 4089 Type: 41 for WTP Frame Tunnel Mode 4091 Length: 1 4093 Reservd: A set of reserved bits for future use. All 4094 implementations complying with this protocol MUST set to zero any 4095 bits that are reserved in the version of the protocol supported by 4096 that implementation. Receivers MUST ignore all bits not defined 4097 for the version of the protocol they support. 4099 N: Native Frame Tunnel mode requires the WTP and AC to encapsulate 4100 all user payloads as native wireless frames, as defined by the 4101 wireless binding (see for example Section 4.4) 4103 E: The 802.3 Frame Tunnel Mode requires the WTP and AC to 4104 encapsulate all user payload as native IEEE 802.3 frames (see 4105 Section 4.4). All user traffic is tunneled to the AC. This value 4106 MUST NOT be used when the WTP MAC Type is set to Split-MAC. 4108 L: When Local Bridging is used, the WTP does not tunnel user 4109 traffic to the AC; all user traffic is locally bridged. This 4110 value MUST NOT be used when the WTP MAC Type is set to Split-MAC. 4112 U: This bit is set to zero and is unused. 4114 4.6.43. WTP MAC Type 4116 The WTP MAC-Type message element allows the WTP to communicate its 4117 mode of operation to the AC. A WTP that advertises support for both 4118 modes allows the AC to select the mode to use, based on local policy. 4120 0 4121 0 1 2 3 4 5 6 7 4122 +-+-+-+-+-+-+-+-+ 4123 | MAC Type | 4124 +-+-+-+-+-+-+-+-+ 4126 Type: 44 for WTP MAC Type 4127 Length: 1 4129 MAC Type: The MAC mode of operation supported by the WTP. The 4130 following enumerated values are supported: 4132 0 - Local-MAC: Local-MAC is the default mode that MUST be 4133 supported by all WTPs. When tunneling is enabled (see 4134 Section 4.6.42), the encapsulated frames MUST be in the 802.3 4135 format (see Section 4.4.2), unless a wireless management or 4136 control frame which MAY be in its native format. Any CAPWAP 4137 binding needs to specify the format of management and control 4138 wireless frames. 4140 1 - Split-MAC: Split-MAC support is optional, and allows the AC 4141 to receive and process native wireless frames. 4143 2 - Both: WTP is capable of supporting both Local-MAC and Split- 4144 MAC. 4146 4.6.44. WTP Name 4148 The WTP Name message element is a variable length byte UTF-8 encoded 4149 string [RFC3629]. The string is not zero terminated. 4151 0 4152 0 1 2 3 4 5 6 7 4153 +-+-+-+-+-+-+-+-+- 4154 | WTP Name ... 4155 +-+-+-+-+-+-+-+-+- 4157 Type: 45 for WTP Name 4159 Length: >= 1 4161 WTP Name: A non-zero terminated UTF-8 encoded string [RFC3629] 4162 containing the WTP name, whose maximum size MUST NOT exceed 512 4163 bytes. 4165 4.6.45. WTP Radio Statistics 4167 The WTP Radio Statistics message element is sent by the WTP to the AC 4168 to communicate statistics on radio behavior and reasons why the WTP 4169 radio has been reset. These counters are never reset on the WTP, and 4170 will therefore roll over to zero when the maximum size has been 4171 reached. 4173 0 1 2 3 4174 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 4175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4176 | Radio ID | Last Fail Type| Reset Count | 4177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4178 | SW Failure Count | HW Failure Count | 4179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4180 | Other Failure Count | Unknown Failure Count | 4181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4182 | Config Update Count | Channel Change Count | 4183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4184 | Band Change Count | Current Noise Floor | 4185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4187 Type: 47 for WTP Radio Statistics 4189 Length: 20 4191 Radio ID: The radio ID of the radio to which the statistics apply. 4193 Last Failure Type: The last WTP failure. The following enumerated 4194 values are supported: 4196 0 - Statistic Not Supported 4198 1 - Software Failure 4200 2 - Hardware Failure 4202 3 - Other Failure 4204 255 - Unknown (e.g., WTP doesn't keep track of info) 4206 Reset Count: The number of times that that the radio has been 4207 reset. 4209 SW Failure Count: The number of times that the radio has failed due 4210 to software related reasons. 4212 HW Failure Count: The number of times that the radio has failed due 4213 to hardware related reasons. 4215 Other Failure Count: The number of times that the radio has failed 4216 due to known reasons, other than software or hardware failure. 4218 Unknown Failure Count: The number of times that the radio has 4219 failed for unknown reasons. 4221 Config Update Count: The number of times that the radio 4222 configuration has been updated. 4224 Channel Change Count: The number of times that the radio channel 4225 has been changed. 4227 Band Change Count: The number of times that the radio has changed 4228 frequency bands. 4230 Current Noise Floor: A signed integer which indicates the noise 4231 floor of the radio receiver in units of dBm. 4233 4.6.46. WTP Reboot Statistics 4235 The WTP Reboot Statistics message element is sent by the WTP to the 4236 AC to communicate reasons why WTP reboots have occurred. These 4237 counters are never reset on the WTP, and will therefore roll over to 4238 zero when the maximum size has been reached. 4240 0 1 2 3 4241 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 4242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4243 | Reboot Count | AC Initiated Count | 4244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4245 | Link Failure Count | SW Failure Count | 4246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4247 | HW Failure Count | Other Failure Count | 4248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4249 | Unknown Failure Count |Last Failure Type| 4250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4252 Type: 48 for WTP Reboot Statistics 4254 Length: 15 4256 Reboot Count: The number of reboots that have occurred due to a WTP 4257 crash. A value of 65535 implies that this information is not 4258 available on the WTP. 4260 AC Initiated Count: The number of reboots that have occurred at the 4261 request of a CAPWAP protocol message, such as a change in 4262 configuration that required a reboot or an explicit CAPWAP 4263 protocol reset request. A value of 65535 implies that this 4264 information is not available on the WTP. 4266 Link Failure Count: The number of times that a CAPWAP protocol 4267 connection with an AC has failed due to link failure. 4269 SW Failure Count: The number of times that a CAPWAP protocol 4270 connection with an AC has failed due to software related reasons. 4272 HW Failure Count: The number of times that a CAPWAP protocol 4273 connection with an AC has failed due to hardware related reasons. 4275 Other Failure Count: The number of times that a CAPWAP protocol 4276 connection with an AC has failed due to known reasons, other than 4277 AC initiated, link, SW or HW failure. 4279 Unknown Failure Count: The number of times that a CAPWAP protocol 4280 connection with an AC has failed for unknown reasons. 4282 Last Failure Type: The failure type of the most recent WTP failure. 4283 The following enumerated values are supported: 4285 0 - Not Supported 4287 1 - AC Initiated (see Section 9.2) 4289 2 - Link Failure 4291 3 - Software Failure 4293 4 - Hardware Failure 4295 5 - Other Failure 4297 255 - Unknown (e.g., WTP doesn't keep track of info) 4299 4.6.47. WTP Static IP Address Information 4301 The WTP Static IP Address Information message element is used by an 4302 AC to configure or clear a previously configured static IP address on 4303 a WTP. IPv6 WTPs are expected to use dynamic addresses. 4305 0 1 2 3 4306 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 4307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4308 | IP Address | 4309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4310 | Netmask | 4311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4312 | Gateway | 4313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4314 | Static | 4315 +-+-+-+-+-+-+-+-+ 4317 Type: 49 for WTP Static IP Address Information 4319 Length: 13 4321 IP Address: The IP Address to assign to the WTP. This field is 4322 only valid if the static field is set to one. 4324 Netmask: The IP Netmask. This field is only valid if the static 4325 field is set to one. 4327 Gateway: The IP address of the gateway. This field is only valid 4328 if the static field is set to one. 4330 Static: An 8-bit boolean stating whether the WTP should use a 4331 static IP address or not. A value of zero disables the static IP 4332 address, while a value of one enables it. 4334 4.7. CAPWAP Protocol Timers 4336 This section contains the definition of the CAPWAP timers. 4338 4.7.1. ChangeStatePendingTimer 4340 The maximum time, in seconds, the AC will wait for the Change State 4341 Event Request from the WTP after having transmitted a successful 4342 Configuration Status Response message. 4344 Default: 25 seconds 4346 4.7.2. DataChannelKeepAlive 4348 The DataChannelKeepAlive timer is used by the WTP to determine the 4349 next opportunity when it must transmit the Data Channel KeepAlive, in 4350 seconds. 4352 Default: 30 seconds 4354 4.7.3. DataChannelDeadInterval 4356 The minimum time, in seconds, a WTP MUST wait without having received 4357 a Data Channel Keep Alive packet before the destination for the Data 4358 Channel Keep Alive packets may be considered dead. The value of this 4359 timer MUST be no less than 2*DataChannelKeepAlive seconds and no 4360 greater that 240 seconds. 4362 Default: 60 4364 4.7.4. DataCheckTimer 4366 The number of seconds the AC will wait for the Data Channel Keep 4367 Alive, which is required by the CAPWAP state machine's Data Check 4368 state. The AC resets the state machine if this timer expires prior 4369 to transitioning to the next state. 4371 Default: 30 4373 4.7.5. DiscoveryInterval 4375 The minimum time, in seconds, that a WTP MUST wait after receiving a 4376 Discovery Response message, before initiating a DTLS handshake. 4378 Default: 5 4380 4.7.6. DTLSSessionDelete 4382 The minimum time, in seconds, a WTP MUST wait for DTLS session 4383 deletion. 4385 Default: 5 4387 4.7.7. EchoInterval 4389 The minimum time, in seconds, between sending Echo Request messages 4390 to the AC with which the WTP has joined. 4392 Default: 30 4394 4.7.8. IdleTimeout 4396 The default Idle Timeout is 300 seconds. 4398 4.7.9. ImageDataStartTimer 4400 The number of seconds the AC or WTP will wait for its peer to 4401 transmit the Image Data Request. 4403 Default: 30 4405 4.7.10. MaxDiscoveryInterval 4407 The maximum time allowed between sending Discovery Request messages, 4408 in seconds. This value MUST be no less than 2 seconds and no greater 4409 than 180 seconds. 4411 Default: 20 seconds. 4413 4.7.11. ReportInterval 4415 The ReportInterval is used by the WTP to determine the interval the 4416 WTP uses between sending the Decryption Error message elements to the 4417 AC to decryption errors, in seconds. 4419 The default Report Interval is 120 seconds. 4421 4.7.12. RetransmitInterval 4423 The minimum time, in seconds, in which a non-acknowledged CAPWAP 4424 packet will be retransmitted. 4426 Default: 3 4428 4.7.13. SilentInterval 4430 For a WTP, this is the minimum time, in seconds, a WTP MUST wait 4431 before it MAY again send Discovery Request messages or attempt to a 4432 establish DTLS session. For an AC, this is the minimum time, in 4433 seconds, during which the AC SHOULD ignore all CAPWAP and DTLS 4434 packets received from the WTP that is in the Sulking state. 4436 Default: 30 seconds 4438 4.7.14. StatisticsTimer 4440 The StatisticsTimer is used by the WTP to determine the interval the 4441 WTP uses between the WTP Events Requests it transmits to the AC to 4442 communicate its statistics, in seconds. 4444 Default: 120 seconds 4446 4.7.15. WaitDTLS 4448 The maximum time, in seconds, a WTP MUST wait without having received 4449 a DTLS Handshake message from an AC. This timer MUST be greater than 4450 30 seconds. 4452 Default: 60 4454 4.7.16. WaitJoin 4456 The maximum time, in seconds, an AC will wait after the DTLS session 4457 has been established until it receives the Join Request from the WTP. 4458 This timer MUST be greater than 20 seconds. 4460 Default: 60 4462 4.8. CAPWAP Protocol Variables 4464 This section defines the CAPWAP protocol variables, which are used 4465 for various protocol functions. Some of these variables are 4466 configurable, while others are counters or have a fixed value. For 4467 non counter related variables, default values are specified. 4468 However, when a WTP's variable configuration is explicitly overridden 4469 by an AC, the WTP MUST save the new value. 4471 4.8.1. AdminState 4473 The default Administrative State value is enabled (1). 4475 4.8.2. DiscoveryCount 4477 The number of Discovery Request messages transmitted by a WTP to a 4478 single AC. This is a monotonically increasing counter. 4480 4.8.3. FailedDTLSAuthFailCount 4482 The number of failed DTLS session establishment attempts due to 4483 authentication failures. 4485 4.8.4. FailedDTLSSessionCount 4487 The number of failed DTLS session establishment attempts. 4489 4.8.5. MaxDiscoveries 4491 The maximum number of Discovery Request messages that will be sent 4492 after a WTP boots. 4494 Default: 10 4496 4.8.6. MaxFailedDTLSSessionRetry 4498 The maximum number of failed DTLS session establishment attempts 4499 before the CAPWAP device enters a silent period. 4501 Default: 3. 4503 4.8.7. MaxRetransmit 4505 The maximum number of retransmissions for a given CAPWAP packet 4506 before the link layer considers the peer dead. 4508 Default: 5 4510 4.8.8. RetransmitCount 4512 The number of retransmissions for a given CAPWAP packet. This is a 4513 monotonically increasing counter. 4515 4.8.9. WTPFallBack 4517 The default WTP Fallback value is enabled (1). 4519 4.9. WTP Saved Variables 4521 In addition to the values defined in Section 4.8, the following 4522 values SHOULD be saved on the WTP in non-volatile memory. CAPWAP 4523 wireless bindings MAY define additional values that SHOULD be stored 4524 on the WTP. 4526 4.9.1. AdminRebootCount 4528 The number of times the WTP has rebooted administratively, defined in 4529 Section 4.6.46. 4531 4.9.2. FrameEncapType 4533 For WTPs that support multiple Frame Encapsulation Types, it is 4534 useful to save the value configured by the AC. The Frame 4535 Encapsulation Type is defined in Section 4.6.42. 4537 4.9.3. LastRebootReason 4539 The reason why the WTP last rebooted, defined in Section 4.6.46. 4541 4.9.4. MacType 4543 For WTPs that support multiple MAC Types, it is useful to save the 4544 value configured by the AC. The MACType is defined in 4545 Section 4.6.43. 4547 4.9.5. PreferredACs 4549 The preferred ACs, with the index, defined in Section 4.6.5. 4551 4.9.6. RebootCount 4553 The number of times the WTP has rebooted, defined in Section 4.6.46. 4555 4.9.7. Static IP Address 4557 The static IP Address assigned to the WTP, as configured by the WTP 4558 Static IP Address Information message element (see Section 4.6.47). 4560 4.9.8. WTPLinkFailureCount 4562 The number of times the link to the AC has failed, see 4563 Section 4.6.46. 4565 4.9.9. WTPLocation 4567 The WTP Location, defined in Section 4.6.29. 4569 4.9.10. WTPName 4571 The WTP Name, defined in Section 4.6.44. 4573 5. CAPWAP Discovery Operations 4575 The Discovery messages are used by a WTP to determine which ACs are 4576 available to provide service, and the capabilities and load of the 4577 ACs. 4579 5.1. Discovery Request Message 4581 The Discovery Request message is used by the WTP to automatically 4582 discover potential ACs available in the network. The Discovery 4583 Request message provides ACs with the primary capabilities of the 4584 WTP. A WTP must exchange this information to ensure subsequent 4585 exchanges with the ACs are consistent with the WTP's functional 4586 characteristics. 4588 Discovery Request messages MUST be sent by a WTP in the Discover 4589 state after waiting for a random delay less than 4590 MaxDiscoveryInterval, after a WTP first comes up or is 4591 (re)initialized. A WTP MUST send no more than the maximum of 4592 MaxDiscoveries Discovery Request messages, waiting for a random delay 4593 less than MaxDiscoveryInterval between each successive message. 4595 This is to prevent an explosion of WTP Discovery Request messages. 4596 An example of this occurring is when many WTPs are powered on at the 4597 same time. 4599 If a Discovery Response message is not received after sending the 4600 maximum number of Discovery Request messages, the WTP enters the 4601 Sulking state and MUST wait for an interval equal to SilentInterval 4602 before sending further Discovery Request messages. 4604 Upon receiving a Discovery Request message, the AC will respond with 4605 a Discovery Response message sent to the address in the source 4606 address of the received Discovery Request message. Once a Discovery 4607 Response has been received, if the WTP decides to establish a session 4608 with the responding AC, it SHOULD perform an MTU discovery, using the 4609 process described in Section 3.5. 4611 It is possible for the AC to receive a cleartext Discovery Request 4612 message while a DTLS session is already active with the WTP. This is 4613 most likely the case if the WTP has rebooted, perhaps due to a 4614 software or power failure, but could also be caused by a DoS attack. 4615 In such cases, any WTP state, including the state machine instance, 4616 MUST NOT be cleared until another DTLS session has been successfully 4617 established, communicated via the DTLSSessionEstablished DTLS 4618 notification (see Section 2.3.2.2). 4620 The binding specific WTP Radio Information message element (see 4621 Section 2.1) is included in the Discovery Request message to 4622 advertise WTP support for one or more CAPWAP bindings. 4624 The Discovery Request message is sent by the WTP when in the 4625 Discovery State. The AC does not transmit this message. 4627 The following message elements MUST be included in the Discovery 4628 Request message: 4630 o Discovery Type, see Section 4.6.21 4632 o WTP Board Data, see Section 4.6.39 4634 o WTP Descriptor, see Section 4.6.40 4636 o WTP Frame Tunnel Mode, see Section 4.6.42 4638 o WTP MAC Type, see Section 4.6.43 4640 o WTP Radio Information message element(s)that the WTP supports; 4641 These are defined by the individual link layer CAPWAP Binding 4642 Protocols (see Section 2.1). 4644 The following message elements MAY be included in the Discovery 4645 Request message: 4647 o MTU Discovery Padding, see Section 4.6.31 4649 o Vendor Specific Payload, see Section 4.6.38 4651 5.2. Discovery Response Message 4653 The Discovery Response message provides a mechanism for an AC to 4654 advertise its services to requesting WTPs. 4656 When a WTP receives a Discovery Response message, it MUST wait for an 4657 interval not less than DiscoveryInterval for receipt of additional 4658 Discovery Response messages. After the DiscoveryInterval elapses, 4659 the WTP enters the DTLS-Init state and selects one of the ACs that 4660 sent a Discovery Response message and send a DTLS Handshake to that 4661 AC. 4663 One or more binding specific WTP Radio Information message elements 4664 (see Section 2.1) are included in the Discovery Request message to 4665 advertise AC support for the CAPWAP bindings. The AC MAY include 4666 only the bindings it shares in common with the WTP, known through the 4667 WTP Radio Information message elements received in the Discovery 4668 Request message, or it MAY include all of the bindings supported. 4670 The WTP MAY use the supported bindings in its AC decision process. 4671 Note that if the WTP joins an AC that does not support a specific 4672 CAPWAP binding, service for that binding MUST NOT be provided by the 4673 WTP. 4675 The Discovery Response message is sent by the AC when in the Idle 4676 State. The WTP does not transmit this message. 4678 The following message elements MUST be included in the Discovery 4679 Response Message: 4681 o AC Descriptor, see Section 4.6.1 4683 o AC Name, see Section 4.6.4 4685 o WTP Radio Information message element(s)that the AC supports; 4686 These are defined by the individual link layer CAPWAP Binding 4687 Protocols (see Section 2.1 for more information). 4689 o One of the following message elements MUST be included in the 4690 Discovery Response Message: 4692 * CAPWAP Control IPv4 Address, see Section 4.6.9 4694 * CAPWAP Control IPv6 Address, see Section 4.6.10 4696 The following message elements MAY be included in the Discovery 4697 Response message: 4699 o Vendor Specific Payload, see Section 4.6.38 4701 5.3. Primary Discovery Request Message 4703 The Primary Discovery Request message is sent by the WTP to determine 4704 whether its preferred (or primary) AC is available or to perform a 4705 Path MTU Discovery (see section Section 3.5. 4707 A Primary Discovery Request message is sent by a WTP when it has a 4708 primary AC configured, and is connected to another AC. This 4709 generally occurs as a result of a failover, and is used by the WTP as 4710 a means to discover when its primary AC becomes available. Since the 4711 WTP only has a single instance of the CAPWAP state machine, the 4712 Primary Discovery Request is sent by the WTP when in the Run State. 4713 The AC does not transmit this message. 4715 The frequency of the Primary Discovery Request messages should be no 4716 more often than the sending of the Echo Request message. 4718 Upon receipt of a Primary Discovery Request message, the AC responds 4719 with a Primary Discovery Response message sent to the address in the 4720 source address of the received Primary Discovery Request message. 4722 The following message elements MUST be included in the Primary 4723 Discovery Request message. 4725 o Discovery Type, see Section 4.6.21 4727 o WTP Board Data, see Section 4.6.39 4729 o WTP Descriptor, see Section 4.6.40 4731 o WTP Frame Tunnel Mode, see Section 4.6.42 4733 o WTP MAC Type, see Section 4.6.43 4735 o WTP Radio Information message element(s)that the WTP supports; 4736 These are defined by the individual link layer CAPWAP Binding 4737 Protocols (see Section 2.1 for more information). 4739 The following message elements MAY be included in the Primary 4740 Discovery Request message: 4742 o MTU Discovery Padding, see Section 4.6.31 4744 o Vendor Specific Payload, see Section 4.6.38 4746 5.4. Primary Discovery Response 4748 The Primary Discovery Response message enables an AC to advertise its 4749 availability and services to requesting WTPs that are configured to 4750 have the AC as its primary AC. 4752 The Primary Discovery Response message is sent by an AC after 4753 receiving a Primary Discovery Request message. 4755 When a WTP receives a Primary Discovery Response message, it may 4756 establish a CAPWAP protocol connection to its primary AC, based on 4757 the configuration of the WTP Fallback Status message element on the 4758 WTP. 4760 The Primary Discovery Response message is sent by the AC when in the 4761 Idle State. The WTP does not transmit this message. 4763 The following message elements MUST be included in the Primary 4764 Discovery Response message. 4766 o AC Descriptor, see Section 4.6.1 4768 o AC Name, see Section 4.6.4 4770 o WTP Radio Information message element(s)that the AC supports; 4771 These are defined by the individual link layer CAPWAP Binding 4772 Protocols (see Section 2.1 for more information). 4774 One of the following message elements MUST be included in the 4775 Discovery Response Message: 4777 o CAPWAP Control IPv4 Address, see Section 4.6.9 4779 o CAPWAP Control IPv6 Address, see Section 4.6.10 4781 The following message elements MAY be included in the Primary 4782 Discovery Response message: 4784 o Vendor Specific Payload, see Section 4.6.38 4786 6. CAPWAP Join Operations 4788 The Join Request message is used by a WTP to request service from an 4789 AC after a DTLS connection is established to that AC. The Join 4790 Response message is used by the AC to indicate that it will or will 4791 not provide service. 4793 6.1. Join Request 4795 The Join Request message is used by a WTP to request service through 4796 the AC. A Join Request message is sent by a WTP after (optionally) 4797 receiving one or more Discovery Response messages, and completion of 4798 DTLS session establishment. When an AC receives a Join Request 4799 message it responds with a Join Response message. 4801 Upon completion of the DTLS handshake, and receiving the 4802 DTLSEstablished notification, the WTP sends the Join Request message 4803 to the AC. When the AC is notified of the DTLS session 4804 establishment, it does not clear the WaitDTLS timer until it has 4805 received the Join Request message, at which time it sends a Join 4806 Response message to the WTP, indicating success or failure. 4808 One or more WTP Radio Information message elements (see Section 2.1) 4809 are included in the Join Request to request service for the CAPWAP 4810 bindings by the AC. Including a binding that is unsupported by the 4811 AC will result in a failed Join Response. 4813 If the AC rejects the Join Request, it sends a Join Response message 4814 with a failure indication and initiates an abort of the DTLS session 4815 via the DTLSAbort command. 4817 If an invalid (i.e. malformed) Join Request message is received, the 4818 message MUST be silently discarded by the AC. No response is sent to 4819 the WTP. The AC SHOULD log this event. 4821 The Join Request is sent by the WTP when in the Join State. The AC 4822 does not transmit this message. 4824 The following message elements MUST be included in the Join Request 4825 message. 4827 o Location Data, see Section 4.6.29 4829 o WTP Board Data, see Section 4.6.39 4831 o WTP Descriptor, see Section 4.6.40 4832 o WTP Name, see Section 4.6.44 4834 o Session ID, see Section 4.6.36 4836 o WTP Frame Tunnel Mode, see Section 4.6.42 4838 o WTP MAC Type, see Section 4.6.43 4840 o WTP Radio Information message element(s)that the WTP supports; 4841 These are defined by the individual link layer CAPWAP Binding 4842 Protocols (see Section 2.1 for more information). 4844 At least one of the following message element MUST be included in the 4845 Join Request message. 4847 o CAPWAP Local IPv4 Address, see Section 4.6.11 4849 o CAPWAP Local IPv6 Address, see Section 4.6.12 4851 The following message element MAY be included in the Join Request 4852 message. 4854 o CAPWAP Transport Protocol, see Section 4.6.14 4856 o Maximum Message Length, see Section 4.6.30 4858 o WTP Reboot Statistics, see Section 4.6.46 4860 o Vendor Specific Payload, see Section 4.6.38 4862 6.2. Join Response 4864 The Join Response message is sent by the AC to indicate to a WTP that 4865 it is capable and willing to provide service to the WTP. 4867 The WTP, receiving a Join Response message, checks for success or 4868 failure. If the message indicates success, the WTP clears the 4869 WaitDTLS timer for the session and proceeds to the Configure state. 4871 If the WaitDTLS Timer expires prior to reception of the Join Response 4872 message, the WTP MUST terminate the handshake, deallocate session 4873 state and initiate the DTLSAbort command. 4875 If an invalid (malformed) Join Response message is received, the WTP 4876 SHOULD log an informative message detailing the error. This error 4877 MUST be treated in the same manner as AC non-responsiveness. The 4878 WaitDTLS timer will eventually expire, and the WTP MAY (if it is so 4879 configured) attempts to join a new AC. 4881 If one of the WTP Radio Information message elements (see 4882 Section 2.1) in the Join Request message requested support for a 4883 CAPWAP binding which the AC does not support, the AC sets the Result 4884 Code message element to "Binding Not Supported". 4886 The AC includes the Image Identifier message element to indicate the 4887 software version it expects the WTP to run. This information is used 4888 to determine whether the WTP MUST either change its currently running 4889 firmware image, or download a new version (see Section 9.1.1). 4891 The Join Response message is sent by the AC when in the Join State. 4892 The WTP does not transmit this message. 4894 The following message elements MUST be included in the Join Response 4895 message. 4897 o Result Code, see Section 4.6.34 4899 o AC Descriptor, see Section 4.6.1 4901 o AC Name, see Section 4.6.4 4903 o WTP Radio Information message element(s)that the AC supports; 4904 These are defined by the individual link layer CAPWAP Binding 4905 Protocols (see Section 2.1). 4907 One of the following message elements MUST be included in the Join 4908 Response Message: 4910 o CAPWAP Control IPv4 Address, see Section 4.6.9 4912 o CAPWAP Control IPv6 Address, see Section 4.6.10 4914 One of the following message elements MUST be included in the Join 4915 Response Message: 4917 o CAPWAP Local IPv4 Address, see Section 4.6.11 4919 o CAPWAP Local IPv6 Address, see Section 4.6.12 4921 The following message elements MAY be included in the Join Response 4922 message. 4924 o AC IPv4 List, see Section 4.6.2 4926 o AC IPv6 List, see Section 4.6.3 4927 o CAPWAP Transport Protocol, see Section 4.6.14 4929 o Image Identifier, see Section 4.6.26 4931 o Maximum Message Length, see Section 4.6.30 4933 o Vendor Specific Payload, see Section 4.6.38 4935 7. Control Channel Management 4937 The Control Channel Management messages are used by the WTP and AC to 4938 maintain a control communication channel. CAPWAP control messages, 4939 such as the WTP Event Request message sent from the WTP to the AC 4940 indicate to the AC that the WTP is operational. When such control 4941 messages are not being sent, the Echo Request and Echo Response 4942 messages are used to maintain the control communication channel. 4944 7.1. Echo Request 4946 The Echo Request message is a keep-alive mechanism for CAPWAP control 4947 messages. 4949 Echo Request messages are sent periodically by a WTP in the Run state 4950 (see Section 2.3) to determine the state of the control connection 4951 between the WTP and the AC. The Echo Request message is sent by the 4952 WTP when the EchoInterval timer expires. 4954 The Echo Request message is sent by the WTP when in the Run State. 4955 The AC does not transmit this message. 4957 The following message elements MAY be included in the Echo Request 4958 message: 4960 o Vendor Specific Payload, see Section 4.6.38 4962 When an AC receives an Echo Request message it responds with an Echo 4963 Response message. 4965 7.2. Echo Response 4967 The Echo Response message acknowledges the Echo Request message. 4969 An Echo Response message is sent by an AC after receiving an Echo 4970 Request message. After transmitting the Echo Response message, the 4971 AC SHOULD reset its EchoInterval timer (see Section 4.7.7. If 4972 another Echo Request message or other control message is not received 4973 by the AC when the timer expires, the AC SHOULD consider the WTP to 4974 be no longer reachable. 4976 The Echo Response message is sent by the AC when in the Run State. 4977 The WTP does not transmit this message. 4979 The following message elements MAY be included in the Echo Response 4980 message: 4982 o Vendor Specific Payload, see Section 4.6.38 4984 When a WTP receives an Echo Response message it initializes the 4985 EchoInterval to the configured value. 4987 8. WTP Configuration Management 4989 WTP Configuration messages are used to exchange configuration 4990 information between the AC and the WTP. 4992 8.1. Configuration Consistency 4994 The CAPWAP protocol provides flexibility in how WTP configuration is 4995 managed. A WTP can behave in one of two ways, which is 4996 implementation specific: 4998 1. The WTP retains no configuration and accepts the configuration 4999 provided by the AC. 5001 2. The WTP saves the configuration of parameters provided by the AC 5002 that are non-default values into local non-volatile memory, and 5003 are enforced during the WTP's power up initialization phase. 5005 If the WTP opts to save configuration locally, the CAPWAP protocol 5006 state machine defines the Configure state, which allows for 5007 configuration exchange. In the Configure state, the WTP sends its 5008 current configuration overrides to the AC via the Configuration 5009 Status Request message. A configuration override is a non-default 5010 parameter. As an example, in the CAPWAP protocol, the default 5011 antenna configuration is internal omni antenna. A WTP that either 5012 has no internal antennas, or has been explicitly configured by the AC 5013 to use external antennas, sends its antenna configuration during the 5014 configure phase, allowing the AC to become aware of the WTP's current 5015 configuration. 5017 Once the WTP has provided its configuration to the AC, the AC sends 5018 its configuration to the WTP. This allows the WTP to receive 5019 configuration and policies from the AC. 5021 The AC maintains a copy of each active WTP configuration. There is 5022 no need for versioning or other means to identify configuration 5023 changes. If a WTP becomes inactive, the AC MAY delete the inactive 5024 WTP configuration. If a WTP fails, and connects to a new AC, the WTP 5025 provides its overridden configuration parameters, allowing the new AC 5026 to be aware of the WTP configuration. 5028 This model allows for resiliency in case of an AC failure, ensuring 5029 another AC can provide service to the WTP. A new AC would be 5030 automatically updated with WTP configuration changes, eliminating the 5031 need for inter-AC communication and the need for all ACs to be aware 5032 of the configuration of all WTPs in the network. 5034 Once the CAPWAP protocol enters the Run state, the WTPs begin to 5035 provide service. It is common for administrators to require that 5036 configuration changes be made while the network is operational. 5037 Therefore, the Configuration Update Request is sent by the AC to the 5038 WTP to make these changes at run-time. 5040 8.1.1. Configuration Flexibility 5042 The CAPWAP protocol provides the flexibility to configure and manage 5043 WTPs of varying design and functional characteristics. When a WTP 5044 first discovers an AC, it provides primary functional information 5045 relating to its type of MAC and to the nature of frames to be 5046 exchanged. The AC configures the WTP appropriately. The AC also 5047 establishes corresponding internal state for the WTP. 5049 8.2. Configuration Status Request 5051 The Configuration Status Request message is sent by a WTP to deliver 5052 its current configuration to the AC. 5054 The Configuration Status Request message carries binding specific 5055 message elements. Refer to the appropriate binding for the 5056 definition of this structure. 5058 When an AC receives a Configuration Status Request message it acts 5059 upon the content of the message and responds to the WTP with a 5060 Configuration Status Response message. 5062 The Configuration Status Request message includes multiple Radio 5063 Administrative State message elements, one for the WTP, and one for 5064 each radio in the WTP. 5066 The Configuration Status Request message is sent by the WTP when in 5067 the Configure State. The AC does not transmit this message. 5069 The following message elements MUST be included in the Configuration 5070 Status Request message. 5072 o AC Name, see Section 4.6.4 5074 o Radio Administrative State, see Section 4.6.32 5076 o Statistics Timer, see Section 4.6.37 5078 o WTP Reboot Statistics, see Section 4.6.46 5080 The following message elements MAY be included in the Configuration 5081 Status Request message. 5083 o AC Name with Index, see Section 4.6.5 5085 o CAPWAP Transport Protocol, see Section 4.6.14 5087 o WTP Static IP Address Information, see Section 4.6.47 5089 o Vendor Specific Payload, see Section 4.6.38 5091 8.3. Configuration Status Response 5093 The Configuration Status Response message is sent by an AC and 5094 provides a mechanism for the AC to override a WTP's requested 5095 configuration. 5097 A Configuration Status Response message is sent by an AC after 5098 receiving a Configuration Status Request message. 5100 The Configuration Status Response message carries binding specific 5101 message elements. Refer to the appropriate binding for the 5102 definition of this structure. 5104 When a WTP receives a Configuration Status Response message it acts 5105 upon the content of the message, as appropriate. If the 5106 Configuration Status Response message includes a Radio Operational 5107 State message element that causes a change in the operational state 5108 of one of the radios, the WTP transmits a Change State Event to the 5109 AC, as an acknowledgement of the change in state. 5111 The Configuration Status Response message is sent by the AC when in 5112 the Configure State. The WTP does not transmit this message. 5114 The following message elements MUST be included in the Configuration 5115 Status Response message. 5117 o CAPWAP Timers, see Section 4.6.13 5119 o Decryption Error Report Period, see Section 4.6.18 5121 o Idle Timeout, see Section 4.6.24 5123 o WTP Fallback, see Section 4.6.41 5125 One or both of the following message elements MUST be included in the 5126 Configuration Status Response Message: 5128 o AC IPv4 List, see Section 4.6.2 5129 o AC IPv6 List, see Section 4.6.3 5131 The following message element MAY be included in the Configuration 5132 Status Response message. 5134 o WTP Static IP Address Information, see Section 4.6.47 5136 o Vendor Specific Payload, see Section 4.6.38 5138 8.4. Configuration Update Request 5140 Configuration Update Request messages are sent by the AC to provision 5141 the WTP while in the Run state. This is used to modify the 5142 configuration of the WTP while it is operational. 5144 When a WTP receives a Configuration Update Request message, it 5145 responds with a Configuration Update Response message, with a Result 5146 Code message element indicating the result of the configuration 5147 request. 5149 The AC includes the Image Identifier message element (see 5150 Section 4.6.26) to force the WTP to update its firmware while in the 5151 Run state. The WTP MAY proceed to download the requested firmware if 5152 it determines the version specified in the Image Identifier message 5153 element is not in its non-volatile storage by transmitting an Image 5154 Data Request (see Section 9.1.1) that includes the Initiate Download 5155 message element (see Section 4.6.28). 5157 The Configuration Update Request is sent by the AC when in the Run 5158 State. The WTP does not transmit this message. 5160 One or more of the following message elements MAY be included in the 5161 Configuration Update message. 5163 o AC Name with Index, see Section 4.6.5 5165 o AC Timestamp, see Section 4.6.6 5167 o Add MAC ACL Entry, see Section 4.6.7 5169 o CAPWAP Timers, see Section 4.6.13 5171 o Decryption Error Report Period, see Section 4.6.18 5173 o Delete MAC ACL Entry, see Section 4.6.19 5175 o Idle Timeout, see Section 4.6.24 5176 o Location Data, see Section 4.6.29 5178 o Radio Administrative State, see Section 4.6.32 5180 o Statistics Timer, see Section 4.6.37 5182 o WTP Fallback, see Section 4.6.41 5184 o WTP Name, see Section 4.6.44 5186 o WTP Static IP Address Information, see Section 4.6.47 5188 o Image Identifier, see Section 4.6.26 5190 o Vendor Specific Payload, see Section 4.6.38 5192 8.5. Configuration Update Response 5194 The Configuration Update Response message is the acknowledgement 5195 message for the Configuration Update Request message. 5197 The Configuration Update Response message is sent by a WTP after 5198 receiving a Configuration Update Request message. 5200 When an AC receives a Configuration Update Response message the 5201 result code indicates if the WTP successfully accepted the 5202 configuration. 5204 The Configuration Update Response message is sent by the WTP when in 5205 the Run State. The AC does not transmit this message. 5207 The following message element MUST be present in the Configuration 5208 Update message. 5210 Result Code, see Section 4.6.34 5212 The following message elements MAY be present in the Configuration 5213 Update Response message. 5215 o Radio Operational State, see Section 4.6.33 5217 o Vendor Specific Payload, see Section 4.6.38 5219 8.6. Change State Event Request 5221 The Change State Event Request message is used by the WTP for two 5222 main purposes: 5224 o When sent by the WTP following the reception of a Configuration 5225 Status Response message from the AC, the WTP uses the Change State 5226 Event Request message to provide an update on the WTP radio's 5227 operational state and to confirm that the configuration provided 5228 by the AC was successfully applied. 5230 o When sent during the Run state, the WTP uses the Change State 5231 Event Request message to notify the AC of an unexpected change in 5232 the WTP's radio operational state. 5234 When an AC receives a Change State Event Request message it responds 5235 with a Change State Event Response message and modifies its data 5236 structures for the WTP as needed. The AC MAY decide not to provide 5237 service to the WTP if it receives an error, based on local policy, 5238 and to transition to the Reset state. 5240 The Change State Event Request message is sent by a WTP to 5241 acknowledge or report an error condition to the AC for a requested 5242 configuration in the Configuration Status Response message. The 5243 Change State Event Request message includes the Result Code message 5244 element, which indicates whether the configuration was successfully 5245 applied. If the WTP is unable to apply a specific configuration 5246 request, it indicates the failure by including one or more Returned 5247 Message Element message elements (see Section 4.6.35). 5249 The Change State Event Request message is sent by the WTP in the 5250 Configure or Run State. The AC does not transmit this message. 5252 The WTP MAY save its configuration to persistent storage prior to 5253 transmitting the response. However, this is implementation specific 5254 and is not required. 5256 The following message elements MUST be present in the Change State 5257 Event Request message. 5259 o Radio Operational State, see Section 4.6.33 5261 o Result Code, see Section 4.6.34 5263 One or more of the following message elements MAY be present in the 5264 Change State Event Request message. 5266 o Returned Message Element(s), see Section 4.6.35 5268 o Vendor Specific Payload, see Section 4.6.38 5270 8.7. Change State Event Response 5272 The Change State Event Response message acknowledges the Change State 5273 Event Request message. 5275 A Change State Event Response message is sent by an AC in response to 5276 a Change State Event Request message. 5278 The Change State Event Response message is sent by the AC when in the 5279 Configure or Run state. The WTP does not transmit this message. 5281 The following message elements MAY be included in the Change State 5282 Event Response message: 5284 o Vendor Specific Payload, see Section 4.6.38 5286 The WTP does not take any action upon receipt of the Change State 5287 Event Response message. 5289 8.8. Clear Configuration Request 5291 The Clear Configuration Request message is used to reset the WTP 5292 configuration. 5294 The Clear Configuration Request message is sent by an AC to request 5295 that a WTP reset its configuration to the manufacturing default 5296 configuration. The Clear Config Request message is sent while in the 5297 Run state. 5299 The Clear Configuration Request is sent by the AC when in the Run 5300 State. The WTP does not transmit this message. 5302 The following message elements MAY be included in the Clear 5303 Configuration Request message: 5305 o Vendor Specific Payload, see Section 4.6.38 5307 When a WTP receives a Clear Configuration Request message it resets 5308 its configuration to the manufacturing default configuration. 5310 8.9. Clear Configuration Response 5312 The Clear Configuration Response message is sent by the WTP after 5313 receiving a Clear Configuration Request message and resetting its 5314 configuration parameters to the manufacturing default values. 5316 The Clear Configuration Response is sent by the WTP when in the Run 5317 State. The AC does not transmit this message. 5319 The Clear Configuration Response message MUST include the following 5320 message element. 5322 o Result Code, see Section 4.6.34 5324 The following message elements MAY be included in the Clear 5325 Configuration Request message: 5327 o Vendor Specific Payload, see Section 4.6.38 5329 9. Device Management Operations 5331 This section defines CAPWAP operations responsible for debugging, 5332 gathering statistics, logging, and firmware management. The 5333 management operations defined in this section are used by the AC to 5334 either push/pull information to/from the WTP, or request that the WTP 5335 reboot. This section does not deal with the management of the AC per 5336 se, and assumes that the AC is operational and configured. 5338 9.1. Firmware Management 5340 This section describes the firmware download procedures used by the 5341 CAPWAP protocol. Firmware download can occur during the Image Data 5342 or Run state. 5344 Figure 6 provides an example of a WTP that performs a firmware 5345 upgrade while in the Image Data state. In this example, the WTP does 5346 not already have the requested firmware (Image Identifier = x), and 5347 downloads the image from the AC. 5349 WTP AC 5351 Join Request 5352 --------------------------------------------------------> 5354 Join Response (Image Identifier = x) 5355 <------------------------------------------------------ 5357 Image Data Request (Image Identifier = x, 5358 Initiate Download) 5359 --------------------------------------------------------> 5361 Image Data Response (Result Code = Success, 5362 Image Information = {size,hash}) 5363 <------------------------------------------------------ 5365 Image Data Request (Image Data = Data) 5366 <------------------------------------------------------ 5368 Image Data Response (Result Code = Success) 5369 --------------------------------------------------------> 5371 ..... 5373 Image Data Request (Image Data = EOF) 5374 <------------------------------------------------------ 5376 Image Data Response (Result Code = Success) 5377 --------------------------------------------------------> 5379 (WTP enters the Reset State) 5381 Figure 6: WTP Firmware Download Case 1 5383 Figure 7 provides an example in which the WTP has the image specified 5384 by the AC in its non-volative storage, but is not its current running 5385 image. In this case, the WTP opts to NOT download the firmware and 5386 immediately reset to the requested image. 5388 WTP AC 5390 Join Request 5391 --------------------------------------------------------> 5393 Join Response (Image Identifier = x) 5394 <------------------------------------------------------ 5396 (WTP enters the Reset State) 5398 Figure 7: WTP Firmware Download Case 2 5400 Figure 8 provides an example of a WTP that performs a firmware 5401 upgrade while in the Run state. This mode of firmware upgrade allows 5402 the WTP to download its image while continuing to provide service. 5403 The WTP will not automatically reset until it is notified by the AC, 5404 with a Reset Request message. 5406 WTP AC 5408 Configuration Update Request (Image Identifier = x) 5409 <------------------------------------------------------ 5411 Configuration Update Response (Result Code = Success) 5412 --------------------------------------------------------> 5414 Image Data Request (Image Identifier = x, 5415 Initiate Download) 5416 --------------------------------------------------------> 5418 Image Data Response (Result Code = Success, 5419 Image Information = {size,hash}) 5420 <------------------------------------------------------ 5422 Image Data Request (Image Data = Data) 5423 <------------------------------------------------------ 5425 Image Data Response (Result Code = Success) 5426 --------------------------------------------------------> 5428 ..... 5430 Image Data Request (Image Data = EOF) 5431 <------------------------------------------------------ 5433 Image Data Response (Result Code = Success) 5434 --------------------------------------------------------> 5436 ..... 5438 (administratively requested reboot request) 5439 Reset Request (Image Identifier = x) 5440 <------------------------------------------------------ 5442 Reset Response (Result Code = Success) 5443 --------------------------------------------------------> 5445 Figure 8: WTP Firmware Download Case 3 5447 Figure 9 provides another example of the firmware download while in 5448 the Run state. In this example, the WTP already has the image 5449 specified by the AC in its non-volative storage. The WTP opts to NOT 5450 download the firmware. The WTP resets upon receipt of a Reset 5451 Request message from the AC. 5453 WTP AC 5455 Configuration Update Request (Image Identifier = x) 5456 <------------------------------------------------------ 5458 Configuration Update Response (Result Code = Already Have Image) 5459 --------------------------------------------------------> 5461 ..... 5463 (administratively requested reboot request) 5464 Reset Request (Image Identifier = x) 5465 <------------------------------------------------------ 5467 Reset Response (Result Code = Success) 5468 --------------------------------------------------------> 5470 Figure 9: WTP Firmware Download Case 4 5472 9.1.1. Image Data Request 5474 The Image Data Request message is used to update firmware on the WTP. 5475 This message and its companion Response message are used by the AC to 5476 ensure that the image being run on each WTP is appropriate. 5478 Image Data Request messages are exchanged between the WTP and the AC 5479 to download a new firmware image to the WTP. When a WTP or AC 5480 receives an Image Data Request message it responds with an Image Data 5481 Response message. The message elements contained within the Image 5482 Data Request message are required to determine the intent of the 5483 request. 5485 The decision that new firmware is to be downloaded to the WTP can 5486 occur in one of two ways: 5488 When the WTP joins the AC, the Join Response message includes the 5489 Image Identifier message element, which informs the WTP of the 5490 firmware it is expected to run. if the WTP does not currently have 5491 the requested firmware version, it transmits an Image Data Request 5492 message, with the appropriate Image Identifier message element. 5493 If the WTP already has the requested firmware in its non-volatile 5494 flash, but is not its currently running image, it simply resets to 5495 run the proper firmware. 5497 Once the WTP is in the Run state, it is possible for the AC to 5498 cause the WTP to initiate a firmware download by sending an 5499 Configuration Update Request message with the Image Identifier 5500 message elements. This will cause the WTP to transmit an Image 5501 Data Request with the Image Identifier and the Initiate Download 5502 message elements. Note that when the firmware is downloaded in 5503 this way, the WTP does not automatically reset after the download 5504 is complete. The WTP will only reset when it receives a Reset 5505 Request message from the AC. If the WTP already had the requested 5506 firmware version in its non-volatile storage, the WTP does not 5507 transmit the Image Data Request message and responds with a 5508 Configuration Update Response message with the Result Code set to 5509 Image Already Present. 5511 Regardless of how the download was initiated, once the AC receives an 5512 Image Data Request message with the Image Identifier message element, 5513 it begins the transfer process by transmitting an Image Data Request 5514 message that includes the Image Data message element. This continues 5515 until the firmware image has been transferred. 5517 The Image Data Request message is sent by the WTP or the AC when in 5518 the Image Data or Run State. 5520 The following message elements MAY be included in the Image Data 5521 Request message. 5523 o CAPWAP Transport Protocol, see Section 4.6.14 5525 o Image Data, see Section 4.6.25 5527 o Vendor Specific Payload, see Section 4.6.38 5529 The following message elements MAY be included in the Image Data 5530 Request message when sent by the WTP. 5532 o Image Identifier, see Section 4.6.26 5534 o Initiate Download, see Section 4.6.28 5536 9.1.2. Image Data Response 5538 The Image Data Response message acknowledges the Image Data Request 5539 message. 5541 An Image Data Response message is sent in response to a received 5542 Image Data Request message. Its purpose is to acknowledge the 5543 receipt of the Image Data Request message. The Result Code is 5544 included to indicate whether a previously sent Image Data Request 5545 message was invalid. 5547 The Image Data Response message is sent by the WTP or the AC when in 5548 the Image Data or Run State. 5550 The following message element MUST be included in the Image Data 5551 Response message. 5553 o Result Code, see Section 4.6.34 5555 The following message elements MAY be included in the Image Data 5556 Response message. 5558 o Vendor Specific Payload, see Section 4.6.38 5560 The following message elements MAY be included in the Image Data 5561 Response message when sent by the AC. 5563 o Image Information, see Section 4.6.27 5565 Upon receiving an Image Data Response message indicating an error, 5566 the WTP MAY retransmit a previous Image Data Request message, or 5567 abandon the firmware download to the WTP by transitioning to the 5568 Reset state. 5570 9.2. Reset Request 5572 The Reset Request message is used to cause a WTP to reboot. 5574 A Reset Request message is sent by an AC to cause a WTP to 5575 reinitialize its operation. If the AC includes the Image Identifier 5576 message element (see Section 4.6.26), it indicates to the WTP that it 5577 SHOULD use that version of software upon reboot. 5579 The Reset Request is sent by the AC when in the Run State. The WTP 5580 does not transmit this message. 5582 The following message elements MUST be included in the Reset Request 5583 message. 5585 o Image Identifier, see Section 4.6.26 5587 The following message elements MAY be included in the Reset Request 5588 message: 5590 o Vendor Specific Payload, see Section 4.6.38 5592 When a WTP receives a Reset Request message, it responds with a Reset 5593 Response message indicating success and then reinitialize itself. If 5594 the WTP is unable to write to its non-volatile storage, to ensure 5595 that it runs the requested software version indicated in the Image 5596 Identifier message element, it MAY send the appropriate Result Code 5597 message element, but MUST reboot. If the WTP is unable to reset, 5598 including a hardware reset, it sends a Reset Response message to the 5599 AC with a Result Code message element indicating failure. The AC no 5600 longer provides service to the WTP. 5602 9.3. Reset Response 5604 The Reset Response message acknowledges the Reset Request message. 5606 A Reset Response message is sent by the WTP after receiving a Reset 5607 Request message. 5609 The Reset Response is sent by the WTP when in the Run State. The AC 5610 does not transmit this message. 5612 The following message element MAY be included in the Reset Response 5613 message. 5615 o Result Code, see Section 4.6.34 5617 o Vendor Specific Payload, see Section 4.6.38 5619 When an AC receives a successful Reset Response message, it is 5620 notified that the WTP will reinitialize its operation. An AC that 5621 receives a Reset Response message indicating failure may opt to no 5622 longer provide service to the WTP. 5624 9.4. WTP Event Request 5626 The WTP Event Request message is used by a WTP to send information to 5627 its AC. The WTP Event Request message MAY be sent periodically, or 5628 sent in response to an asynchronous event on the WTP. For example, a 5629 WTP MAY collect statistics and use the WTP Event Request message to 5630 transmit the statistics to the AC. 5632 When an AC receives a WTP Event Request message it will respond with 5633 a WTP Event Response message. 5635 The presence of the Delete Station message element is used by the WTP 5636 to inform the AC that it is no longer providing service to the 5637 station. This could be the result of an Idle Timeout (see 5638 Section 4.6.24), due to resource shortages, or some other reason. 5640 The WTP Event Request message is sent by the WTP when in the Run 5641 State. The AC does not transmit this message. 5643 The WTP Event Request message MUST contain one of the message 5644 elements listed below, or a message element that is defined for a 5645 specific wireless technology. More than one of each message element 5646 listed MAY be included in the WTP Event Request message. 5648 o Decryption Error Report, see Section 4.6.17 5650 o Duplicate IPv4 Address, see Section 4.6.22 5652 o Duplicate IPv6 Address, see Section 4.6.23 5654 o WTP Radio Statistics, see Section 4.6.45 5656 o WTP Reboot Statistics, see Section 4.6.46 5658 o Delete Station, see Section 4.6.20 5660 o Vendor Specific Payload, see Section 4.6.38 5662 9.5. WTP Event Response 5664 The WTP Event Response message acknowledges receipt of the WTP Event 5665 Request message. 5667 A WTP Event Response message is sent by an AC after receiving a WTP 5668 Event Request message. 5670 The WTP Event Response message is sent by the AC when in the Run 5671 State. The WTP does not transmit this message. 5673 The following message elements MAY be included in the WTP Event 5674 Response message: 5676 o Vendor Specific Payload, see Section 4.6.38 5678 9.6. Data Transfer 5680 This section describes the data transfer procedures used by the 5681 CAPWAP protocol. The data transfer mechanism is used to upload 5682 information available at the WTP to the AC, such as crash or debug 5683 information. The data transfer messages can only be exchanged while 5684 in the Run state. 5686 Figure 10 provides an example of an AC that requests that the WTP 5687 transfer its latest crash file. Once the WTP acknowledges that it 5688 has information to send, via the Data Transfer Response, it transmits 5689 its own Data Transfer Request. Upon receipt, the AC responds with a 5690 Data Transfer Response, and the exchange continues until the WTP 5691 transmits a Data Transfer Data message element that indicates an End 5692 of File (EOF). 5694 WTP AC 5696 Data Transfer Request (Data Transfer Mode = Crash Data) 5697 <------------------------------------------------------ 5699 Data Transfer Response (Result Code = Success) 5700 --------------------------------------------------------> 5702 Data Transfer Request (Data Transfer Data = Data) 5703 --------------------------------------------------------> 5705 Data Transfer Response (Result Code = Success) 5706 <------------------------------------------------------ 5708 ..... 5710 Data Transfer Request (Data Transfer Data = EOF) 5711 --------------------------------------------------------> 5713 Data Transfer Response (Result Code = Success) 5714 <------------------------------------------------------ 5716 Figure 10: WTP Data Transfer Case 1 5718 Figure 11 provides an example of an AC that requests that the WTP 5719 transfer its latest crash file. However, in this example, the WTP 5720 does not have any crash information to send, and therefore sends a 5721 Data Transfer Response with a Result Code indicating the error. 5723 WTP AC 5725 Data Transfer Request (Data Transfer Mode = Crash Data) 5726 <------------------------------------------------------ 5728 Data Transfer Response (Result Code = Data Transfer 5729 Error (No Information to Transfer)) 5730 --------------------------------------------------------> 5732 Figure 11: WTP Data Transfer Case 2 5734 9.6.1. Data Transfer Request 5736 The Data Transfer Request message is used to deliver debug 5737 information from the WTP to the AC. 5739 The Data Transfer Request messages can be sent either by the AC or 5740 the WTP. When sent by the AC, it is used to request that data be 5741 transmitted from the WTP to the AC, and includes the Data Transfer 5742 Mode message element, which specifies the information desired by the 5743 AC. The Data Transfer Request is sent by the WTP in order to 5744 transfer actual data to the AC, through the Data Transfer Data 5745 message element. 5747 Given that the CAPWAP protocol minimizes the need for WTPs to be 5748 directly managed, the Data Transfer Request is an important 5749 troubleshooting tool used by the AC to retrieve information that may 5750 be available on the WTP. For instance, some WTPs implementations may 5751 store crash information to help manufacturers identify software 5752 faults. The Data Transfer Request message can be used to send such 5753 information from the WTP to the AC. Another possible use would be to 5754 allow a remote debugger function in the WTP to use the Data Transfer 5755 Request message to send console output to the AC for debugging 5756 purposes. 5758 When the WTP or AC receives a Data Transfer Request message it 5759 responds to the WTP with a Data Transfer Response message. The AC 5760 MAY log the information received through the Data Transfer Data 5761 message element. 5763 The Data Transfer Request message is sent by the WTP or AC when in 5764 the Run State. 5766 When sent by the AC, the Data Transfer Request message MUST contain 5767 the following message elements: 5769 o Data Transfer Mode, see Section 4.6.16 5771 When sent by the WTP, the Data Transfer Request message MUST contain 5772 the following message elements: 5774 o Data Transfer Data, see Section 4.6.15 5776 Regardless of whether the Data Transfer Request is sent by the AC or 5777 WTP, the following message elements MAY be included in the Data 5778 Transfer Request message: 5780 o Vendor Specific Payload, see Section 4.6.38 5782 9.6.2. Data Transfer Response 5784 The Data Transfer Response message acknowledges the Data Transfer 5785 Request message. 5787 A Data Transfer Response message is sent in response to a received 5788 Data Transfer Request message. Its purpose is to acknowledge receipt 5789 of the Data Transfer Request message. When sent by the WTP, the 5790 Result Code message element is used to indicate whether the data 5791 transfer requested by the AC can be completed. When sent by the AC, 5792 the Result Code message element is used to indicate receipt of the 5793 data transfered in the Data Transfer Request message. 5795 The Data Transfer Response message is sent by the WTP or AC when in 5796 the Run State. 5798 The following message element MUST be included in the Data Transfer 5799 Response message. 5801 o Result Code, see Section 4.6.34 5803 The following message elements MAY be included in the Data Transfer 5804 Response message: 5806 o Vendor Specific Payload, see Section 4.6.38 5808 Upon receipt of a Data Transfer Response message, the WTP transmits 5809 more information, if more information is available. 5811 10. Station Session Management 5813 Messages in this section are used by the AC to create, modify or 5814 delete station session state on the WTPs. 5816 10.1. Station Configuration Request 5818 The Station Configuration Request message is used to create, modify 5819 or delete station session state on a WTP. The message is sent by the 5820 AC to the WTP, and MAY contain one or more message elements. The 5821 message elements for this CAPWAP control message include information 5822 that is generally highly technology specific. Refer to the 5823 appropriate binding document for definitions of the messages elements 5824 that are included in this control message. 5826 The Station Configuration Request message is sent by the AC when in 5827 the Run State. The WTP does not transmit this message. 5829 The following CAPWAP Control message elements MAY be included in the 5830 Station Configuration Request message. More than one of each message 5831 element listed MAY be included in the Station Configuration Request 5832 message. 5834 o Add Station, see Section 4.6.8 5836 o Delete Station, see Section 4.6.20 5838 o Vendor Specific Payload, see Section 4.6.38 5840 10.2. Station Configuration Response 5842 The Station Configuration Response message is used to acknowledge a 5843 previously received Station Configuration Request message. 5845 The Station Configuration Response message is sent by the WTP when in 5846 the Run State. The AC does not transmit this message. 5848 The following message element MUST be present in the Station 5849 Configuration Response message. 5851 o Result Code, see Section 4.6.34 5853 The following message elements MAY be included in the Station 5854 Configuration Response message: 5856 o Vendor Specific Payload, see Section 4.6.38 5858 The Result Code message element indicates that the requested 5859 configuration was successfully applied, or that an error related to 5860 processing of the Station Configuration Request message occurred on 5861 the WTP. 5863 11. NAT Considerations 5865 There are three specific situations in which a NAT deployment may be 5866 used in conjunction with a CAPWAP-enabled deployment. The first 5867 consists of a configuration in which a single WTP is behind a NAT 5868 system. Since all communication is initiated by the WTP, and all 5869 communication is performed over IP using two UDP ports, the protocol 5870 easily traverses NAT systems in this configuration. 5872 In the second case, two or more WTPs are deployed behind the same NAT 5873 system. Here, the AC would receive multiple connection requests from 5874 the same IP address, and cannot differentiate the originating WTP of 5875 the connection requests. The CAPWAP Data Check state, which 5876 establishes the data plane connection and communicates the CAPWAP 5877 Data Channel Keepalive, includes the Session Identifier message 5878 element, which is used to bind the control and data plane. Use of 5879 the Session Identifier message element enables the AC to match the 5880 control and data plane flows from multiple WTPs behind the same NAT 5881 system (multiple WTPs sharing the same IP address). 5883 In the third configuration, the AC is deployed behind a NAT. Two 5884 issues exist in this situation. First, an AC communicates its 5885 interfaces and corresponding WTP load using the CAPWAP Control IPv4 5886 Address and CAPWAP Control IPv6 Address message elements. This 5887 message element is mandatory, but contains invalid information if a 5888 middlebox is present between the AC and WTP. The WTP MUST NOT 5889 utilize the information in these message elements if it detects a NAT 5890 (as described in the CAPWAP Transport Protocol message element). 5891 Note this would disable the load balancing capabilities of the CAPWAP 5892 protocol. Alternatively, the AC could have a configured NAT'ed 5893 address, which it would include in either of the two control address 5894 message elements. 5896 In order for a CAPWAP WTP or AC to detect whether a middlebox is 5897 present, both the Join Request (see Section 6.1) and the Join 5898 Response (see Section 6.2) include either the CAPWAP Local IPv4 5899 Address (see Section 4.6.11), or the CAPWAP Local IPv6 Address (see 5900 Section 4.6.12) message element. Upon receiving one of these 5901 messages, if the packet's source IP address differs from the address 5902 found in either one of these message elements, it indicates that a 5903 middlebox is present. 5905 The CAPWAP protocol allows for all of the AC identities supporting a 5906 group of WTPs to be communicated through the AC List message element. 5907 This feature MUST be ignored by the WTP when it detects the AC is 5908 behind a middlebox. 5910 The CAPWAP protocol allows an AC to configure a static IP address on 5911 a WTP using the WTP Static IP Address Information message element. 5912 This message element SHOULD NOT be used in NAT'ed environments, 5913 unless the administrator is familiar with the internal IP addressing 5914 scheme within the WTP's private network, and does not rely on the 5915 public address seen by the AC. 5917 When a WTP detects the duplicate address condition, it generates a 5918 message to the AC, which includes the Duplicate IP Address message 5919 element. The IP Address embedded within this message element is 5920 different from the public IP address seen by the AC. 5922 12. Security Considerations 5924 This section describes security considerations for the CAPWAP 5925 protocol. It also provides security recommendations for protocols 5926 used in conjunction with CAPWAP. 5928 12.1. CAPWAP Security 5930 As it is currently specified, the CAPWAP protocol sits between the 5931 security mechanisms specified by the wireless link layer protocol 5932 (e.g.IEEE 802.11i) and AAA. One goal of CAPWAP is to bootstrap trust 5933 between the STA and WTP using a series of preestablished trust 5934 relationships: 5936 STA WTP AC AAA 5937 ============================================== 5939 DTLS Cred AAA Cred 5940 <------------><-------------> 5942 EAP Credential 5943 <------------------------------------------> 5945 wireless link layer 5946 (e.g.802.11 PTK) 5947 <--------------> or 5948 <---------------------------> 5949 (derived) 5951 Figure 12: STA Session Setup 5953 Within CAPWAP, DTLS is used to secure the link between the WTP and 5954 AC. In addition to securing control messages, it's also a link in 5955 this chain of trust for establishing link layer keys. Consequently, 5956 much rests on the security of DTLS. 5958 In some CAPWAP deployment scenarios, there are two channels between 5959 the WTP and AC: the control channel, carrying CAPWAP control 5960 messages, and the data channel, over which client data packets are 5961 tunneled between the AC and WTP. Typically, the control channel is 5962 secured by DTLS, while the data channel is not. 5964 The use of parallel protected and unprotected channels deserves 5965 special consideration, but does not create a threat. There are two 5966 potential concerns: attempting to convert protected data into un- 5967 protected data and attempting to convert un-protected data into 5968 protected data. These concerns are addressed below. 5970 12.1.1. Converting Protected Data into Unprotected Data 5972 Since CAPWAP does not support authentication-only ciphers (i.e. all 5973 supported ciphersuites include encryption and authentication), it is 5974 not possible to convert protected data into unprotected data. Since 5975 encrypted data is (ideally) indistinguishable from random data, the 5976 probability of an encrypted packet passing for a well-formed packet 5977 is effectively zero. 5979 12.1.2. Converting Unprotected Data into Protected Data (Insertion) 5981 The use of message authentication makes it impossible for the 5982 attacker to forge protected records. This makes conversion of 5983 unprotected records to protected records impossible. 5985 12.1.3. Deletion of Protected Records 5987 An attacker could remove protected records from the stream, though 5988 not undetectably so, due the built-in reliability of the underlying 5989 CAPWAP protocol. In the worst case, the attacker would remove the 5990 same record repeatedly, resulting in a CAPWAP session timeout and 5991 restart. This is effectively a DoS attack, and could be accomplished 5992 by a man in the middle regardless of the CAPWAP protocol security 5993 mechanisms chosen. 5995 12.1.4. Insertion of Unprotected Records 5997 An attacker could inject packets into the unprotected channel, but 5998 this may become evident if sequence number desynchronization occurs 5999 as a result. Only if the attacker is a MiM can packets be inserted 6000 undetectably. This is a consequence of that channel's lack of 6001 protection, and not a new threat resulting from the CAPWAP security 6002 mechanism. 6004 12.1.5. Use of MD5 6006 The Image Information Section 4.6.27) message element makes use of 6007 MD5 to compute the hash field. The authenticity and integrity of the 6008 image file is protected by DTLS, and in this context, MD5 is not used 6009 as a cryptographically secure hash, but just as a basic checksum. 6010 Therefore, the use of MD5 is not considered a security vulnerability, 6011 and no mechanisms for algorithm agility are provided. 6013 12.2. Session ID Security 6015 Since DTLS does not export a unique session identifier, there can be 6016 no explicit protocol binding between the DTLS layer and CAPWAP layer. 6017 As a result, implementations MUST provide a mechanism for performing 6018 this binding. For example, an AC MUST NOT associate decrypted DTLS 6019 control packets with a particular WTP session based solely on the 6020 Session ID in the packet header. Instead, identification should be 6021 done based on which DTLS session decrypted the packet. Otherwise one 6022 authenticated WTP could spoof another authenticated WTP by altering 6023 the Session ID in the encrypted CAPWAP header. 6025 It should be noted that when the CAPWAP data channel is unencrypted, 6026 the WTP Session ID is exposed and possibly known to adversaries and 6027 other WTPs. This would allow the forgery of the source of data- 6028 channel traffic. This, however, should not be a surprise for 6029 unencrypted data channels. When the data channel is encrypted, the 6030 Session ID is not exposed, and therefore can safely be used to 6031 associate a data and control channel. The 64-bit length of the 6032 Session ID mitigates online guessing attacks where an adversarial, 6033 authenticated WTP tries to correlate his own data channel with 6034 another WTP's control channel. Note that for encrypted data 6035 channels, the Session ID should only be used for correlation for the 6036 first packet immediately after the initial DTLS handshake. Future 6037 correlation should instead be done via identification of a packet's 6038 DTLS session. 6040 12.3. Discovery or DTLS Setup Attacks 6042 Since the Discovery Request messages are sent in the clear, it is 6043 important that AC implementations NOT assume that receiving a 6044 Discovery Request message from a WTP implies that the WTP has 6045 rebooted, and consequently tear down any active DTLS sessions. 6046 Discovery Request messages can easily be spoofed by malicious 6047 devices, so it is important that the AC maintain two separate sets of 6048 states for the WTP until the DTLSSessionEstablished notification is 6049 received, indicating that the WTP was authenticated. Once a new DTLS 6050 session is successfully established, any state referring to the old 6051 session can be cleared. 6053 Similarly, entering the DTLS Setup phase SHOULD NOT assume that the 6054 WTP has reset, and therefore should not discard active state until 6055 the DTLS session has been successfully established. While the 6056 HelloVerifyRequest provides some protection against denial of service 6057 (DoS) attacks on the AC, an adversary capable of receiving packets at 6058 a valid address (or a malfunctioning or misconfigured WTP) may 6059 repeatedly attempt DTLS handshakes with the AC, potentially creating 6060 a resource shortage. If either the FailedDTLSSessionCount or the 6061 FailedDTLSAuthFailCount counter reaches the value of 6062 MaxFailedDTLSSessionRetry variable (see Section 4.8), implementations 6063 MAY choose to rate-limit new DTLS handshakes for some period of time. 6064 It is RECOMMENDED that implementations choosing to implement rate 6065 limiting use a random discard technique, rather than mimicking the 6066 WTP's sulking behavior. This will ensure that messages from valid 6067 WTPs will have some probability of eliciting a response, even in the 6068 face of a significant DoS attack. 6070 Some CAPWAP implementations may wish to restrict the DTLS setup 6071 process to only those peers that have been configured in the access 6072 control list, authorizing only those clients to initiate a DTLS 6073 handshake. Note that the impact of this on mitigating denial of 6074 service attacks against the DTLS layer is minimal, because DTLS 6075 already uses client-side cookies to minimize processor consumption 6076 attacks. 6078 12.4. Interference with a DTLS Session 6080 If a WTP or AC repeatedly receives packets which fail DTLS 6081 authentication or decryption, this could indicate a DTLS 6082 desynchronization between the AC and WTP, a link prone to 6083 undetectable bit errors, or an attacker trying to disrupt a DTLS 6084 session. 6086 In the state machine (section 2.3), transitions to the DTLS tear down 6087 state can be triggered by frequently receiving DTLS packets with 6088 authentication or decryption errors. The threshold or technique for 6089 deciding when to move to the tear down state should be chosen 6090 carefully. Being able to easily transition to DTLS TD allows easy 6091 detection of malfunctioning devices, but allows for denial of service 6092 attacks. Making it difficult to transition to DTLS TD prevents 6093 denial of service attacks, but makes it more difficult to detect and 6094 reset a malfunctioning session. Implementers should set this policy 6095 with care. 6097 12.5. CAPWAP Pre-Provisioning 6099 In order for CAPWAP to establish a secure communication with a peer, 6100 some level of pre-provisioning on both the WTP and AC is necessary. 6101 This section will detail the minimal number of configuration 6102 parameters. 6104 When using preshared keys, it is necessary to configure the preshared 6105 key for each possible peer with which a DTLS session may be 6106 established. To support this mode of operation, one or more entries 6107 of the following table may be configured on either the AC or WTP: 6109 o Identity: The identity of the peering AC or WTP. This format MAY 6110 be either in the form of an IP address or host name (the latter of 6111 which needs to be resolved to an IP address using DNS). 6113 o Key: The pre-shared key for use with the peer when establishing 6114 the DTLS session (see Section 12.6 for more information). 6116 o PSK Identity: Identity hint associated with the provisioned key 6117 (see Section 2.4.4.4 for more information). 6119 When using certificates, the following items need to be pre- 6120 provisioned: 6122 o Device Certificate: The local device's certificate (see 6123 Section 12.7 for more information) 6125 o Trust Anchor: Trusted root certificate chain used to validate any 6126 certificate received from CAPWAP peers. Note that one or more 6127 root certificate MAY be configured on a given device. 6129 Regardless of the authentication method, the following items need to 6130 be pre-provisioned: 6132 o Access Control List: The access control list table contains the 6133 identities of one or more CAPWAP peers, along with a rule. The 6134 rule is used to determine whether communication with the peer is 6135 permitted (see Section 2.4.4.3 for more information). 6137 12.6. Use of Preshared Keys in CAPWAP 6139 While use of preshared keys may provide deployment and provisioning 6140 advantages not found in public key based deployments, it also 6141 introduces a number of operational and security concerns. In 6142 particular, because the keys must typically be entered manually, it 6143 is common for people to base them on memorable words or phrases. 6144 These are referred to as "low entropy passwords/passphrases". 6146 Use of low-entropy preshared keys, coupled with the fact that the 6147 keys are often not frequently updated, tends to significantly 6148 increase exposure. For these reasons, the following recommendations 6149 are made: 6151 o When DTLS is used with a preshared-key (PSK) ciphersuite, each WTP 6152 SHOULD have a unique PSK. Since WTPs will likely be widely 6153 deployed, their physical security is not guaranteed. If PSKs are 6154 not unique for each WTP, key reuse would allow the compromise of 6155 one WTP to result in the compromise of others 6157 o Generating PSKs from low entropy passwords is NOT RECOMMENDED. 6159 o It is RECOMMENDED that implementations that allow the 6160 administrator to manually configure the PSK also provide a 6161 capability for generation of new random PSKs, taking RFC 4086 6162 [RFC4086] into account. 6164 o Preshared keys SHOULD be periodically updated. Implementations 6165 MAY facilitate this by providing an administrative interface for 6166 automatic key generation and periodic update, or it MAY be 6167 accomplished manually instead. 6169 Every pairwise combination of WTP and AC on the network SHOULD have a 6170 unique PSK. This prevents the domino effect (see Guidance for AAA 6171 Key Management [RFC4962]). If PSKs are tied to specific WTPs, then 6172 knowledge of the PSK implies a binding to a specified identity that 6173 can be authorized. 6175 If PSKs are shared, this binding between device and identity is no 6176 longer possible. Compromise of one WTP can yield compromise of 6177 another WTP, violating the CAPWAP security hierarchy. Consequently, 6178 sharing keys between WTPs is NOT RECOMMENDED. 6180 12.7. Use of Certificates in CAPWAP 6182 For public-key-based DTLS deployments, each device SHOULD have unique 6183 credentials, with an extended key usage authorizing the device to act 6184 as either a WTP or AC. If devices do not have unique credentials, it 6185 is possible that by compromising one device, any other device using 6186 the same credential may also be considered to be compromised. 6188 Certificate validation involves checking a large variety of things. 6189 Since the necessary things to validate are often environment- 6190 specific, many are beyond the scope of this document. In this 6191 section, we provide some basic guidance on certificate validation. 6193 Each device is responsible for authenticating and authorizing devices 6194 with which they communicate. Authentication entails validation of 6195 the chain of trust leading to the peer certificate, followed by the 6196 peer certificate itself. Implementations SHOULD also provide a 6197 secure method for verifying that the credential in question has not 6198 been revoked. 6200 Note that if the WTP relies on the AC for network connectivity (e.g. 6201 the AC is a layer 2 switch to which the WTP is directly connected), 6202 the WTP may not be able to contact an OCSP server or otherwise obtain 6203 an up to date CRL if a compromised AC doesn't explicitly permit this. 6204 This cannot be avoided, except through effective physical security 6205 and monitoring measures at the AC. 6207 Proper validation of certificates typically requires checking to 6208 ensure the certificate has not yet expired. If devices have a real- 6209 time clock, they SHOULD verify the certificate validity dates. If no 6210 real-time clock is available, the device SHOULD make a best-effort 6211 attempt to validate the certificate validity dates through other 6212 means. Failure to check a certificate's temporal validity can make a 6213 device vulnerable to man-in-the-middle attacks launched using 6214 compromised, expired certificates, and therefore devices should make 6215 every effort to perform this validation. 6217 12.8. AAA Security 6219 The AAA protocol is used to distribute EAP keys to the ACs, and 6220 consequently its security is important to the overall system 6221 security. When used with TLS or IPsec, security guidelines specified 6222 in RFC 3539 [RFC3539] SHOULD be followed. 6224 In general, the link between the AC and AAA server SHOULD be secured 6225 using a strong ciphersuite keyed with mutually authenticated session 6226 keys. Implementations SHOULD NOT rely solely on Basic RADIUS shared 6227 secret authentication as it is often vulnerable to dictionary 6228 attacks, but rather SHOULD use stronger underlying security 6229 mechanisms. 6231 13. Operational Considerations 6233 The CAPWAP protocol assumes that it is the only configuration 6234 interface to the WTP to configure parameters that are specified in 6235 the CAPWAP specifications. While the use of a separate management 6236 protocol MAY be used for the purposes of monitoring the WTP directly, 6237 configuring the WTP through a separate management interface is not 6238 recommended. Configuring the WTP through a separate protocol, such 6239 as via a CLI or SNMP, could lead to the AC state being out of sync 6240 with the WTP. 6242 The CAPWAP protocol does not deal with the management of the ACs. 6243 The AC is assumed to be configured through some separate management 6244 interface, which could be via a proprietary CLI, SNMP, NETCONF or 6245 some other management protocol. 6247 The CAPWAP protocol's control channel is fairly light weight from a 6248 traffic perspective. Once the WTP has been configured, the WTP sends 6249 periodic statistics. Further, the specification calls for a 6250 keepalive packet to be sent on the protocol's data channel to make 6251 sure that any possible middleboxes (e.g., NAT) maintain their UDP 6252 state. The overhead associated with the control and data channel is 6253 not expected to impact network traffic. That said, the CAPWAP 6254 protocol does allow for the frequency of these packets to be modified 6255 through the DataChannelKeepAlive and StatisticsTimer (see 6256 Section 4.7.2 and Section 4.7.14, respectively). 6258 14. Transport Considerations 6260 The CAPWAP WG carefully considered the congestion control 6261 requirements of the CAPWAP protocol, both for the CAPWAP control and 6262 data channels. 6264 CAPWAP specifies a single-threaded command/response protocol to be 6265 used on the control channel, and we have specified that an 6266 exponential back-off algorithm should be used when commands are 6267 retransmitted. When CAPWAP runs in its default mode (Local MAC), the 6268 control channel is the only CAPWAP channel. 6270 However, CAPWAP can also be run in Split MAC mode, in which case 6271 there will be a DTLS-encrypted data channel between each WTP and the 6272 AC. The WG discussed various options for providing congestion 6273 control on this channel. However, due to performance problems with 6274 TCP when it is run over another congestion control mechanism and the 6275 fact that the vast majority of traffic run over the CAPWAP data 6276 channel is likely to be congestion-controlled IP traffic, the CAPWAP 6277 WG felt that specifying a congestion control mechanism for the CAPWAP 6278 data channel would be more likely to cause problems than to resolve 6279 any. 6281 Because there is no congestion control mechanism specified for the 6282 CAPWAP data channel, it is recommended that non-congestion-controlled 6283 traffic not be tunneled over CAPWAP. When a significant amount of 6284 non-congestion-controlled traffic is expected to be present on a 6285 WLAN, the CAPWAP connection between the AC and the WTP for that LAN 6286 should be configured to remain in Local MAC mode with Distribution 6287 function at the WTP. 6289 The lock step nature of the CAPWAP protocol's control channel can 6290 cause the firmware download process to take some time, depending upon 6291 the RTT. This is not expected to be a problem since the CAPWAP 6292 protocol allows firmware to be downloaded while the WTP provides 6293 service to wireless clients/devices. 6295 It is necessary for the WTP and AC to configure their MTU based on 6296 the capabilities of the path. See Section 3.5 for more information. 6298 15. IANA Considerations 6300 This section details the actions to be taken by IANA during the 6301 publication of the specification. There are numerous registries that 6302 need to be created, and the contents, document action (see [RFC5226], 6303 and registry format are all included below. Note that in cases where 6304 bit fields are referred to, the bit numbering is left to right, where 6305 the leftmost bit is labelled as bit zero (0). 6307 For registration requests where an Expert Review is required, a 6308 Designated Expert should be consulted, which is appointed by the 6309 responsible IESG area director. The intention is that any allocation 6310 will be accompanied by a published RFC, but given that other SDOs may 6311 want to create standards built on top of CAPWAP, a document the 6312 Designated Expert can review is also acceptable. IANA should allow 6313 for allocation of values prior to documents being approved for 6314 publication, so the Designated Expert can approve allocations once it 6315 seems clear that publication will occur. The Designated expert will 6316 post a request to the CAPWAP WG mailing list (or a successor 6317 designated by the Area Director) for comment and review. Before a 6318 period of 30 days has passed, the Designated Expert will either 6319 approve or deny the registration request and publish a notice of the 6320 decision to the CAPWAP WG mailing list or its successor, as well as 6321 informing IANA. A denial notice must be justified by an explanation, 6322 and in the cases where it is possible, concrete suggestions on how 6323 the request can be modified so as to become acceptable should be 6324 provided. 6326 15.1. Multicast Address 6328 This document requires a new organization local multicast address 6329 called the "All ACs multicast address" from the IPv6 multicast 6330 address registry [to be removed upon publication 6331 http://www.iana.org/assignments/ipv6-multicast-addresses]. The new 6332 multicast address is to be inserted in Section 3.3. 6334 15.2. UDP Port 6336 This document requires a two UDP Ports organization local multicast 6337 address from the registered port numbers registry [to be removed upon 6338 publication http://www.iana.org/assignments/port-numbers]. The new 6339 UDP Ports numbers have already been assigned and can be found in 6340 Section 3.1. The following values are being registered: 6342 Keyword Decimal Description References 6343 ------- ------- ----------- ---------- 6344 capwap-control 5246/udp CAPWAP Control Protocol This Document 6345 capwap-data 5247/udp CAPWAP Data Protocol This Document 6346 15.3. CAPWAP Message Types 6348 The Message Type field in the CAPWAP header (see Section 4.5.1.1) is 6349 used to identify the operation performed by the message. There are 6350 multiple namespaces, which is identified via the first three octets 6351 of the field containing the IANA Enterprise Number [RFC5226]. 6353 IANA will create and maintain the CAPWAP Message Types registry for 6354 all message types whose Enterprise Number is set to zero (0). The 6355 namespace is 32 bits (0-4294967295), where the value of zero (0) is 6356 reserved and must not be assigned. The values one (1) through 26 are 6357 allocated in this specification, and can be found in Section 4.5.1.1. 6358 Any new assignments of a CAPWAP Message Type, whose Enterprise Number 6359 is set to zero (0) requires a Expert Review. The format of the 6360 registry to be maintained by IANA has the following format: 6362 CAPWAP Control Message Message Type Reference 6363 Value 6365 15.4. CAPWAP Header Flags 6367 The Flags field in the CAPWAP header (see Section 4.3) is 9 bits in 6368 length and is used to identify any special treatment related to the 6369 message. This specification defines bits zero (0) through five (5), 6370 while bits six (6) through eight (8) are reserved. There are 6371 currently three unused, reserved bits which are managed by IANA and 6372 whose assignment requires a Expert Review. IANA will create the 6373 CAPWAP Header Flags registry, whose format is: 6375 Flag Field Name Bit Position Reference 6377 15.5. CAPWAP Control Message Flags 6379 The Flags field in the CAPWAP Control Message header (see 6380 Section 4.5.1.4) is used to identify any special treatment related to 6381 the control message. There are currently eight (8) unused, reserved 6382 bits. These bits whose assignment is managed by IANA and requires a 6383 Expert Review. IANA will create the CAPWAP Control Message Flags 6384 registry, whose format is: 6386 Flag Field Name Bit Position Reference 6388 15.6. CAPWAP Message Element Type 6390 The Type field in the CAPWAP Message Element header (see Section 4.6) 6391 is used to identify the data being transported. The namespace is 16 6392 bits (0-65535), where the value of zero (0) is reserved and must not 6393 be assigned. The values one (1) through 52 are allocated in this 6394 specification, and can be found in Section 4.5.1.1. This namespace 6395 is managed by IANA and assignments require a Expert Review. IANA 6396 will create the CAPWAP Message Element Type registry, whose format 6397 is: 6399 CAPWAP Message Element Type Value Reference 6401 15.7. Wireless Binding Identifiers 6403 The Wireless Binding Identifier (WBID) field in the CAPWAP header 6404 (see Section 4.3) is used to identify the wireless technology 6405 associated with the packet. This specification allocates the values 6406 one (1) and three (3). Due to the limited address space available, a 6407 new WBID request requires Expert Review. IANA will create the CAPWAP 6408 Wireless Binding Identifier registry, whose format is: 6410 CAPWAP Wireless Binding Identifier Type Value Reference 6412 15.8. AC Security Types 6414 The Security field in the AC Descriptor message element (see 6415 Section 4.6.1) is 8 bits in length and used to identify the 6416 authentication methods available on the AC. This specification 6417 defines bits five (5) and six (6), while bits zero (0) through four 6418 (4) as well as bit seven (7) are reserved and unused. These reserved 6419 bits are managed by IANA and assignment requires a Standards Action. 6420 IANA will create the AC Security Types registry, whose format is: 6422 AC Security Type Bit Position Reference 6424 15.9. AC DTLS Policy 6426 The DTLS Policy field in the AC Descriptor message element (see 6427 Section 4.6.1) is 8 bits in length and used to identify whether the 6428 CAPWAP Data Channel is to be secured. This specification defines 6429 bits five (5) and six (6), while bits zero (0) through four (4) as 6430 well as bit seven (7) are reserved and unused. These reserved bits 6431 are managed by IANA and assignment requires a Standards Action. IANA 6432 will create the AC DTLS Policy registry, whose format is: 6434 AC DTLS Policy Bit Position Reference 6436 15.10. AC Information Type 6438 The Information Type field in the AC Descriptor message element (see 6439 Section 4.6.1) is used to represent information about the AC. The 6440 namespace is 16 bits (0-65535), where the value of zero (0) is 6441 reserved and must not be assigned. This field, combined with the AC 6442 Information Vendor ID, allows vendors to use a private namespace. 6443 This specification defines the AC Information Type namespace when the 6444 AC Information Vendor ID is set to zero (0), for which the values 6445 four (4) and five (5) are allocated in this specification, and can be 6446 found in Section 4.6.1. This namespace is managed by IANA and 6447 assignments require a Expert Review. IANA will create the AC 6448 Information Type registry, whose format is: 6450 AC Information Type Type Value Reference 6452 15.11. CAPWAP Transport Protocol Types 6454 The Transport field in the CAPWAP Transport Protocol message element 6455 (see Section 4.6.14) is used to identify the transport to use for the 6456 CAPWAP Data Channel. The namespace is 8 bits (0-255), where the 6457 value of zero (0) is reserved and must not be assigned. The values 6458 one (1) and two (2) are allocated in this specification, and can be 6459 found in Section 4.6.14. This namespace is managed by IANA and 6460 assignments require a Expert Review. IANA will create the CAPWAP 6461 Transport Protocol Types registry, whose format is: 6463 CAPWAP Transport Protocol Type Type Value Reference 6465 15.12. Data Transfer Type 6467 The Data Type field in the Data Transfer Data message element (see 6468 Section 4.6.15) and Image Data message element (see Section 4.6.25) 6469 is used to provide information about the data being carried. The 6470 namespace is 8 bits (0-255), where the value of zero (0) is reserved 6471 and must not be assigned. The values one (1), two (2) and five (5) 6472 are allocated in this specification, and can be found in 6473 Section 4.6.15. This namespace is managed by IANA and assignments 6474 require a Expert Review. IANA will create the Data Transfer Type 6475 registry, whose format is: 6477 Data Transfer Type Type Value Reference 6479 15.13. Data Transfer Mode 6481 The Data Mode field in the Data Transfer Data message element (see 6482 Section 4.6.15) and Data Transfer Mode message element (see 6483 Section 15.13) is used to provide information about the data being 6484 carried. The namespace is 8 bits (0-255), where the value of zero 6485 (0) is reserved and must not be assigned. The values one (1) and two 6486 (2) are allocated in this specification, and can be found in 6487 Section 15.13. This namespace is managed by IANA and assignments 6488 require a Expert Review. IANA will create the Data Transfer Mode 6489 registry, whose format is: 6491 Data Transfer Mode Type Value Reference 6493 15.14. Discovery Types 6495 The Discovery Type field in the Discovery Type message element (see 6496 Section 4.6.21) is used by the WTP to indicate to the AC how it was 6497 discovered. The namespace is 8 bits (0-255). The values zero (0) 6498 through four (4) are allocated in this specification, and can be 6499 found in Section 4.6.21. This namespace is managed by IANA and 6500 assignments require a Expert Review. IANA will create the Discovery 6501 Types registry, whose format is: 6503 Discovery Types Type Value Reference 6505 15.15. Radio Admin State 6507 The Radio Admin field in the Radio Administrative State message 6508 element (see Section 4.6.32) is used by the WTP to represent the 6509 state of its radios. The namespace is 8 bits (0-255), where the 6510 value of zero (0) is reserved and must not be assigned. The values 6511 one (1) and two (2) are allocated in this specification, and can be 6512 found in Section 4.6.32. This namespace is managed by IANA and 6513 assignments require a Expert Review. IANA will create the Radio 6514 Admin State registry, whose format is: 6516 Radio Admin State Type Value Reference 6518 15.16. Radio Operational State 6520 The State field in the Radio Operational State message element (see 6521 Section 4.6.33) is used by the WTP to represent the operational state 6522 of its radios. The namespace is 8 bits (0-255), where the value of 6523 zero (0) is reserved and must not be assigned. The values one (1) 6524 and two (2) are allocated in this specification, and can be found in 6525 Section 4.6.33. This namespace is managed by IANA and assignments 6526 require a Expert Review. IANA will create the Radio Operational 6527 State registry, whose format is: 6529 Radio Operational State Type Value Reference 6531 15.17. Radio Failure Causes 6533 The Cause field in the Radio Operational State message element (see 6534 Section 4.6.33) is used by the WTP to represent the reason why a 6535 radio may have failed. The namespace is 8 bits (0-255), where the 6536 value of zero (0) through three (3) are allocated in this 6537 specification, and can be found in Section 4.6.33. This namespace is 6538 managed by IANA and assignments require a Expert Review. IANA will 6539 create the Radio Failure Causes registry, whose format is: 6541 Radio Failure Causes Type Value Reference 6543 15.18. Result Code 6545 The Result Code field in the Result Code message element (see 6546 Section 4.6.34) is used to indicate the success, or failure, of a 6547 CAPWAP control message. The namespace is 32 bits (0-4294967295), 6548 where the value of zero (0) through 22 are allocated in this 6549 specification, and can be found in Section 4.6.34. This namespace is 6550 managed by IANA and assignments require a Expert Review. IANA will 6551 create the Result Code registry, whose format is: 6553 Result Code Type Value Reference 6555 15.19. Returned Message Element Reason 6557 The Reason field in the Returned Message Element message element (see 6558 Section 4.6.35) is used to indicate the reason why a message element 6559 was not processed successfully. The namespace is 8 bits (0-255), 6560 where the value of zero (0) is reserved and must not be assigned. 6561 The values one (1) through four (4) are allocated in this 6562 specification, and can be found in Section 4.6.35. This namespace is 6563 managed by IANA and assignments require a Expert Review. IANA will 6564 create the Returned Message Element Reason registry, whose format is: 6566 Returned Message Element Reason Type Value Reference 6568 15.20. WTP Board Data Type 6570 The Board Data Type field in the WTP Board Data message element (see 6571 Section 4.6.39) is used to represent information about the WTP 6572 hardware. The namespace is 16 bits (0-65535). The WTP Board Data 6573 Type values zero (0) through four (4) are allocated in this 6574 specification, and can be found in Section 4.6.39. This namespace is 6575 managed by IANA and assignments require a Expert Review. IANA will 6576 create the WTP Board Data Type registry, whose format is: 6578 WTP Board Data Type Type Value Reference 6580 15.21. WTP Descriptor Type 6582 The Descriptor Type field in the WTP Descriptor message element (see 6583 Section 4.6.40) is used to represent information about the WTP 6584 software. The namespace is 16 bits (0-65535). This field, combined 6585 with the Descriptor Vendor ID, allows vendors to use a private 6586 namespace. This specification defines the WTP Descriptor Type 6587 namespace when the Descriptor Vendor ID is set to zero (0), for which 6588 the values zero (0) through three (3) are allocated in this 6589 specification, and can be found in Section 4.6.40. This namespace is 6590 managed by IANA and assignments require a Expert Review. IANA will 6591 create the WTP Board Data Type registry, whose format is: 6593 WTP Descriptor Type Type Value Reference 6595 15.22. WTP Fallback Mode 6597 The Mode field in the WTP Fallback message element (see 6598 Section 4.6.41) is used to indicate to the WTP the type of AC 6599 fallback mechanism it should employ. The namespace is 8 bits 6600 (0-255), where the value of zero (0) is reserved and must not be 6601 assigned. The values one (1) and two (2) are allocated in this 6602 specification, and can be found in Section 4.6.41. This namespace is 6603 managed by IANA and assignments require a Expert Review. IANA will 6604 create the WTP Fallback Mode registry, whose format is: 6606 WTP Fallback Mode Type Value Reference 6608 15.23. WTP Frame Tunnel Mode 6610 The Tunnel Type field in the WTP Frame Tunnel Mode message element 6611 (see Section 4.6.42) is 8 bits and is used to indicate the type of 6612 tunneling to use between the WTP and the AC. This specification 6613 defines bits four (4) through six (6), while bits zero (0) through 6614 four (4) as well as bit seven (7) are reserved and unused. These 6615 reserved bits are managed by IANA and assignment requires a Expert 6616 Review. IANA will create the AC DTLS Policy registry, whose format 6617 is: 6619 WTP Frame Tunnel Mode Bit Position Reference 6621 15.24. WTP MAC Type 6623 The MAC Type field in the WTP MAC Type message element (see 6624 Section 4.6.43) is used to indicate the type of MAC to use in 6625 tunneled frames between the WTP and the AC. The namespace is 8 bits 6626 (0-255), where the value of zero (0) through two (2) are allocated in 6627 this specification, and can be found in Section 4.6.43. This 6628 namespace is managed by IANA and assignments require a Expert Review. 6629 IANA will create the WTP MAC Type registry, whose format is: 6631 WTP MAC Type Type Value Reference 6633 15.25. WTP Radio Stats Failure Type 6635 The Last Failure Type field in the WTP Radio Statistics message 6636 element (see Section 4.6.45) is used to indicate the last WTP 6637 failure. The namespace is 8 bits (0-255), where the value of zero 6638 (0) through three (3) as well as the value 255 are allocated in this 6639 specification, and can be found in Section 4.6.45. This namespace is 6640 managed by IANA and assignments require a Expert Review. IANA will 6641 create the WTP Radio Stats Failure Type registry, whose format is: 6643 WTP Radio Stats Failure Type Type Value Reference 6645 15.26. WTP Reboot Stats Failure Type 6647 The Last Failure Type field in the WTP Reboot Statistics message 6648 element (see Section 4.6.46) is used to indicate the last reboot 6649 reason. The namespace is 8 bits (0-255), where the value of zero (0) 6650 through five (5) as well as the value 255 are allocated in this 6651 specification, and can be found in Section 4.6.46. This namespace is 6652 managed by IANA and assignments require a Expert Review. IANA will 6653 create the WTP Reboot Stats Failure Type registry, whose format is: 6655 WTP Reboot Stats Failure Type Type Value Reference 6657 16. Acknowledgments 6659 The following individuals are acknowledged for their contributions to 6660 this protocol specification: Puneet Agarwal, Abhijit Choudhury, Pasi 6661 Eronen, Saravanan Govindan, Peter Nilsson, David Perkins and Yong 6662 Zhang. 6664 Michael Vakulenko contributed text to describe how CAPWAP can be used 6665 over layer 3 (IP/UDP) networks. 6667 17. References 6669 17.1. Normative References 6671 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 6672 Requirement Levels", BCP 14, RFC 2119, March 1997. 6674 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 6675 April 1992. 6677 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 6678 Requirements for Security", BCP 106, RFC 4086, June 2005. 6680 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 6681 Specification, Implementation", RFC 1305, March 1992. 6683 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 6684 Housley, R., and W. Polk, "Internet X.509 Public Key 6685 Infrastructure Certificate and Certificate Revocation List 6686 (CRL) Profile", RFC 5280, May 2008. 6688 [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and 6689 Accounting (AAA) Transport Profile", RFC 3539, June 2003. 6691 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 6692 for Transport Layer Security (TLS)", RFC 4279, 6693 December 2005. 6695 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 6696 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 6698 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 6699 Security", RFC 4347, April 2006. 6701 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 6702 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 6703 May 2008. 6705 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 6706 G. Fairhurst, "The Lightweight User Datagram Protocol 6707 (UDP-Lite)", RFC 3828, July 2004. 6709 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 6710 Discovery", RFC 4821, March 2007. 6712 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 6713 (IPv6) Specification", RFC 2460, December 1998. 6715 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 6716 November 1990. 6718 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 6719 for IP version 6", RFC 1981, August 1996. 6721 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 6722 specifying the location of services (DNS SRV)", RFC 2782, 6723 February 2000. 6725 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 6726 10646", STD 63, RFC 3629, November 2003. 6728 [I-D.ietf-capwap-protocol-binding-ieee80211] 6729 Calhoun, P., "CAPWAP Protocol Binding for IEEE 802.11", 6730 draft-ietf-capwap-protocol-binding-ieee80211-07 (work in 6731 progress), July 2008. 6733 [I-D.ietf-capwap-dhc-ac-option] 6734 Calhoun, P., "CAPWAP Access Controller DHCP Option", 6735 draft-ietf-capwap-dhc-ac-option-01 (work in progress), 6736 March 2008. 6738 [FRAME-EXT] 6739 IEEE, "IEEE Standard 802.3as-2006", 2005. 6741 17.2. Informational References 6743 [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by 6744 an On-line Database", RFC 3232, January 2002. 6746 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 6747 RFC 3753, June 2004. 6749 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 6750 Authorization, and Accounting (AAA) Key Management", 6751 BCP 132, RFC 4962, July 2007. 6753 [RFC4564] Govindan, S., Cheng, H., Yao, ZH., Zhou, WH., and L. Yang, 6754 "Objectives for Control and Provisioning of Wireless 6755 Access Points (CAPWAP)", RFC 4564, July 2006. 6757 [I-D.ohara-capwap-lwapp] 6758 Calhoun, P., "Light Weight Access Point Protocol", 6759 draft-ohara-capwap-lwapp-04 (work in progress), 6760 March 2007. 6762 [I-D.narasimhan-ietf-slapp] 6763 Narasimhan, P., "SLAPP : Secure Light Access Point 6764 Protocol", draft-narasimhan-ietf-slapp-01 (work in 6765 progress), March 2006. 6767 [DTLS-DESIGN] 6768 Modadugu et al, N., "The Design and Implementation of 6769 Datagram TLS", Feb 2004. 6771 [EUI-48] IEEE, "Guidelines for use of a 48-bit Extended Unique 6772 Identifier", Dec 2005. 6774 [EUI-64] IEEE, "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) 6775 REGISTRATION AUTHORITY". 6777 [EPCGlobal] 6778 "See http://www.epcglobalinc.org/home". 6780 Editors' Addresses 6782 Pat R. Calhoun 6783 Cisco Systems, Inc. 6784 170 West Tasman Drive 6785 San Jose, CA 95134 6787 Phone: +1 408-902-3240 6788 Email: pcalhoun@cisco.com 6790 Michael P. Montemurro 6791 Research In Motion 6792 5090 Commerce Blvd 6793 Mississauga, ON L4W 5M4 6794 Canada 6796 Phone: +1 905-629-4746 x4999 6797 Email: mmontemurro@rim.com 6799 Dorothy Stanley 6800 Aruba Networks 6801 1322 Crossman Ave 6802 Sunnyvale, CA 94089 6804 Phone: +1 630-363-1389 6805 Email: dstanley@arubanetworks.com 6807 Full Copyright Statement 6809 Copyright (C) The IETF Trust (2008). 6811 This document is subject to the rights, licenses and restrictions 6812 contained in BCP 78, and except as set forth therein, the authors 6813 retain all their rights. 6815 This document and the information contained herein are provided on an 6816 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 6817 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 6818 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 6819 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 6820 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 6821 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 6823 Intellectual Property 6825 The IETF takes no position regarding the validity or scope of any 6826 Intellectual Property Rights or other rights that might be claimed to 6827 pertain to the implementation or use of the technology described in 6828 this document or the extent to which any license under such rights 6829 might or might not be available; nor does it represent that it has 6830 made any independent effort to identify any such rights. Information 6831 on the procedures with respect to rights in RFC documents can be 6832 found in BCP 78 and BCP 79. 6834 Copies of IPR disclosures made to the IETF Secretariat and any 6835 assurances of licenses to be made available, or the result of an 6836 attempt made to obtain a general license or permission for the use of 6837 such proprietary rights by implementers or users of this 6838 specification can be obtained from the IETF on-line IPR repository at 6839 http://www.ietf.org/ipr. 6841 The IETF invites any interested party to bring to its attention any 6842 copyrights, patents or patent applications, or other proprietary 6843 rights that may cover technology that may be required to implement 6844 this standard. Please address the information to the IETF at 6845 ietf-ipr@ietf.org.