idnits 2.17.1 draft-ietf-capwap-protocol-specification-08.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 5739. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 5750. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 5757. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 5763. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([16]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Unless otherwise specified, a control message that lists a set of supported (or expected) message elements MUST not expect the message elements to be in any specific order. The sender MAY include the message elements in any order. Unless otherwise noted, one message element of each type is present in a given control message. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 16, 2007) is 5999 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'ChangeCipherSpec' on line 1193 == Unused Reference: '9' is defined on line 5646, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 5657, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1305 (ref. '3') (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 3280 (ref. '4') (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 4346 (ref. '7') (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4347 (ref. '8') (Obsoleted by RFC 6347) ** Obsolete normative reference: RFC 2434 (ref. '10') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 1883 (ref. '13') (Obsoleted by RFC 2460) ** Obsolete normative reference: RFC 1981 (ref. '15') (Obsoleted by RFC 8201) == Outdated reference: A later version (-12) exists of draft-ietf-capwap-protocol-binding-ieee80211-04 -- Possible downref: Normative reference to a draft: ref. '17' Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 10 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 Expires: May 19, 2008 M. Montemurro, Editor 5 Research In Motion 6 D. Stanley, Editor 7 Aruba Networks 8 November 16, 2007 10 CAPWAP Protocol Specification 11 draft-ietf-capwap-protocol-specification-08 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on May 19, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This specification defines the Control And Provisioning of Wireless 45 Access Points (CAPWAP) Protocol. The CAPWAP protocol meets the IETF 46 CAPWAP working group protocol requirements. The CAPWAP protocol is 47 designed to be flexible, allowing it to be used for a variety of 48 wireless technologies. This document describes the base CAPWAP 49 protocol. The CAPWAP protocol binding which defines extensions for 50 use with the IEEE 802.11 wireless LAN protocol is available in [16]. 51 Extensions are expected to be defined to enable use of the CAPWAP 52 protocol with additional wireless technologies. 54 1. Introduction 56 This document describes the CAPWAP Protocol, a standard, 57 interoperable protocol which enables an Access Controller (AC) to 58 manage a collection of Wireless Termination Points (WTPs). The 59 CAPWAP protocol is defined to be independent of layer 2 technology. 61 The emergence of centralized IEEE 802.11 Wireless Local Area Network 62 (WLAN) architectures, in which simple IEEE 802.11 WTPs are managed by 63 an Access Controller (AC) suggested that a standards based, 64 interoperable protocol could radically simplify the deployment and 65 management of wireless networks. WTPs require a set of dynamic 66 management and control functions related to their primary task of 67 connecting the wireless and wired mediums. Traditional protocols for 68 managing WTPs are either manual static configuration via HTTP, 69 proprietary Layer 2 specific or non-existent (if the WTPs are self- 70 contained). An IEEE 802.11 binding is defined in [16] to support use 71 of the CAPWAP protocol with IEEE 802.11 WLAN networks. 73 CAPWAP assumes a network configuration consisting of multiple WTPs 74 communicating via the Internet Protocol (IP) to an AC. WTPs are 75 viewed as remote RF interfaces controlled by the AC. The CAPWAP 76 protocol supports two modes of operation: Split and Local MAC. In 77 Split MAC mode all L2 wireless data and management frames are 78 encapsulated via the CAPWAP protocol and exchanged between the AC and 79 the WTP. As shown in Figure 1, the wireless frames received from a 80 mobile device, which is referred to in this specification as a 81 Station (STA), are directly encapsulated by the WTP and forwarded to 82 the AC. 84 +-+ wireless frames +-+ 85 | |--------------------------------| | 86 | | +-+ | | 87 | |--------------| |---------------| | 88 | |wireless PHY/ | | CAPWAP | | 89 | | MAC sublayer | | | | 90 +-+ +-+ +-+ 91 STA WTP AC 93 Figure 1: Representative CAPWAP Architecture for Split MAC 95 The Local MAC mode of operation allows for the data frames to be 96 either locally bridged, or tunneled as 802.3 frames. The latter 97 implies that the WTP performs the 802 bridging function. In either 98 case the L2 wireless management frames are processed locally by the 99 WTP, and then forwarded to the AC. Figure 2 shows the Local MAC 100 mode, in which a station transmits a wireless frame which is 101 encapsulated in an 802.3 frame and forwarded to the AC. 103 +-+wireless frames +-+ 802.3 frames +-+ 104 | |----------------| |--------------| | 105 | | | | | | 106 | |----------------| |--------------| | 107 | |wireless PHY/ | | CAPWAP | | 108 | | MAC sublayer | | | | 109 +-+ +-+ +-+ 110 STA WTP AC 112 Figure 2: Representative CAPWAP Architecture for Local MAC 114 Provisioning WTPs with security credentials, and managing which WTPs 115 are authorized to provide service are traditionally handled by 116 proprietary solutions. Allowing these functions to be performed from 117 a centralized AC in an interoperable fashion increases manageability 118 and allows network operators to more tightly control their wireless 119 network infrastructure. 121 1.1. Goals 123 The goals for the CAPWAP protocol are listed below: 125 1. To centralize the authentication and policy enforcement functions 126 for a wireless network. The AC may also provide centralized 127 bridging, forwarding, and encryption of user traffic. 128 Centralization of these functions will enable reduced cost and 129 higher efficiency by applying the capabilities of network 130 processing silicon to the wireless network, as in wired LANs. 132 2. To enable shifting of the higher level protocol processing from 133 the WTP. This leaves the time critical applications of wireless 134 control and access in the WTP, making efficient use of the 135 computing power available in WTPs which are the subject to severe 136 cost pressure. 138 3. To provide a generic encapsulation and transport mechanism, 139 enabling the CAPWAP protocol to be applied to many access point 140 types in the future, via a specific wireless binding. 142 The CAPWAP protocol concerns itself solely with the interface between 143 the WTP and the AC. Inter-AC and station-to AC-communication are 144 strictly outside the scope of this document. 146 1.2. Conventions used in this document 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in RFC 2119 [1]. 152 1.3. Contributing Authors 154 This section lists and acknowledges the authors of significant text 155 and concepts included in this specification. 157 The CAPWAP Working Group selected the Lightweight Access Point 158 Protocol (LWAPP) [add reference, when available] to be used as the 159 basis of the CAPWAP protocol specification. The following people are 160 authors of the LWAPP document: 162 Bob O'Hara, Cisco Systems, Inc. 163 170 West Tasman Drive, San Jose, CA 95134 164 Phone: +1 408-853-5513, Email: bob.ohara@cisco.com 166 Pat Calhoun, Cisco Systems, Inc. 167 170 West Tasman Drive, San Jose, CA 95134 168 Phone: +1 408-853-5269, Email: pcalhoun@cisco.com 170 Rohit Suri, Cisco Systems, Inc. 171 170 West Tasman Drive, San Jose, CA 95134 172 Phone: +1 408-853-5548, Email: rsuri@cisco.com 174 Nancy Cam Winget, Cisco Systems, Inc. 175 170 West Tasman Drive, San Jose, CA 95134 176 Phone: +1 408-853-0532, Email: ncamwing@cisco.com 178 Scott Kelly, Aruba Networks 179 1322 Crossman Ave, Sunnyvale, CA 94089 180 Phone: +1 408-754-8408, Email: skelly@arubanetworks.com 182 Michael Glenn Williams, Nokia, Inc. 183 313 Fairchild Drive, Mountain View, CA 94043 184 Phone: +1 650-714-7758, Email: Michael.G.Williams@Nokia.com 186 Sue Hares, Nexthop Technologies, Inc. 187 825 Victors Way, Suite 100, Ann Arbor, MI 48108 188 Phone: +1 734 222 1610, Email: shares@nexthop.com 190 DTLS is used as the security solution for the CAPWAP protocol. The 191 following people are authors of significant DTLS-related text 192 included in this document: 194 Scott Kelly, Aruba Networks 195 1322 Crossman Ave, Sunnyvale, CA 94089 196 Phone: +1 408-754-8408, Email: skelly@arubanetworks.com 198 Eric Rescorla, Network Resonance 199 2483 El Camino Real, #212,Palo Alto CA, 94303 200 Email: ekr@networkresonance.com 202 The concept of using DTLS to secure the CAPWAP protocol was part of 203 the Secure Light Access Point Protocol (SLAPP) proposal [add 204 reference when available]. The following people are authors of the 205 SLAPP proposal: 207 Partha Narasimhan, Aruba Networks 208 1322 Crossman Ave, Sunnyvale, CA 94089 209 Phone: +1 408-480-4716, Email: partha@arubanetworks.com 211 Dan Harkins, Tropos Networks 212 555 Del Rey Avenue, Sunnyvale, CA, 95085 213 Phone: +1 408 470 7372, Email: dharkins@tropos.com 215 Subbu Ponnuswamy, Aruba Networks 216 1322 Crossman Ave, Sunnyvale, CA 94089 217 Phone: +1 408-754-1213, Email: subbu@arubanetworks.com 219 The following individuals contributed significant security related 220 text to the draft: 222 T. Charles Clancy, Laboratory for Telecommunications Sciences, 223 8080 Greenmead Drive, College Park, MD 20740 224 Phone: +1 240-373-5069, Email: clancy@ltsnet.net 226 Scott Kelly, Aruba Networks 227 1322 Crossman Ave, Sunnyvale, CA 94089 228 Phone: +1 408-754-8408, Email: skelly@arubanetworks.com 230 1.4. Terminology 232 Access Controller (AC): The network entity that provides WTPs access 233 to the network infrastructure in the data plane, control plane, 234 management plane, or a combination therein. 236 CAPWAP Control Channel: A bi-directional flow defined by the AC IP 237 Address, WTP IP Address, AC control port, WTP control port and the 238 transport-layer protocol (UDP or UDP-Lite) over which CAPWAP control 239 packets are sent and received. 241 CAPWAP Data Channel: A bi-directional flow defined by the AC IP 242 Address, WTP IP Address, AC data port, WTP data port, and the 243 transport-layer protocol (UDP or UDP-Lite) over which CAPWAP data 244 packets are sent and received. 246 Station (STA): A device that contains an IEEE 802.11 conformant 247 medium access control (MAC) and physical layer (PHY) interface to the 248 wireless medium (WM). 250 Wireless Termination Point (WTP): The physical or network entity that 251 contains an RF antenna and wireless PHY to transmit and receive 252 station traffic for wireless access networks. 254 This document uses additional terminology defined in [19]. 256 2. Protocol Overview 258 The CAPWAP protocol is a generic protocol defining AC and WTP control 259 and data plane communication via a CAPWAP protocol transport 260 mechanism. CAPWAP control messages, and optionally CAPWAP data 261 messages, are secured using Datagram Transport Layer Security (DTLS) 262 [7]. DTLS is a standards-track IETF protocol based upon TLS. The 263 underlying security-related protocol mechanisms of TLS have been 264 successfully deployed for many years. 266 The CAPWAP protocol Transport layer carries two types of payload, 267 CAPWAP Data messages and CAPWAP Control messages. CAPWAP Data 268 messages encapsulate forwarded wireless frames. CAPWAP protocol 269 Control messages are management messages exchanged between a WTP and 270 an AC. The CAPWAP Data and Control packets are sent over separate 271 UDP ports. Since both data and control packets can exceed the 272 Maximum Transmission Unit (MTU) length, the payload of a CAPWAP data 273 or control message can be fragmented. The fragmentation behavior is 274 defined in Section 3. 276 The CAPWAP Protocol begins with a discovery phase. The WTPs send a 277 Discovery Request message, causing any Access Controller (AC) 278 receiving the message to respond with a Discovery Response message. 279 From the Discovery Response messages received, a WTP selects an AC 280 with which to establish a secure DTLS session. CAPWAP protocol 281 messages will be fragmented to the maximum length discovered to be 282 supported by the network. 284 Once the WTP and the AC have completed DTLS session establishment, a 285 configuration exchange occurs in which both devices agree on version 286 information. During this exchange the WTP may receive provisioning 287 settings. The WTP is then enabled for operation. 289 When the WTP and AC have completed the version and provision exchange 290 and the WTP is enabled, the CAPWAP protocol is used to encapsulate 291 the wireless data frames sent between the WTP and AC. The CAPWAP 292 protocol will fragment the L2 frames if the size of the encapsulated 293 wireless user data (Data) or protocol control (Management) frames 294 causes the resulting CAPWAP protocol packet to exceed the MTU 295 supported between the WTP and AC. Fragmented CAPWAP packets are 296 reassembled to reconstitute the original encapsulated payload. MTU 297 Discovery and Fragmentation is described in Section 3. 299 The CAPWAP protocol provides for the delivery of commands from the AC 300 to the WTP for the management of stations that are communicating with 301 the WTP. This may include the creation of local data structures in 302 the WTP for the stations and the collection of statistical 303 information about the communication between the WTP and the stations. 305 The CAPWAP protocol provides a mechanism for the AC to obtain 306 statistical information collected by the WTP. 308 The CAPWAP protocol provides for a keep alive feature that preserves 309 the communication channel between the WTP and AC. If the AC fails to 310 appear alive, the WTP will try to discover a new AC. 312 2.1. Wireless Binding Definition 314 The CAPWAP protocol is independent of a specific WTP radio 315 technology. Elements of the CAPWAP protocol are designed to 316 accommodate the specific needs of each wireless technology in a 317 standard way. Implementation of the CAPWAP protocol for a particular 318 wireless technology MUST follow the binding requirements defined for 319 that technology. 321 When defining a binding for wireless technologies, the authors MUST 322 include any necessary definitions for technology-specific messages 323 and all technology-specific message elements for those messages. At 324 a minimum, a binding MUST provide: 326 1 - The definition for a binding-specific Statistics message 327 element, carried in the WTP Event Request message 329 2 - A message element carried in the Station Configuration Request 330 message to configure station information on the WTP 332 3 - A WTP Radio Information message element carried in the 333 Discovery, Primary Discovery and Join Request and Response 334 messages, indicating the binding specific radio types supported at 335 the WTP and AC. 337 If technology specific message elements are required for any of the 338 existing CAPWAP messages defined in this specification, they MUST 339 also be defined in the technology binding document. 341 The naming of binding-specific message elements MUST begin with the 342 name of the technology type, e.g., the binding for IEEE 802.11, 343 provided in [16], begins with "IEEE 802.11". 345 The CAPWAP binding concept is also used in any future specifications 346 that add functionality to either the base CAPWAP protocol 347 specification, or any published CAPWAP binding specification. A 348 separate WTP Radio Information message element MUST be created to 349 properly advertise support for the specification. This mechanism 350 allows for future protocol extensibility, while providing the 351 necessary capabilities advertisement, through the WTP Radio 352 Information message element, to ensure WTP/AC interoperability. 354 2.2. CAPWAP Session Establishment Overview 356 This section describes the session establishment process message 357 exchanges in the ideal case. The annotated ladder diagram shows the 358 AC on the right, the WTP on the left, and assumes the use of 359 certificates for DTLS authentication. The CAPWAP Protocol State 360 Machine is described in detail in Section 2.3. Note that DTLS allows 361 certain messages to be aggregated into a single frame, which is 362 denoted via an asterix in the following figure. 364 ============ ============ 365 WTP AC 366 ============ ============ 367 [----------- begin optional discovery ------------] 369 Discover Request 370 ------------------------------------> 371 Discover Response 372 <------------------------------------ 374 [----------- end optional discovery ------------] 376 (-- begin DTLS handshake --) 378 ClientHello 379 ------------------------------------> 380 HelloVerifyRequest (with cookie) 381 <------------------------------------ 383 ClientHello (with cookie) 384 ------------------------------------> 385 ServerHello, 386 Certificate, 387 ServerHelloDone* 388 <------------------------------------ 390 (-- WTP callout for AC authorization --) 392 Certificate (optional), 393 ClientKeyExchange, 394 CertificateVerify (optional), 395 ChangeCipherSpec, 396 Finished* 397 ------------------------------------> 399 (-- AC callout for WTP authorization --) 400 ChangeCipherSpec, 401 Finished* 402 <------------------------------------ 404 (-- DTLS session is established now --) 406 Join Request 407 ------------------------------------> 408 Join Response 409 <------------------------------------ 410 [-- Join State Complete --] 412 (-- assume image is up to date --) 414 Configuration Status Request 415 ------------------------------------> 416 Configuration Status Response 417 <------------------------------------ 418 [-- Configure State Complete --] 420 Change State Event Request 421 ------------------------------------> 422 Change State Event Response 423 <------------------------------------ 424 [-- Data Check State Complete --] 426 (-- enter RUN state --) 428 : 429 : 431 Echo Request 432 ------------------------------------> 433 Echo Response 434 <------------------------------------ 436 : 437 : 439 Event Request 440 ------------------------------------> 441 Event Response 442 <------------------------------------ 444 : 445 : 447 At the end of the illustrated CAPWAP message exchange, the AC and WTP 448 are securely exchanging CAPWAP control messages. This is an 449 idealized illustration, provided to clarify protocol operation. 450 Section 2.3 provides a detailed description of the corresponding 451 state machine. 453 2.3. CAPWAP State Machine Definition 455 The following state diagram represents the lifecycle of a WTP-AC 456 session. Use of DTLS by the CAPWAP protocol results in the 457 juxtaposition of two nominally separate yet tightly bound state 458 machines. The DTLS and CAPWAP state machines are coupled through an 459 API consisting of commands (see Section 2.3.2.1) and notifications 460 (see Section 2.3.2.2). Certain transitions in the DTLS state machine 461 are triggered by commands from the CAPWAP state machine, while 462 certain transitions in the CAPWAP state machine are triggered by 463 notifications from the DTLS state machine. 465 /-------------------------------------\ 466 | /-------------------------\| 467 | w| || 468 | 5+----------+ x +------------+ || 469 | | Run |-->| Reset |-\|| 470 | +----------+ +------------+ ||| 471 6| u ^ ^ ^ y||| 472 +------------+--------/ | | ||| 473 | Data Check | /-------/ | ||| 474 +------------+<-------\ | | ||| 475 | | | ||| 476 /------------------+--------\ | ||| 477 r| t| s| 4 v o| ||| 478 +--------+ +-----------+ +--------------+||| 479 | Join |---->| Configure | | Image Data |||| 480 +--------+ q +-----------+ +--------------+||| 481 ^ p| V| x| ||| 482 | | \-------------------\ | ||| 483 | \--------------------------------------\| | ||| 484 \------------------------\ || | ||| 485 /--------------<----------------+--------------\ || | ||| 486 | /------------<-------------\ | | || | ||| 487 | | m| |n z| vv v vvv 488 | | +----------------+ +--------------+ +-----------+ 489 | | | DTLS Setup | | DTLS Connect | | DTLS TD | 490 | | +----------------+ +--------------+ +-----------+ 491 | | g| ^ ^ |h ^ ^ 492 v v | | | | | | 493 | | | | | \-------\ | /-----------/ 494 | | | | | | | | 495 | | v |e f| 2 v |j |k 496 | \->+------+ +------+ +-----------+ 497 | | Idle |-->| Disc | | Authorize | 498 \--->+------+ a +------+ +-----------+ 499 b| ^ |c 500 | | /----/ 501 v d| | 502 +---------+ | 503 | Sulking |<-/ 504 3 +---------+ 506 Figure 3: CAPWAP Integrated State Machine 508 The CAPWAP protocol state machine, depicted above, is used by both 509 the AC and the WTP. In cases where states are not shared (i.e. not 510 implemented in one or the other of the AC or WTP), this is explicitly 511 called out in the transition descriptions below. For every state 512 defined, only certain messages are permitted to be sent and received. 514 The CAPWAP control messages definitions specify the state(s) in which 515 each message is valid. 517 Since the WTP only communicates with a single AC, it only has a 518 single instance of the CAPWAP state machine. The AC has a separate 519 instance of the CAPWAP state machine per WTP it is communicating 520 with. 522 2.3.1. CAPWAP Protocol State Transitions 524 This section describes the various state transitions, and the events 525 that cause them. This section does not discuss interactions between 526 DTLS- and CAPWAP-specific states. Those interactions, and DTLS- 527 specific states and transitions, are discussed in Section 2.3.2. 529 Idle to Discovery (a): This transition occurs once device 530 initialization is complete. 532 WTP: The WTP enters the Discovery state prior to transmitting the 533 first Discovery Request message (see Section 5.1). Upon 534 entering this state, the WTP sets the DiscoveryInterval timer 535 (see Section 4.7). The WTP resets the DiscoveryCount counter 536 to zero (0) (see Section 4.8). The WTP also clears all 537 information from ACs it may have received during a previous 538 Discovery phase. 540 AC: The AC does not maintain state information for the WTP upon 541 reception of the Discovery Request message, but it SHOULD 542 respond with a Discovery Response message (see Section 5.2). 543 This transition is a no-op for the AC. 545 Idle to Sulking (b): This transition occurs to force the WTP and AC 546 to enter a quiet period to avoid repeatedly attempting to 547 establish a connection. 549 WTP: The WTP enters this state when the FailedDTLSSessionCount or 550 the FailedDTLSAuthFailCount counter reaches 551 MaxFailedDTLSSessionRetry variable (see Section 4.8). Upon 552 entering this state, the WTP MUST start the SilentInterval 553 timer. While in the Sulking state, all received CAPWAP and 554 DTLS protocol messages received MUST be ignored. 556 AC: The AC enters this state with the specific WTP when the 557 FailedDTLSSessionCount or the FailedDTLSAuthFailCount counter 558 reaches MaxFailedDTLSSessionRetry variable (see Section 4.8). 559 Upon entering this state, the AC MUST start the SilentInterval 560 timer. While in the Sulking state, all received CAPWAP and 561 DTLS protocol messages received from the WTP MUST be ignored. 563 Discovery to Discovery (2): In the Discovery state, the WTP 564 determines which AC to connect to. 566 WTP: This transition occurs when the DiscoveryInterval timer 567 expires. If the WTP is configured with a list of ACs, it 568 transmits a Discovery Request message to every AC from which it 569 has not received a Discovery Response message. For every 570 transition to this event, the WTP increments the DiscoveryCount 571 counter. See Section 5.1 for more information on how the WTP 572 knows the ACs to which it should transmit the Discovery Request 573 messages. The WTP restarts the DiscoveryInterval timer 574 whenever it transmits Discovery Request messages. 576 AC: This is a no-op. 578 Discovery to Sulking (c): This transition occurs on a WTP when 579 Discovery or connectivity to the AC fails. 581 WTP: The WTP enters this state when the DiscoveryInterval timer 582 expires or the DiscoveryCount variable is equal to the 583 MaxDiscoveries variable (see Section 4.8). Upon entering this 584 state, the WTP MUST start the SilentInterval timer. While in 585 the Sulking state, all received CAPWAP protocol messages 586 received MUST be ignored. 588 AC: This is a no-op. 590 Sulking to Idle (d): This transition occurs on a WTP when it must 591 restart the discovery phase. 593 WTP: The WTP enters this state when the SilentInterval timer (see 594 Section 4.7) expires. The FailedDTLSSessionCount, 595 DiscoveryCount and FailedDTLSAuthFailCount counters are reset 596 to zero. 598 AC: The AC enters this state when the SilentInterval timer (see 599 Section 4.7) expires. The FailedDTLSSessionCount, 600 DiscoveryCount and FailedDTLSAuthFailCount counters are reset 601 to zero. 603 Sulking to Sulking (3): The Sulking state provides the silent 604 period, minimizing the possibility for Denial of Service (DoS) 605 attacks. 607 WTP: All packets received from the AC while in the sulking state 608 are ignored. 610 AC: All packets receive from the WTP while in the sulking state 611 are ignored. 613 Idle to DTLS Setup (e): This transition occurs to establish a secure 614 DTLS session with the peer. 616 WTP: The WTP initiates this transition by invoking the DTLSStart 617 command, which starts the DTLS session establishment with the 618 chosen AC. When the discovery phase is bypassed, it is assumed 619 the WTP has a locally configured AC. 621 AC: The AC initiates this transition by invoking the DTLSListen 622 command, which informs the DTLS stack that it is willing to 623 listen for an incoming session. The AC MAY provide optional 624 qualifiers in the DTLSListen command to only accept session 625 requests from specific WTPs. 627 Discovery to DTLS Setup (f): This transition occurs to establish a 628 secure DTLS session with the peer. 630 WTP: The WTP initiates this transition by invoking the DTLSStart 631 command (see Section 2.3.2.1), which starts the DTLS session 632 establishment with the chosen AC. The decision of which AC to 633 connect to is the result of the discovery phase, which is 634 described in Section 3.3. 636 AC: The AC initiates this transition by invoking the DTLSListen 637 command (see Section 2.3.2.1), which informs the DTLS stack 638 that it is willing to listen for an incoming session. The AC 639 MAY have maintained state information when it received the 640 Discovery Request message to provide optional qualifiers in the 641 DTLSListen command to only accept session requests from a 642 specific WTP. Note that maintaining state information based on 643 an unsecured Discovery Request message MAY lead to a Denial of 644 Service attack. Therefore the AC SHOULD ensure that the state 645 information is freed after a period, which is implementation 646 specific. 648 DTLS Setup to Idle (g): This transition occurs when the DTLS Session 649 failed to be established. 651 WTP: The WTP initiates this state transition when it receives a 652 DTLSEstablishFail notification from DTLS (see Section 2.3.2.2). 653 This error notification aborts the secure DTLS session 654 establishment. When this notification is received, the 655 FailedDTLSSessionCount counter is incremented. 657 AC: The WTP initiates this state transition when it receives a 658 DTLSEstablishFail notification from DTLS (see Section 2.3.2.2). 659 This error notification aborts the secure DTLS session 660 establishment. When this notification is received, the 661 FailedDTLSSessionCount counter is incremented. 663 DTLS Setup to Authorize (h): This transition occurs when an incoming 664 DTLS session is being established, and the DTLS stack needs 665 authorization to proceed with the session establishment. 667 WTP: This state transition occurs when the WTP receives the 668 DTLSPeerAuthorize notification (see Section 2.3.2.2). Upon 669 entering this state, the WTP performs an authorization check 670 against the AC credentials. See Section 2.4.4 for more 671 information on AC authorization. 673 AC: This state transition occurs when the AC receives the 674 DTLSPeerAuthorize notification (see Section 2.3.2.2). Upon 675 entering this state, the AC performs an authorization check 676 against the WTP credentials. See Section 2.4.4 for more 677 information on WTP authorization. 679 Authorize to DTLS Connect (j): This transition occurs to notify the 680 DTLS stack that the session should be established. 682 WTP: This state transition occurs when the WTP has either opted 683 to forgo the authorization check of the AC's credentials, or 684 the credentials were successfully authorized. This is done by 685 invoking the DTLSAccept DTLS command (see Section 2.3.2.1). 687 AC: This state transition occurs when the AC has either opted to 688 forgo the authorization check of the WTP's credentials, or the 689 credentials were successfully authorized. This is done by 690 invoking the DTLSAccept DTLS command (see Section 2.3.2.1). 692 Authorize to DTLS Teardown (k): This transition occurs to notify the 693 DTLS stack that the session should be aborted. 695 WTP: This state transition occurs when the WTP was unable to 696 authorize the AC, using the AC credentials. The WTP then 697 aborts the DTLS session by invoking the DTLSAbortSession 698 command (see Section 2.3.2.1). 700 AC: This state transition occurs when the AC was unable to 701 authorize the WTP, using the WTP credentials. The AC then 702 aborts the DTLS session by invoking the DTLSAbortSession 703 command (see Section 2.3.2.1). 705 DTLS Connect to Idle (m): This transition occurs when the DTLS 706 Session failed to be established. 708 WTP: This state transition occurs when the WTP receives either a 709 DTLSAborted or DTLSAuthenticateFail notification (see 710 Section 2.3.2.2), indicating that the DTLS session was not 711 successfully established. When this transition occurs due to 712 the DTLSAuthenticateFail notification, the 713 FailedDTLSAuthFailCount is incremented, otherwise the 714 FailedDTLSSessionCount counter is incremented. 716 AC: This state transition occurs when the AC receives either a 717 DTLSAborted or DTLSAuthenticateFail notification (see 718 Section 2.3.2.2), indicating that the DTLS session was not 719 successfully established. When this transition occurs due to 720 the DTLSAuthenticateFail notification, the 721 FailedDTLSAuthFailCount is incremented, otherwise the 722 FailedDTLSSessionCount counter is incremented. 724 DTLS Connect to Join (n): This transition occurs when the DTLS 725 Session is successfully established. 727 WTP: This state transition occurs when the WTP receives the 728 DTLSEstablished notification (see Section 2.3.2.2), indicating 729 that the DTLS session was successfully established. When this 730 notification is received, the FailedDTLSSessionCount counter is 731 set to zero. 733 AC: This state transition occurs when the AC receives the 734 DTLSEstablished notification (see Section 2.3.2.2), indicating 735 that the DTLS session was successfully established. When this 736 notification is received, the FailedDTLSSessionCount counter is 737 set to zero, and the WaitJoin timer is started (see 738 Section 4.7). 740 Join to DTLS Teardown (p): This transition occurs when the join 741 process failed. 743 WTP: This state transition occurs when the WTP receives a Join 744 Response message with a Result Code message element containing 745 an error, if the Image Identifier provided by the AC in the 746 Join Response message differs from the WTP's currently running 747 firmware version and the WTP has the requested image in its 748 non-volatile memory, or if the WaitDTLS timer expires. This 749 causes the WTP to initiate the DTLSShutdown command (see 750 Section 2.3.2.1). This transition also occurs if the WTP 751 receives one of the following DTLS notifications: DTLSAborted, 752 DTLSReassemblyFailure or DTLSPeerDisconnect. 754 AC: This state transition occurs either if the WaitJoin timer 755 expires or if the AC transmits a Join Response message with a 756 Result Code message element containing an error. This causes 757 the AC to initiate the DTLSShutdown command (see 758 Section 2.3.2.1). This transition also occurs if the AC 759 receives one of the following DTLS notifications: DTLSAborted, 760 DTLSReassemblyFailure or DTLSPeerDisconnect. 762 Join to Image Data (r): This state transition is used by the WTP and 763 the AC to download executable firmware. 765 WTP: The WTP enters the Image Data state when it receives a 766 successful Join Response message and determines and the 767 included Image Identifier message element is not the same as 768 its currently running image. The WTP also detects that the 769 requested image version is not currently available in the WTP's 770 non-volatile storage (see Section 9.1 for a full description of 771 the firmware download process). The WTP initializes the 772 EchoInterval timer (see Section 4.7), and transmits the Image 773 Data Request message (see Section 9.1.1) requesting the start 774 of the firmware download. 776 AC: This state transition occurs when the AC receives the Image 777 Data Request message from the WTP. The AC MUST transmit an 778 Image Data Response message (see Section 9.1.2) to the WTP, 779 which includes a portion of the firmware. The AC MUST start 780 the ImageDataStartTimer timer (see Section 4.7). 782 Join to Configure (q): This state transition is used by the WTP and 783 the AC to exchange configuration information. 785 WTP: The WTP enters the Configure state when it receives a 786 successful Join Response, and determines that the included 787 Image Identifier message element is the same as its currently 788 running image. The WTP transmits the Configuration Status 789 message (see Section 8.2) to the AC with message elements 790 describing its current configuration. The WTP also starts the 791 ResponseTimeout timer (see Section 4.7). 793 AC: This state transition occurs immediately after the AC 794 transmits the Join Response message to the WTP. If the AC 795 receives the Configuration Status message from the WTP, the AC 796 MUST transmit a Configuration Status Response message (see 797 Section 8.3) to the WTP, and MAY include specific message 798 elements to override the WTP's configuration. The WTP also 799 starts the ChangeStatePendingTimer timer (see Section 4.7). 801 Configure to Reset (s): This state transition is used to reset the 802 connection either due to an error during the configuration phase, 803 or when the WTP determines it needs to reset in order for the new 804 configuration to take effect. 806 WTP: The WTP enters the Reset state when it receives a 807 Configuration Status Response indicating an error or when it 808 determines that a reset of the WTP is required, due to the 809 characteristics of a new configuration. 811 AC: The AC transitions to the Reset state when it receives a 812 Change State Event message from the WTP that contains an error 813 for which AC policy does not permit the WTP to provide service. 814 This state transition also occurs when the AC 815 ChangeStatePendingTimer timer expires. 817 Configure to DTLS Teardown (V): This transition occurs when the 818 configuration process aborts due to a DTLS error. 820 WTP: The WTP enters this state when it receives one of the 821 following DTLS notifications: DTLSAborted, 822 DTLSReassemblyFailure or DTLSPeerDisconnect (see 823 Section 2.3.2.2). The WTP MAY tear down the DTLS session if it 824 receives frequent DTLSDecapFailure notifications. 826 AC: The AC enters this state when it receives one of the 827 following DTLS notifications: DTLSAborted, 828 DTLSReassemblyFailure or DTLSPeerDisconnect (see 829 Section 2.3.2.2). The WTP MAY tear down the DTLS session if it 830 receives frequent DTLSDecapFailure notifications. 832 Image Data to Image Data (4): The Image Data state is used by the 833 WTP and the AC during the firmware download phase. 835 WTP: The WTP enters the Image Data state when it receives an 836 Image Data Response message indicating that the AC has more 837 data to send. 839 AC: This state transition occurs when the AC receives the Image 840 Data Request message from the WTP while already in the Image 841 Data state. The AC resets the ImageDataStartTimer timer. 843 Image Data to Reset (o): This state transition is used to reset the 844 DTLS connection prior to restarting the WTP after an image 845 download. 847 WTP: When an image download completes, the WTP enters the Reset 848 state. The WTP MAY also transition to this state upon 849 receiving an Image Data Response message from the AC (see 850 Section 9.1.2) indicating a failure. 852 AC: The AC enters the Reset state when an error occurs during the 853 image download process or if the ImageDataStartTimer timer 854 expires. 856 Image Data to DTLS Teardown (x): This transition occurs when the 857 firmware download process aborts due to a DTLS error. 859 WTP: The WTP enters this state when it receives one of the 860 following DTLS notifications: DTLSAborted, 861 DTLSReassemblyFailure or DTLSPeerDisconnect (see 862 Section 2.3.2.2). The WTP MAY tear down the DTLS session if it 863 receives frequent DTLSDecapFailure notifications. 865 AC: The AC enters this state when it receives one of the 866 following DTLS notifications: DTLSAborted, 867 DTLSReassemblyFailure or DTLSPeerDisconnect (see 868 Section 2.3.2.2). The WTP MAY tear down the DTLS session if it 869 receives frequent DTLSDecapFailure notifications. 871 Configure to Data Check (t): This state transition occurs when the 872 WTP and AC confirm the configuration. 874 WTP: The WTP enters this state when it receives a successful 875 Configuration Status Response message from the AC. The WTP 876 initializes the EchoInterval timer (see Section 4.7), and 877 transmits the Change State Event Request message (see 878 Section 8.6). 880 AC: This state transition occurs when the AC receives the Change 881 State Event Request message (see Section 8.6) from the WTP. 882 The AC responds with a Change State Event Response message (see 883 Section 8.7). The AC MUST start the DataCheckTimer timer (see 884 Section 4.7). 886 Data Check to DTLS Teardown (6): This transition occurs when the WTP 887 does not complete the Data Check exchange. 889 WTP: This state transition occurs if the WTP does not receive the 890 Change State Event Response before a CAPWAP transmission 891 timeout occurs. 893 AC: The AC enters this state when the DataCheckTimer timer 894 expires (see Section 4.7). 896 Data Check to Run (u): This state transition occurs when the linkage 897 between the control and data channels has occured, causing the WTP 898 and AC to enter their normal state of operation. 900 WTP: The WTP enters this state when it receives a successful 901 Change State Event Response message from the AC. The WTP 902 initiates the data channel, which MAY require the establishment 903 of a DTLS session, starts the DataChannelKeepAlive timer (see 904 Section 4.7) and transmits a Data Channel Keep Alive packet 905 (see Section 4.4.1). The WTP then starts the 906 DataChannelDeadInterval timer (see Section 4.7). 908 AC: This state transition occurs when the AC receives the Data 909 Channel Keep Alive packet (see Section 4.4.1), with a Session 910 ID message element matching that included by the WTP in the 911 Join Request message. The AC disables the DataCheckTimer 912 timer. Note that if AC policy is to require the data channel 913 to be encrypted, this process would also require the 914 establishment of a data channel DTLS session. Upon receiving 915 the Data Channel Keep Alive packet, the AC transmits its own 916 Data Channel Keep Alive packet. 918 Run to DTLS Teardown (u): This state transition occurs when an error 919 has occured in the DTLS stack, causing the DTLS session to be 920 torndown. 922 WTP: The WTP enters this state when it receives one of the 923 following DTLS notifications: DTLSAborted, 924 DTLSReassemblyFailure or DTLSPeerDisconnect (see 925 Section 2.3.2.2). The WTP MAY tear down the DTLS session if it 926 receives frequent DTLSDecapFailure notifications. The WTP also 927 transitions to this state if the underlying reliable 928 transport's RetransmitCount counter has reached the 929 MaxRetransmit variable (see Section 4.7). 931 AC: The AC enters this state when it receives one of the 932 following DTLS notifications: DTLSAborted, 933 DTLSReassemblyFailure or DTLSPeerDisconnect (see 934 Section 2.3.2.2). The WTP MAY tear down the DTLS session if it 935 receives frequent DTLSDecapFailure notifications. The AC 936 transitions to this state if the underlying reliable 937 transport's RetransmitCount counter has reached the 938 MaxRetransmit variable (see Section 4.7). 940 Run to Run (5): This is the normal state of operation. 942 WTP: This is the WTP's normal state of operation. There are many 943 events that result this state transition: 945 Configuration Update: The WTP receives a Configuration Update 946 Request message(see Section 8.4). The WTP MUST respond with 947 a Configuration Update Response message (see Section 8.5). 949 Change State Event: The WTP receives a Change State Event 950 Response message, or determines that it must initiate a 951 Change State Event Request message, as a result of a failure 952 or change in the state of a radio. 954 Echo Request: The WTP sends an Echo Request message 955 (Section 7.1) or receives the corresponding Echo Response 956 message, (see Section 7.2) from the AC. 958 Clear Config Request: The WTP receives a Clear Configuration 959 Request message (see Section 8.8). The WTP MUST reset its 960 configuration back to manufacturer defaults. 962 WTP Event: The WTP sends a WTP Event Request message, 963 delivering information to the AC (see Section 9.4). The WTP 964 receives a WTP Event Response message from the AC (see 965 Section 9.5). 967 Data Transfer: The WTP sends a Data Transfer Request message 968 to the AC (see Section 9.6). The WTP receives a Data 969 Transfer Response message from the AC (see Section 9.7). 971 Station Configuration Request: The WTP receives a Station 972 Configuration Request message (see Section 10.1), to which 973 it MUST respond with a Station Configuration Response 974 message (see Section 10.2). 976 AC: This is the AC's normal state of operation: 978 Configuration Update: The AC sends a Configuration Update 979 Request message (see Section 8.4) to the WTP to update its 980 configuration. The AC receives a Configuration Update 981 Response message (see Section 8.5) from the WTP. 983 Change State Event: The AC receives a Change State Event 984 Request message (see Section 8.6), to which it MUST respond 985 with the Change State Event Response message (see 986 Section 8.7). 988 Echo Request: The AC receives an Echo Request message (see 989 Section 7.1), to which it MUST respond with an Echo Response 990 message(see Section 7.2). 992 Clear Config Response: The AC receives a Clear Configuration 993 Response message from the WTP (see Section 8.9). 995 WTP Event: The AC receives a WTP Event Request message from 996 the WTP (see Section 9.4) and MUST generate a corresponding 997 WTP Event Response message (see Section 9.5). 999 Data Transfer: The AC receives a Data Transfer Request message 1000 from the WTP (see Section 9.6) and MUST generate a 1001 corresponding Data Transfer Response message (see 1002 Section 9.7). 1004 Station Configuration Request: The AC sends a Station 1005 Configuration Request message (see Section 10.1) or receives 1006 the corresponding Station Configuration Response message 1007 (see Section 10.2) from the WTP. 1009 Run to Reset (x): This state transition is used when either the AC 1010 or WTP tear down the connection. This may occur as part of normal 1011 operation, or due to error conditions. 1013 WTP: The WTP enters the Reset state when it receives a Reset 1014 Request message from the AC. 1016 AC: The AC enters the Reset state when it transmits a Reset 1017 Request message to the WTP. 1019 Reset to DTLS Teardown (y): This transition occurs when the CAPWAP 1020 reset is complete, to terminate the DTLS session. 1022 WTP: This state transition occurs when the WTP receives a Reset 1023 Response message. This causes the WTP to initiate the 1024 DTLSShutdown command (see Section 2.3.2.1). 1026 AC: This state transition occurs when the AC transmits a Reset 1027 Response message. The AC does not invoke the DTLSShutdown 1028 command (see Section 2.3.2.1). 1030 DTLS Teardown to Idle (z): This transition occurs when the DTLS 1031 session has been shutdown. 1033 WTP: This state transition occurs when the WTP has successfully 1034 cleaned up all resources associated with the control plane DTLS 1035 session. The data plane DTLS session is also shutdown, and all 1036 resources freed, if a DTLS session was established for the data 1037 plane. Any timers set for the current instance of the state 1038 machine are also cleared. 1040 AC: This state transition occurs when the AC has successfully 1041 cleaned up all resources associated with the control plane DTLS 1042 session. The data plane DTLS session is also shutdown, and all 1043 resources freed, if a DTLS session was established for the data 1044 plane. Any timers set for the current instance of the state 1045 machine are also cleared. 1047 2.3.2. CAPWAP/DTLS Interface 1049 This section describes the DTLS Commands used by CAPWAP, and the 1050 notifications received from DTLS to the CAPWAP protocol stack. 1052 2.3.2.1. CAPWAP to DTLS Commands 1054 Six commands are defined for the CAPWAP to DTLS API. These 1055 "commands" are conceptual, and may be implemented as one or more 1056 function calls. This API definition is provided to clarify 1057 interactions between the DTLS and CAPWAP components of the integrated 1058 CAPWAP state machine. 1060 Below is a list of the minimal command API: 1062 o DTLSStart is sent to the DTLS component to cause a DTLS session to 1063 be established. Upon invoking the DTLSStart command, the WaitDTLS 1064 timer is started. The WTP initiates this DTLS command, as the AC 1065 does not initiate DTLS sessions. 1067 o DTLSListen is sent to the DTLS component to allow the DTLS 1068 component to listen for incoming DTLS session requests. 1070 o DTLSAccept is sent to the DTLS component to allow the DTLS session 1071 establishment to continue successfully. 1073 o DTLSAbortSession is sent to the DTLS component to cause the 1074 session that is in the process of being established to be aborted. 1075 This command is also sent when the WaitDTLS timer expires. When 1076 this command is executed, the FailedDTLSSessionCount counter is 1077 incremented. 1079 o DTLSShutdown is sent to the DTLS component to cause session 1080 teardown. 1082 o DTLSMtuUpdate is sent by the CAPWAP component to modify the MTU 1083 size used by the DTLS component. See Section 3.5 for more 1084 information on MTU Discovery. The default size is 1468 bytes. 1086 2.3.2.2. DTLS to CAPWAP Notifications 1088 DTLS notifications are defined for the DTLS to CAPWAP API. These 1089 "notifications" are conceptual, and may be implemented in numerous 1090 ways (e.g. as function return values). This API definition is 1091 provided to clarify interactions between the DTLS and CAPWAP 1092 components of the integrated CAPWAP state machine. It is important 1093 to note that the notifications listed below MAY cause the CAPWAP 1094 state machine to jump from one state to another using a state 1095 transition not listed in Section 2.3.1. When a notification listed 1096 below occurs, the target CAPWAP state shown in Figure 3 becomes the 1097 current state. 1099 Below is a list of the API notifications: 1101 o DTLSPeerAuthorize is sent to the CAPWAP component during DTLS 1102 session establishment once the peer's identity has been received. 1103 This notification MAY be used by the CAPWAP component to authorize 1104 the session, based on the peer's identity. The authorization 1105 process will lead to the CAPWAP component initiating either the 1106 DTLSAccept or DTLSAbortSession commands. 1108 o DTLSEstablished is sent to the CAPWAP component to indicate that 1109 that a secure channel now exists, using the parameters provided 1110 during the DTLS initialization process. When this notification is 1111 received, the FailedDTLSSessionCount counter is reset to zero. 1112 When this notification is received, the WaitDTLS timer is stopped. 1114 o DTLSEstablishFail is sent when the DTLS session establishment has 1115 failed, either due to a local error, or due to the peer rejecting 1116 the session establishment. When this notification is received, 1117 the FailedDTLSSessionCount counter is incremented. 1119 o DTLSAuthenticateFail is sent when DTLS session establishment 1120 failed due to an authentication error. When this notification is 1121 received, the FailedDTLSAuthFailCount counter is incremented. 1123 o DTLSAborted is sent to the CAPWAP component to indicate that 1124 session abort (as requested by CAPWAP) is complete; this occurs to 1125 confirm a DTLS session abort, or when the WaitDTLS timer expires. 1126 When this notification is received, the WaitDTLS timer is stopped. 1128 o DTLSReassemblyFailure MAY be sent to the CAPWAP component to 1129 indicate DTLS fragment reassembly failure. 1131 o DTLSDecapFailure MAY be sent to the CAPWAP module to indicate a 1132 decapsulation failure. DTLSDecapFailure MAY be sent to the CAPWAP 1133 module to indicate an encryption/authentication failure. This 1134 notification is intended for informative purposes only, and is not 1135 intended to cause a change in the CAPWAP state machine (see 1136 Section 12.4). 1138 o DTLSPeerDisconnect is sent to the CAPWAP component to indicate the 1139 DTLS session has been torn down. Note that this notification is 1140 only received if the DTLS session has been established. 1142 2.4. Use of DTLS in the CAPWAP Protocol 1144 DTLS is used as a tightly-integrated, secure wrapper for the CAPWAP 1145 protocol. In this document DTLS and CAPWAP are discussed as 1146 nominally distinct entitites; however they are very closely coupled, 1147 and may even be implemented inseparably. Since there are DTLS 1148 library implementations currently available, and since security 1149 protocols (e.g. IPsec, TLS) are often implemented in widely 1150 available acceleration hardware, it is both convenient and forward- 1151 looking to maintain a modular distinction in this document. 1153 This section describes a detailed walk-through of the interactions 1154 between the DTLS module and the CAPWAP module, via 'commands' (CAPWAP 1155 to DTLS) and 'notifications' (DTLS to CAPWAP) as they would be 1156 encountered during the normal course of operation. 1158 2.4.1. DTLS Handshake Processing 1160 Details of the DTLS handshake process are specified in [8]. This 1161 section describes the interactions between the DTLS session 1162 establishment process and the CAPWAP protocol. Note that the 1163 conceptual DTLS state is shown below to help understand the point at 1164 which the DTLS states transition. In the normal case, the DTLS 1165 handshake will proceed as follows (NOTE: this example uses 1166 certificates, but preshared keys are also supported): 1168 ============ ============ 1169 WTP AC 1170 ============ ============ 1171 ClientHello ------> 1172 <------ HelloVerifyRequest 1173 (with cookie) 1175 ClientHello ------> 1176 (with cookie) 1177 <------ ServerHello 1178 <------ Certificate 1179 <------ ServerHelloDone 1181 (WTP callout for AC authorization 1182 occurs in CAPWAP Auth state) 1184 Certificate* 1185 ClientKeyExchange 1186 CertificateVerify* 1187 [ChangeCipherSpec] 1188 Finished ------> 1190 (AC callout for WTP authorization 1191 occurs in CAPWAP Auth state) 1193 [ChangeCipherSpec] 1194 <------ Finished 1196 DTLS, as specified, provides its own retransmit timers with an 1197 exponential back-off. However, DTLS will never terminate the 1198 handshake due to non-responsiveness; instead, DTLS will continue to 1199 increase its back-off timer period. Hence, timing out incomplete 1200 DTLS handshakes is entirely the responsiblity of the CAPWAP module. 1202 The DTLS implementation used by CAPWAP MUST support TLS Session 1203 Resumption. Session resumption is used to establish the DTLS session 1204 used for the data channel. The DTLS implementation on the WTP MUST 1205 return some unique identifier to the CAPWAP module to enable 1206 subsequent establishment of a DTLS-encrypted data channel, if 1207 necessary. 1209 2.4.2. DTLS Session Establishment 1211 The WTP, either through the Discovery process, or through pre- 1212 configuration, determines the AC to connect to. The WTP uses the 1213 DTLSStart command to request that a secure connection be established 1214 to the selected AC. Prior to initiation of the DTLS handshake, the 1215 WTP sets the WaitDTLS timer. Upon receiving the DTLSPeerAuthorize 1216 DTLS notification, the AC sets the WaitDTLS timer. If the 1217 DTLSEstablished notification is not received prior to timer 1218 expiration, the DTLS session is aborted by issuing the 1219 DTLSAbortSession DTLS command. This notification causes the CAPWAP 1220 module to transition to the Idle state. Upon receiving a 1221 DTLSEstablished notification, the WaitDTLS timer is deactivated. 1223 2.4.3. DTLS Error Handling 1225 If the AC does not respond to any DTLS messages sent by the WTP, the 1226 DTLS specification calls for the WTP to retransmit these messages. 1227 If the WaitDTLS timer expires, CAPWAP will issue the DTLSAbortSession 1228 command, causing DTLS to terminate the handshake and remove any 1229 allocated session context. Note that DTLS MAY send a single TLS 1230 Alert message to the AC to indicate session termination. 1232 If the WTP does not respond to any DTLS messages sent by the AC, the 1233 CAPWAP protocol allows for three possiblities, listed below. Note 1234 that DTLS MAY send a single TLS Alert message to the AC to indicate 1235 session termination. 1237 o The message was lost in transit; in this case, the WTP will re- 1238 transmit its last outstanding message, since it did not receive a 1239 reply. 1241 o The WTP sent a DTLS Alert, which was lost in transit; in this 1242 case, the AC's WaitDTLS timer will expire, and the session will be 1243 terminated. 1245 o Communication with the WTP has completely failed; in this case, 1246 the AC's WaitDTLS timer will expire, and the session will be 1247 terminated. 1249 The DTLS specification provides for retransmission of unacknowledged 1250 requests. If retransmissions remain unacknowledged, the WaitDTLS 1251 timer will eventually expire, at which time the CAPWAP component will 1252 terminate the session. 1254 If a cookie fails to validate, this could represent a WTP error, or 1255 it could represent a DoS attack. Hence, AC resource utilization 1256 SHOULD be minimized. The AC MAY log a message indicating the 1257 failure, but SHOULD NOT attempt to reply to the WTP. 1259 Since DTLS handshake messages are potentially larger than the maximum 1260 record size, DTLS supports fragmenting of handshake messages across 1261 multiple records. There are several potential causes of re-assembly 1262 errors, including overlapping and/or lost fragments. The DTLS 1263 component MUST send a DTLSReassemblyFailure notification to the 1264 CAPWAP component. Whether precise information is given along with 1265 notification is an implementation issue, and hence is beyond the 1266 scope of this document. Upon receipt of such an error, the CAPWAP 1267 component SHOULD log an appropriate error message. Whether 1268 processing continues or the DTLS session is terminated is 1269 implementation dependent. 1271 DTLS decapsulation errors consist of three types: decryption errors, 1272 authentication errors, and malformed DTLS record headers. Since DTLS 1273 authenticates the data prior to encapsulation, if decryption fails, 1274 it is difficult to detect this without first attempting to 1275 authenticate the packet. If authentication fails, a decryption error 1276 is also likely, but not guaranteed. Rather than attempt to derive 1277 (and require the implementation of) algorithms for detecting 1278 decryption failures, decryption failures are reported as 1279 authentication failures. The DTLS component MUST provide a 1280 DTLSDecapFailure notification to the CAPWAP component when such 1281 errors occur. If a malformed DTLS record header is detected, the 1282 packets SHOULD be silently discarded, and the receiver MAY log an 1283 error message. 1285 There is currently only one encapsulation error defined: MTU 1286 exceeded. As part of DTLS session establishment, the CAPWAP 1287 component informs the DTLS component of the MTU size. This may be 1288 dynamically modified at any time when the CAPWAP component sends the 1289 DTLSMtuUpdate command to the DTLS component (see Section 2.3.2.1). 1290 The value provided to the DTLS stack is the result of the MTU 1291 Discovery process, which is described in Section 3.5. The DTLS 1292 component returns this notification to the CAPWAP component whenever 1293 a transmission request will result in a packet which exceeds the MTU. 1295 2.4.4. DTLS EndPoint Authentication and Authorization 1297 DTLS supports endpoint authentication with certificates or preshared 1298 keys. The TLS algorithm suites for each endpoint authentication 1299 method are described below. 1301 2.4.4.1. Authenticating with Certificates 1303 Note that only block ciphers are currently recommended for use with 1304 DTLS. To understand the reasoning behind this, see [21]. At 1305 present, the following algorithms MUST be supported when using 1306 certificates for CAPWAP authentication: 1308 o TLS_RSA_WITH_AES_128_CBC_SHA 1310 The following algorithms SHOULD be supported when using certificates: 1312 o TLS_DH_RSA_WITH_AES_128_CBC_SHA 1314 The following algorithms MAY be supported when using certificates: 1316 o TLS_RSA_WITH_AES_256_CBC_SHA 1318 o TLS_DH_RSA_WITH_AES_256_CBC_SHA 1320 2.4.4.2. Authenticating with Preshared Keys 1322 Pre-shared keys present significant challenges from a security 1323 perspective, and for that reason, their use is strongly discouraged. 1324 Several methods for authenticating with preshared keys are defined 1325 [6], and we focus on the following two: 1327 o PSK key exchange algorithm - simplest method, ciphersuites use 1328 only symmetric key algorithms 1330 o DHE_PSK key exchange algorithm - use a PSK to authenticate a 1331 Diffie-Hellman exchange. These ciphersuites give some additional 1332 protection against dictionary attacks and also provide Perfect 1333 Forward Secrecy (PFS). 1335 The first approach (plain PSK) is susceptible to passive dictionary 1336 attacks; hence, while this alorithm MUST be supported, special care 1337 should be taken when choosing that method. In particular, user- 1338 readable passphrases SHOULD NOT be used, and use of short PSKs SHOULD 1339 be strongly discouraged. 1341 The following cryptographic algorithms MUST be supported when using 1342 preshared keys: 1344 o TLS_PSK_WITH_AES_128_CBC_SHA 1346 o TLS_DHE_PSK_WITH_AES_128_CBC_SHA 1348 The following algorithms MAY be supported when using preshared keys: 1350 o TLS_PSK_WITH_AES_256_CBC_SHA 1352 o TLS_DHE_PSK_WITH_AES_256_CBC_SHA 1354 2.4.4.3. Certificate Usage 1356 Certificate authorization by the AC and WTP is required so that only 1357 an AC may perform the functions of an AC and that only a WTP may 1358 perform the functions of a WTP. This restriction of functions to the 1359 AC or WTP requires that the certificates used by the AC MUST be 1360 distinguishable from the certificate used by the WTP. To accomplish 1361 this differentiation, the x.509 certificates MUST include the 1362 Extended Key Usage (EKU) certificate extension [4]. 1364 The EKU field indicates one or more purposes for which a certificate 1365 may be used. It is an essential part in authorization. Its syntax 1366 is as follows: 1368 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 1370 KeyPurposeId ::= OBJECT IDENTIFIER 1372 Here we define two KeyPurposeId values, one for the WTP and one for 1373 the AC. Inclusion of one of these two values indicates a certificate 1374 is authorized for use by a WTP or AC, respectively. These values are 1375 formatted as id-kp fields. 1377 id-kp OBJECT IDENTIFIER ::= 1378 { iso(1) identified-organization(3) dod(6) internet(1) 1379 security(5) mechanisms(5) pkix(7) 3 } 1381 id-kp-capwapAC OBJECT IDENTIFIER ::= { id-kp 18 } 1383 id-kp-capwapWTP OBJECT IDENTIFIER ::= { id-kp 19 } 1385 For an AC, the id-kp-capwapAC EKU MUST be present in the certificate. 1386 For a WTP, the id-kp-capwapWTP EKU MUST be present in the 1387 certificate. 1389 Part of the CAPWAP certificate validation process includes ensuring 1390 that the proper EKU is included and allowing the CAPWAP session to be 1391 established only if the extension properly represents the device. 1393 The certificate common name (CN) for both the WTP and AC MUST be the 1394 MAC address of that device. The MAC address MUST be formatted as 1395 ASCII HEX, e.g. 01:23:45:67:89:ab. 1397 ACs and WTPs SHOULD authorize (e.g. through access control lists) 1398 certificates of devices to which they are connecting, based on the 1399 MAC address and organizational information specified in the O and OU 1400 fields. The identities specified in the certificates bind a 1401 particular DTLS session to a specific pair of mutually-authenticated 1402 and authorized MAC addresses. 1404 2.4.4.4. PSK Usage 1406 When DTLS uses PSK Ciphersuites, the ServerKeyExchange message MUST 1407 contain the "PSK identity hint" field and the ClientKeyExchange 1408 message MUST contain the "PSK identity" field. These fields are used 1409 to help the WTP select the appropriate PSK for use with the AC, and 1410 then indicate to the AC which key is being used. When PSKs are 1411 provisioned to WTPs and ACs, both the PSK Hint and PSK Identity for 1412 the key MUST be specified. 1414 The PSK Hint SHOULD uniquely identify the AC and the PSK Identity 1415 SHOULD uniquely identify the WTP. It is RECOMMENDED that these hints 1416 and identities be the ASCII HEX-formatted MAC addresses of the 1417 respective devices, since each pairwise combination of WTP and AC 1418 SHOULD have a unique PSK. The PSK hint and identity SHOULD be 1419 sufficient to perform authorization, as simply having knowledge of a 1420 PSK does not necessarily imply authorization. 1422 If a single PSK is being used for multiple devices on a CAPWAP 1423 network, which is NOT RECOMMENDED, the PSK Hint and Identity can no 1424 longer be a MAC address, so appropriate hints and identities SHOULD 1425 be selected to identify the group of devices to which the PSK is 1426 provisioned. 1428 3. CAPWAP Transport 1430 Communication between a WTP and an AC is established using the 1431 standard UDP client/server model. The CAPWAP protocol supports both 1432 UDP and UDP-Lite [11] transport protocols. When run over IPv4, UDP 1433 is used for the CAPWAP control and data channels. 1435 When run over IPv6, the CAPWAP control channel always uses UDP, while 1436 the CAPWAP data channel may use either UDP or UDP-Lite. UDP-Lite is 1437 the default transport protocol for the CAPWAP data channel. However, 1438 if a middlebox or IPv4 to IPv6 gateway has been discovered, UDP is 1439 used for the CAPWAP data channel. 1441 This section describes how the CAPWAP protocol is carried over IP and 1442 UDP/UDP-Lite transport protocols. The CAPWAP Transport Protocol 1443 message element Section 4.6.12 describes the rules to use in 1444 determing which transport protocol is to be used. 1446 3.1. UDP Transport 1448 One of the CAPWAP protocol requirements is to allow a WTP to reside 1449 behind a middlebox, firewall and/or Network Address Translation (NAT) 1450 device. Since a CAPWAP session is initiated by the WTP (client) to 1451 the well-known UDP port of the AC (server), the use of UDP is a 1452 logical choice. The UDP checksum field in CAPWAP packets MUST be set 1453 to zero. 1455 CAPWAP protocol control packets sent from the WTP to the AC use the 1456 CAPWAP control channel, as defined in Section 1.4. The CAPWAP 1457 control port at the AC is the well known UDP port [to be IANA 1458 assigned]. The CAPWAP control port at the WTP can be any port 1459 selected by the WTP. 1461 CAPWAP protocol data packets sent from the WTP to the AC use the 1462 CAPWAP data channel, as defined in Section 1.4. The CAPWAP data port 1463 at the AC is the well known UDP port [to be IANA assigned]. The 1464 CAPWAP data port at the WTP can be any port selected by the WTP. 1466 3.2. UDP-Lite Transport 1468 When CAPWAP is run over IPv6, UDP-Lite is the default transport 1469 protocol, which reduces the checksum processing required for each 1470 packet (compared to the use of UDP over IPv6 [13]). When UDP-Lite is 1471 used, the checksum field MUST have a coverage of 8 [11]. 1473 UDP-Lite uses the same port assignments as UDP. 1475 3.3. AC Discovery 1477 The AC discovery phase allows the WTP to determine which ACs are 1478 available, and chose the best AC with which to establish a CAPWAP 1479 session. The discovery phase occurs when the WTP enters the optional 1480 Discovery state. A WTP does not need to complete the AC Discovery 1481 phase if it uses a pre-configured AC. This section details the 1482 mechanism used by a WTP to dynamically discover candidate ACs. 1484 A WTP and an AC will frequently not reside in the same IP subnet 1485 (broadcast domain). When this occurs, the WTP must be capable of 1486 discovering the AC, without requiring that multicast services are 1487 enabled in the network. 1489 When the WTP attempts to establish communication with an AC, it sends 1490 the Discovery Request message and receives the Discovery Response 1491 message from the AC(s). The WTP MUST send the Discovery Request 1492 message to either the limited broadcast IP address (255.255.255.255), 1493 a well known multicast address or to the unicast IP address of the 1494 AC. For IPv6 networks, since broadcast does not exist, the use of 1495 "All ACs multicast address" is used instead. Upon receipt of the 1496 Discovery Request message, the AC sends a Discovery Response message 1497 to the unicast IP address of the WTP, regardless of whether the 1498 Discovery Request message was sent as a broadcast, multicast or 1499 unicast message. 1501 WTP use of a limited IP broadcast, multicast or unicast IP address is 1502 implementation dependent. 1504 When a WTP transmits a Discovery Request message to a unicast 1505 address, the WTP must first obtain the IP address of the AC. Any 1506 static configuration of an AC's IP address on the WTP non-volatile 1507 storage is implementation dependent. However, additional dynamic 1508 schemes are possible, for example: 1510 DHCP: See [17] for more information on the use of DHCP to discover 1511 AC IP addresses. 1513 DNS: The DNS name "CAPWAP-AC-Address" MAY be resolvable to one or 1514 more AC addresses. 1516 An AC MAY also communicate alternative ACs to the WTP within the 1517 Discovery Response message through the AC IPv4 List (see 1518 Section 4.6.2) and AC IPv6 List (see Section 4.6.2). The addresses 1519 provided in these two message elements are intended to help the WTP 1520 discover additional ACs through means other than those listed above. 1522 The AC Name with Index message element (see Section 4.6.5), is used 1523 to communicate a list of preferred ACs to the WTP. The WTP SHOULD 1524 attempt to utilize the ACs listed in the order provided by the AC. 1525 The Name to IP Address mapping is handled via the Discovery message 1526 exchange, in which the ACs provide their identity in the AC Name (see 1527 Section 4.6.4) message element in the Discovery Response message. 1529 Once the WTP has received Discovery Response messages from the 1530 candidate ACs, it MAY use other factors to determine the preferred 1531 AC. For instance, each binding defines a WTP Radio Information 1532 message element (see Section 2.1), which the AC includes in Discovery 1533 Response messages. The presence of one or more of these message 1534 elements is used to identify the CAPWAP bindings supported by the AC. 1535 A WTP MAY connect to an AC based on the supported bindings 1536 advertised. 1538 3.4. Fragmentation/Reassembly 1540 While fragmentation and reassembly services are provided by IP, the 1541 CAPWAP protocol also provides such services. Environments where the 1542 CAPWAP protocol is used involve firewall, NAT and "middle box" 1543 devices, which tend to drop IP fragments to minimize possible DoS 1544 attacks. By providing fragmentation and reassembly at the 1545 application layer, any fragmentation required due to the tunneling 1546 component of the CAPWAP protocol becomes transparent to these 1547 intermediate devices. Consequently, the CAPWAP protocol can be used 1548 in any network configuration. 1550 3.5. MTU Discovery 1552 Once a WTP has discovered the AC it wishes to establish a CAPWAP 1553 session with, it SHOULD perform a Path MTU (PMTU) discovery. The MTU 1554 discovered is used to configure the DTLS component (see 1555 Section 2.3.2.1), while non-DTLS frames need to be fragmented to fit 1556 the MTU, defined in Section 3.4. The procedures described in [14], 1557 for IPv4, or [15], for IPv6 SHOULD be used. The WTP SHOULD also 1558 periodically re-evaluate the MTU using the guidelines provided in 1559 these two RFCs. 1561 4. CAPWAP Packet Formats 1563 This section contains the CAPWAP protocol packet formats. A CAPWAP 1564 protocol packet consists of one or more CAPWAP Transport Layer packet 1565 headers followed by a CAPWAP message. The CAPWAP message can be 1566 either of type Control or Data, where Control packets carry 1567 signaling, and Data packets carry user payloads. The CAPWAP frame 1568 formats for CAPWAP Data packets, and for DTLS encapsulated CAPWAP 1569 Data and Control packets are defined below. 1571 The CAPWAP Control protocol includes two messages that are never 1572 protected by DTLS: the Discovery Request message and the Discovery 1573 Response message. These messages need to be in the clear to allow 1574 the CAPWAP protocol to properly identify and process them. The 1575 format of these packets are as follows: 1577 CAPWAP Control Packet (Discovery Request/Response): 1578 +-------------------------------------------+ 1579 | IP | UDP | CAPWAP | Control | Message | 1580 | Hdr | Hdr | Header | Header | Element(s) | 1581 +-------------------------------------------+ 1583 All other CAPWAP control protocol messages MUST be protected via the 1584 DTLS protocol, which ensures that the packets are both authenticated 1585 and encrypted. These packets include the CAPWAP DTLS Header, which 1586 is described in Section 4.2. The format of these packets is as 1587 follows: 1589 CAPWAP Control Packet (DTLS Security Required): 1590 +------------------------------------------------------------------+ 1591 | IP | UDP | CAPWAP | DTLS | CAPWAP | Control| Message | DTLS | 1592 | Hdr | Hdr | DTLS Hdr | Hdr | Header | Header | Element(s)| Trlr | 1593 +------------------------------------------------------------------+ 1594 \---------- authenticated -----------/ 1595 \------------- encrypted ------------/ 1597 The CAPWAP protocol allows optional protection of data packets, using 1598 DTLS. Use of data packet protection is determined by AC policy. 1599 When DTLS is utilized, the optional CAPWAP DTLS Header is present, 1600 which is described in Section 4.2. The format of CAPWAP data packets 1601 is shown below: 1603 CAPWAP Plain Text Data Packet : 1604 +-------------------------------+ 1605 | IP | UDP | CAPWAP | Wireless | 1606 | Hdr | Hdr | Header | Payload | 1607 +-------------------------------+ 1609 DTLS Secured CAPWAP Data Packet: 1610 +--------------------------------------------------------+ 1611 | IP | UDP | CAPWAP | DTLS | CAPWAP | Wireless | DTLS | 1612 | Hdr | Hdr | DTLS Hdr | Hdr | Hdr | Payload | Trlr | 1613 +--------------------------------------------------------+ 1614 \------ authenticated -----/ 1615 \------- encrypted --------/ 1617 UDP Header: All CAPWAP packets are encapsulated within either UDP, 1618 or UDP-Lite when used over IPv6. Section 3 defines the specific 1619 UDP or UDP-Lite usage. 1621 CAPWAP DTLS Header: All DTLS encrypted CAPWAP protocol packets are 1622 prefixed with the CAPWAP DTLS header (see Section 4.2). 1624 DTLS Header: The DTLS header provides authentication and encryption 1625 services to the CAPWAP payload it encapsulates. This protocol is 1626 defined in RFC 4347 [8]. 1628 CAPWAP Header: All CAPWAP protocol packets use a common header that 1629 immediately follows the CAPWAP preamble or DTLS header. The 1630 CAPWAP Header is defined in Section 4.3. 1632 Wireless Payload: A CAPWAP protocol packet that contains a wireless 1633 payload is a CAPWAP data packet. The CAPWAP protocol does not 1634 specify the format of the wireless payload, which is defined by 1635 the appropriate wireless standard. Additional information is in 1636 Section 4.4. 1638 Control Header: The CAPWAP protocol includes a signalling component, 1639 known as the CAPWAP control protocol. All CAPWAP control packets 1640 include a Control Header, which is defined in Section 4.5.1. 1641 CAPWAP data packets do not contain a Control Header field. 1643 Message Elements: A CAPWAP Control packet includes one or more 1644 message elements, which are found immediately following the 1645 Control Header. These message elements are in a Type/Length/value 1646 style header, defined in Section 4.6. 1648 A CAPWAP implementation MUST be capable of receiving a reassembled 1649 CAPWAP message of length 4096 bytes. A CAPWAP implementation MAY 1650 indicate that it supports a higher maximum message length, by 1651 including the Maximum Message Length message element, see 1652 Section 4.6.32 in the Join Request message or the Join Response 1653 message. 1655 4.1. CAPWAP Preamble 1657 The CAPWAP preamble is common to all CAPWAP transport headers and is 1658 used to identify the header type that immediately follows. The 1659 reason for this header is to avoid needing to perform byte 1660 comparisons in order to guess whether the frame is DTLS encrypted or 1661 not. It also provides an extensibility framework that can be used to 1662 support additional transport types. The format of the preamble is as 1663 follows: 1665 0 1666 0 1 2 3 4 5 6 7 1667 +-+-+-+-+-+-+-+-+ 1668 |Version| Type | 1669 +-+-+-+-+-+-+-+-+ 1671 Version: A 4 bit field which contains the version of CAPWAP used in 1672 this packet. The value for this specification is zero (0). 1674 Payload Type: A 4 bit field which specifies the payload type that 1675 follows the UDP header. The following values are supported: 1677 0 - CAPWAP Header. The CAPWAP Header (see Section 4.3) 1678 immediately follows the UDP header. If the packet is received 1679 on the CAPWAP data channel, the CAPWAP stack MUST treat the 1680 packet as a clear text CAPWAP data packet. If received on the 1681 CAPWAP control channel, the CAPWAP stack MUST treat the packet 1682 as a clear text CAPWAP control packet. If the control packet 1683 is not a Discovery Request or Discovery Response packet, the 1684 packet MUST be dropped. 1686 1 - CAPWAP DTLS Header. The CAPWAP DTLS Header, and DTLS packet, 1687 immediately follows the UDP header (see Section 4.2). 1689 4.2. CAPWAP DTLS Header 1691 The CAPWAP DTLS Header is used to identify the packet as a DTLS 1692 encrypted packet. The first eight bits includes the common CAPWAP 1693 Preamble. The remaining 24 bits are padding to ensure 4 byte 1694 alignment, and MAY be used in a future version of the protocol. The 1695 DTLS packet [8] always immediately follows this header. The format 1696 of the CAPWAP DTLS Header is as follows: 1698 0 1 2 3 1699 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 1700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1701 |CAPWAP Preamble| Reserved | 1702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1704 CAPWAP Preamble: The CAPWAP Preamble is defined in Section 4.1. The 1705 CAPWAP Preamble's Payload Type field MUST be set to one (1). 1707 Reserved: The 24-bit field is reserved for future use. All 1708 implementations complying with this protocol MUST set to zero any 1709 bits that are reserved in the version of the protocol supported by 1710 that implementation. Receivers MUST ignore all bits not defined 1711 for the version of the protocol they support. 1713 4.3. CAPWAP Header 1715 All CAPWAP protocol messages are encapsulated using a common header 1716 format, regardless of the CAPWAP Control or CAPWAP Data transport 1717 used to carry the messages. However, certain flags are not 1718 applicable for a given transport. Refer to the specific transport 1719 section in order to determine which flags are valid. 1721 Note that the optional fields defined in this section MUST be present 1722 in the precise order shown below. 1724 0 1 2 3 1725 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 1726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1727 |CAPWAP Preamble| HLEN | RID | WBID |T|F|L|W|M|K|Flags | 1728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1729 | Fragment ID | Frag Offset |Rsvd | 1730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1731 | (optional) Radio MAC Address | 1732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1733 | (optional) Wireless Specific Information | 1734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1735 | Payload .... | 1736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1738 CAPWAP Preamble: The CAPWAP Preamble is defined in Section 4.1. The 1739 CAPWAP Preamble's Payload Type field MUST be set to zero (0). If 1740 the CAPWAP DTLS Header is present, the version number in both 1741 CAPWAP Preambles MUST match. The reason for this duplicate field 1742 is to avoid any possible tampering of the version field in the 1743 preamble which is not encrypted or authenticated. 1745 HLEN: A 5 bit field containing the length of the CAPWAP transport 1746 header in 4 byte words (Similar to IP header length). This length 1747 includes the optional headers. 1749 RID: A 5 bit field which contains the Radio ID number for this 1750 packet. Given that MAC Addresses are not necessarily unique 1751 across physical radios in a WTP, the Radio Identifier (RID) field 1752 is used to indiciate which physical radio the message is 1753 associated with. 1755 WBID: A 5 bit field which is the wireless binding identifier. The 1756 identifier will indicate the type of wireless packet type 1757 associated with the radio. The following values are defined: 1759 1 - IEEE 802.11 1761 2 - IEEE 802.16 1763 3 - EPCGlobal 1765 T: The Type 'T' bit indicates the format of the frame being 1766 transported in the payload. When this bit is set to one (1), the 1767 payload has the native frame format indicated by the WBID field. 1768 When this bit is zero (0) the payload is an IEEE 802.3 frame. 1770 F: The Fragment 'F' bit indicates whether this packet is a fragment. 1771 When this bit is one (1), the packet is a fragment and MUST be 1772 combined with the other corresponding fragments to reassemble the 1773 complete information exchanged between the WTP and AC. 1775 L: The Last 'L' bit is valid only if the 'F' bit is set and indicates 1776 whether the packet contains the last fragment of a fragmented 1777 exchange between WTP and AC. When this bit is 1, the packet is 1778 the last fragment. When this bit is 0, the packet is not the last 1779 fragment. 1781 W: The Wireless 'W' bit is used to specify whether the optional 1782 Wireless Specific Information field is present in the header. A 1783 value of one (1) is used to represent the fact that the optional 1784 header is present. 1786 M: The M bit is used to indicate that the Radio MAC Address optional 1787 header is present. This is used to communicate the MAC address of 1788 the receiving radio. 1790 K: The 'Keep-alive' K bit indicates the packet is a Data Channel Keep 1791 Alive packet. This packet is used to map the data channel to the 1792 control channel for the specified Session ID and to maintain 1793 freshness of the data channel. The K bit MUST NOT be set for data 1794 packets containing user data. 1796 Flags: A set of reserved bits for future flags in the CAPWAP header. 1797 All implementations complying with this protocol MUST set to zero 1798 any bits that are reserved in the version of the protocol 1799 supported by that implementation. Receivers MUST ignore all bits 1800 not defined for the version of the protocol they support. 1802 Fragment ID: A 16 bit field whose value is assigned to each group of 1803 fragments making up a complete set. The fragment ID space is 1804 managed individually for every WTP/AC pair. The value of Fragment 1805 ID is incremented with each new set of fragments. The Fragment ID 1806 wraps to zero after the maximum value has been used to identify a 1807 set of fragments. 1809 Fragment Offset: A 13 bit field that indicates where in the payload 1810 this fragment belongs during re-assembly. This field is valid 1811 when the 'F' bit is set to 1. The fragment offset is measured in 1812 units of 8 octets (64 bits). The first fragment has offset zero. 1813 Note the CAPWAP protocol does not allow for overlapping fragments. 1815 Reserved: The 3-bit field is reserved for future use. All 1816 implementations complying with this protocol MUST set to zero any 1817 bits that are reserved in the version of the protocol supported by 1818 that implementation. Receivers MUST ignore all bits not defined 1819 for the version of the protocol they support. 1821 Radio MAC Address: This optional field contains the MAC address of 1822 the radio receiving the packet. This is useful in packets sent 1823 from the WTP to the AC, when the native wireless frame format is 1824 converted to 802.3 by the WTP. This field is only present if the 1825 'M' bit is set. The HLEN field assumes 4 byte alignment, and this 1826 field MUST be padded with zeroes (0x00) if it is not 4 byte 1827 aligned. 1829 The field contains the basic format: 1831 0 1 2 3 1832 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 1833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1834 | Length | MAC Address 1835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1837 Length: The length of the MAC Address field [22] [23]. 1839 MAC Address: The MAC Address of the receiving radio. 1841 Wireless Specific Information: This optional field contains 1842 technology specific information that may be used to carry per 1843 packet wireless information. This field is only present if the 1844 'W' bit is set. The HLEN field assumes 4 byte alignment, and this 1845 field MUST be padded with zeroes (0x00) if it is not 4 byte 1846 aligned. 1848 The Wireless Specific Information field uses the following format: 1850 0 1 2 3 1851 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 1852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1853 | Wireless ID | Length | Data 1854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1856 Wireless ID: The wireless binding identifier. The following 1857 values are defined: 1859 1 - IEEE 802.11 1861 2 - IEEE 802.16 1863 3 - EPCGlobal 1865 Length: The length of the data field 1867 Data: Wireless specific information, defined by the wireless 1868 specific binding. 1870 Payload: This field contains the header for a CAPWAP Data Message or 1871 CAPWAP Control Message, followed by the data contained in the 1872 message. 1874 4.4. CAPWAP Data Messages 1876 There are two different types of CAPWAP data packets, CAPWAP Data 1877 Channel Keep Alive packets and Data Payload packets. The first is 1878 used by the WTP to synchronize the control and data channels, and to 1879 maintain freshness of the data channel. The second is used to 1880 transmit user payloads between the AC and WTP. This section 1881 describes both types of CAPWAP data packet formats. 1883 Both CAPWAP data messages are transmitted on the CAPWAP data channel. 1885 4.4.1. CAPWAP Data Keepalive 1887 The CAPWAP Data Channel Keep Alive packet is used to bind the CAPWAP 1888 control channel with the data channel, and to maintain freshness of 1889 the data channel, ensuring that the channel is still functioning. 1890 The CAPWAP Data Channel Keep Alive packet is transmitted by the WTP 1891 when the DataChannelKeepAlive timer expires. When the CAPWAP Data 1892 Channel Keep Alive packet is transmitted, the WTP sets the 1893 DataChannelDeadInterval timer. 1895 In the CAPWAP Data Channel Keep Alive packet, all of the fields in 1896 the CAPWAP header, except the HLEN field and the K bit, are set to 1897 zero upon transmission. Upon receiving a CAPWAP Data Channel Keep 1898 Alive packet, the AC transmits a CAPWAP Data Channel Keep Alive 1899 packet back to the WTP. The contents of the transmitted packet are 1900 identical to the contents of the received packet. 1902 Upon receiving a CAPWAP Data Channel Keep Alive packet, the WTP 1903 cancels the DataChannelDeadInterval timer and resets the 1904 DataChannelKeepAlive timer. The CAPWAP Data Channel Keep Alive 1905 packet is retransmitted by the WTP in the same manner as the CAPWAP 1906 control messages. If the DataChannelDeadInterval timer expires, the 1907 WTP tears down the control DTLS session, and the data DTLS session if 1908 one existed. 1910 The CAPWAP Data Channel Keep Alive packet contains the following 1911 payload immediately following the CAPWAP Header (see Section 4.3) 1913 0 1 2 3 1914 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 1915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1916 | Message Element Length | Message Element [0..N] ... 1917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1919 Message Element Length: The Length field indicates the number of 1920 bytes following the CAPWAP Header. 1922 Message Element[0..N]: The message element(s) carry the information 1923 pertinent to each of the CAPWAP Data Keepalive message. The 1924 following message elements MUST be present in this CAPWAP message: 1926 Session ID, see Section 4.6.37 1928 4.4.2. Data Payload 1930 A CAPWAP protocol Data Payload packet encapsulates a forwarded 1931 wireless frame. The CAPWAP protocol defines two different modes of 1932 encapsulation; IEEE 802.3 and native wireless. IEEE 802.3 1933 encapsulation requires that the bridging function be performed in the 1934 WTP. An IEEE 802.3 encapsulated user payload frame has the following 1935 format: 1937 +------------------------------------------------------+ 1938 | IP Header | UDP Header | CAPWAP Header | 802.3 Frame | 1939 +------------------------------------------------------+ 1941 The CAPWAP protocol also defines the native wireless encapsulation 1942 mode. The format of the encapsulated CAPWAP data frame is subject to 1943 the rules defined by the specific wireless technology binding. Each 1944 wireless technology binding MUST contain a section entitled "Payload 1945 Encapsulation", which defines the format of the wireless payload that 1946 is encapsulated within CAPWAP Data packets. 1948 If the encapsulated frame would exceed the transport layer's MTU, the 1949 sender is responsible for fragmentation of the frame, as specified in 1950 Section 3.4. 1952 4.4.3. Establishment of a DTLS Data Channel 1954 If the AC and WTP are configured to tunnel the data channel over 1955 DTLS, the proper DTLS session must be initiated. To avoid having to 1956 reauthenticate and reauthorize an AC and WTP, the DTLS data channel 1957 MUST be initiated using the TLS session resumption feature [7]. 1959 When establishing the DTLS-encrypted data channel, the WTP MUST 1960 provide the identifier returned during the initialization of the 1961 control channel to the DTLS component so it can perform the 1962 resumption using the proper session information. 1964 The AC DTLS implementation MUST NOT accept a session resumption 1965 request for a DTLS session in which the control channel for the 1966 session has been torn down. 1968 4.5. CAPWAP Control Messages 1970 The CAPWAP Control protocol provides a control channel between the 1971 WTP and the AC. Control messages are divided into the following 1972 message types: 1974 Discovery: CAPWAP Discovery messages are used to identify potential 1975 ACs, their load and capabilities. 1977 Join: CAPWAP Join messages are used by a WTP to request service from 1978 an AC, and for the AC to respond to the WTP. 1980 Control Channel Management: CAPWAP control channel management 1981 messages are used to maintain the control channel. 1983 WTP Configuration Management: The WTP Configuration messages are 1984 used by the AC to deliver a specific configuration to the WTP. 1985 Messages which retrieve statistics from a WTP are also included in 1986 WTP Configuration Management. 1988 Station Session Management: Station Session Management messages are 1989 used by the AC to deliver specific station policies to the WTP. 1991 Device Management Operations: Device management operations are used 1992 to request and deliver a firmware image to the WTP. 1994 Binding Specific CAPWAP Management Messages: Messages in this 1995 category are used by the AC and the WTP to exchange protocol- 1996 specific CAPWAP management messages. These messages may or may 1997 not be used to change the link state of a station. 1999 Discovery, Join, Control Channel Management, WTP Configuration 2000 Management and Station Session Management CAPWAP control messages 2001 MUST be implemented. Device Management Operations messages MAY be 2002 implemented. 2004 CAPWAP control messages sent from the WTP to the AC indicate that the 2005 WTP is operational, providing an implicit keep-alive mechanism for 2006 the WTP. The Control Channel Management Echo Request and Echo 2007 Response messages provide an explicit keep-alive mechanism when other 2008 CAPWAP control messages are not exchanged. 2010 4.5.1. Control Message Format 2012 All CAPWAP control messages are sent encapsulated within the CAPWAP 2013 header (see Section 4.3). Immediately following the CAPWAP header, 2014 is the control header, which has the following format: 2016 0 1 2 3 2017 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 2018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2019 | Message Type | 2020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2021 | Seq Num | Msg Element Length | Flags | 2022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2023 | Msg Element [0..N] ... 2024 +-+-+-+-+-+-+-+-+-+-+-+-+ 2026 4.5.1.1. Message Type 2028 The Message Type field identifies the function of the CAPWAP control 2029 message. The Message Type field is comprised of an IANA Enterprise 2030 Number and an enterprise specific message type number. The first 2031 three octets contain the enterprise number in network byte order, 2032 with zero used for CAPWAP protocol defined message types and the IEEE 2033 802.11 IANA assigned enterprise number 13277 is used for IEEE 802.11 2034 technology specific message types. The last octet is the enterprise 2035 specific message type number, which has a range from 0 to 255. 2037 The message type field is defined as: 2039 Message Type = 2040 IANA Enterprise Number * 256 + 2041 Enterprise Specific Message Type Number 2043 The CAPWAP protocol reliability mechanism requires that messages be 2044 defined in pairs, consisting of both a Request and a Response 2045 message. The Response message MUST acknowledge the Request message. 2046 The assignment of CAPWAP control Message Type Values always occurs in 2047 pairs. All Request messages have odd numbered Message Type Values, 2048 and all Response messages have even numbered Message Type Values. 2049 The Request value MUST be assigned first. As an example, assigning a 2050 Message Type Value of 3 for a Request message and 4 for a Response 2051 message is valid, while assigning a Message Type Value of 4 for a 2052 Response message and 5 for the corresponding Request message is 2053 invalid. 2055 When a WTP or AC receives a message with a Message Type Value field 2056 that is not recognized and is an odd number, the number in the 2057 Message Type Value Field is incremented by one, and a Response 2058 message with a Message Type Value field containing the incremented 2059 value and containing the Result Code message element with the value 2060 (Unrecognized Request) is returned to the sender of the received 2061 message. If the unknown message type is even, the message is 2062 ignored. 2064 The valid values for CAPWAP Control Message Types are specified in 2065 the table below: 2067 CAPWAP Control Message Message Type 2068 Value 2069 Discovery Request 1 2070 Discovery Response 2 2071 Join Request 3 2072 Join Response 4 2073 Configuration Status 5 2074 Configuration Status Response 6 2075 Configuration Update Request 7 2076 Configuration Update Response 8 2077 WTP Event Request 9 2078 WTP Event Response 10 2079 Change State Event Request 11 2080 Change State Event Response 12 2081 Echo Request 13 2082 Echo Response 14 2083 Image Data Request 15 2084 Image Data Response 16 2085 Reset Request 17 2086 Reset Response 18 2087 Primary Discovery Request 19 2088 Primary Discovery Response 20 2089 Data Transfer Request 21 2090 Data Transfer Response 22 2091 Clear Configuration Request 23 2092 Clear Configuration Response 24 2093 Station Configuration Request 25 2094 Station Configuration Response 26 2096 4.5.1.2. Sequence Number 2098 The Sequence Number Field is an identifier value used to match 2099 Request and Response packets. When a CAPWAP packet with a Request 2100 Message Type Value is received, the value of the Sequence Number 2101 field is copied into the corresponding Response message. 2103 When a CAPWAP control message is sent, the sender's internal sequence 2104 number counter is monotonically incremented, ensuring that no two 2105 pending Request messages have the same Sequence Number. The Sequence 2106 Number field wraps back to zero. 2108 4.5.1.3. Message Element Length 2110 The Length field indicates the number of bytes following the Sequence 2111 Number field. 2113 4.5.1.4. Flags 2115 The Flags field MUST be set to zero. 2117 4.5.1.5. Message Element[0..N] 2119 The message element(s) carry the information pertinent to each of the 2120 control message types. Every control message in this specification 2121 specifies which message elements are permitted. 2123 When a WTP or AC receives a CAPWAP message without a message element 2124 that is specified as mandatory for the CAPWAP message, then the 2125 CAPWAP message is discarded. If the received message was a Request 2126 message for which the corresponding Response message carries message 2127 elements, then a corresponding Response message with a Result Code 2128 message element indicating "Failure - Missing Mandatory Message 2129 Element" is returned to the sender. 2131 When a WTP or AC receives a CAPWAP message with a message element 2132 that the WTP or AC does not recognize, the CAPWAP message is 2133 discarded. If the received message was a Request message for which 2134 the corresponding Response message carries message elements, then a 2135 corresponding Response message with a Result Code message element 2136 indicating "Failure - Unrecognized Message Element" and one or more 2137 Returned Message Element message elements is included, containing the 2138 unrecognized message element(s). 2140 4.5.2. Control Message Quality of Service 2142 It is recommended that CAPWAP control messages be sent by both the AC 2143 and the WTP with an appropriate Quality of Service precedence value, 2144 ensuring that congestion in the network minimizes occurrences of 2145 CAPWAP control channel disconnects. Therefore, a Quality of Service 2146 enabled CAPWAP device SHOULD use the following values: 2148 802.1P: The precedence value of 7 SHOULD be used. 2150 DSCP: The DSCP tag value of 46 SHOULD be used. 2152 4.5.3. Retransmissions 2154 The CAPWAP control protocol operates as a reliable transport. For 2155 each Request message, a Response message is defined, which is used to 2156 acknowledge receipt of the Request message. In addition, the control 2157 header Sequence Number field is used to pair the Request and Response 2158 messages (see Section 4.5.1). 2160 Response messages are not explicitly acknowledged, therefore if a 2161 Response message is not received, the original Request message is 2162 retransmitted. Implementations MAY cache Response messages to 2163 respond to a retransmitted Request messages with minimal local 2164 processing. Retransmitted Request messages MUST NOT be altered by 2165 the sender. The sender MUST assume that the original Request message 2166 was processed, but that the Response message was lost. Any 2167 alterations to the original Request message MUST have a new Sequence 2168 Number, and be treated as a new Request message by the receiver. 2170 After transmitting a Request message, the RetransmitInterval (see 2171 Section 4.7) timer and MaxRetransmit (see Section 4.8) variable are 2172 used to determine if the original Request message needs to be 2173 retransmitted. The RetransmitInterval timer is used the first time 2174 the Request is retransmitted. The timer is then doubled every 2175 subsequent time the same Request message is retransmitted, up to 2176 MaxRetransmit but no more than half the EchoInterval timer (see 2177 Section 4.7.7). Response messages are not subject to these timers. 2179 When a Request message is retransmitted, it MUST be re-encrypted via 2180 the DTLS stack. If the peer had received the Request message, and 2181 the corresponding Response message was lost, it is necessary to 2182 ensure that retransmitted Request messages are not identified as 2183 replays by the DTLS stack. Similarly, any cached Response messages 2184 that are retransmitted as a result of receiving a retransmitted 2185 Request message MUST be re-encrypted via DTLS. 2187 Duplicate Response messages, identified by the Sequence Number field 2188 in the CAPWAP control message header, SHOULD be discarded upon 2189 receipt. 2191 4.6. CAPWAP Protocol Message Elements 2193 This section defines the CAPWAP Protocol message elements which are 2194 included in CAPWAP protocol control messages. 2196 Message elements are used to carry information needed in control 2197 messages. Every message element is identified by the Type Value 2198 field, defined below. The total length of the message elements is 2199 indicated in the message element Length field. 2201 All of the message element definitions in this document use a diagram 2202 similar to the one below in order to depict its format. Note that to 2203 simplify this specification, these diagrams do not include the header 2204 fields (Type and Length). The header field values are defined in the 2205 message element descriptions. 2207 Unless otherwise specified, a control message that lists a set of 2208 supported (or expected) message elements MUST not expect the message 2209 elements to be in any specific order. The sender MAY include the 2210 message elements in any order. Unless otherwise noted, one message 2211 element of each type is present in a given control message. 2213 Additional message elements may be defined in separate IETF 2214 documents. 2216 The format of a message element uses the TLV format shown here: 2218 0 1 2 3 2219 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 2220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2221 | Type | Length | 2222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2223 | Value ... | 2224 +-+-+-+-+-+-+-+-+ 2226 The 16 bit Type field identifies the information carried in the Value 2227 field and Length (16 bits) indicates the number of bytes in the Value 2228 field. Type field values are allocated as follows: 2230 Usage Type Values 2232 CAPWAP Protocol Message Elements 1-1023 2233 IEEE 802.11 Message Elements 1024-2047 2234 IEEE 802.16 Message Elements 2048 - 3071 2235 EPCGlobal Message Elements 3072 - 4095 2236 Reserved for Future Use 4096 - 65024 2238 The table below lists the CAPWAP protocol Message Elements and their 2239 Type values. 2241 CAPWAP Message Element Type Value 2243 AC Descriptor 1 2244 AC IPv4 List 2 2245 AC IPv6 List 3 2246 AC Name 4 2247 AC Name with Index 5 2248 AC Timestamp 6 2249 Add MAC ACL Entry 7 2250 Add Station 8 2251 Add Static MAC ACL Entry 9 2252 CAPWAP Control IPV4 Address 10 2253 CAPWAP Control IPV6 Address 11 2254 CAPWAP Transport Protocol TBD 2255 CAPWAP Local IPV4 Address TBD 2256 CAPWAP Local IPV6 Address TBD 2257 CAPWAP Timers 12 2258 Data Transfer Data 13 2259 Data Transfer Mode 14 2260 Decryption Error Report 15 2261 Decryption Error Report Period 16 2262 Delete MAC ACL Entry 17 2263 Delete Station 18 2264 Delete Static MAC ACL Entry 19 2265 Discovery Type 20 2266 Duplicate IPv4 Address 21 2267 Duplicate IPv6 Address 22 2268 Idle Timeout 23 2269 Image Data 24 2270 Image Identifier 25 2271 Image Info 26 2272 Initiate Download 27 2273 Location Data 28 2274 Maximum Message Length 29 2276 CAPWAP Message Element Type Value 2278 AC Descriptor 1 2279 AC IPv4 List 2 2280 AC IPv6 List 3 2281 AC Name 4 2282 AC Name with Index 5 2283 AC Timestamp 6 2284 Add MAC ACL Entry 7 2285 Add Station 8 2286 Add Static MAC ACL Entry 9 2287 CAPWAP Control IPV4 Address 10 2288 CAPWAP Control IPV6 Address 11 2289 CAPWAP Transport Protocol TBD 2290 CAPWAP Local IPV4 Address TBD 2291 CAPWAP Local IPV6 Address TBD 2292 CAPWAP Timers 12 2293 Data Transfer Data 13 2294 Data Transfer Mode 14 2295 Decryption Error Report 15 2296 Decryption Error Report Period 16 2297 Delete MAC ACL Entry 17 2298 Delete Station 18 2299 Delete Static MAC ACL Entry 19 2300 Discovery Type 20 2301 Duplicate IPv4 Address 21 2302 Duplicate IPv6 Address 22 2303 Idle Timeout 23 2304 Image Data 24 2305 Image Identifier 25 2306 Image Info 26 2307 Initiate Download 27 2308 Location Data 28 2309 Maximum Message Length 29 2311 4.6.1. AC Descriptor 2313 The AC Descriptor message element is used by the AC to communicate 2314 its current state. The value contains the following fields. 2316 0 1 2 3 2317 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 2318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2319 | Stations | Limit | 2320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2321 | Active WTPs | Max WTPs | 2322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2323 | Security | R-MAC Field | Reserved1 | DTLS Policy | 2324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2325 | Vendor Identifier | 2326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2327 | Type=4 | Length | 2328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2329 | Value... 2330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2331 | Vendor Identifier | 2332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2333 | Type=5 | Length | 2334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2335 | Value... 2336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2338 Type: 1 for AC Descriptor 2340 Length: >= 12 2342 Stations: The number of stations currently served by the AC 2344 Limit: The maximum number of stations supported by the AC 2346 Active WTPs: The number of WTPs currently attached to the AC 2347 Max WTPs: The maximum number of WTPs supported by the AC 2349 Security: A 8 bit bit mask specifying the authentication credential 2350 type supported by the AC. The following values are supported (see 2351 Section 2.4.4): 2353 1 - X.509 Certificate Based 2355 2 - Pre-Shared Secret 2357 R-MAC Field: The AC supports the optional Radio MAC Address field 2358 in the CAPWAP transport Header (see Section 4.3). 2360 Reserved: A set of reserved bits for future use. All 2361 implementations complying with this protocol MUST set to zero any 2362 bits that are reserved in the version of the protocol supported by 2363 that implementation. Receivers MUST ignore all bits not defined 2364 for the version of the protocol they support. 2366 DTLS Policy: The AC communicates its policy on the use of DTLS for 2367 the CAPWAP data channel. The AC MAY communicate more than one 2368 supported option, represented by the bit field below. The WTP 2369 MUST abide by one of the options communicated by AC. The 2370 following bit field values are supported: 2372 1 - Clear Text Data Channel Supported 2374 2 - DTLS Enabled Data Channel Supported 2376 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 2377 Network Management Private Enterprise Codes" 2379 Type: Vendor specific encoding of AC information. The following 2380 values are supported. The Hardware and Software Version values 2381 MUST be included. 2383 4 - Hardware Version: The AC's hardware version number. 2385 5 - Software Version: The AC's Software (firmware) version 2386 number. 2388 Length: Length of vendor specific encoding of AC information. 2390 Value: Vendor specific encoding of AC information. 2392 4.6.2. AC IPv4 List 2394 The AC IPv4 List message element is used to configure a WTP with the 2395 latest list of ACs available for the WTP to join. 2397 0 1 2 3 2398 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 2399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2400 | AC IP Address[] | 2401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2403 Type: 2 for AC IPv4 List 2405 Length: >= 4 2407 The AC IP Address: An array of 32-bit integers containing AC IPv4 2408 Addresses. 2410 4.6.3. AC IPv6 List 2412 The AC IPv6 List message element is used to configure a WTP with the 2413 latest list of ACs available for the WTP to join. 2415 0 1 2 3 2416 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 2417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2418 | AC IP Address[] | 2419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2420 | AC IP Address[] | 2421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2422 | AC IP Address[] | 2423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2424 | AC IP Address[] | 2425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2427 Type: 3 for AC IPV6 List 2429 Length: >= 16 2431 The AC IP Address: An array of 128-bit integers containing AC IPv6 2432 Addresses. 2434 4.6.4. AC Name 2436 The AC Name message element contains an UTF-8 representation of the 2437 AC identity. The value is a variable length byte string. The string 2438 is NOT zero terminated. 2440 0 2441 0 1 2 3 4 5 6 7 2442 +-+-+-+-+-+-+-+-+ 2443 | Name ... 2444 +-+-+-+-+-+-+-+-+ 2446 Type: 4 for AC Name 2448 Length: > 0 2450 Name: A variable length UTF-8 encoded string containing the AC's 2451 name 2453 4.6.5. AC Name with Index 2455 The AC Name with Index message element is sent by the AC to the WTP 2456 to configure preferred ACs. The number of instances of this message 2457 element is equal to the number of ACs configured on the WTP. 2459 0 1 2460 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2462 | Index | AC Name... 2463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2465 Type: 5 for AC Name with Index 2467 Length: > 2 2469 Index: The index of the preferred server (1=primary, 2=secondary). 2471 AC Name: A variable length UTF-8 encoded string containing the AC 2472 name. 2474 4.6.6. AC Timestamp 2476 The AC Timestamp message element is sent by the AC to synchronize the 2477 WTP clock. 2479 0 1 2 3 2480 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2482 | Timestamp | 2483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2485 Type: 6 for AC Timestamp 2487 Length: 4 2489 Timestamp: The AC's current time, allowing all of the WTPs to be 2490 time synchronized in the format defined by Network Time Protocol 2491 (NTP) in RFC 1305 [3]. 2493 4.6.7. Add MAC ACL Entry 2495 The Add MAC Access Control List (ACL) Entry message element is used 2496 by an AC to add a MAC ACL list entry on a WTP, ensuring that the WTP 2497 no longer provides service to the MAC addresses provided in the 2498 message. The MAC Addresses provided in this message element are not 2499 expected to be saved in non-volatile memory on the WTP. 2501 0 1 2 3 2502 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 2503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2504 | Num of Entries| Length | MAC Address ... 2505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2507 Type: 7 for Add MAC ACL Entry 2509 Length: >= 8 2511 Num of Entries: The number of instances of the Type/MAC Addresses 2512 fields in the array. 2514 Length: The length of the MAC Address field. 2516 MAC Address: MAC Addresses to add to the ACL. 2518 4.6.8. Add Station 2520 The Add Station message element is used by the AC to inform a WTP 2521 that it should forward traffic for a station. The Add Station 2522 message element is accompanied by technology specific binding 2523 information element(s) which may include security parameters. 2524 Consequently, the security parameters MUST be applied by the WTP for 2525 the station. 2527 After station policy has been delivered to the WTP through the Add 2528 Station message element, an AC MAY change any policies by sending a 2529 modified Add Station message element. When a WTP receives an Add 2530 Station message element for an existing station, it MUST override any 2531 existing state for the station. 2533 0 1 2 3 2534 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 2535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2536 | Radio ID | Length | MAC Address ... 2537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2538 | VLAN Name... 2539 +-+-+-+-+-+-+-+-+ 2541 Type: 8 for Add Station 2543 Length: >= 8 2545 Radio ID: An 8-bit value representing the radio 2547 Length: The length of the MAC Address field. 2549 MAC Address: The station's MAC Address 2551 VLAN Name: An optional variable length UTF-8 encoded string 2552 containing the VLAN Name on which the WTP is to locally bridge 2553 user data. Note this field is only valid with WTPs configured in 2554 Local MAC mode. 2556 4.6.9. Add Static MAC ACL Entry 2558 The Add Static MAC ACL Entry message element is used by an AC to add 2559 a permanent ACL entry on a WTP, ensuring that the WTP no longer 2560 provides any service to the MAC addresses provided in the message. 2561 The MAC Addresses provided in this message element are expected to be 2562 saved in non-volative memory on the WTP. 2564 0 1 2 3 2565 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 2566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2567 | Num of Entries| Length | MAC Address ... 2568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2570 Type: 9 for Add Static MAC ACL Entry 2571 Length: >= 8 2573 Num of Entries: The number of instances of the Type/MAC Addresses 2574 fields in the array. 2576 Length: The length of the MAC Address field. 2578 MAC Address: MAC Addresses to add to the permanent ACL. 2580 4.6.10. CAPWAP Control IPv4 Address 2582 The CAPWAP Control IPv4 Address message element is sent by the AC to 2583 the WTP during the discovery process and is used by the AC to provide 2584 the interfaces available on the AC, and the current number of WTPs 2585 connected. When multiple CAPWAP Control IPV4 Address message 2586 elements are returned, the WTP SHOULD perform load balancing across 2587 the multiple interfaces. 2589 0 1 2 3 2590 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 2591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2592 | IP Address | 2593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2594 | WTP Count | 2595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2597 Type: 10 for CAPWAP Control IPv4 Address 2599 Length: 6 2601 IP Address: The IP Address of an interface. 2603 WTP Count: The number of WTPs currently connected to the interface. 2605 4.6.11. CAPWAP Control IPv6 Address 2607 The CAPWAP Control IPv6 Address message element is sent by the AC to 2608 the WTP during the discovery process and is used by the AC to provide 2609 the interfaces available on the AC, and the current number of WTPs 2610 connected. This message element is useful for the WTP to perform 2611 load balancing across multiple interfaces. 2613 0 1 2 3 2614 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 2615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2616 | IP Address | 2617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2618 | IP Address | 2619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2620 | IP Address | 2621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2622 | IP Address | 2623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2624 | WTP Count | 2625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2627 Type: 11 for CAPWAP Control IPv6 Address 2629 Length: 18 2631 IP Address: The IP Address of an interface. 2633 WTP Count: The number of WTPs currently connected to the interface. 2635 4.6.12. CAPWAP Transport Protocol 2637 When CAPWAP is run over IPv6, the UDP-Lite or UDP transports MAY be 2638 used (see Section 3). The CAPWAP IPv6 Transport Protocol message 2639 element is used by either the WTP or the AC to signal which transport 2640 protocol is to be used for the CAPWAP data channel. 2642 Upon receiving the Join Request, the AC MAY set the CAPWAP Transport 2643 Protocol to UDP-Lite in the Configuration Status Request or Image 2644 Data Request message if the CAPWAP message was received over IPv6, 2645 and the CAPWAP Local IPv6 Address message element (see 2646 Section 4.6.14) is present and the address matches the packet's 2647 source IP address. 2649 Upon receiving the Configuration Status Request or Image Data Request 2650 message, the WTP MAY set the CAPWAP Transport Protocol to UDP-Lite in 2651 the Configuration Status Response or Image Data Response message if 2652 the message was received over IPv6, and the CAPWAP Local IPv6 Address 2653 message element (see Section 4.6.14) is present and the address 2654 matches the packet's source IP address. 2656 For any other condition, the CAPWAP Transport Protocol MUST be set to 2657 UDP. 2659 0 2660 0 1 2 3 4 5 6 7 2661 +-+-+-+-+-+-+-+-+ 2662 | Transport | 2663 +-+-+-+-+-+-+-+-+ 2665 Type: TBD for CAPWAP Transport Protocol 2667 Length: 1 2669 Transport: The transport to use for the CAPWAP data channel. 2671 1 - UDP-Lite The UDP-Lite transport protocol is to be used for 2672 the CAPWAP data channel. Note that this option is illegal is 2673 either the WTP or the AC uses IPv4. 2675 2 - UDP The UDP transport protocol is to be used for the CAPWAP 2676 data channel. 2678 4.6.13. CAPWAP Local IPv4 Address 2680 The CAPWAP Local IPv4 Address message element is sent by either the 2681 WTP or the AC in the Join Request, Configuration Status Request or 2682 Image Data Request message in order to communicate the IP Address of 2683 the transmitter. The receiver uses this to determine whether a 2684 middlebox exists between the two peers, by comparing the source IP 2685 address of the packet against the value of the message element. 2687 0 1 2 3 2688 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 2689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2690 | IP Address | 2691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2693 Type: TBD for CAPWAP Local IPv4 Address 2695 Length: 4 2697 IP Address: The IP Address of the sender. 2699 4.6.14. CAPWAP Local IPv6 Address 2701 The CAPWAP Local IPv6 Address message element is sent by either the 2702 WTP or the AC in the Discovery Response or Join Request in order to 2703 communicate the IP Address of the transmitter. The receiver uses 2704 this to determine whether a middlebox exists between the two peers, 2705 by comparing the source IP address of the packet against the value of 2706 the message element. 2708 0 1 2 3 2709 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 2710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2711 | IP Address | 2712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2713 | IP Address | 2714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2715 | IP Address | 2716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2717 | IP Address | 2718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2720 Type: TBD for CAPWAP Local IPv6 Address 2722 Length: 16 2724 IP Address: The IP Address of the sender. 2726 4.6.15. CAPWAP Timers 2728 The CAPWAP Timers message element is used by an AC to configure 2729 CAPWAP timers on a WTP. 2731 0 1 2732 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2734 | Discovery | Echo Request | 2735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2737 Type: 12 for CAPWAP Timers 2739 Length: 2 2741 Discovery: The number of seconds between CAPWAP Discovery messages, 2742 when the WTP is in the discovery phase. 2744 Echo Request: The number of seconds between WTP Echo Request CAPWAP 2745 messages. The default value for this message element is specified 2746 in Section 4.7.7. 2748 4.6.16. Data Transfer Data 2750 The Data Transfer Data message element is used by the WTP to provide 2751 information to the AC for debugging purposes. 2753 0 1 2 2754 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2756 | Data Type | Data Length | Data .... 2757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2759 Type: 13 for Data Transfer Data 2761 Length: >= 3 2763 Data Type: An 8-bit value the type of information being sent. The 2764 following values are supported: 2766 1 - WTP Crash Data 2768 2 - WTP Memory Dump 2770 Data Length: Length of data field. 2772 Data: Debug information. 2774 4.6.17. Data Transfer Mode 2776 The Data Transfer Mode message element is used by the WTP to indicate 2777 the type of data transfer information it is sending to the AC for 2778 debugging purposes. 2780 0 2781 0 1 2 3 4 5 6 7 2782 +-+-+-+-+-+-+-+-+ 2783 | Data Type | 2784 +-+-+-+-+-+-+-+-+ 2786 Type: 14 for Data Transfer Mode 2788 Length: 1 2790 Data Type: An 8-bit value the type of information being requested. 2791 The following values are supported: 2793 1 - WTP Crash Data 2795 2 - WTP Memory Dump 2797 4.6.18. Decryption Error Report 2799 The Decryption Error Report message element value is used by the WTP 2800 to inform the AC of decryption errors that have occurred since the 2801 last report. Note that this error reporting mechanism is not used if 2802 encryption and decryption services are provided in the AC. 2804 0 1 2 2805 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2807 | Radio ID |Num Of Entries | Length | MAC Address... 2808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2810 Type: 15 for Decryption Error Report 2812 Length: >= 9 2814 Radio ID: The Radio Identifier refers to an interface index on the 2815 WTP. 2817 Num of Entries: The number of instances of the Type/MAC Addresses 2818 fields in the array. 2820 Length: The length of the MAC Address field. 2822 MAC Address: MAC addresses of the station that has caused 2823 decryption errors. 2825 4.6.19. Decryption Error Report Period 2827 The Decryption Error Report Period message element value is used by 2828 the AC to inform the WTP how frequently it should send decryption 2829 error report messages. Note that this error reporting mechanism is 2830 not used if encryption and decryption services are provided in the 2831 AC. 2833 0 1 2 2834 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2836 | Radio ID | Report Interval | 2837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2839 Type: 16 for Decryption Error Report Period 2841 Length: 3 2842 Radio ID: The Radio Identifier refers to an interface index on the 2843 WTP. 2845 Report Interval: A 16-bit unsigned integer indicating the time, in 2846 seconds. The default value for this message element can be found 2847 in Section 4.8.8. 2849 4.6.20. Delete MAC ACL Entry 2851 The Delete MAC ACL Entry message element is used by an AC to delete a 2852 MAC ACL entry on a WTP, ensuring that the WTP provides service to the 2853 MAC addresses provided in the message. 2855 0 1 2 3 2856 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2858 | Num of Entries| Length | MAC Address ... 2859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2861 Type: 17 for Delete MAC ACL Entry 2863 Length: >= 8 2865 Num of Entries: The number of instances of the Type/MAC Addresses 2866 fields in the array. 2868 Length: The length of the MAC Address field. 2870 MAC Address: An array of MAC Addresses to delete from the ACL. 2872 4.6.21. Delete Station 2874 The Delete Station message element is used by the AC to inform a WTP 2875 that it should no longer provide service to a particular station. 2876 The WTP MUST terminate service to the station immediately upon 2877 receiving this message element. 2879 The transmission of a Delete Station message element could occur for 2880 various reasons, including for administrative reasons, or if the 2881 station has roamed to another WTP. 2883 The Delete Station message element MAY be sent by the WTP, in the WTP 2884 Event Request message, to inform the AC that a particular station is 2885 no longer being provided service. This could occur as a result of an 2886 Idle Timeout (see section 4.4.43), due to internal resource shortages 2887 or for some other reason. 2889 0 1 2 3 2890 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 2891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2892 | Radio ID | Length | MAC Address... 2893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2895 Type: 18 for Delete Station 2897 Length: >= 8 2899 Radio ID: An 8-bit value representing the radio 2901 Length: The length of the MAC Address field. 2903 MAC Address: The station's MAC Address 2905 4.6.22. Delete Static MAC ACL Entry 2907 The Delete Static MAC ACL Entry message element is used by an AC to 2908 delete a previously added static MAC ACL entry on a WTP, ensuring 2909 that the WTP provides service to the MAC addresses provided in the 2910 message. 2912 0 1 2 3 2913 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 2914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2915 | Num of Entries| Length | MAC Address ... 2916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2918 Type: 19 for Delete Static MAC ACL Entry 2920 Length: >= 8 2922 Num of Entries: The number of instances of the Type/MAC Addresses 2923 fields in the array. 2925 Length: The length of the MAC Address field. 2927 MAC Address: An array of MAC Addresses to delete from the static 2928 MAC ACL entry. 2930 4.6.23. Discovery Type 2932 The Discovery Type message element is used by the WTP to indicate how 2933 it has come to know about the existence of the AC to which it is 2934 sending the Discovery Request message. 2936 0 2937 0 1 2 3 4 5 6 7 2938 +-+-+-+-+-+-+-+-+ 2939 | Discovery Type| 2940 +-+-+-+-+-+-+-+-+ 2942 Type: 20 for Discovery Type 2944 Length: 1 2946 Discovery Type: An 8-bit value indicating how the WTP discovered 2947 the AC. The following values are supported: 2949 0 - Unknown 2951 1 - Static Configuration 2953 2 - DHCP 2955 3 - DNS 2957 4 - AC Referral (used when the AC was configured either through 2958 the AC IPv4 List or AC IPv6 List message element) 2960 4.6.24. Duplicate IPv4 Address 2962 The Duplicate IPv4 Address message element is used by a WTP to inform 2963 an AC that it has detected another IP device using the same IP 2964 address that the WTP is currently using. 2966 The WTP MUST transmit this message element with the status set to 1 2967 after it has detected a duplicate IP address. When the WTP detects 2968 that the duplicate IP address has been cleared, it MUSY send this 2969 message element with the status set to 0. 2971 0 1 2 3 2972 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 2973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2974 | IP Address | 2975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2976 | Status | Length | MAC Address ... 2977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2979 Type: 21 for Duplicate IPv4 Address 2980 Length: >= 12 2982 IP Address: The IP Address currently used by the WTP. 2984 Status: The status of the duplicate IP address. The value MUST be 2985 set to 1 when a duplicate address is detected, and 0 when the 2986 duplicate address has been cleared. 2988 Length: The length of the MAC Address field. 2990 MAC Address: The MAC Address of the offending device. 2992 4.6.25. Duplicate IPv6 Address 2994 The Duplicate IPv6 Address message element is used by a WTP to inform 2995 an AC that it has detected another host using the same IP address 2996 that the WTP is currently using. 2998 The WTP MUST transmit this message element with the status set to 1 2999 after it has detected a duplicate IP address. When the WTP detects 3000 that the duplicate IP address has been cleared, it MUST send this 3001 message element with the status set to 0. 3003 0 1 2 3 3004 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3006 | IP Address | 3007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3008 | IP Address | 3009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3010 | IP Address | 3011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3012 | IP Address | 3013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3014 | Status | Length | MAC Address ... 3015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3017 Type: 23 for Duplicate IPv6 Address 3019 Length: >= 24 3021 IP Address: The IP Address currently used by the WTP. 3023 Status: The status of the duplicate IP address. The value MUST be 3024 set to 1 when a duplicate address is detected, and 0 when the 3025 duplicate address has been cleared. 3027 Length: The length of the MAC Address field. 3029 MAC Address: The MAC Address of the offending device. 3031 4.6.26. Idle Timeout 3033 The Idle Timeout message element is sent by the AC to the WTP to 3034 provide the idle timeout value that the WTP SHOULD enforce for its 3035 active stations. The value applies to all radios on the WTP. 3037 0 1 2 3 3038 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 3039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3040 | Timeout | 3041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3043 Type: 23 for Idle Timeout 3045 Length: 4 3047 Timeout: The current idle timeout to be enforced by the WTP. The 3048 default value for this message element is specified in 3049 Section 4.8.5. 3051 4.6.27. Image Data 3053 The Image Data message element is present in the Image Data Request 3054 message sent by the AC and contains the following fields. 3056 0 1 2 3 3057 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 3058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3059 | Opcode | Value ... 3060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3062 Type: 24 for Image Data 3064 Length: >= 1 3066 Opcode: An 8-bit value representing the transfer opcode. The 3067 following values are supported: 3069 1 - Image data is included 3071 2 - Last Image Data Block is included (EOF) 3072 5 - An error occurred. Transfer is aborted 3074 Value: The Image Data field contains up to 1024 characters. If the 3075 block being sent is the last one, the Opcode is set to 2. The AC 3076 MAY opt to abort the data transfer by setting the Opcode to 5. 3077 When the Opcode is 5, the Value field has a zero length. 3079 4.6.28. Image Identifier 3081 The Image Identifier message element is sent by the AC to the WTP and 3082 is used to indicate the expected active software version that is to 3083 be run on the WTP. The value is a variable length UTF-8 encoded 3084 string, which is NOT zero terminated. 3086 0 1 2 3 3087 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 3088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3089 | Vendor Identifier | 3090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3091 | Value... 3092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3094 Type: 25 for Image Identifier 3096 Length: >= 1 3098 Value: A variable length UTF-8 encoded string containing the 3099 firmware identifier to be run on the WTP. 3101 4.6.29. Image Information 3103 The Image Information message element is present in the Image Data 3104 Response message sent by the AC to the WTP and contains the following 3105 fields. 3107 0 1 2 3 3108 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 3109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3110 | File Size | 3111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3112 | Hash | 3113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3114 | Hash | 3115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3116 | Hash | 3117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3118 | Hash | 3119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3121 Type: 26 for Image Information 3123 Length: 18 3125 File Size: A 32-bit value containing the size of the file, in 3126 bytes, that will be transfered by the AC to the WTP. 3128 Hash: A 16 octet hash of the image. The hash is computed using 3129 MD5, using the following pseudo-code: 3131 #include 3132 CapwapCreateHash(char *hash, char *image, int image_len) 3133 { 3134 MD_CTX context; 3136 MDInit (&context); 3137 MDUpdate (&context, buffer, len); 3138 MDFinal (hash, &context); 3139 } 3141 4.6.30. Initiate Download 3143 The Initiate Download message element is used by the AC to inform the 3144 WTP that the WTP SHOULD initiate a firmware upgrade. The WTP 3145 subsequently transmits an Image Data Request message which includes 3146 the Image Download message element. This message element does not 3147 contain any data. 3149 Type: 27 for Initiate Download 3151 Length: 0 3153 4.6.31. Location Data 3155 The Location Data message element is a variable length byte UTF-8 3156 encoded string containing user defined location information (e.g. 3157 "Next to Fridge"). This information is configurable by the network 3158 administrator, and allows the WTP location to be determined. The 3159 string is not zero terminated. 3161 0 3162 0 1 2 3 4 5 6 7 3163 +-+-+-+-+-+-+-+-+- 3164 | Location ... 3165 +-+-+-+-+-+-+-+-+- 3167 Type: 28 for Location Data 3169 Length: > 0 3171 Location: A non-zero terminated UTF-8 encoded string containing the 3172 WTP location. 3174 4.6.32. Maximum Message Length 3176 The Maximum Message Length message element is included in the Join 3177 Request message by the WTP to indicate the maximum CAPWAP message 3178 length that it supports to the AC. The Maximum Message Length 3179 message element is optionally included in Join Response message by 3180 the AC to indicate the maximum CAPWAP message length that it supports 3181 to the WTP. 3183 0 1 2 3184 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 3186 | Maximum Message Length | 3187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 3189 Type: 29 for Maximim Message Length 3191 Length: 2 3193 Maximum Message Length An 16-bit unsigned integer indicating the 3194 maximum message length. 3196 4.6.33. Radio Administrative State 3198 The Radio Administrative State message element is used to communicate 3199 the state of a particular radio. The Radio Administrative State 3200 message element is sent by the AC to change the state of the WTP. 3201 The WTP saves the value, to ensure that it remains across WTP resets. 3202 The WTP communicates this message element during the configuration 3203 phase, in the Configuration Status Request message, to ensure that AC 3204 has the WTP radio current administrative state settings. The message 3205 element contains the following fields. 3207 0 1 3208 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3210 | Radio ID | Admin State | 3211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3213 Type: 31 for Radio Administrative State 3215 Length: 2 3217 Radio ID: An 8-bit value representing the radio to configure. The 3218 Radio ID field MAY also include the value of 0xff, which is used 3219 to identify the WTP. If an AC wishes to change the administrative 3220 state of a WTP, it includes 0xff in the Radio ID field. 3222 Admin State: An 8-bit value representing the administrative state 3223 of the radio. The default value for the Admin State field is 3224 listed in Section 4.8.1. The following values are supported: 3226 1 - Enabled 3228 2 - Disabled 3230 4.6.34. Radio Operational State 3232 The Radio Operational State message element is sent by the WTP to the 3233 AC to communicate a radio's operational state. This message element 3234 is included in the Configuration Update Response message by the WTP 3235 if it was requested to change the state of its radio, via the Radio 3236 Administrative State message element, but was unable to comply to the 3237 request. This message element is included in the Change State Event 3238 message when a WTP radio state was changed unexpectedly. This could 3239 occur due to a hardware failure. Note that the operational state 3240 setting is not saved on the WTP, and therefore does not remain across 3241 WTP resets. The value contains three fields, as shown below. 3243 0 1 2 3244 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 3245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3246 | Radio ID | State | Cause | 3247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3249 Type: 32 for Radio Operational State 3251 Length: 3 3253 Radio ID: The Radio Identifier refers to an interface index on the 3254 WTP. A value of 0xFF is invalid, as it is not possible to change 3255 the WTP's operational state. 3257 State: An 8-bit boolean value representing the state of the radio. 3258 A value of one disables the radio, while a value of two enables 3259 it. 3261 Cause: When a radio is inoperable, the cause field contains the 3262 reason the radio is out of service. The following values are 3263 supported: 3265 0 - Normal 3267 1 - Radio Failure 3269 2 - Software Failure 3271 3 - Administratively Set 3273 4.6.35. Result Code 3275 The Result Code message element value is a 32-bit integer value, 3276 indicating the result of the Request message corresponding to the 3277 Sequence Number included in the Response message. 3279 0 1 2 3 3280 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 3281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3282 | Result Code | 3283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3285 Type: 33 for Result Code 3287 Length: 4 3289 Result Code: The following values are defined: 3291 0 Success 3293 1 Failure (AC List message element MUST be present) 3295 2 Success (NAT detected) 3297 3 Join Failure (unspecified) 3299 4 Join Failure (Resource Depletion) 3301 5 Join Failure (Unknown Source) 3303 6 Join Failure (Incorrect Data) 3305 7 Join Failure (Session ID already in use) 3306 8 Join Failure (WTP Hardware not supported) 3308 9 Join Failure (Binding Not Supported) 3310 10 Reset Failure (Unable to Reset) 3312 11 Reset Failure (Firmware Write Error) 3314 12 Configuration Failure (Unable to Apply Requested Configuration 3315 - Service Provided Anyhow) 3317 13 Configuration Failure (Unable to Apply Requested Configuration 3318 - Service Not Provided) 3320 14 Image Data Error (Invalid Checksum) 3322 15 Image Data Error (Invalid Data Length) 3324 16 Image Data Error (Other Error) 3326 17 Image Data Error (Image Already Present) 3328 18 Message Unexpected (Invalid in current state) 3330 19 Message Unexpected (Unrecognized Request) 3332 20 Failure - Missing Mandatory Message Element 3334 21 Failure - Unrecognized Message Element 3336 4.6.36. Returned Message Element 3338 The Returned Message Element is sent by the WTP in the Change State 3339 Event Request message to communicate to the AC which message elements 3340 in the Configuration Status Response it was unable to apply locally. 3341 The Returned Message Element message element contains a result code 3342 indicating the reason that the configuration could not be applied, 3343 and encapsulates the failed message element. 3345 0 1 2 3346 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 3347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3348 | Reason | Message Element... 3349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3351 Type: 34 for Returned Message Element 3353 Length: >= 1 3355 Reason: The reason why the configuration in the offending message 3356 element could not be applied by the WTP. 3358 1 - Unknown Message Element 3360 2 - Unsupported Message Element 3362 3 - Unknown Message Element Value 3364 4 - Unsupported Message Element Value 3366 Message Element: The Message Element field encapsulates the message 3367 element sent by the AC in the Configuration Status Response 3368 message that caused the error. 3370 4.6.37. Session ID 3372 The Session ID message element value contains a randomly generated 3373 unsigned 32-bit integer. 3375 0 1 2 3 3376 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 3377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3378 | Session ID | 3379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3381 Type: 35 for Session ID 3383 Length: 16 3385 Session ID: A 32-bit unsigned integer used as a random session 3386 identifier 3388 4.6.38. Statistics Timer 3390 The Statistics Timer message element value is used by the AC to 3391 inform the WTP of the frequency with which it expects to receive 3392 updated statistics. 3394 0 1 3395 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3397 | Statistics Timer | 3398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3400 Type: 36 for Statistics Timer 3402 Length: 2 3404 Statistics Timer: A 16-bit unsigned integer indicating the time, in 3405 seconds. The default value for this timer is specified in 3406 Section 4.7.14. 3408 4.6.39. Vendor Specific Payload 3410 The Vendor Specific Payload message element is used to communicate 3411 vendor specific information between the WTP and the AC. The message 3412 element uses the following format: 3414 0 1 2 3 3415 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 3416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3417 | Vendor Identifier | 3418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3419 | Element ID | Value... | 3420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3422 Type: 37 for Vendor Specific 3424 Length: >= 7 3426 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 3427 Network Management Private Enterprise Codes" [18] 3429 Element ID: A 16-bit Element Identifier which is managed by the 3430 vendor. 3432 Value: The value associated with the vendor specific element. 3434 4.6.40. WTP Board Data 3436 The WTP Board Data message element is sent by the WTP to the AC and 3437 contains information about the hardware present. 3439 0 1 2 3 3440 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 3441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3442 | Vendor Identifier | 3443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3444 | Type=0 | Length | 3445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3446 | Value... 3447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3448 | Type=1 | Length | 3449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3450 | Value... 3451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3452 | Optional additional vendor specific WTP board data TLVs..... 3453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3455 Type: 38 for WTP Board Data 3457 Length: >=14 3459 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 3460 Network Management Private Enterprise Codes" 3462 Type: The following values are supported: 3464 0 - WTP Model Number: The WTP Model Number MUST be included in 3465 the WTP Board Data message element. 3467 1 - WTP Serial Number: The WTP Serial Number MUST be included in 3468 the WTP Board Data message element. 3470 2 - Board ID: A hardware identifier, which MAY be included in 3471 the WTP Board Data mesage element. 3473 3 - Board Revision A revision number of the board, which MAY be 3474 included in the WTP Board Data message element. 3476 4 - Base MAC Addres The WTP's Base MAC Address, which MAY be 3477 assigned to the primary Ethernet interface. 3479 4.6.41. WTP Descriptor 3481 The WTP Descriptor message element is used by a WTP to communicate 3482 its current hardware and software (firmware) configuration. The 3483 value contains the following fields. 3485 0 1 2 3 3486 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 3487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3488 | Max Radios | Radios in use | Encryption Capabilities | 3489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3490 | Vendor Identifier | 3491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3492 | Type=0 | Length | 3493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3494 | Value... 3495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3496 | Vendor Identifier | 3497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3498 | Type=1 | Length | 3499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3500 | Value... 3501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3502 | Vendor Identifier | 3503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3504 | Type=2 | Length | 3505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3506 | Value... 3507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3508 | Vendor Identifier | 3509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3510 | Type=3 | Length | 3511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3512 | Value... 3513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3515 Type: 39 for WTP Descriptor 3517 Length: >= 31 3519 Max Radios: An 8-bit value representing the number of radios (where 3520 each radio is identified via the Radio ID field) supported by the 3521 WTP. 3523 Radios in use: An 8-bit value representing the number of radios in 3524 use in the WTP. 3526 Encryption Capabilities: This 16-bit field is used by the WTP to 3527 communicate its capabilities to the AC. A WTP that does not have 3528 any encryption capabilities sets this field to zero (0). Refer to 3529 the specific wireless binding for further specification of the 3530 Encryption Capabilities field. 3532 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 3533 Network Management Private Enterprise Codes". 3535 Type: The following values are supported. The Hardware Version, 3536 Active Software Version, and Boot Version values MUST be included. 3537 Zero or more Other Software Version values MAY be included. 3539 0 - Hardware Version: The WTP hardware version number. 3541 1 - Active Software Version: The WTP running software version 3542 number. 3544 2 - Boot Version: The WTP boot loader version number. 3546 3 - Other Software Version: The WTP non-running software 3547 (firmware) version number. 3549 Length: Length of vendor specific encoding of WTP information. 3551 Value: Vendor specific data of WTP information encoded in the UTF-8 3552 format. 3554 4.6.42. WTP Fallback 3556 The WTP Fallback message element is sent by the AC to the WTP to 3557 enable or disable automatic CAPWAP fallback in the event that a WTP 3558 detects its preferred AC, and is not currently connected to it. 3560 0 3561 0 1 2 3 4 5 6 7 3562 +-+-+-+-+-+-+-+-+ 3563 | Mode | 3564 +-+-+-+-+-+-+-+-+ 3566 Type: 40 for WTP Fallback 3568 Length: 1 3570 Mode: The 8-bit value indicates the status of automatic CAPWAP 3571 fallback on the WTP. When enabled, if the WTP detects that its 3572 primary AC is available, and that the WTP is not connected to the 3573 primary AC, the WTP SHOULD automatically disconnect from its 3574 current AC and reconnect to its primary AC. If disabled, the WTP 3575 will only reconnect to its primary AC through manual intervention 3576 (e.g., through the Reset Request message). The default value for 3577 this field is specified in Section 4.8.10. The following values 3578 are supported: 3580 1 - Enabled 3582 2 - Disabled 3584 4.6.43. WTP Frame Tunnel Mode 3586 The WTP Frame Tunnel Mode message element allows the WTP to 3587 communicate the tunneling modes of operation which it supports to the 3588 AC. A WTP that advertises support for all types allows the AC to 3589 select which type will be used, based on its local policy. 3591 0 3592 0 1 2 3 4 5 6 7 3593 +-+-+-+-+-+-+-+-+ 3594 | Tunnel Mode | 3595 +-+-+-+-+-+-+-+-+ 3597 Type: 41 for WTP Frame Tunnel Mode 3599 Length: 1 3601 Frame Tunnel Mode: The Frame Tunnel mode specifies the tunneling 3602 modes for station data that are supported by the WTP. The 3603 following values are supported: 3605 1 - Local Bridging: When Local Bridging is used, the WTP does 3606 not tunnel user traffic to the AC; all user traffic is locally 3607 bridged. This value MUST NOT be used when the WTP MAC Type is 3608 set to Split-MAC. 3610 2 - 802.3 Frame Tunnel Mode: The 802.3 Frame Tunnel Mode 3611 requires the WTP and AC to encapsulate all user payload as 3612 native IEEE 802.3 frames (see Section 4.4). All user traffic 3613 is tunneled to the AC. This value MUST NOT be used when the 3614 WTP MAC Type is set to Split-MAC. 3616 4 - Native Frame Tunnel Mode: Native Frame Tunnel mode requires 3617 the WTP and AC to encapsulate all user payloads as native 3618 wireless frames, as defined by the wireless binding (see for 3619 example Section 4.4). 3621 7 - All: The WTP is capable of supporting all frame tunnel 3622 modes. 3624 4.6.44. WTP IPv4 IP Address 3626 The WTP IPv4 address is used to perform NAT detection. 3628 0 1 2 3 3629 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 3630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3631 | WTP IPv4 IP Address | 3632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3634 Type: 42 for WTP IPv4 IP Address 3636 Length: 4 3638 WTP IPv4 IP Address: The IPv4 address from which the WTP is sending 3639 packets. This field is used for NAT detection. 3641 4.6.45. WTP IPv6 IP Address 3643 The WTP IPv6 address is used to perform NAT detection (e.g., IPv4 to 3644 IPv6 NAT to help with technology transition). 3646 0 1 2 3 3647 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 3648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3649 | WTP IPv6 IP Address | 3650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3651 | WTP IPv6 IP Address | 3652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3653 | WTP IPv6 IP Address | 3654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3655 | WTP IPv6 IP Address | 3656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3658 Type: 43 for WTP IPv6 IP Address 3660 Length: 32 3662 WTP IPv6 IP Address: The IPv6 address from which the WTP is sending 3663 packets. This field is used for NAT detection. 3665 4.6.46. WTP MAC Type 3667 The WTP MAC-Type message element allows the WTP to communicate its 3668 mode of operation to the AC. A WTP that advertises support for both 3669 modes allows the AC to select the mode to use, based on local policy. 3671 0 3672 0 1 2 3 4 5 6 7 3673 +-+-+-+-+-+-+-+-+ 3674 | MAC Type | 3675 +-+-+-+-+-+-+-+-+ 3677 Type: 44 for WTP MAC Type 3679 Length: 1 3681 MAC Type: The MAC mode of operation supported by the WTP. The 3682 following values are supported 3684 0 - Local-MAC: Local-MAC is the default mode that MUST be 3685 supported by all WTPs. 3687 1 - Split-MAC: Split-MAC support is optional, and allows the AC 3688 to receive and process native wireless frames. 3690 2 - Both: WTP is capable of supporting both Local-MAC and Split- 3691 MAC. 3693 4.6.47. WTP Name 3695 The WTP Name message element is a variable length byte UTF-8 encoded 3696 string. The string is not zero terminated. 3698 0 3699 0 1 2 3 4 5 6 7 3700 +-+-+-+-+-+-+-+-+- 3701 | WTP Name ... 3702 +-+-+-+-+-+-+-+-+- 3704 Type: 45 for WTP Name 3706 Length: variable 3708 WTP Name: A non-zero terminated UTF-8 encoded string containing the 3709 WTP name. 3711 4.6.48. WTP Operational Statistics 3713 The WTP Operational Statistics message element is sent by the WTP to 3714 the AC to provide statistics related to the operation of the WTP. 3716 0 1 2 3 3717 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 3718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3719 | Radio ID | Tx Queue Level | Wireless Link Frames per Sec | 3720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3722 Type: 46 for WTP Operational Statistics 3724 Length: 4 3726 Radio ID: The radio ID of the radio to which the statistics apply. 3728 Wireless Transmit Queue Level: The percentage of Wireless Transmit 3729 queue utilization, calculated as the sum of utilized transmit 3730 queue lengths divided by the sum of maximum transmit queue 3731 lengths, multiplied by 100. The Wireless Transmit Queue Level is 3732 representative of congestion conditions over wireless interfaces 3733 between the WTP and stations. 3735 Wireless Link Frames per Sec: The number of frames transmitted or 3736 received per second by the WTP over the air interface. 3738 4.6.49. WTP Radio Statistics 3740 The WTP Radio Statistics message element is sent by the WTP to the AC 3741 to communicate statistics on radio behavior and reasons why the WTP 3742 radio has been reset. 3744 0 1 2 3 3745 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 3746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3747 | Radio ID | Last Fail Type| Reset Count | 3748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3749 | SW Failure Count | HW Failure Count | 3750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3751 | Other Failure Count | Unknown Failure Count | 3752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3753 | Config Update Count | Channel Change Count | 3754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3755 | Band Change Count | Current Noise Floor | 3756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3758 Type: 47 for WTP Radio Statistics 3759 Length: 20 3761 Radio ID: The radio ID of the radio to which the statistics apply. 3763 Last Failure Type: The last WTP failure. The following values are 3764 supported: 3766 0 - Statistic Not Supported 3768 1 - Software Failure 3770 2 - Hardware Failure 3772 3 - Other Failure 3774 255 - Unknown (e.g., WTP doesn't keep track of info) 3776 Reset Count: The number of times that that the radio has been 3777 reset. 3779 SW Failure Count: The number of times that the radio has failed due 3780 to software related reasons. 3782 HW Failure Count: The number of times that the radio has failed due 3783 to hardware related reasons. 3785 Other Failure Count: The number of times that the radio has failed 3786 due to known reasons, other than software or hardware failure. 3788 Unknown Failure Count: The number of times that the radio has 3789 failed for unknown reasons. 3791 Config Update Count: The number of times that the radio 3792 configuration has been updated. 3794 Channel Change Count: The number of times that the radio channel 3795 has been changed. 3797 Band Change Count: The number of times that the radio has changed 3798 frequency bands. 3800 Current Noise Floor: A signed integer which indicates the noise 3801 floor of the radio receiver in units of dBm. 3803 4.6.50. WTP Reboot Statistics 3805 The WTP Reboot Statistics message element is sent by the WTP to the 3806 AC to communicate reasons why WTP reboots have occurred. 3808 0 1 2 3 3809 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 3810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3811 | Reboot Count | AC Initiated Count | 3812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3813 | Link Failure Count | SW Failure Count | 3814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3815 | HW Failure Count | Other Failure Count | 3816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3817 | Unknown Failure Count |Last Failure Type| 3818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3820 Type: 48 for WTP Reboot Statistics 3822 Length: 15 3824 Reboot Count: The number of reboots that have occurred due to a WTP 3825 crash. A value of 65535 implies that this information is not 3826 available on the WTP. 3828 AC Initiated Count: The number of reboots that have occurred at the 3829 request of a CAPWAP protocol message, such as a change in 3830 configuration that required a reboot or an explicit CAPWAP 3831 protocol reset request. A value of 65535 implies that this 3832 information is not available on the WTP. 3834 Link Failure Count: The number of times that a CAPWAP protocol 3835 connection with an AC has failed due to link failure. 3837 SW Failure Count: The number of times that a CAPWAP protocol 3838 connection with an AC has failed due to software related reasons. 3840 HW Failure Count: The number of times that a CAPWAP protocol 3841 connection with an AC has failed due to hardware related reasons. 3843 Other Failure Count: The number of times that a CAPWAP protocol 3844 connection with an AC has failed due to known reasons, other than 3845 AC initiated, link, SW or HW failure. 3847 Unknown Failure Count: The number of times that a CAPWAP protocol 3848 connection with an AC has failed for unknown reasons. 3850 Last Failure Type: The failure type of the most recent WTP failure. 3851 The following values are supported: 3853 0 - Not Supported 3855 1 - AC Initiated (see Section 9.2) 3857 2 - Link Failure 3859 3 - Software Failure 3861 4 - Hardware Failure 3863 5 - Other Failure 3865 255 - Unknown (e.g., WTP doesn't keep track of info) 3867 4.6.51. WTP Static IP Address Information 3869 The WTP Static IP Address Information message element is used by an 3870 AC to configure or clear a previously configured static IP address on 3871 a WTP. 3873 0 1 2 3 3874 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 3875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3876 | IP Address | 3877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3878 | Netmask | 3879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3880 | Gateway | 3881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3882 | Static | 3883 +-+-+-+-+-+-+-+-+ 3885 Type: 49 for WTP Static IP Address Information 3887 Length: 13 3889 IP Address: The IP Address to assign to the WTP. This field is 3890 only valid if the static field is set to one. 3892 Netmask: The IP Netmask. This field is only valid if the static 3893 field is set to one. 3895 Gateway: The IP address of the gateway. This field is only valid 3896 if the static field is set to one. 3898 Netmask: The IP Netmask. This field is only valid if the static 3899 field is set to one. 3901 Static: An 8-bit boolean stating whether the WTP should use a 3902 static IP address or not. A value of zero disables the static IP 3903 address, while a value of one enables it. 3905 4.7. CAPWAP Protocol Timers 3907 This section contains the CAPWAP timers. 3909 4.7.1. ChangeStatePendingTimer 3911 The maximum time, in seconds, the AC will wait for the Change State 3912 Event Request from the WTP after having transmitted a successful 3913 Configuration Status Response message. The default value is 25 3914 seconds. 3916 4.7.2. DataChannelKeepAlive 3918 The DataChannelKeepAlive timer is used by the WTP to determine the 3919 next opportunity when it must transmit the Data Channel KeepAlive. 3921 Default: 30 3923 4.7.3. DataChannelDeadInterval 3925 The minimum time, in seconds, a WTP MUST wait without having received 3926 a Data Channel Keep Alive packet before the destination for the Data 3927 Channel Keep Alive packets may be considered dead. The value of this 3928 timer MUST be no less than 2*DataChannelKeepAlive seconds and no 3929 greater that 240 seconds. 3931 Default: 5 3933 4.7.4. DataCheckTimer 3935 The number of seconds the AC will wait for the Data Channel Keep 3936 Alive, which is required by the CAPWAP state machine's Data Check 3937 state. The AC resets the state machine if this timer expires prior 3938 to transitioning to the next state. 3940 Default: 30 3942 4.7.5. DiscoveryInterval 3944 The minimum time, in seconds, that a WTP MUST wait after receiving a 3945 Discovery Response message, before initiating a DTLS handshake. 3947 Default: 5 3949 4.7.6. DTLSSessionDelete 3951 The minimum time, in seconds, a WTP MUST wait for DTLS session 3952 deletion. 3954 Default: 5 3956 4.7.7. EchoInterval 3958 The minimum time, in seconds, between sending Echo Request messages 3959 to the AC with which the WTP has joined. 3961 Default: 30 3963 4.7.8. ImageDataStartTimer 3965 The number of seconds the AC will wait for the WTP to initiate the 3966 Image Data process. 3968 Default: 30 3970 4.7.9. MaxDiscoveryInterval 3972 The maximum time allowed between sending Discovery Request messages, 3973 in seconds. This value MUST be no less than 2 seconds and no greater 3974 than 180 seconds. 3976 Default: 20 seconds. 3978 4.7.10. MaxFailedDTLSSessionRetry 3980 The maximum number of failed DTLS session establishment attempts 3981 before the CAPWAP device enters a silent period. 3983 Default: 3. 3985 4.7.11. ResponseTimeout 3987 The minimum time, in seconds, in which the WTP or AC MUST respond to 3988 a CAPWAP Request message. 3990 Default: 1 3992 4.7.12. RetransmitInterval 3994 The minimum time, in seconds, in which a non-acknowledged CAPWAP 3995 packet will be retransmitted. 3997 Default: 3 3999 4.7.13. SilentInterval 4001 For a WTP, this is the minimum time, in seconds, a WTP MUST wait 4002 before it MAY again send Discovery Request messages or attempt to a 4003 establish DTLS session. For an AC, this is the minimum time, in 4004 seconds, during which the AC SHOULD ignore all CAPWAP and DTLS 4005 packets received from the WTP that is in the Sulking state. 4007 Default: 30 4009 4.7.14. StatisticsTimer 4011 The default Statistics Interval is 120 seconds. 4013 4.7.15. WaitDTLS 4015 The maximum time, in seconds, a WTP MUST wait without having received 4016 a DTLS Handshake message from an AC. This timer MUST be greater than 4017 30 seconds. 4019 Default: 60 4021 4.7.16. WaitJoin 4023 The maximum time, in seconds, after which the DTLS session has been 4024 established that the AC will wait before receiving a Join Request 4025 message. This timer MUST be greater than 30 seconds. 4027 Default: 60 4029 4.8. CAPWAP Protocol Variables 4031 A WTP or AC that implements the CAPWAP Discovery phase MUST allow for 4032 the following variables to be configured by system management; 4033 default values are specified, making explicit configuration 4034 unnecessary in many cases. If the default values are explicitly 4035 overriden by the AC, the WTP MUST save the values sent by the AC. 4037 4.8.1. AdminState 4039 The default Administrative State value is enabled (1). 4041 4.8.2. DiscoveryCount 4043 The number of Discovery Request messages transmitted by a WTP to a 4044 single AC. This is a monotonically increasing counter. 4046 4.8.3. FailedDTLSAuthFailCount 4048 The number of failed DTLS session establishment attempts due to 4049 authentication failures. 4051 4.8.4. FailedDTLSSessionCount 4053 The number of failed DTLS session establishment attempts. 4055 4.8.5. IdleTimeout 4057 The default Idle Timeout is 300 seconds. 4059 4.8.6. MaxDiscoveries 4061 The maximum number of Discovery Request messages that will be sent 4062 after a WTP boots. 4064 Default: 10 4066 4.8.7. MaxRetransmit 4068 The maximum number of retransmissions for a given CAPWAP packet 4069 before the link layer considers the peer dead. 4071 Default: 5 4073 4.8.8. ReportInterval 4075 The default Report Interval is 120 seconds. 4077 4.8.9. RetransmitCount 4079 The number of retransmissions for a given CAPWAP packet. This is a 4080 monotonically increasing counter. 4082 4.8.10. WTPFallBack 4084 The default WTP Fallback value is enabled (1). 4086 4.9. WTP Saved Variables 4088 In addition to the values defined in Section 4.8, the following 4089 values SHOULD be saved on the WTP in non-volatile memory. CAPWAP 4090 wireless bindings MAY define additional values that SHOULD be stored 4091 on the WTP. 4093 4.9.1. AdminRebootCount 4095 The number of times the WTP has rebooted administratively, defined in 4096 Section 4.6.50. 4098 4.9.2. FrameEncapType 4100 For WTPs that support multiple Frame Encapsulation Types, it is 4101 useful to save the value configured by the AC. The Frame 4102 Encapsulation Type is defined in Section 4.6.43. 4104 4.9.3. LastRebootReason 4106 The reason why the WTP last rebooted, defined in Section 4.6.50. 4108 4.9.4. MacType 4110 For WTPs that support multiple MAC Types, it is useful to save the 4111 value configured by the AC. The MACType is defined in 4112 Section 4.6.46. 4114 4.9.5. PreferredACs 4116 The preferred ACs, with the index, defined in Section 4.6.5. 4118 4.9.6. RebootCount 4120 The number of times the WTP has rebooted, defined in Section 4.6.50. 4122 4.9.7. Static ACL Table 4124 The static ACL table saved on the WTP, as configured by the Add 4125 Static MAC ACL Entry message element, see Section 4.6.9. 4127 4.9.8. Static IP Address 4129 The static IP Address assigned to the WTP, as configured by the WTP 4130 Static IP Address Information message element (see Section 4.6.51). 4132 4.9.9. WTPLinkFailureCount 4134 The number of times the link to the AC has failed, see 4135 Section 4.6.50. 4137 4.9.10. WTPLocation 4139 The WTP Location, defined in Section 4.6.31. 4141 4.9.11. WTPName 4143 The WTP Name, defined in Section 4.6.47. 4145 5. CAPWAP Discovery Operations 4147 The Discovery messages are used by a WTP to determine which ACs are 4148 available to provide service, and the capabilities and load of the 4149 ACs. 4151 5.1. Discovery Request Message 4153 The Discovery Request message is used by the WTP to automatically 4154 discover potential ACs available in the network. The Discovery 4155 Request message provides ACs with the primary capabilities of the 4156 WTP. A WTP must exchange this information to ensure subsequent 4157 exchanges with the ACs are consistent with the WTP's functional 4158 characteristics. 4160 Discovery Request messages MUST be sent by a WTP in the Discover 4161 state after waiting for a random delay less than 4162 MaxDiscoveryInterval, after a WTP first comes up or is 4163 (re)initialized. A WTP MUST send no more than the maximum of 4164 MaxDiscoveries Discovery Request messages, waiting for a random delay 4165 less than MaxDiscoveryInterval between each successive message. 4167 This is to prevent an explosion of WTP Discovery Request messages. 4168 An example of this occurring is when many WTPs are powered on at the 4169 same time. 4171 If a Discovery Response message is not received after sending the 4172 maximum number of Discovery Request messages, the WTP enters the 4173 Sulking state and MUST wait for an interval equal to SilentInterval 4174 before sending further Discovery Request messages. 4176 Upon receiving a Discovery Request message, the AC will respond with 4177 a Discovery Response message sent to the address in the source 4178 address of the received Discovery Request message. Once a Discovery 4179 Response has been received, if the WTP decides to establish a session 4180 with the responding AC, it SHOULD perform an MTU discovery, using the 4181 process described in Section 3.5. 4183 It is possible for the AC to receive a cleartext Discovery Request 4184 message while a DTLS session is already active with the WTP. This is 4185 most likely the case if the WTP has rebooted, perhaps due to a 4186 software or power failure, but could also be caused by a DoS attack. 4187 In such cases, any WTP state, including the state machine instance, 4188 MUST NOT be cleared until another DTLS session has been successfully 4189 established, communicated via the DTLSSessionEstablished DTLS 4190 notification (see Section 2.3.2.2). 4192 The binding specific WTP Radio Information message element (see 4193 Section 2.1) is included in the Discovery Request message to 4194 advertise WTP support for one or more CAPWAP bindings. 4196 The Discovery Request message is sent by the WTP when in the 4197 Discovery State. The AC does not transmit this message. 4199 The following message elements MUST be included in the Discovery 4200 Request message: 4202 o Discovery Type, see Section 4.6.23 4204 o WTP Board Data, see Section 4.6.40 4206 o WTP Descriptor, see Section 4.6.41 4208 o WTP Frame Tunnel Mode, see Section 4.6.43 4210 o WTP MAC Type, see Section 4.6.46 4212 o WTP Radio Information message element(s)that the WTP supports; 4213 These are defined by the individual link layer CAPWAP Binding 4214 Protocols (see Section 2.1). 4216 5.2. Discovery Response Message 4218 The Discovery Response message provides a mechanism for an AC to 4219 advertise its services to requesting WTPs. 4221 When a WTP receives a Discovery Response message, it MUST wait for an 4222 interval not less than DiscoveryInterval for receipt of additional 4223 Discovery Response messages. After the DiscoveryInterval elapses, 4224 the WTP enters the DTLS-Init state and selects one of the ACs that 4225 sent a Discovery Response message and send a DTLS Handshake to that 4226 AC. 4228 One or more binding specific WTP Radio Information message elements 4229 (see Section 2.1) are included in the Discovery Request message to 4230 advertise AC support for the CAPWAP bindings. The AC MAY include 4231 only the bindings it shares in common with the WTP, known through the 4232 WTP Radio Information message elements received in the Discovery 4233 Request message, or it MAY include all of the bindings supported. 4234 The WTP MAY use the supported bindings in its AC decision process. 4235 Note that if the WTP joins an AC that does not support a specific 4236 CAPWAP binding, service for that binding MUST NOT be provided by the 4237 WTP. 4239 The Discovery Response message is sent by the AC when in the Idle 4240 State. The WTP does not transmit this message. 4242 The following message elements MUST be included in the Discovery 4243 Response Message: 4245 o AC Descriptor, see Section 4.6.1 4247 o AC Name, see Section 4.6.4 4249 o WTP Radio Information message element(s)that the AC supports; 4250 These are defined by the individual link layer CAPWAP Binding 4251 Protocols (see Section 2.1 for more information). 4253 o One of the following message elements MUST be included in the 4254 Discovery Response Message: 4256 * CAPWAP Control IPv4 Address, see Section 4.6.10 4258 * CAPWAP Control IPv6 Address, see Section 4.6.11 4260 5.3. Primary Discovery Request Message 4262 The Primary Discovery Request message is sent by the WTP to determine 4263 whether its preferred (or primary) AC is available. 4265 A Primary Discovery Request message is sent by a WTP when it has a 4266 primary AC configured, and is connected to another AC. This 4267 generally occurs as a result of a failover, and is used by the WTP as 4268 a means to discover when its primary AC becomes available. Since the 4269 WTP only has a single instance of the CAPWAP state machine, the 4270 Primary Discovery Request is sent by the WTP when in the Run State. 4271 The AC does not transmit this message. 4273 The frequency of the Primary Discovery Request messages should be no 4274 more often than the sending of the Echo Request message. 4276 Upon receipt of a Primary Discovery Request message, the AC responds 4277 with a Primary Discovery Response message sent to the address in the 4278 source address of the received Primary Discovery Request message. 4280 The following message elements MUST be included in the Primary 4281 Discovery Request message. 4283 o Discovery Type, see Section 4.6.23 4285 o WTP Board Data, see Section 4.6.40 4287 o WTP Descriptor, see Section 4.6.41 4288 o WTP Frame Tunnel Mode, see Section 4.6.43 4290 o WTP MAC Type, see Section 4.6.46 4292 o WTP Radio Information message element(s)that the WTP supports; 4293 These are defined by the individual link layer CAPWAP Binding 4294 Protocols (see Section 2.1 for more information). 4296 5.4. Primary Discovery Response 4298 The Primary Discovery Response message enables an AC to advertise its 4299 availability and services to requesting WTPs that are configured to 4300 have the AC as its primary AC. 4302 The Primary Discovery Response message is sent by an AC after 4303 receiving a Primary Discovery Request message. 4305 When a WTP receives a Primary Discovery Response message, it may 4306 establish a CAPWAP protocol connection to its primary AC, based on 4307 the configuration of the WTP Fallback Status message element on the 4308 WTP. 4310 The Primary Discovery Response message is sent by the AC when in the 4311 Idle State. The WTP does not transmit this message. 4313 The following message elements MUST be included in the Primary 4314 Discovery Response message. 4316 o AC Descriptor, see Section 4.6.1 4318 o AC Name, see Section 4.6.4 4320 o WTP Radio Information message element(s)that the AC supports; 4321 These are defined by the individual link layer CAPWAP Binding 4322 Protocols (see Section 2.1 for more information). 4324 One of the following message elements MUST be included in the 4325 Discovery Response Message: 4327 o CAPWAP Control IPv4 Address, see Section 4.6.10 4329 o CAPWAP Control IPv6 Address, see Section 4.6.11 4331 6. CAPWAP Join Operations 4333 The Join Request message is used by a WTP to request service from an 4334 AC after a DTLS connection is established to that AC. The Join 4335 Response message is used by the the AC to indicate that it will or 4336 will not provide service. 4338 6.1. Join Request 4340 The Join Request message is used by a WTP to request service through 4341 the AC. A Join Request message is sent by a WTP after (optionally) 4342 receiving one or more Discovery Response messages, and completion of 4343 DTLS session establishment. When an AC receives a Join Request 4344 message it responds with a Join Response message. 4346 Upon completion of the DTLS handshake, and receiving the 4347 DTLSEstablished notification, the WTP sends the Join Request message 4348 to the AC. When the AC is notified of the DTLS session 4349 establishment, it does not clear the WaitDTLS timer until it has 4350 received the Join Request message, at which time it sends a Join 4351 Response message to the WTP, indicating success or failure. 4353 One or more WTP Radio Information message elements (see Section 2.1) 4354 are included in the Join Request to request service for the CAPWAP 4355 bindings by the AC. Including a binding that is unsupported by the 4356 AC will result in a failed Join Response. 4358 If the AC rejects the Join Request, it sends a Join Response message 4359 with a failure indication and initiates an abort of the DTLS session 4360 via the DTLSAbort command. 4362 If an invalid (i.e. malformed) Join Request message is received, the 4363 message MUST be silently discarded by the AC. No response is sent to 4364 the WTP. The AC SHOULD log this event. 4366 The Join Request is sent by the WTP when in the Join State. The AC 4367 does not transmit this message. 4369 The following message elements MUST be included in the Join Request 4370 message. 4372 o Location Data, see Section 4.6.31 4374 o WTP Board Data, see Section 4.6.40 4376 o WTP Descriptor, see Section 4.6.41 4377 o WTP Name, see Section 4.6.47 4379 o Session ID, see Section 4.6.37 4381 o WTP Frame Tunnel Mode, see Section 4.6.43 4383 o WTP MAC Type, see Section 4.6.46 4385 o WTP Radio Information message element(s)that the WTP supports; 4386 These are defined by the individual link layer CAPWAP Binding 4387 Protocols (see Section 2.1 for more information). 4389 At least one of the following message element MUST be included in the 4390 Join Request message. 4392 o WTP IPv4 IP Address, see Section 4.6.44 4394 o WTP IPv6 IP Address, see Section 4.6.45 4396 The following message element MAY be included in the Join Request 4397 message. 4399 o Maximum Message Length, see Section 4.6.32 4401 o WTP Reboot Statistics, see Section 4.6.50 4403 o WTP IPv4 IP Address, see Section 4.6.44 4405 o WTP IPv6 IP Address, see Section 4.6.45 4407 6.2. Join Response 4409 The Join Response message is sent by the AC to indicate to a WTP that 4410 it is capable and willing to provide service to the WTP. 4412 The WTP, receiving a Join Response message, checks for success or 4413 failure. If the message indicates success, the WTP clears the 4414 WaitDTLS timer for the session and proceeds to the Configure state. 4416 If the WaitDTLS Timer expires prior to reception of the Join Response 4417 message, the WTP MUST terminate the handshake, deallocate session 4418 state and initiate the DTLSAbort command. 4420 If an invalid (malformed) Join Response message is received, the WTP 4421 SHOULD log an informative message detailing the error. This error 4422 MUST be treated in the same manner as AC non-responsiveness. The 4423 WaitDTLS timer will eventually expire, and the WTP MAY (if it is so 4424 configured) attempts to join a new AC. 4426 If one of the WTP Radio Information message elements (see 4427 Section 2.1) in the Join Request message requested support for a 4428 CAPWAP binding which the AC does not support, the AC sets the Result 4429 Code message element to "Binding Not Supported". 4431 The AC includes the Image Identifier message element to indicate the 4432 software version it expects the WTP to run. This information is used 4433 to determine whether the WTP MUST either change its currently running 4434 firmware image, or download a new version (see Section 9.1.1). 4436 The Join Response message is sent by the AC when in the Join State. 4437 The WTP does not transmit this message. 4439 The following message elements MAY be included in the Join Response 4440 message. 4442 o AC IPv4 List, see Section 4.6.2 4444 o AC IPv6 List, see Section 4.6.3 4446 o Image Identifier, see Section 4.6.28 4448 o Maximum Message Length, see Section 4.6.32 4450 The following message elements MUST be included in the Join Response 4451 message. 4453 o Result Code, see Section 4.6.35 4455 o AC Descriptor, see Section 4.6.1 4457 o AC Name, see Section 4.6.4 4459 o WTP Radio Information message element(s)that the AC supports; 4460 These are defined by the individual link layer CAPWAP Binding 4461 Protocols (see Section 2.1). 4463 One of the following message elements MUST be included in the 4464 Discovery Response Message: 4466 o CAPWAP Control IPv4 Address, see Section 4.6.10 4468 o CAPWAP Control IPv6 Address, see Section 4.6.11 4470 7. Control Channel Management 4472 The Control Channel Management messages are used by the WTP and AC to 4473 maintain a control communication channel. CAPWAP control messages, 4474 such as the WTP Event Request message sent from the WTP to the AC 4475 indicate to the AC that the WTP is operational. When such control 4476 messages are not being sent, the Echo Request and Echo Response 4477 messages are used to maintain the control communication channel. 4479 7.1. Echo Request 4481 The Echo Request message is a keep-alive mechanism for CAPWAP control 4482 messages. 4484 Echo Request messages are sent periodically by a WTP in the Run state 4485 (see Section 2.3) to determine the state of the control connection 4486 between the WTP and the AC. The Echo Request message is sent by the 4487 WTP when the EchoInterval timer expires. 4489 The Echo Request message is sent by the WTP when in the Run State. 4490 The AC does not transmit this message. 4492 The Echo Request message carries no message elements. 4494 When an AC receives an Echo Request message it responds with an Echo 4495 Response message. 4497 7.2. Echo Response 4499 The Echo Response message acknowledges the Echo Request message. 4501 An Echo Response message is sent by an AC after receiving an Echo 4502 Request message. After transmitting the Echo Response message, the 4503 AC SHOULD reset its EchoInterval timer. If another Echo Request 4504 message or other control message is not received by the AC when the 4505 timer expires, the AC SHOULD consider the WTP to be no longer 4506 reachable. 4508 The Echo Response message is sent by the AC when in the Run State. 4509 The WTP does not transmit this message. 4511 The Echo Response message carries no message elements. 4513 When a WTP receives an Echo Response message it initializes the 4514 EchoInterval to the configured value. 4516 8. WTP Configuration Management 4518 WTP Configuration messages are used to exchange configuration 4519 information between the AC and the WTP. 4521 8.1. Configuration Consistency 4523 The CAPWAP protocol provides flexibility in how WTP configuration is 4524 managed. A WTP has two options: 4526 1. The WTP retains no configuration and accepts the configuration 4527 provided by the AC. 4529 2. The WTP retains the configuration of parameters provided by the AC 4530 that are non-default values. 4532 If the WTP opts to save configuration locally, the CAPWAP protocol 4533 state machine defines the Configure state, which allows for 4534 configuration exchange. In the Configure state, the WTP sends its 4535 current configuration overrides to the AC via the Configuration 4536 Status message. A configuration override is a non-default parameter. 4537 As an example, in the CAPWAP protocol, the default antenna 4538 configuration is internal omni antenna. A WTP that either has no 4539 internal antennas, or has been explicitly configured by the AC to use 4540 external antennas, sends its antenna configuration during the 4541 configure phase, allowing the AC to become aware of the WTP's current 4542 configuration. 4544 Once the WTP has provided its configuration to the AC, the AC sends 4545 its configuration to the WTP. This allows the WTP to receive 4546 configuration and policies from the AC. 4548 The AC maintains a copy of each active WTP configuration. There is 4549 no need for versioning or other means to identify configuration 4550 changes. If a WTP becomes inactive, the AC MAY delete the inactive 4551 WTP configuration. If a WTP fails, and connects to a new AC, the WTP 4552 provides its overridden configuration parameters, allowing the new AC 4553 to be aware of the WTP configuration. 4555 This model allows for resiliency in case of an AC failure, ensuring 4556 another AC can provide service to the WTP. A new AC would be 4557 automatically updated with WTP configuration changes, eliminating the 4558 need for inter-AC communication and the need for all ACs to be aware 4559 of the configuration of all WTPs in the network. 4561 Once the CAPWAP protocol enters the Run state, the WTPs begin to 4562 provide service. It is common for administrators to require that 4563 configuration changes be made while the network is operational. 4565 Therefore, the Configuration Update Request is sent by the AC to the 4566 WTP to make these changes at run-time. 4568 8.1.1. Configuration Flexibility 4570 The CAPWAP protocol provides the flexibility to configure and manage 4571 WTPs of varying design and functional characteristics. When a WTP 4572 first discovers an AC, it provides primary functional information 4573 relating to its type of MAC and to the nature of frames to be 4574 exchanged. The AC configures the WTP appropriately. The AC also 4575 establishes corresponding internal state for the WTP. 4577 8.2. Configuration Status 4579 The Configuration Status message is sent by a WTP to deliver its 4580 current configuration to the AC. 4582 The Configuration Status message carries binding specific message 4583 elements. Refer to the appropriate binding for the definition of 4584 this structure. 4586 When an AC receives a Configuration Status message it acts upon the 4587 content of the message and responds to the WTP with a Configuration 4588 Status Response message. 4590 The Configuration Status message includes multiple Radio 4591 Administrative State message elements, one for the WTP, and one for 4592 each radio in the WTP. 4594 The Configuration Status message is sent by the WTP when in the 4595 Configure State. The AC does not transmit this message. 4597 The following message elements MUST be included in the Configuration 4598 Status message. 4600 o AC Name, see Section 4.6.4 4602 o AC Name with Index, see Section 4.6.5 4604 o Radio Administrative State, see Section 4.6.33 4606 o Statistics Timer, see Section 4.6.38 4608 o WTP Reboot Statistics, see Section 4.6.50 4610 The following message elements MAY be included in the Configuration 4611 Status message. 4613 o WTP Static IP Address Information, see Section 4.6.51 4615 8.3. Configuration Status Response 4617 The Configuration Status Response message is sent by an AC and 4618 provides a mechanism for the AC to override a WTP's requested 4619 configuration. 4621 A Configuration Status Response message is sent by an AC after 4622 receiving a Configuration Request message. 4624 The Configuration Status Response message carries binding specific 4625 message elements. Refer to the appropriate binding for the 4626 definition of this structure. 4628 When a WTP receives a Configuration Status Response message it acts 4629 upon the content of the message, as appropriate. If the 4630 Configuration Status Response message includes a Radio Operational 4631 State message element that causes a change in the operational state 4632 of one of the radios, the WTP transmits a Change State Event to the 4633 AC, as an acknowledgement of the change in state. 4635 The Configuration Status Response message is sent by the AC when in 4636 the Configure State. The WTP does not transmit this message. 4638 The following message elements MUST be included in the Configuration 4639 Status Response message. 4641 o AC IPv4 List, see Section 4.6.2 4643 o AC IPv6 List, see Section 4.6.3 4645 o CAPWAP Timers, see Section 4.6.15 4647 o Decryption Error Report Period, see Section 4.6.19 4649 o Idle Timeout, see Section 4.6.26 4651 o WTP Fallback, see Section 4.6.42 4653 The following message element MAY be included in the Configuration 4654 Status Response message. 4656 o WTP Static IP Address Information, see Section 4.6.51 4658 8.4. Configuration Update Request 4660 Configuration Update Request messages are sent by the AC to provision 4661 the WTP while in the Run state. This is used to modify the 4662 configuration of the WTP while it is operational. 4664 When a WTP receives a Configuration Update Request message, it 4665 responds with a Configuration Update Response message, with a Result 4666 Code message element indicating the result of the configuration 4667 request. 4669 The AC includes the Image Identifier and Initiate Download message 4670 elements to force the WTP to update its firmware while in the Run 4671 state. The WTP MAY proceed to download the requested firmware if it 4672 determines the version specified in the Image Identifier message 4673 element is not in its non-volatile storage (see Section 9.1.1). 4675 The Configuration Update Request is sent by the AC when in the Run 4676 State. The WTP does not transmit this message. 4678 One or more of the following message elements MAY be included in the 4679 Configuration Update message. 4681 o AC Name with Index, see Section 4.6.5 4683 o AC Timestamp, see Section 4.6.6 4685 o Add MAC ACL Entry, see Section 4.6.7 4687 o Add Static MAC ACL Entry, see Section 4.6.9 4689 o CAPWAP Timers, see Section 4.6.15 4691 o Decryption Error Report Period, see Section 4.6.19 4693 o Delete MAC ACL Entry, see Section 4.6.20 4695 o Delete Static MAC ACL Entry, see Section 4.6.22 4697 o Idle Timeout, see Section 4.6.26 4699 o Location Data, see Section 4.6.31 4701 o Radio Administrative State, see Section 4.6.33 4703 o Statistics Timer, see Section 4.6.38 4704 o WTP Fallback, see Section 4.6.42 4706 o WTP Name, see Section 4.6.47 4708 o WTP Static IP Address Information, see Section 4.6.51 4710 o Image Identifier, see Section 4.6.28 4712 o Initiate Download, see Section 4.6.30 4714 8.5. Configuration Update Response 4716 The Configuration Update Response message is the acknowledgement 4717 message for the Configuration Update Request message. 4719 The Configuration Update Response message is sent by a WTP after 4720 receiving a Configuration Update Request message. 4722 When an AC receives a Configuration Update Response message the 4723 result code indicates if the WTP successfully accepted the 4724 configuration. 4726 The Configuration Update Response message is sent by the WTP when in 4727 the Run State. The AC does not transmit this message. 4729 The following message element MUST be present in the Configuration 4730 Update message. 4732 Result Code, see Section 4.6.35 4734 The following message elements MAY be present in the Configuration 4735 Update Response message. 4737 o Radio Operational State, see Section 4.6.34 4739 8.6. Change State Event Request 4741 The Change State Event Request message is used by the WTP for two 4742 main purposes: 4744 o When sent by the WTP following the reception of a Configuration 4745 Status Response message from the AC, the WTP uses the Change State 4746 Event Request message to provide an update on the WTP radio's 4747 operational state and to confirm that the configuration provided 4748 by the AC was successfully applied. 4750 o When sent during the Run state, the WTP uses the Change State 4751 Event Request message to notify the AC of an unexpected change in 4752 the WTP's radio operational state. 4754 When an AC receives a Change State Event Request message it responds 4755 with a Change State Event Response message and modifies its data 4756 structures for the WTP as needed. The AC MAY decide not to provide 4757 service to the WTP if it receives an error, based on local policy, 4758 and to transition to the Reset state. 4760 The Change State Event Request message is sent by a WTP to 4761 acknowledge or report an error condition to the AC for a requested 4762 configuration in the Configuration Status Response message. The 4763 Change State Event Request message includes the Result Code message 4764 element, which indicates whether the configuration was successfully 4765 applied. If the WTP is unable to apply a specfic configuration 4766 request, it indicates the failure by including one or more Returned 4767 Message Element message elements (see Section 4.6.36). 4769 The Change State Event Request message is sent by the WTP in the 4770 Configure or Run State. The AC does not transmit this message. 4772 The WTP MAY save its configuration to persistent storage prior to 4773 transmitting the response. However, this is implementation specific 4774 and is not required. 4776 The following message elements MUST be present in the Change State 4777 Event Request message. 4779 o Radio Operational State, see Section 4.6.34 4781 o Result Code, see Section 4.6.35 4783 One or more of the following message elements MAY be present in the 4784 Change State Event Request message. 4786 o Returned Message Element(s), see Section 4.6.36 4788 8.7. Change State Event Response 4790 The Change State Event Response message acknowledges the Change State 4791 Event Request message. 4793 A Change State Event Response message is sent by an AC in response to 4794 a Change State Event Request message. 4796 The Change State Event Response message is sent by the AC when in the 4797 Configure or Run state. The WTP does not transmit this message. 4799 The Change State Event Response message carries no message elements. 4801 The WTP does not take any action upon receipt of the Change State 4802 Event Response message. 4804 8.8. Clear Configuration Request 4806 The Clear Configuration Request message is used to reset the WTP 4807 configuration. 4809 The Clear Configuration Request message is sent by an AC to request 4810 that a WTP reset its configuration to the manufacturing default 4811 configuration. The Clear Config Request message is sent while in the 4812 Run state. 4814 The Clear Configuration Request is sent by the AC when in the Run 4815 State. The WTP does not transmit this message. 4817 The Clear Configuration Request message carries no message elements. 4819 When a WTP receives a Clear Configuration Request message it resets 4820 its configuration to the manufacturing default configuration. 4822 8.9. Clear Configuration Response 4824 The Clear Configuration Response message is sent by the WTP after 4825 receiving a Clear Configuration Request message and resetting its 4826 configuration parameters to the manufacturing default values. 4828 The Clear Configuration Response is sent by the WTP when in the Run 4829 State. The AC does not transmit this message. 4831 The Clear Configuration Request message MUST include the following 4832 message element. 4834 o Result Code, see Section 4.6.35 4836 9. Device Management Operations 4838 This section defines CAPWAP operations responsible for debugging, 4839 gathering statistics, logging, and firmware management. 4841 9.1. Firmware Management 4843 This section describes the firmware download procedures used by the 4844 CAPWAP protocol. Firmware download can occur during the Image Data 4845 or Run state. 4847 Figure 4 provides an example of a WTP that performs a firmware 4848 upgrade while in the Image Data state. In this example, the WTP does 4849 not already have the requested firmware (Image Identifier = x), and 4850 downloads the image from the AC. 4852 WTP AC 4854 Join Request 4855 --------------------------------------------------------> 4857 Join Response (Image Identifier = x) 4858 <------------------------------------------------------ 4860 Image Data Request (Image Identifier = x) 4861 --------------------------------------------------------> 4863 Image Data Response (Result Code = Success, 4864 Image Information = {size,hash}, 4865 Initiate Download) 4866 <------------------------------------------------------ 4868 Image Data Request (Image Data = Data) 4869 <------------------------------------------------------ 4871 Image Data Response (Result Code = Success) 4872 --------------------------------------------------------> 4874 ..... 4876 Image Data Request (Image Data = EOF) 4877 <------------------------------------------------------ 4879 Image Data Response (Result Code = Success) 4880 --------------------------------------------------------> 4882 (WTP enters the Reset State) 4884 Figure 4: WTP Firmware Download Case 1 4886 Figure 5 provides an example in which the WTP has the image specified 4887 by the AC in its non-volative storage. The WTP opts to NOT download 4888 the firmware and immediately reset. 4890 WTP AC 4892 Join Request 4893 --------------------------------------------------------> 4895 Join Response (Image Identifier = x) 4896 <------------------------------------------------------ 4898 (WTP enters the Reset State) 4900 Figure 5: WTP Firmware Download Case 2 4902 Figure 6 provides an example of a WTP that performs a firmware 4903 upgrade while in the Run state. This mode of firmware upgrade allows 4904 the WTP to download its image while continuing to provide service. 4905 The WTP will not automatically reset until it is notified by the AC, 4906 with a Reset Request message. 4908 WTP AC 4910 Configuration Update Request (Image Identifier = x) 4911 <------------------------------------------------------ 4913 Configuration Update Response (Result Code = Success) 4914 --------------------------------------------------------> 4916 Image Data Request (Image Identifier = x) 4917 --------------------------------------------------------> 4919 Image Data Response (Result Code = Success, 4920 Image Information = {size,hash}, 4921 Initiate Download) 4922 <------------------------------------------------------ 4924 Image Data Request (Image Data = Data) 4925 <------------------------------------------------------ 4927 Image Data Response (Result Code = Success) 4928 --------------------------------------------------------> 4930 ..... 4932 Image Data Request (Image Data = EOF) 4933 <------------------------------------------------------ 4935 Image Data Response (Result Code = Success) 4936 --------------------------------------------------------> 4938 ..... 4940 (administratively requested reboot request) 4941 Reset Request (Image Identifier = x) 4942 <------------------------------------------------------ 4944 Reset Response (Result Code = Success) 4945 --------------------------------------------------------> 4947 Figure 6: WTP Firmware Download Case 3 4949 Figure 7 provides another example of the firmware download while in 4950 the Run state. In this example, the WTP already has the image 4951 specified by the AC in its non-volative storage. The WTP opts to NOT 4952 download the firmware. The WTP resets upon receipt of a Reset 4953 Request message from the AC. 4955 WTP AC 4957 Configuration Update Request (Image Identifier = x, 4958 Image Information = {size,hash}, 4959 Initiate Download) 4960 <------------------------------------------------------ 4962 Configuration Update Response (Result Code = Already Have Image) 4963 --------------------------------------------------------> 4965 ..... 4967 (administratively requested reboot request) 4968 Reset Request (Image Identifier = x) 4969 <------------------------------------------------------ 4971 Reset Response (Result Code = Success) 4972 --------------------------------------------------------> 4974 Figure 7: WTP Firmware Download Case 4 4976 9.1.1. Image Data Request 4978 The Image Data Request message is used to update firmware on the WTP. 4979 This message and its companion Response message are used by the AC to 4980 ensure that the image being run on each WTP is appropriate. 4982 Image Data Request messages are exchanged between the WTP and the AC 4983 to download a new firmware image to the WTP. When a WTP or AC 4984 receives an Image Data Request message it responds with an Image Data 4985 Response message. The message elements contained within the Image 4986 Data Request message are required to determine the intent of the 4987 request. 4989 The decision that new firmware is to be downloaded to the WTP can 4990 occur in one of two ways: 4992 When the WTP joins the AC, the Join Response message includes the 4993 Image Identifier message element, which informs the WTP of the 4994 firmware it is expected to run. if the WTP does not currently have 4995 the requested firmware version, it transmits an Image Data Request 4996 message, with the appropriate Image Identifier message element. 4997 If the WTP already has the requested firmware, it simply resets. 4999 Once the WTP is in the Run state, it is possible for the AC to 5000 cause the WTP to initiate a firmware download by sending a 5001 Configuration Update Request message with the Initiate Download 5002 and and Image Identifier message elements. The WTP then transmits 5003 the Image Data Request message, which includes the Image 5004 Identifier message element to start the download process. Note 5005 that when the firmware is downloaded in this way, the WTP does not 5006 automatically reset after the download is complete. The WTP will 5007 only reset when it receives a Reset Request message from the AC. 5008 If the WTP already had the requested firmware version in its non- 5009 volatile storage, the WTP does not transmit the Image Data Request 5010 message and responds with a Configuration Update Response message 5011 with the Result Code set to Image Already Present. 5013 Regardless of how the download was initiated, once the AC receives an 5014 Image Data Request message with the Image Identifier message element, 5015 it begins the transfer process by transmitting an Image Data Request 5016 message that includes the Image Data message element. This continues 5017 until the firmware image has been transfered. 5019 The Image Data Request message is sent by the WTP or the AC when in 5020 the Image Data or Run State. 5022 The following message elements MAY be included in the Image Data 5023 Request message. 5025 o Image Data, see Section 4.6.27 5027 o Image Identifier, see Section 4.6.28 5029 9.1.2. Image Data Response 5031 The Image Data Response message acknowledges the Image Data Request 5032 message. 5034 An Image Data Response message is sent in response to a received 5035 Image Data Request message. Its purpose is to acknowledge the 5036 receipt of the Image Data Request message. The Result Code is 5037 included to indicate whether a previously sent Image Data Request 5038 message was invalid. 5040 The Image Data Response message is sent by the WTP or the AC when in 5041 the Image Data or Run State. 5043 The following message element MUST be included in the Image Data 5044 Response message. 5046 o Result Code, see Section 4.6.35 5048 The following message elements MAY be included in the Image Data 5049 Response message. 5051 o Image Information, see Section 4.6.29 5053 o Initiate Download, see Section 4.6.30 5055 Upon receiving an Image Data Response message indicating an error, 5056 the WTP MAY retransmit a previous Image Data Reqest message, or 5057 abandon the firmware download to the WTP by transitioning to the 5058 Reset state. 5060 9.2. Reset Request 5062 The Reset Request message is used to cause a WTP to reboot. 5064 A Reset Request message is sent by an AC to cause a WTP to 5065 reinitialize its operation. 5067 The Reset Request is sent by the AC when in the Run State. The WTP 5068 does not transmit this message. 5070 The following message elements MUST be included in the Reset Request 5071 message. 5073 o Image Identifier, see Section 4.6.28 5075 When a WTP receives a Reset Request message, it responds with a Reset 5076 Response message indicating success and then reinitialize itself. If 5077 the WTP is unable to write to its non-volatile storage, to ensure 5078 that it runs the requested software version indicated in the Image 5079 Identifier message element, it MAY send the appropriate Result Code 5080 message element, but MUST reboot. If the WTP is unable to reset, 5081 including a hardware reset, it sends a Reset Response message to the 5082 AC with a Result Code message element indicating failure. The AC no 5083 longer provides service to the WTP. 5085 9.3. Reset Response 5087 The Reset Response message acknowledges the Reset Request message. 5089 A Reset Response message is sent by the WTP after receiving a Reset 5090 Request message. 5092 The Reset Response is sent by the WTP when in the Run State. The AC 5093 does not transmit this message. 5095 The following message element MAY be included in the Image Data 5096 Request message. 5098 o Result Code, see Section 4.6.35 5100 When an AC receives a successful Reset Response message, it is 5101 notified that the WTP will reinitialize its operation. An AC that 5102 receives a Reset Response message indicating failure may opt to no 5103 longer provide service to the WTP. 5105 9.4. WTP Event Request 5107 The WTP Event Request message is used by a WTP to send information to 5108 its AC. The WTP Event Request message MAY be sent periodically, or 5109 sent in response to an asynchronous event on the WTP. For example, a 5110 WTP MAY collect statistics and use the WTP Event Request message to 5111 transmit the statistics to the AC. 5113 When an AC receives a WTP Event Request message it will respond with 5114 a WTP Event Response message. 5116 The presence of the Delete Station message element is used by the WTP 5117 to inform the AC that it is no longer providing service to the 5118 station. This could be the result of an Idle Timeout (see 5119 Section 4.6.26), due to to resource shortages, or some other reason. 5121 The WTP Event Request message is sent by the WTP when in the Run 5122 State. The AC does not transmit this message. 5124 The WTP Event Request message MUST contain one of the message 5125 elements listed below, or a message element that is defined for a 5126 specific wireless technology. More than one of each messsage element 5127 listed MAY be included in the WTP Event Request message. 5129 o Decryption Error Report, see Section 4.6.18 5131 o Duplicate IPv4 Address, see Section 4.6.24 5133 o Duplicate IPv6 Address, see Section 4.6.25 5135 o WTP Operational Statistics, see Section 4.6.48 5137 o WTP Radio Statistics, see Section 4.6.49 5139 o WTP Reboot Statistics, see Section 4.6.50 5141 o Delete Station, see Section 4.6.21 5143 9.5. WTP Event Response 5145 The WTP Event Response message acknowledges receipt of the WTP Event 5146 Request message. 5148 A WTP Event Response message is sent by an AC after receiving a WTP 5149 Event Request message. 5151 The WTP Event Response message is sent by the AC when in the Run 5152 State. The WTP does not transmit this message. 5154 The WTP Event Response message carries no message elements. 5156 9.6. Data Transfer Request 5158 The Data Transfer Request message is used to deliver debug 5159 information from the WTP to the AC. 5161 Data Transfer Request messages are sent by the WTP to the AC when the 5162 WTP determines that it has important information to send to the AC. 5163 For instance, if the WTP detects that its previous reboot was caused 5164 by a system crash, it can send the crash file to the AC. The remote 5165 debugger function in the WTP also uses the Data Transfer Request 5166 message to send console output to the AC for debugging purposes. 5168 When the AC receives a Data Transfer Request message it responds to 5169 the WTP with a Data Transfer Response message. The AC MAY log the 5170 information received. 5172 The Data Transfer Request message is sent by the WTP when in the Run 5173 State. The AC does not transmit this message. 5175 The Data Transfer Request message MUST contain one of the message 5176 elements listed below. 5178 o Data Transfer Data, see Section 4.6.16 5180 o Data Transfer Mode, see Section 4.6.17 5182 9.7. Data Transfer Response 5184 The Data Transfer Response message acknowledges the Data Transfer 5185 Request message. 5187 A Data Transfer Response message is sent in response to a received 5188 Data Transfer Request message. Its purpose is to acknowledge receipt 5189 of the Data Transfer Request message. 5191 The Data Transfer Response message is sent by the AC when in the Run 5192 State. The WTP does not transmit this message. 5194 The Data Transfer Response message carries no message elements. 5196 Upon receipt of a Data Transfer Response message, the WTP transmits 5197 more information, if more information is available. 5199 10. Station Session Management 5201 Messages in this section are used by the AC to create, modify or 5202 delete station session state on the WTPs. 5204 10.1. Station Configuration Request 5206 The Station Configuration Request message is used to create, modify 5207 or delete station session state on a WTP. The message is sent by the 5208 AC to the WTP, and MAY contain one or more message elements. The 5209 message elements for this CAPWAP control message include information 5210 that is generally highly technology specific. Refer to the 5211 appropriate binding document for definitions of the messages elements 5212 that are included in this control message. 5214 The Station Configuration Request message is sent by the AC when in 5215 the Run State. The WTP does not transmit this message. 5217 The following CAPWAP Control message elements MAY be included in the 5218 Station Configuration Request message. More than one of each message 5219 element listed MAY be included in the Station Configuration Request 5220 message. 5222 o Add Station, see Section 4.6.8 5224 o Delete Station, see Section 4.6.21 5226 10.2. Station Configuration Response 5228 The Station Configuration Response message is used to acknowledge a 5229 previously received Station Configuration Request message. 5231 The Station Configuration Response message is sent by the WTP when in 5232 the Run State. The AC does not transmit this message. 5234 The following message element MUST be present in the Station 5235 Configuration Response message. 5237 o Result Code, see Section 4.6.35 5239 The Result Code message element indicates that the requested 5240 configuration was successfully applied, or that an error related to 5241 processing of the Station Configuration Request message occurred on 5242 the WTP. 5244 11. NAT Considerations 5246 There are three specific situations in which a NAT deployment may be 5247 used in conjunction with a CAPWAP-enabled deployment. The first 5248 consists of a configuration in which a single WTP is behind a NAT 5249 system. Since all communication is initiated by the WTP, and all 5250 communication is performed over IP using two UDP ports, the protocol 5251 easily traverses NAT systems in this configuration. 5253 In the second case, two or more WTPs are deployed behind the same NAT 5254 system. Here, the AC would receive multiple connection requests from 5255 the same IP address, and cannot differentiate the originating WTP of 5256 the connection requests. The CAPWAP Data Check state, which 5257 establishes the data plane connection and communicates the Data 5258 Keepalive, includes the Session Identifier message element, which is 5259 used to bind the control and data plane. Use of the Session 5260 Identifier message element enables the AC to match the control and 5261 data plane flows from multiple WTPs behind the same NAT system 5262 (multiple WTPs sharing the same IP address). 5264 In the third configuration, the AC is deployed behind a NAT. Two 5265 issues exist in this situation. First, an AC communicates its 5266 interfaces and corresponding WTP load using the CAPWAP Control IPv4 5267 Address and CAPWAP Control IPv6 Address message elements. This 5268 message element is mandatory, but contains invalid information if a 5269 middlebox is present between the AC and WTP. The WTP MUST NOT 5270 utilize the information in these message elements if it detects a NAT 5271 (as described in the CAPWAP Transport Protocol message element). 5272 Note this would disable the load balancing capabilities of the CAPWAP 5273 protocol. Alternatively, the AC could have a configured NAT'ed 5274 address, which it would include in either of the two control address 5275 message elements. 5277 The CAPWAP protocol allows for all of the AC identities supporting a 5278 group of WTPs to be communicated through the AC List message element. 5279 This feature MUST be ignored by the WTP when it detects the AC is 5280 behind a middlebox. 5282 The CAPWAP protocol allows an AC to configure a static IP address on 5283 a WTP using the WTP Static IP Address Information message element. 5284 This message element SHOULD NOT be used in NAT'ed environments, 5285 unless the administrator is familiar with the internal IP addressing 5286 scheme within the WTP's private network, and does not rely on the 5287 public address seen by the AC. 5289 When a WTP detects the duplicate address condition, it generates a 5290 message to the AC, which includes the Duplicate IP Address message 5291 element. The IP Address embedded within this message element is 5292 different from the public IP address seen by the AC. 5294 12. Security Considerations 5296 This section describes security considerations for the CAPWAP 5297 protocol. It also provides security recommendations for protocols 5298 used in conjunction with CAPWAP. 5300 12.1. CAPWAP Security 5302 As it is currently specified, the CAPWAP protocol sits between the 5303 security mechanisms specified by the wireless link layer protocol 5304 (e.g.IEEE 802.11i) and AAA. One goal of CAPWAP is to bootstrap trust 5305 between the STA and WTP using a series of preestablished trust 5306 relationships: 5308 STA WTP AC AAA 5309 ============================================== 5311 DTLS Cred AAA Cred 5312 <------------><-------------> 5314 EAP Credential 5315 <------------------------------------------> 5317 wireless link layer 5318 (e.g.802.11 PTK) 5319 <--------------> or 5320 <---------------------------> 5321 (derived) 5323 Within CAPWAP, DTLS is used to secure the link between the WTP and 5324 AC. In addition to securing control messages, it's also a link in 5325 this chain of trust for establishing link layer keys. Consequently, 5326 much rests on the security of DTLS. 5328 In some CAPWAP deployment scenarios, there are two channels between 5329 the WTP and AC: the control channel, carrying CAPWAP control 5330 messages, and the data channel, over which client data packets are 5331 tunneled between the AC and WTP. Typically, the control channel is 5332 secured by DTLS, while the data channel is not. 5334 The use of parallel protected and unprotected channels deserves 5335 special consideration, but does not create a threat. There are two 5336 potential concerns: attempting to convert protected data into un- 5337 protected data and attempting to convert un-protected data into 5338 protected data. These concerns are addressed below. 5340 12.1.1. Converting Protected Data into Unprotected Data 5342 Since CAPWAP does not support authentication-only ciphers (i.e. all 5343 supported ciphersuites include encryption and authentication), it is 5344 not possible to convert protected data into unprotected data. Since 5345 encrypted data is (ideally) indistinguishable from random data, the 5346 probability of an encrypted packet passing for a well-formed packet 5347 is effectively zero. 5349 12.1.2. Converting Unprotected Data into Protected Data (Insertion) 5351 The use of message authentication makes it impossible for the 5352 attacker to forge protected records. This makes conversion of 5353 unprotected records to protected records impossible. 5355 12.1.3. Deletion of Protected Records 5357 An attacker could remove protected records from the stream, though 5358 not undetectably so, due the built-in reliability of the underlying 5359 CAPWAP protocol. In the worst case, the attacker would remove the 5360 same record repeatedly, resulting in a CAPWAP session timeout and 5361 restart. This is effectively a DoS attack, and could be accomplished 5362 by a man in the middle regardless of the CAPWAP protocol security 5363 mechanisms chosen. 5365 12.1.4. Insertion of Unprotected Records 5367 An attacker could inject packets into the unprotected channel, but 5368 this may become evident if sequence number desynchronization occurs 5369 as a result. Only if the attacker is a MiM can packets be inserted 5370 undetectably. This is a consequence of that channel's lack of 5371 protection, and not a new threat resulting from the CAPWAP security 5372 mechanism. 5374 12.2. Session ID Security 5376 Since DTLS does not export a unique session identifier, there can be 5377 no explicit protocol binding between the DTLS layer and CAPWAP layer. 5378 As a result, implementations MUST provide a mechanism for performing 5379 this binding. For example, an AC MUST NOT associate decrypted DTLS 5380 control packets with a particular WTP session based solely on the 5381 Session ID in the packet header. Instead, identification should be 5382 done based on which DTLS session decrypted the packet. Otherwise one 5383 authenticated WTP could spoof another authenticated WTP by altering 5384 the Session ID in the encrypted CAPWAP header. 5386 It should be noted that when the CAPWAP data channel is unencrypted, 5387 the WTP Session ID is exposed and possibly known to adversaries and 5388 other WTPs. This would allow the forgery of the source of data- 5389 channel traffic. This, however, should not be a surprise for 5390 unencrypted data channels. When the data channel is encrypted, the 5391 Session ID is not exposed, and therefore can safely be used to 5392 associate a data and control channel. The 64-bit length of the 5393 Session ID mitigates online guessing attacks where an adversarial, 5394 authenticated WTP tries to correlate his own data channel with 5395 another WTP's control channel. Note that for encrypted data 5396 channels, the Session ID should only be used for correlation for the 5397 first packet immediately after the initial DTLS handshake. Future 5398 correlation should instead be done via identification of a packet's 5399 DTLS session. 5401 12.3. Discovery Attacks 5403 Since the Discovery Request messages are sent in the clear, it is 5404 important that AC implementations NOT assume that receiving such a 5405 request from a WTP implies that it has rebooted, and consequently 5406 tear down any active DTLS sessions. Discovery Request messages can 5407 easily be spoofed by malicious devices, so it is important that the 5408 AC maintain two separate sets of states for the WTP until the 5409 DTLSSessionEstablished notification is received, indicating that the 5410 WTP was authenticated. Once a new DTLS session is successfully 5411 established, any state referring to the old session can be cleared. 5413 12.4. Interference with a DTLS Session 5415 If a WTP or AC repeatedly receives packets which fail DTLS 5416 authentication or decryption, this could indicate a DTLS 5417 desynchronization between the AC and WTP, a link prone to 5418 undetectable bit errors, or an attacker trying to disrupt a DTLS 5419 session. 5421 In the state machine (section 2.3), transitions to the DTLS tear down 5422 state can be triggered by frequently receiving DTLS packets with 5423 authentication or decryption errors. The threshold or technique for 5424 deciding when to move to the tear down state should be chosen 5425 carefully. Being able to easily transition to DTLS TD allows easy 5426 detection of malfunctioning devices, but allows for denial of service 5427 attacks. Making it difficult to transition to DTLS TD prevents 5428 denial of service attacks, but makes it more difficult to detect and 5429 reset a malfunctioning session. Implementers should set this policy 5430 with care. 5432 12.5. Use of Preshared Keys in CAPWAP 5434 While use of preshared keys may provide deployment and provisioning 5435 advantages not found in public key based deployments, it also 5436 introduces a number of operational and security concerns. In 5437 particular, because the keys must typically be entered manually, it 5438 is common for people to base them on memorable words or phrases. 5439 These are referred to as "low entropy passwords/passphrases". 5441 Use of low-entropy preshared keys, coupled with the fact that the 5442 keys are often not frequently updated, tends to significantly 5443 increase exposure. For these reasons, the following recommendations 5444 are made: 5446 o When DTLS is used with a preshared-key (PSK) ciphersuite, each WTP 5447 SHOULD have a unique PSK. Since WTPs will likely be widely 5448 deployed, their physical security is not guaranteed. If PSKs are 5449 not unique for each WTP, key reuse would allow the compromise of 5450 one WTP to result in the compromise of others 5452 o Generating PSKs from low entropy passwords is NOT RECOMMENDED. 5454 o It is RECOMMENDED that implementations that allow the 5455 administrator to manually configure the PSK also provide a 5456 capability for generation of new random PSKs, taking RFC 4086 [2] 5457 into account. 5459 o Preshared keys SHOULD be periodically updated. Implementations 5460 MAY facilitate this by providing an administrative interface for 5461 automatic key generation and periodic update, or it MAY be 5462 accomplished manually instead. 5464 Every pairwise combination of WTP and AC on the network SHOULD have a 5465 unqiue PSK. This prevents the domino effect (see Guidance for AAA 5466 Key Management [20]). If PSKs are tied to specific WTPs, then 5467 knowledge of the PSK implies a binding to a specified identity that 5468 can be authorized. 5470 If PSKs are shared, this binding between device and identity is no 5471 longer possible. Compromise of one WTP can yield compromise of 5472 another WTP, violating the CAPWAP security hierarchy. Consequently, 5473 sharing keys between WTPs is NOT RECOMMENDED. 5475 12.6. Use of Certificates in CAPWAP 5477 For public-key-based DTLS deployments, each device SHOULD have unique 5478 credentials, with an extended key usage authorizing the device to act 5479 as either a WTP or AC. If devices do not have unique credentials, it 5480 is possible that by compromising one device, any other device using 5481 the same credential may also be considered to be compromised. 5483 Certificate validation involves checking a large variety of things. 5485 Since the necessary things to validate are often environment- 5486 specific, many are beyond the scope of this document. In this 5487 section, we provide some basic guidance on certificate validation. 5489 Each device is responsible for authenticating and authorizing devices 5490 with which they communicate. Authentication entails validation of 5491 the chain of trust leading to the peer certificate, followed by the 5492 the peer certificate itself. At a minimum, devices SHOULD use SSH- 5493 style certificate caching to guarantee consistency. If devices have 5494 access to a certificate authority, they SHOULD properly validate the 5495 trust chain. Implementations SHOULD also provide a secure method for 5496 verifying that the credential in question has not been revoked. 5498 Note that if the WTP relies on the AC for network connectivity (e.g. 5499 the AC is a layer 2 switch to which the WTP is directly connected), 5500 the WTP may not be able to contact an OCSP server or otherwise obtain 5501 an up to date CRL if a compromised AC doesn't explicitly permit this. 5502 This cannot be avoided, except through effective physical security 5503 and monitoring measures at the AC. 5505 Proper validation of certificates typically requires checking to 5506 ensure the certificate has not yet expired. If devices have a real- 5507 time clock, they SHOULD verify the certificate validity dates. If no 5508 real-time clock is available, the device SHOULD make a best-effort 5509 attempt to validate the certificate validity dates through other 5510 means. Failure to check a certificate's temporal validity can make a 5511 device vulnerable to man-in-the-middle attacks launched using 5512 compromised, expired certificates, and therefore devices should make 5513 every effort to perform this validation. 5515 12.7. AAA Security 5517 The AAA protocol is used to distribute EAP keys to the ACs, and 5518 consequently its security is important to the overall system 5519 security. When used with TLS or IPsec, security guidelines specified 5520 in RFC 3539 [5] SHOULD be followed. 5522 In general, the link between the AC and AAA server SHOULD be secured 5523 using a strong ciphersuite keyed with mutually authenticated session 5524 keys. Implementations SHOULD NOT rely solely on Basic RADIUS shared 5525 secret authentication as it is often vulnerable to dictionary 5526 attacks, but rather SHOULD use stronger underlying security 5527 mechanisms. 5529 13. Management Considerations 5531 The CAPWAP protocol assumes that it is the only configuration 5532 interface to the WTP to configure parameters that are specified in 5533 the CAPWAP specifications. While the use of a separate management 5534 protocol MAY be used for the purposes of monitoring the WTP directly, 5535 configuring the WTP through a separate management interface is not 5536 recommended. Configuring the WTP through a separate protocol, such 5537 as via a CLI or SNMP, could lead to the AC state being out of sync 5538 with the WTP. 5540 14. Transport Considerations 5542 The CAPWAP WG carefully considered the congestion control 5543 requirements of the CAPWAP protocol, both for the CAPWAP control and 5544 data channels. 5546 CAPWAP specifies a single-threaded command/response protocol to be 5547 used on the control channel, and we have specified that an 5548 exponential back-off algorithm should be used when commands are 5549 retransmitted. When CAPWAP runs in its default mode (Local MAC), the 5550 control channel is the only CAPWAP channel. 5552 However, CAPWAP can also be run in Split MAC mode, in which case 5553 there will be a DTLS-encrypted data channel between each WTP and the 5554 AC. The WG discussed various options for providing congestion 5555 control on this channel. However, due to performance problems with 5556 TCP when it is run over another congestion control mechanism and the 5557 fact that the vast majority of traffic run over the CAPWAP data 5558 channel is likely to be congestion-controlled IP traffic, the CAPWAP 5559 WG felt that specifying a congestion control mechanism for the CAPWAP 5560 data channel would be more likely to cause problems than to resolve 5561 any. 5563 Because there is no congestion control mechanism specified for the 5564 CAPWAP data channel, it is recommended that non-congestion-controlled 5565 traffic not be tunneled over CAPWAP. When a significant amount of 5566 non-congestion-controlled traffic is expected to be present on a 5567 WLAN, the CAPWAP connection between the AC and the WTP for that LAN 5568 should be configured to remain in Local MAC mode with Distribution 5569 function at the WTP. 5571 The lock step nature of the CAPWAP protocol's control channel can 5572 cause the firmware download process to take some time, depending upon 5573 the RTT. This is not expected to be a problem since the CAPWAP 5574 protocol allows firmware to be downloaded while the WTP provides 5575 service to wireless clients/devices. 5577 It is necessary for the WTP and AC to configure their MTU based on 5578 the capabilities of the path. See Section 3.5 for more information. 5580 15. IANA Considerations 5582 A separate UDP port for data channel communications is (currently) 5583 the selected demultiplexing mechanism, and a port must be assigned 5584 for this purpose in Section 3.1. The UDP port numbers are listed by 5585 IANA at http://www.iana.org/assignments/port-numbers. 5587 IANA needs to assign an organization local multicast address called 5588 the "All ACs multicast address" from the IPv6 multicast address 5589 registry in Section 3.3 5591 15.1. CAPWAP Message Types 5593 The Message Type field in the CAPWAP header (Section 4.5.1.1) is used 5594 to identify the operation performed by the message. There are 5595 multiple namespaces, which is identified via the first three octets 5596 of the field containing the IANA Enterprise Number [10]. When the 5597 Enterprise Number is set to zero, the message types are reserved for 5598 use by the base CAPWAP specification which are controlled and 5599 maintained by IANA and requires a Standards Action. 5601 15.2. Wireless Binding Identifiers 5603 The Wireless Binding Identifier (WBID) field in the CAPWAP header 5604 (Section 4.3) is used to identify the wireless technology associated 5605 with the packet. Due to the limited address space available, a new 5606 WBID request requires Standards Action. 5608 16. Acknowledgements 5610 The following individuals are acknowledged for their contributions to 5611 this protocol specification: Puneet Agarwal, Saravanan Govindan, 5612 Peter Nilsson, and David Perkins. 5614 Michael Vakulenko contributed text to describe how CAPWAP can be used 5615 over layer 3 (IP/UDP) networks. 5617 17. References 5619 17.1. Normative References 5621 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 5622 Levels", BCP 14, RFC 2119, March 1997. 5624 [2] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 5625 Requirements for Security", BCP 106, RFC 4086, June 2005. 5627 [3] Mills, D., "Network Time Protocol (Version 3) Specification, 5628 Implementation", RFC 1305, March 1992. 5630 [4] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 5631 Public Key Infrastructure Certificate and Certificate 5632 Revocation List (CRL) Profile", RFC 3280, April 2002. 5634 [5] Aboba, B. and J. Wood, "Authentication, Authorization and 5635 Accounting (AAA) Transport Profile", RFC 3539, June 2003. 5637 [6] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for 5638 Transport Layer Security (TLS)", RFC 4279, December 2005. 5640 [7] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 5641 Protocol Version 1.1", RFC 4346, April 2006. 5643 [8] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 5644 Security", RFC 4347, April 2006. 5646 [9] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 5647 Extensions", RFC 2132, March 1997. 5649 [10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 5650 Considerations Section in RFCs", BCP 26, RFC 2434, 5651 October 1998. 5653 [11] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. 5654 Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)", 5655 RFC 3828, July 2004. 5657 [12] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 5658 Discovery", RFC 4821, March 2007. 5660 [13] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 5661 Specification", RFC 1883, December 1995. 5663 [14] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 5664 November 1990. 5666 [15] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for 5667 IP version 6", RFC 1981, August 1996. 5669 [16] Calhoun, P., "CAPWAP Protocol Binding for IEEE 802.11", 5670 draft-ietf-capwap-protocol-binding-ieee80211-04 (work in 5671 progress), June 2007. 5673 [17] Calhoun, P., "CAPWAP Access Controller DHCP Option", 5674 draft-calhoun-dhc-capwap-ac-option-00 (work in progress), 5675 April 2007. 5677 17.2. Informational References 5679 [18] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On- 5680 line Database", RFC 3232, January 2002. 5682 [19] Manner, J. and M. Kojo, "Mobility Related Terminology", 5683 RFC 3753, June 2004. 5685 [20] Housley, R. and B. Aboba, "Guidance for AAA Key Management", 5686 draft-housley-aaa-key-mgmt-09 (work in progress), 5687 February 2007. 5689 [21] Modadugu et al, N., "The Design and Implementation of Datagram 5690 TLS", Feb 2004. 5692 [22] IEEE, "Guidelines for use of a 48-bit Extended Unique 5693 Identifier", Dec 2005. 5695 [23] IEEE, "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) 5696 REGISTRATION AUTHORITY". 5698 Editors' Addresses 5700 Pat R. Calhoun 5701 Cisco Systems, Inc. 5702 170 West Tasman Drive 5703 San Jose, CA 95134 5705 Phone: +1 408-853-5269 5706 Email: pcalhoun@cisco.com 5708 Michael P. Montemurro 5709 Research In Motion 5710 5090 Commerce Blvd 5711 Mississauga, ON L4W 5M4 5712 Canada 5714 Phone: +1 905-629-4746 x4999 5715 Email: mmontemurro@rim.com 5717 Dorothy Stanley 5718 Aruba Networks 5719 1322 Crossman Ave 5720 Sunnyvale, CA 94089 5722 Phone: +1 630-363-1389 5723 Email: dstanley@arubanetworks.com 5725 Full Copyright Statement 5727 Copyright (C) The IETF Trust (2007). 5729 This document is subject to the rights, licenses and restrictions 5730 contained in BCP 78, and except as set forth therein, the authors 5731 retain all their rights. 5733 This document and the information contained herein are provided on an 5734 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 5735 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 5736 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 5737 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 5738 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 5739 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 5741 Intellectual Property 5743 The IETF takes no position regarding the validity or scope of any 5744 Intellectual Property Rights or other rights that might be claimed to 5745 pertain to the implementation or use of the technology described in 5746 this document or the extent to which any license under such rights 5747 might or might not be available; nor does it represent that it has 5748 made any independent effort to identify any such rights. Information 5749 on the procedures with respect to rights in RFC documents can be 5750 found in BCP 78 and BCP 79. 5752 Copies of IPR disclosures made to the IETF Secretariat and any 5753 assurances of licenses to be made available, or the result of an 5754 attempt made to obtain a general license or permission for the use of 5755 such proprietary rights by implementers or users of this 5756 specification can be obtained from the IETF on-line IPR repository at 5757 http://www.ietf.org/ipr. 5759 The IETF invites any interested party to bring to its attention any 5760 copyrights, patents or patent applications, or other proprietary 5761 rights that may cover technology that may be required to implement 5762 this standard. Please address the information to the IETF at 5763 ietf-ipr@ietf.org. 5765 Acknowledgment 5767 Funding for the RFC Editor function is provided by the IETF 5768 Administrative Support Activity (IASA).