idnits 2.17.1 draft-ietf-capwap-protocol-specification-07.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 5569. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 5580. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 5587. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 5593. 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 : ---------------------------------------------------------------------------- ** There is 1 instance of lines with control characters in the document. ** The abstract seems to contain references ([12]), 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 (June 11, 2007) is 6161 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 1170 == Unused Reference: '9' is defined on line 5488, 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) == Outdated reference: A later version (-12) exists of draft-ietf-capwap-protocol-binding-ieee80211-04 == Outdated reference: A later version (-02) exists of draft-ietf-capwap-dhc-ac-option-00 Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Calhoun, Editor 3 Internet-Draft Cisco Systems, Inc. 4 Expires: December 13, 2007 M. Montemurro, Editor 5 Research In Motion 6 D. Stanley, Editor 7 Aruba Networks 8 June 11, 2007 10 CAPWAP Protocol Specification 11 draft-ietf-capwap-protocol-specification-07 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 December 13, 2007. 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 [12]. 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 [12] 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 [15]. 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. 298 The CAPWAP protocol provides for the delivery of commands from the AC 299 to the WTP for the management of stations that are communicating with 300 the WTP. This may include the creation of local data structures in 301 the WTP for the stations and the collection of statistical 302 information about the communication between the WTP and the stations. 303 The CAPWAP protocol provides a mechanism for the AC to obtain 304 statistical information collected by the WTP. 306 The CAPWAP protocol provides for a keep alive feature that preserves 307 the communication channel between the WTP and AC. If the AC fails to 308 appear alive, the WTP will try to discover a new AC. 310 2.1. Wireless Binding Definition 312 The CAPWAP protocol is independent of a specific WTP radio 313 technology. Elements of the CAPWAP protocol are designed to 314 accommodate the specific needs of each wireless technology in a 315 standard way. Implementation of the CAPWAP protocol for a particular 316 wireless technology MUST follow the binding requirements defined for 317 that technology. 319 When defining a binding for wireless technologies, the authors MUST 320 include any necessary definitions for technology-specific messages 321 and all technology-specific message elements for those messages. At 322 a minimum, a binding MUST provide: 324 1 - The definition for a binding-specific Statistics message 325 element, carried in the WTP Event Request message 327 2 - A message element carried in the Station Configuration Request 328 message to configure station information on the WTP 330 3 - A WTP Radio Information message element carried in the 331 Discovery, Primary Discovery and Join Request and Response 332 messages, indicating the binding specific radio types supported at 333 the WTP and AC. 335 If technology specific message elements are required for any of the 336 existing CAPWAP messages defined in this specification, they MUST 337 also be defined in the technology binding document. 339 The naming of binding-specific message elements MUST begin with the 340 name of the technology type, e.g., the binding for IEEE 802.11, 341 provided in [12], begins with "IEEE 802.11". 343 The CAPWAP binding concept is also used in any future specifications 344 that add functionality to either the base CAPWAP protocol 345 specification, or any published CAPWAP binding specification. A 346 separate WTP Radio Information message element MUST be created to 347 properly advertise support for the specification. This mechanism 348 allows for future protocol extensibility, while providing the 349 necessary capabilities advertisement, through the WTP Radio 350 Information message element, to ensure WTP/AC interoperability. 352 2.2. CAPWAP Session Establishment Overview 354 This section describes the session establishment process message 355 exchanges in the ideal case. The annotated ladder diagram shows the 356 AC on the right, the WTP on the left, and assumes the use of 357 certificates for DTLS authentication. The CAPWAP Protocol State 358 Machine is described in detail in Section 2.3. Note that DTLS allows 359 certain messages to be aggregated into a single frame, which is 360 denoted via an asterix in the following figure. 362 ============ ============ 363 WTP AC 364 ============ ============ 365 [----------- begin optional discovery ------------] 367 Discover Request 368 ------------------------------------> 369 Discover Response 370 <------------------------------------ 372 [----------- end optional discovery ------------] 374 (-- begin DTLS handshake --) 376 ClientHello 377 ------------------------------------> 378 HelloVerifyRequest (with cookie) 379 <------------------------------------ 381 ClientHello (with cookie) 382 ------------------------------------> 383 ServerHello, 384 Certificate, 385 ServerHelloDone* 386 <------------------------------------ 388 (-- WTP callout for AC authorization --) 390 Certificate (optional), 391 ClientKeyExchange, 392 CertificateVerify (optional), 393 ChangeCipherSpec, 394 Finished* 395 ------------------------------------> 397 (-- AC callout for WTP authorization --) 398 ChangeCipherSpec, 399 Finished* 400 <------------------------------------ 402 (-- DTLS session is established now --) 404 Join Request 405 ------------------------------------> 406 Join Response 407 <------------------------------------ 409 (-- assume image is up to date --) 411 Configuration Status Request 412 ------------------------------------> 413 Configuration Status Response 414 <------------------------------------ 416 (-- enter RUN state --) 418 : 419 : 421 Echo Request 422 ------------------------------------> 423 Echo Response 424 <------------------------------------ 426 : 427 : 429 Event Request 430 ------------------------------------> 431 Event Response 432 <------------------------------------ 434 : 435 : 437 At the end of the illustrated CAPWAP message exchange, the AC and WTP 438 are securely exchanging CAPWAP control messages. This is an 439 idealized illustration, provided to clarify protocol operation. 440 Section 2.3 provides a detailed description of the corresponding 441 state machine. 443 2.3. CAPWAP State Machine Definition 445 The following state diagram represents the lifecycle of a WTP-AC 446 session. Use of DTLS by the CAPWAP protocol results in the 447 juxtaposition of two nominally separate yet tightly bound state 448 machines. The DTLS and CAPWAP state machines are coupled through an 449 API consisting of commands (see Section 2.3.2.1) and notifications 450 (see Section 2.3.2.2). Certain transitions in the DTLS state machine 451 are triggered by commands from the CAPWAP state machine, while 452 certain transitions in the CAPWAP state machine are triggered by 453 notifications from the DTLS state machine. 455 /-------------------------\ 456 w| | 457 5+----------+ x +------------+ | 458 | Run |-->| Reset |-\| 459 +----------+ +------------+ || 460 u ^ ^ ^ y|| 461 +------------+--------/ | | || 462 | Data Check | /-------/ | || 463 +------------+<-------\ | | || 464 | | || 465 /------------------+--------\ | || 466 r| t| s| 4 v o| || 467 +--------+ +-----------+ +--------------+|| 468 | Join |---->| Configure | | Image Data ||| 469 +--------+ q +-----------+ +--------------+|| 470 ^ p| V| x| || 471 | | \-------------------\ | || 472 | \--------------------------------------\| | || 473 \------------------------\ || | || 474 /--------------<----------------+--------------\ || | || 475 | /------------<-------------\ | | || | || 476 | | m| |n z| vv v vv 477 | | +----------------+ +--------------+ +-----------+ 478 | | | DTLS Setup | | DTLS Connect | | DTLS TD | 479 | | +----------------+ +--------------+ +-----------+ 480 | | g| ^ ^ |h ^ ^ 481 v v | | | | | | 482 | | | | | \-------\ | /-----------/ 483 | | | | | | | | 484 | | v |e f| 2 v |j |k 485 | \->+------+ +------+ +-----------+ 486 | | Idle |-->| Disc | | Authorize | 487 \--->+------+ a +------+ +-----------+ 488 b| ^ |c 489 | | /----/ 490 v d| | 491 +---------+ | 492 | Sulking |<-/ 493 3 +---------+ 495 Figure 3: CAPWAP Integrated State Machine 497 The CAPWAP protocol state machine, depicted above, is used by both 498 the AC and the WTP. In cases where states are not shared (i.e. not 499 implemented in one or the other of the AC or WTP), this is explicitly 500 called out in the transition descriptions below. For every state 501 defined, only certain messages are permitted to be sent and received. 502 The CAPWAP control messages definitions specify the state(s) in which 503 each message is valid. 505 Since the WTP only communicates with a single AC, it only has a 506 single instance of the CAPWAP state machine. The AC has a separate 507 instance of the CAPWAP state machine per WTP it is communicating 508 with. 510 2.3.1. CAPWAP Protocol State Transitions 512 This section describes the various state transitions, and the events 513 that cause them. This section does not discuss interactions between 514 DTLS- and CAPWAP-specific states. Those interactions, and DTLS- 515 specific states and transitions, are discussed in Section 2.3.2. 517 Idle to Discovery (a): This transition occurs once device 518 initialization is complete. 520 WTP: The WTP enters the Discovery state prior to transmitting the 521 first Discovery Request message (see Section 5.1). Upon 522 entering this state, the WTP sets the DiscoveryInterval timer 523 (see Section 4.7). The WTP resets the DiscoveryCount counter 524 to zero (0) (see Section 4.8). The WTP also clears all 525 information from ACs it may have received during a previous 526 Discovery phase. 528 AC: The AC does not maintain state information for the WTP upon 529 reception of the Discovery Request message, but it SHOULD 530 respond with a Discovery Response message (see Section 5.2). 531 This transition is a no-op for the AC. 533 Idle to Sulking (b): This transition occurs to force the WTP and AC 534 to enter a quiet period to avoid repeatedly attempting to 535 establish a connection. 537 WTP: The WTP enters this state when the FailedDTLSSessionCount or 538 the FailedDTLSAuthFailCount counter reaches 539 MaxFailedDTLSSessionRetry variable (see Section 4.8). Upon 540 entering this state, the WTP MUST start the SilentInterval 541 timer. While in the Sulking state, all received CAPWAP and 542 DTLS protocol messages received MUST be ignored. 544 AC: The AC enters this state with the specific WTP when the 545 FailedDTLSSessionCount or the FailedDTLSAuthFailCount counter 546 reaches MaxFailedDTLSSessionRetry variable (see Section 4.8). 547 Upon entering this state, the AC MUST start the SilentInterval 548 timer. While in the Sulking state, all received CAPWAP and 549 DTLS protocol messages received from the WTP MUST be ignored. 551 Discovery to Discovery (2): In the Discovery state, the WTP 552 determines which AC to connect to. 554 WTP: This transition occurs when the DiscoveryInterval timer 555 expires. If the WTP is configured with a list of ACs, it 556 transmits a Discovery Request message to every AC from which it 557 has not received a Discovery Response message. For every 558 transition to this event, the WTP increments the DiscoveryCount 559 counter. See Section 5.1 for more information on how the WTP 560 knows the ACs to which it should transmit the Discovery Request 561 messages. The WTP restarts the DiscoveryInterval timer 562 whenever it transmits Discovery Request messages. 564 AC: This is a no-op. 566 Discovery to Sulking (c): This transition occurs on a WTP when 567 Discovery or connectivity to the AC fails. 569 WTP: The WTP enters this state when the DiscoveryInterval timer 570 expires or the DiscoveryCount variable is equal to the 571 MaxDiscoveries variable (see Section 4.8). Upon entering this 572 state, the WTP MUST start the SilentInterval timer. While in 573 the Sulking state, all received CAPWAP protocol messages 574 received MUST be ignored. 576 AC: This is a no-op. 578 Sulking to Idle (d): This transition occurs on a WTP when it must 579 restart the discovery phase. 581 WTP: The WTP enters this state when the SilentInterval timer (see 582 Section 4.7) expires. The FailedDTLSSessionCount, 583 DiscoveryCount and FailedDTLSAuthFailCount counters are reset 584 to zero. 586 AC: The AC enters this state when the SilentInterval timer (see 587 Section 4.7) expires. The FailedDTLSSessionCount, 588 DiscoveryCount and FailedDTLSAuthFailCount counters are reset 589 to zero. 591 Sulking to Sulking (3): The Sulking state provides the silent 592 period, minimizing the possibility for Denial of Service (DoS) 593 attacks. 595 WTP: All packets received from the AC while in the sulking state 596 are ignored. 598 AC: All packets receive from the WTP while in the sulking state 599 are ignored. 601 Idle to DTLS Setup (e): This transition occurs to establish a secure 602 DTLS session with the peer. 604 WTP: The WTP initiates this transition by invoking the DTLSStart 605 command, which starts the DTLS session establishment with the 606 chosen AC. When the discovery phase is bypassed, it is assumed 607 the WTP has a locally configured AC. 609 AC: The AC initiates this transition by invoking the DTLSListen 610 command, which informs the DTLS stack that it is willing to 611 listen for an incoming session. The AC MAY provide optional 612 qualifiers in the DTLSListen command to only accept session 613 requests from specific WTPs. 615 Discovery to DTLS Setup (f): This transition occurs to establish a 616 secure DTLS session with the peer. 618 WTP: The WTP initiates this transition by invoking the DTLSStart 619 command (see Section 2.3.2.1), which starts the DTLS session 620 establishment with the chosen AC. The decision of which AC to 621 connect to is the result of the discovery phase, which is 622 described in Section 3.3. 624 AC: The AC initiates this transition by invoking the DTLSListen 625 command (see Section 2.3.2.1), which informs the DTLS stack 626 that it is willing to listen for an incoming session. The AC 627 MAY have maintained state information when it received the 628 Discovery Request message to provide optional qualifiers in the 629 DTLSListen command to only accept session requests from a 630 specific WTP. Note that maintaining state information based on 631 an unsecured Discovery Request message MAY lead to a Denial of 632 Service attack. Therefore the AC SHOULD ensure that the state 633 information is freed after a period, which is implementation 634 specific. 636 DTLS Setup to Idle (g): This transition occurs when the DTLS Session 637 failed to be established. 639 WTP: The WTP initiates this state transition when it receives a 640 DTLSEstablishFail notification from DTLS (see Section 2.3.2.2). 641 This error notification aborts the secure DTLS session 642 establishment. When this notification is received, the 643 FailedDTLSSessionCount counter is incremented. 645 AC: The WTP initiates this state transition when it receives a 646 DTLSEstablishFail notification from DTLS (see Section 2.3.2.2). 647 This error notification aborts the secure DTLS session 648 establishment. When this notification is received, the 649 FailedDTLSSessionCount counter is incremented. 651 DTLS Setup to Authorize (h): This transition occurs when an incoming 652 DTLS session is being established, and the DTLS stack needs 653 authorization to proceed with the session establishment. 655 WTP: This state transition occurs when the WTP receives the 656 DTLSPeerAuthorize notification (see Section 2.3.2.2). Upon 657 entering this state, the WTP performs an authorization check 658 against the AC credentials. See Section 2.4.4 for more 659 information on AC authorization. 661 AC: This state transition occurs when the AC receives the 662 DTLSPeerAuthorize notification (see Section 2.3.2.2). Upon 663 entering this state, the AC performs an authorization check 664 against the WTP credentials. See Section 2.4.4 for more 665 information on WTP authorization. 667 Authorize to DTLS Connect (j): This transition occurs to notify the 668 DTLS stack that the session should be established. 670 WTP: This state transition occurs when the WTP has either opted 671 to forgo the authorization check of the AC's credentials, or 672 the credentials were successfully authorized. This is done by 673 invoking the DTLSAccept DTLS command (see Section 2.3.2.1). 675 AC: This state transition occurs when the AC has either opted to 676 forgo the authorization check of the WTP's credentials, or the 677 credentials were successfully authorized. This is done by 678 invoking the DTLSAccept DTLS command (see Section 2.3.2.1). 680 Authorize to DTLS Teardown (k): This transition occurs to notify the 681 DTLS stack that the session should be aborted. 683 WTP: This state transition occurs when the WTP was unable to 684 authorize the AC, using the AC credentials. The WTP then 685 aborts the DTLS session by invoking the DTLSAbortSession 686 command (see Section 2.3.2.1). 688 AC: This state transition occurs when the AC was unable to 689 authorize the WTP, using the WTP credentials. The AC then 690 aborts the DTLS session by invoking the DTLSAbortSession 691 command (see Section 2.3.2.1). 693 DTLS Connect to Idle (m): This transition occurs when the DTLS 694 Session failed to be established. 696 WTP: This state transition occurs when the WTP receives either a 697 DTLSAborted or DTLSAuthenticateFail notification (see 698 Section 2.3.2.2), indicating that the DTLS session was not 699 successfully established. When this transition occurs due to 700 the DTLSAuthenticateFail notification, the 701 FailedDTLSAuthFailCount is incremented, otherwise the 702 FailedDTLSSessionCount counter is incremented. 704 AC: This state transition occurs when the AC receives either a 705 DTLSAborted or DTLSAuthenticateFail notification (see 706 Section 2.3.2.2), indicating that the DTLS session was not 707 successfully established. When this transition occurs due to 708 the DTLSAuthenticateFail notification, the 709 FailedDTLSAuthFailCount is incremented, otherwise the 710 FailedDTLSSessionCount counter is incremented. 712 DTLS Connect to Join (n): This transition occurs when the DTLS 713 Session is successfully established. 715 WTP: This state transition occurs when the WTP receives the 716 DTLSEstablished notification (see Section 2.3.2.2), indicating 717 that the DTLS session was successfully established. When this 718 notification is received, the FailedDTLSSessionCount counter is 719 set to zero. 721 AC: This state transition occurs when the AC receives the 722 DTLSEstablished notification (see Section 2.3.2.2), indicating 723 that the DTLS session was successfully established. When this 724 notification is received, the FailedDTLSSessionCount counter is 725 set to zero, and the WaitJoin timer is started (see 726 Section 4.7). 728 Join to DTLS Teardown (p): This transition occurs when the join 729 process failed. 731 WTP: This state transition occurs when the WTP receives a Join 732 Response message with a Result Code message element containing 733 an error, if the Image Identifier provided by the AC in the 734 Join Response message differs from the WTP's currently running 735 firmware version and the WTP has the requested image in its 736 non-volatile memory, or if the WaitDTLS timer expires. This 737 causes the WTP to initiate the DTLSShutdown command (see 738 Section 2.3.2.1). This transition also occurs if the WTP 739 receives one of the following DTLS notifications: DTLSAborted, 740 DTLSReassemblyFailure or DTLSPeerDisconnect. 742 AC: This state transition occurs either if the WaitJoin timer 743 expires or if the AC transmits a Join Response message with a 744 Result Code message element containing an error. This causes 745 the AC to initiate the DTLSShutdown command (see 746 Section 2.3.2.1). This transition also occurs if the AC 747 receives one of the following DTLS notifications: DTLSAborted, 748 DTLSReassemblyFailure or DTLSPeerDisconnect. 750 Join to Image Data (r): This state transition is used by the WTP and 751 the AC to download executable firmware. 753 WTP: The WTP enters the Image Data state when it receives a 754 successful Join Response message and determines and the 755 included Image Identifier message element is not the same as 756 its currently running image. The WTP also detects that the 757 requested image version is not currently available in the WTP's 758 non-volatile storage (see Section 9.1 for a full description of 759 the firmware download process). The WTP initializes the 760 EchoInterval timer (see Section 4.7), and transmits the Image 761 Data Request message (see Section 9.1.1) requesting the start 762 of the firmware download. 764 AC: This state transition occurs when the AC receives the Image 765 Data Request message from the WTP. The AC MUST transmit an 766 Image Data Response message (see Section 9.1.2) to the WTP, 767 which includes a portion of the firmware. The AC MUST start 768 the NeighborDeadInterval timer (see Section 4.7). 770 Join to Configure (q): This state transition is used by the WTP and 771 the AC to exchange configuration information. 773 WTP: The WTP enters the Configure state when it receives a 774 successful Join Response, and determines that the included 775 Image Identifier message element is the same as its currently 776 running image. The WTP transmits the Configuration Status 777 message (see Section 8.2) to the AC with message elements 778 describing its current configuration. The WTP also starts the 779 ResponseTimeout timer (see Section 4.7). 781 AC: This state transition occurs immediately after the AC 782 transmits the Join Response message to the WTP. If the AC 783 receives the Configuration Status message from the WTP, the AC 784 MUST transmit a Configuration Status Response message (see 785 Section 8.3) to the WTP, and MAY include specific message 786 elements to override the WTP's configuration. The WTP also 787 starts the ChangeStatePendingTimer timer (see Section 4.7). 789 Configure to Reset (s): This state transition is used to reset the 790 connection either due to an error during the configuration phase, 791 or when the WTP determines it needs to reset in order for the new 792 configuration to take effect. 794 WTP: The WTP enters the Reset state when it receives a 795 Configuration Status Response indicating an error or when it 796 determines that a reset of the WTP is required, due to the 797 characteristics of a new configuration. 799 AC: The AC transitions to the Reset state when it receives a 800 Change State Event message from the WTP that contains an error 801 for which AC policy does not permit the WTP to provide service. 802 This state transition also occurs when the AC 803 ChangeStatePendingTimer timer expires. 805 Configure to DTLS Teardown (V): This transition occurs when the 806 configuration process aborts due to a DTLS error. 808 WTP: The WTP enters this state when it receives one of the 809 following DTLS notifications: DTLSAborted, 810 DTLSReassemblyFailure or DTLSPeerDisconnect (see 811 Section 2.3.2.2). The WTP MAY tear down the DTLS session if it 812 receives frequent DTLSDecapFailure notifications. 814 AC: The AC enters this state when it receives one of the 815 following DTLS notifications: DTLSAborted, 816 DTLSReassemblyFailure or DTLSPeerDisconnect (see 817 Section 2.3.2.2). The WTP MAY tear down the DTLS session if it 818 receives frequent DTLSDecapFailure notifications. 820 Image Data to Image Data (4): The Image Data state is used by the 821 WTP and the AC during the firmware download phase. 823 WTP: The WTP enters the Image Data state when it receives an 824 Image Data Response message indicating that the AC has more 825 data to send. 827 AC: This state transition occurs when the AC receives the Image 828 Data Request message from the WTP while already in the Image 829 Data state, and it detects that the firmware download has not 830 completed. 832 Image Data to Reset (o): This state transition is used to reset the 833 DTLS connection prior to restarting the WTP after an image 834 download. 836 WTP: When an image download completes, the WTP enters the Reset 837 state. The WTP MAY also transition to this state upon 838 receiving an Image Data Response message from the AC (see 839 Section 9.1.2) indicating a failure. 841 AC: The AC enters the Reset state when the image download is 842 complete, or if an error occurs during the image download 843 process. 845 Image Data to DTLS Teardown (x): This transition occurs when the 846 firmware download process aborts due to a DTLS error. 848 WTP: The WTP enters this state when it receives one of the 849 following DTLS notifications: DTLSAborted, 850 DTLSReassemblyFailure or DTLSPeerDisconnect (see 851 Section 2.3.2.2). The WTP MAY tear down the DTLS session if it 852 receives frequent DTLSDecapFailure notifications. 854 AC: The AC enters this state when it receives one of the 855 following DTLS notifications: DTLSAborted, 856 DTLSReassemblyFailure or DTLSPeerDisconnect (see 857 Section 2.3.2.2). The WTP MAY tear down the DTLS session if it 858 receives frequent DTLSDecapFailure notifications. 860 Configure to Data Check (t): This state transition occurs when the 861 WTP and AC confirm the configuration. 863 WTP: The WTP enters this state when it receives a successful 864 Configuration Status Response message from the AC. The WTP 865 initializes the EchoInterval timer (see Section 4.7), and 866 transmits the Change State Event Request message (see 867 Section 8.6). 869 AC: This state transition occurs when the AC receives the Change 870 State Event Request message (see Section 8.6) from the WTP. 871 The AC responds with a Change State Event Response message (see 872 Section 8.7). The AC MUST start the NeighborDeadInterval timer 873 (see Section 4.7). 875 Data Check to Run (u): This state transition occurs when the linkage 876 between the control and data channels has occured, causing the WTP 877 and AC to enter their normal state of operation. 879 WTP: The WTP enters this state when it receives a successful 880 Change State Event Response message from the AC. The WTP 881 initiates the data channel, which MAY require the establishment 882 of a DTLS session, starts the DataChannelKeepAlive timer (see 883 Section 4.7) and transmits a Data Channel Keep Alive packet 884 (see Section 4.4.1). The WTP then starts the 885 DataChannelDeadInterval timer (see Section 4.7). 887 AC: This state transition occurs when the AC receives the Data 888 Channel Keep Alive packet (see Section 4.4.1), with a Session 889 ID message element matching that included by the WTP in the 890 Join Request message. Note that if AC policy is to require the 891 data channel to be encrypted, this process would also require 892 the establishment of a data channel DTLS session. Upon 893 receiving the Data Channel Keep Alive packet, the AC transmits 894 its own Data Channel Keep Alive packet. 896 Run to DTLS Teardown (u): This state transition occurs when an error 897 has occured in the DTLS stack, causing the DTLS session to be 898 torndown. 900 WTP: The WTP enters this state when it receives one of the 901 following DTLS notifications: DTLSAborted, 902 DTLSReassemblyFailure or DTLSPeerDisconnect (see 903 Section 2.3.2.2). The WTP MAY tear down the DTLS session if it 904 receives frequent DTLSDecapFailure notifications. The WTP also 905 transitions to this state if the underlying reliable 906 transport's RetransmitCount counter has reached the 907 MaxRetransmit variable (see Section 4.7). 909 AC: The AC enters this state when it receives one of the 910 following DTLS notifications: DTLSAborted, 911 DTLSReassemblyFailure or DTLSPeerDisconnect (see 912 Section 2.3.2.2). The WTP MAY tear down the DTLS session if it 913 receives frequent DTLSDecapFailure notifications. The AC 914 transitions to this state if the underlying reliable 915 transport's RetransmitCount counter has reached the 916 MaxRetransmit variable (see Section 4.7). 918 Run to Run (5): This is the normal state of operation. 920 WTP: This is the WTP's normal state of operation. There are many 921 events that result this state transition: 923 Configuration Update: The WTP receives a Configuration Update 924 Request message(see Section 8.4). The WTP MUST respond with 925 a Configuration Update Response message (see Section 8.5). 927 Change State Event: The WTP receives a Change State Event 928 Response message, or determines that it must initiate a 929 Change State Event Request message, as a result of a failure 930 or change in the state of a radio. 932 Echo Request: The WTP sends an Echo Request message 933 (Section 7.1) or receives the corresponding Echo Response 934 message, (see Section 7.2) from the AC. 936 Clear Config Request: The WTP receives a Clear Configuration 937 Request message (see Section 8.8). The WTP MUST reset its 938 configuration back to manufacturer defaults. 940 WTP Event: The WTP sends a WTP Event Request message, 941 delivering information to the AC (see Section 9.4). The WTP 942 receives a WTP Event Response message from the AC (see 943 Section 9.5). 945 Data Transfer: The WTP sends a Data Transfer Request message 946 to the AC (see Section 9.6). The WTP receives a Data 947 Transfer Response message from the AC (see Section 9.7). 949 Station Configuration Request: The WTP receives a Station 950 Configuration Request message (see Section 10.1), to which 951 it MUST respond with a Station Configuration Response 952 message (see Section 10.2). 954 AC: This is the AC's normal state of operation: 956 Configuration Update: The AC sends a Configuration Update 957 Request message (see Section 8.4) to the WTP to update its 958 configuration. The AC receives a Configuration Update 959 Response message (see Section 8.5) from the WTP. 961 Change State Event: The AC receives a Change State Event 962 Request message (see Section 8.6), to which it MUST respond 963 with the Change State Event Response message (see 964 Section 8.7). 966 Echo Request: The AC receives an Echo Request message (see 967 Section 7.1), to which it MUST respond with an Echo Response 968 message(see Section 7.2). 970 Clear Config Response: The AC receives a Clear Configuration 971 Response message from the WTP (see Section 8.9). 973 WTP Event: The AC receives a WTP Event Request message from 974 the WTP (see Section 9.4) and MUST generate a corresponding 975 WTP Event Response message (see Section 9.5). 977 Data Transfer: The AC receives a Data Transfer Request message 978 from the WTP (see Section 9.6) and MUST generate a 979 corresponding Data Transfer Response message (see 980 Section 9.7). 982 Station Configuration Request: The AC sends a Station 983 Configuration Request message (see Section 10.1) or receives 984 the corresponding Station Configuration Response message 985 (see Section 10.2) from the WTP. 987 Run to Reset (x): This state transition is used when either the AC 988 or WTP tear down the connection. This may occur as part of normal 989 operation, or due to error conditions. 991 WTP: The WTP enters the Reset state when it receives a Reset 992 Request message from the AC. 994 AC: The AC enters the Reset state when it transmits a Reset 995 Request message to the WTP. 997 Reset to DTLS Teardown (y): This transition occurs when the CAPWAP 998 reset is complete, to terminate the DTLS session. 1000 WTP: This state transition occurs when the WTP receives a Reset 1001 Response message. This causes the WTP to initiate the 1002 DTLSShutdown command (see Section 2.3.2.1). 1004 AC: This state transition occurs when the AC transmits a Reset 1005 Response message. The AC does not invoke the DTLSShutdown 1006 command (see Section 2.3.2.1). 1008 DTLS Teardown to Idle (z): This transition occurs when the DTLS 1009 session has been shutdown. 1011 WTP: This state transition occurs when the WTP has successfully 1012 cleaned up all resources associated with the control plane DTLS 1013 session. The data plane DTLS session is also shutdown, and all 1014 resources freed, if a DTLS session was established for the data 1015 plane. Any timers set for the current instance of the state 1016 machine are also cleared. 1018 AC: This state transition occurs when the AC has successfully 1019 cleaned up all resources associated with the control plane DTLS 1020 session. The data plane DTLS session is also shutdown, and all 1021 resources freed, if a DTLS session was established for the data 1022 plane. Any timers set for the current instance of the state 1023 machine are also cleared. 1025 2.3.2. CAPWAP/DTLS Interface 1027 This section describes the DTLS Commands used by CAPWAP, and the 1028 notifications received from DTLS to the CAPWAP protocol stack. 1030 2.3.2.1. CAPWAP to DTLS Commands 1032 Six commands are defined for the CAPWAP to DTLS API. These 1033 "commands" are conceptual, and may be implemented as one or more 1034 function calls. This API definition is provided to clarify 1035 interactions between the DTLS and CAPWAP components of the integrated 1036 CAPWAP state machine. 1038 Below is a list of the minimal command API: 1040 o DTLSStart is sent to the DTLS component to cause a DTLS session to 1041 be established. Upon invoking the DTLSStart command, the WaitDTLS 1042 timer is started. The WTP initiates this DTLS command, as the AC 1043 does not initiate DTLS sessions. 1045 o DTLSListen is sent to the DTLS component to allow the DTLS 1046 component to listen for incoming DTLS session requests. 1048 o DTLSAccept is sent to the DTLS component to allow the DTLS session 1049 establishment to continue successfully. 1051 o DTLSAbortSession is sent to the DTLS component to cause the 1052 session that is in the process of being established to be aborted. 1053 This command is also sent when the WaitDTLS timer expires. When 1054 this command is executed, the FailedDTLSSessionCount counter is 1055 incremented. 1057 o DTLSShutdown is sent to the DTLS component to cause session 1058 teardown. 1060 o DTLSMtuUpdate is sent by the CAPWAP component to modify the MTU 1061 size used by the DTLS component. The default size is 1468 bytes. 1063 2.3.2.2. DTLS to CAPWAP Notifications 1065 DTLS notifications are defined for the DTLS to CAPWAP API. These 1066 "notifications" are conceptual, and may be implemented in numerous 1067 ways (e.g. as function return values). This API definition is 1068 provided to clarify interactions between the DTLS and CAPWAP 1069 components of the integrated CAPWAP state machine. It is important 1070 to note that the notifications listed below MAY cause the CAPWAP 1071 state machine to jump from one state to another using a state 1072 transition not listed in Section 2.3.1. When a notification listed 1073 below occurs, the target CAPWAP state shown in Figure 3 becomes the 1074 current state. 1076 Below is a list of the API notifications: 1078 o DTLSPeerAuthorize is sent to the CAPWAP component during DTLS 1079 session establishment once the peer's identity has been received. 1080 This notification MAY be used by the CAPWAP component to authorize 1081 the session, based on the peer's identity. The authorization 1082 process will lead to the CAPWAP component initiating either the 1083 DTLSAccept or DTLSAbortSession commands. 1085 o DTLSEstablished is sent to the CAPWAP component to indicate that 1086 that a secure channel now exists, using the parameters provided 1087 during the DTLS initialization process. When this notification is 1088 received, the FailedDTLSSessionCount counter is reset to zero. 1089 When this notification is received, the WaitDTLS timer is stopped. 1091 o DTLSEstablishFail is sent when the DTLS session establishment has 1092 failed, either due to a local error, or due to the peer rejecting 1093 the session establishment. When this notification is received, 1094 the FailedDTLSSessionCount counter is incremented. 1096 o DTLSAuthenticateFail is sent when DTLS session establishment 1097 failed due to an authentication error. When this notification is 1098 received, the FailedDTLSAuthFailCount counter is incremented. 1100 o DTLSAborted is sent to the CAPWAP component to indicate that 1101 session abort (as requested by CAPWAP) is complete; this occurs to 1102 confirm a DTLS session abort, or when the WaitDTLS timer expires. 1103 When this notification is received, the WaitDTLS timer is stopped. 1105 o DTLSReassemblyFailure MAY be sent to the CAPWAP component to 1106 indicate DTLS fragment reassembly failure. 1108 o DTLSDecapFailure MAY be sent to the CAPWAP module to indicate a 1109 decapsulation failure. DTLSDecapFailure MAY be sent to the CAPWAP 1110 module to indicate an encryption/authentication failure. This 1111 notification is intended for informative purposes only, and is not 1112 intended to cause a change in the CAPWAP state machine (see 1113 Section 12.4). 1115 o DTLSPeerDisconnect is sent to the CAPWAP component to indicate the 1116 DTLS session has been torn down. Note that this notification is 1117 only received if the DTLS session has been established. 1119 2.4. Use of DTLS in the CAPWAP Protocol 1121 DTLS is used as a tightly-integrated, secure wrapper for the CAPWAP 1122 protocol. In this document DTLS and CAPWAP are discussed as 1123 nominally distinct entitites; however they are very closely coupled, 1124 and may even be implemented inseparably. Since there are DTLS 1125 library implementations currently available, and since security 1126 protocols (e.g. IPsec, TLS) are often implemented in widely 1127 available acceleration hardware, it is both convenient and forward- 1128 looking to maintain a modular distinction in this document. 1130 This section describes a detailed walk-through of the interactions 1131 between the DTLS module and the CAPWAP module, via 'commands' (CAPWAP 1132 to DTLS) and 'notifications' (DTLS to CAPWAP) as they would be 1133 encountered during the normal course of operation. 1135 2.4.1. DTLS Handshake Processing 1137 Details of the DTLS handshake process are specified in [8]. This 1138 section describes the interactions between the DTLS session 1139 establishment process and the CAPWAP protocol. Note that the 1140 conceptual DTLS state is shown below to help understand the point at 1141 which the DTLS states transition. In the normal case, the DTLS 1142 handshake will proceed as follows (NOTE: this example uses 1143 certificates, but preshared keys are also supported): 1145 ============ ============ 1146 WTP AC 1147 ============ ============ 1148 ClientHello ------> 1149 <------ HelloVerifyRequest 1150 (with cookie) 1152 ClientHello ------> 1153 (with cookie) 1154 <------ ServerHello 1155 <------ Certificate 1156 <------ ServerHelloDone 1158 (WTP callout for AC authorization 1159 occurs in CAPWAP Auth state) 1161 Certificate* 1162 ClientKeyExchange 1163 CertificateVerify* 1164 [ChangeCipherSpec] 1165 Finished ------> 1167 (AC callout for WTP authorization 1168 occurs in CAPWAP Auth state) 1170 [ChangeCipherSpec] 1171 <------ Finished 1173 DTLS, as specified, provides its own retransmit timers with an 1174 exponential back-off. However, DTLS will never terminate the 1175 handshake due to non-responsiveness; instead, DTLS will continue to 1176 increase its back-off timer period. Hence, timing out incomplete 1177 DTLS handshakes is entirely the responsiblity of the CAPWAP module. 1179 The DTLS implementation used by CAPWAP MUST support TLS Session 1180 Resumption. Session resumption is used to establish the DTLS session 1181 used for the data channel. The DTLS implementation on the WTP MUST 1182 return some unique identifier to the CAPWAP module to enable 1183 subsequent establishment of a DTLS-encrypted data channel, if 1184 necessary. 1186 2.4.2. DTLS Session Establishment 1188 The WTP, either through the Discovery process, or through pre- 1189 configuration, determines the AC to connect to. The WTP uses the 1190 DTLSStart command to request that a secure connection be established 1191 to the selected AC. Prior to initiation of the DTLS handshake, the 1192 WTP sets the WaitDTLS timer. Upon receiving the DTLSPeerAuthorize 1193 DTLS notification, the AC sets the WaitDTLS timer. If the 1194 DTLSEstablished notification is not received prior to timer 1195 expiration, the DTLS session is aborted by issuing the 1196 DTLSAbortSession DTLS command. This notification causes the CAPWAP 1197 module to transition to the Idle state. Upon receiving a 1198 DTLSEstablished notification, the WaitDTLS timer is deactivated. 1200 2.4.3. DTLS Error Handling 1202 If the AC does not respond to any DTLS messages sent by the WTP, the 1203 DTLS specification calls for the WTP to retransmit these messages. 1204 If the WaitDTLS timer expires, CAPWAP will issue the DTLSAbortSession 1205 command, causing DTLS to terminate the handshake and remove any 1206 allocated session context. Note that DTLS MAY send a single TLS 1207 Alert message to the AC to indicate session termination. 1209 If the WTP does not respond to any DTLS messages sent by the AC, the 1210 CAPWAP protocol allows for three possiblities, listed below. Note 1211 that DTLS MAY send a single TLS Alert message to the AC to indicate 1212 session termination. 1214 o The message was lost in transit; in this case, the WTP will re- 1215 transmit its last outstanding message, since it did not receive a 1216 reply. 1218 o The WTP sent a DTLS Alert, which was lost in transit; in this 1219 case, the AC's WaitDTLS timer will expire, and the session will be 1220 terminated. 1222 o Communication with the WTP has completely failed; in this case, 1223 the AC's WaitDTLS timer will expire, and the session will be 1224 terminated. 1226 The DTLS specification provides for retransmission of unacknowledged 1227 requests. If retransmissions remain unacknowledged, the WaitDTLS 1228 timer will eventually expire, at which time the CAPWAP component will 1229 terminate the session. 1231 If a cookie fails to validate, this could represent a WTP error, or 1232 it could represent a DoS attack. Hence, AC resource utilization 1233 SHOULD be minimized. The AC MAY log a message indicating the 1234 failure, but SHOULD NOT attempt to reply to the WTP. 1236 Since DTLS handshake messages are potentially larger than the maximum 1237 record size, DTLS supports fragmenting of handshake messages across 1238 multiple records. There are several potential causes of re-assembly 1239 errors, including overlapping and/or lost fragments. The DTLS 1240 component MUST send a DTLSReassemblyFailure notification to the 1241 CAPWAP component. Whether precise information is given along with 1242 notification is an implementation issue, and hence is beyond the 1243 scope of this document. Upon receipt of such an error, the CAPWAP 1244 component SHOULD log an appropriate error message. Whether 1245 processing continues or the DTLS session is terminated is 1246 implementation dependent. 1248 DTLS decapsulation errors consist of three types: decryption errors, 1249 authentication errors, and malformed DTLS record headers. Since DTLS 1250 authenticates the data prior to encapsulation, if decryption fails, 1251 it is difficult to detect this without first attempting to 1252 authenticate the packet. If authentication fails, a decryption error 1253 is also likely, but not guaranteed. Rather than attempt to derive 1254 (and require the implementation of) algorithms for detecting 1255 decryption failures, decryption failures are reported as 1256 authentication failures. The DTLS component MUST provide a 1257 DTLSDecapFailure notification to the CAPWAP component when such 1258 errors occur. If a malformed DTLS record header is detected, the 1259 packets SHOULD be silently discarded, and the receiver MAY log an 1260 error message. 1262 There is currently only one encapsulation error defined: MTU 1263 exceeded. As part of DTLS session establishment, the CAPWAP 1264 component informs the DTLS component of the MTU size. This may be 1265 dynamically modified at any time when the CAPWAP component sends the 1266 DTLSMtuUpdate command to the DTLS component (see Section 2.3.2.1). 1267 The DTLS component returns this notification to the CAPWAP component 1268 whenever a transmission request will result in a packet which exceeds 1269 the MTU. 1271 2.4.4. DTLS EndPoint Authentication and Authorization 1273 DTLS supports endpoint authentication with certificates or preshared 1274 keys. The TLS algorithm suites for each endpoint authentication 1275 method are described below. 1277 2.4.4.1. Authenticating with Certificates 1279 Note that only block ciphers are currently recommended for use with 1280 DTLS. To understand the reasoning behind this, see [17]. At 1281 present, the following algorithms MUST be supported when using 1282 certificates for CAPWAP authentication: 1284 o TLS_RSA_WITH_AES_128_CBC_SHA 1286 The following algorithms SHOULD be supported when using certificates: 1288 o TLS_DH_RSA_WITH_AES_128_CBC_SHA 1290 The following algorithms MAY be supported when using certificates: 1292 o TLS_RSA_WITH_AES_256_CBC_SHA 1294 o TLS_DH_RSA_WITH_AES_256_CBC_SHA 1296 2.4.4.2. Authenticating with Preshared Keys 1298 Pre-shared keys present significant challenges from a security 1299 perspective, and for that reason, their use is strongly discouraged. 1300 Several methods for authenticating with preshared keys are defined 1301 [6], and we focus on the following two: 1303 o PSK key exchange algorithm - simplest method, ciphersuites use 1304 only symmetric key algorithms 1306 o DHE_PSK key exchange algorithm - use a PSK to authenticate a 1307 Diffie-Hellman exchange. These ciphersuites give some additional 1308 protection against dictionary attacks and also provide Perfect 1309 Forward Secrecy (PFS). 1311 The first approach (plain PSK) is susceptible to passive dictionary 1312 attacks; hence, while this alorithm MUST be supported, special care 1313 should be taken when choosing that method. In particular, user- 1314 readable passphrases SHOULD NOT be used, and use of short PSKs SHOULD 1315 be strongly discouraged. 1317 The following cryptographic algorithms MUST be supported when using 1318 preshared keys: 1320 o TLS_PSK_WITH_AES_128_CBC_SHA 1322 o TLS_DHE_PSK_WITH_AES_128_CBC_SHA 1324 The following algorithms MAY be supported when using preshared keys: 1326 o TLS_PSK_WITH_AES_256_CBC_SHA 1328 o TLS_DHE_PSK_WITH_AES_256_CBC_SHA 1330 2.4.4.3. Certificate Usage 1332 Certificate authorization by the AC and WTP is required so that only 1333 an AC may perform the functions of an AC and that only a WTP may 1334 perform the functions of a WTP. This restriction of functions to the 1335 AC or WTP requires that the certificates used by the AC MUST be 1336 distinguishable from the certificate used by the WTP. To accomplish 1337 this differentiation, the x.509 certificates MUST include the 1338 Extended Key Usage (EKU) certificate extension [4]. 1340 The EKU field indicates one or more purposes for which a certificate 1341 may be used. It is an essential part in authorization. Its syntax 1342 is as follows: 1344 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 1346 KeyPurposeId ::= OBJECT IDENTIFIER 1348 Here we define two KeyPurposeId values, one for the WTP and one for 1349 the AC. Inclusion of one of these two values indicates a certificate 1350 is authorized for use by a WTP or AC, respectively. These values are 1351 formatted as id-kp fields. 1353 id-kp OBJECT IDENTIFIER ::= 1354 { iso(1) identified-organization(3) dod(6) internet(1) 1355 security(5) mechanisms(5) pkix(7) 3 } 1357 id-kp-capwapAC OBJECT IDENTIFIER ::= { id-kp 18 } 1359 id-kp-capwapWTP OBJECT IDENTIFIER ::= { id-kp 19 } 1361 For an AC, the id-kp-capwapAC EKU MUST be present in the certificate. 1362 For a WTP, the id-kp-capwapWTP EKU MUST be present in the 1363 certificate. 1365 Part of the CAPWAP certificate validation process includes ensuring 1366 that the proper EKU is included and allowing the CAPWAP session to be 1367 established only if the extension properly represents the device. 1369 The certificate common name (CN) for both the WTP and AC MUST be the 1370 MAC address of that device. The MAC address MUST be formatted as 1371 ASCII HEX, e.g. 01:23:45:67:89:ab. 1373 ACs and WTPs SHOULD authorize (e.g. through access control lists) 1374 certificates of devices to which they are connecting, based on the 1375 MAC address and organizational information specified in the O and OU 1376 fields. The identities specified in the certificates bind a 1377 particular DTLS session to a specific pair of mutually-authenticated 1378 and authorized MAC addresses. 1380 2.4.4.4. PSK Usage 1382 When DTLS uses PSK Ciphersuites, the ServerKeyExchange message MUST 1383 contain the "PSK identity hint" field and the ClientKeyExchange 1384 message MUST contain the "PSK identity" field. These fields are used 1385 to help the WTP select the appropriate PSK for use with the AC, and 1386 then indicate to the AC which key is being used. When PSKs are 1387 provisioned to WTPs and ACs, both the PSK Hint and PSK Identity for 1388 the key MUST be specified. 1390 The PSK Hint SHOULD uniquely identify the AC and the PSK Identity 1391 SHOULD uniquely identify the WTP. It is RECOMMENDED that these hints 1392 and identities be the ASCII HEX-formatted MAC addresses of the 1393 respective devices, since each pairwise combination of WTP and AC 1394 SHOULD have a unique PSK. The PSK hint and identity SHOULD be 1395 sufficient to perform authorization, as simply having knowledge of a 1396 PSK does not necessarily imply authorization. 1398 If a single PSK is being used for multiple devices on a CAPWAP 1399 network, which is NOT RECOMMENDED, the PSK Hint and Identity can no 1400 longer be a MAC address, so appropriate hints and identities SHOULD 1401 be selected to identify the group of devices to which the PSK is 1402 provisioned. 1404 3. CAPWAP Transport 1406 Communication between a WTP and an AC is established using the 1407 standard UDP client/server model. The CAPWAP protocol supports both 1408 UDP and UDP-Lite [11] transport protocols. The UDP protocol is used 1409 with IPv4. When CAPWAP is used over IPv6, the UDP-Lite protocol is 1410 used. This section describes how the CAPWAP protocol is carried over 1411 IP and UDP/UDP-Lite transport protocols. 1413 3.1. UDP Transport 1415 One of the CAPWAP protocol requirements is to allow a WTP to reside 1416 behind a firewall and/or Network Address Translation (NAT) device. 1417 Since a CAPWAP session is initiated by the WTP (client) to the well- 1418 known UDP port of the AC (server), the use of UDP is a logical 1419 choice. The UDP checksum field in CAPWAP packets MUST be set to 1420 zero. 1422 CAPWAP protocol control packets sent from the WTP to the AC use the 1423 CAPWAP control channel, as defined in Section 1.4. The CAPWAP 1424 control port at the AC is the well known UDP port [to be IANA 1425 assigned]. The CAPWAP control port at the WTP can be any port 1426 selected by the WTP. 1428 CAPWAP protocol data packets sent from the WTP to the AC use the 1429 CAPWAP data channel, as defined in Section 1.4. The CAPWAP data port 1430 at the AC is the well known UDP port [to be IANA assigned]. The 1431 CAPWAP data port at the WTP can be any port selected by the WTP. 1433 3.2. UDP-Lite Transport 1435 When CAPWAP is run over IPv6, UDP-Lite is used as the transport 1436 protocol, reducing the checksum processing required for each packet 1437 (compared to UDP and IPv6). When UDP-Lite is used, the checksum 1438 field MUST have a coverage of 8 [11]. 1440 UDP-Lite uses the same port assignments as UDP. 1442 3.3. AC Discovery 1444 The AC discovery phase allows the WTP to determine which ACs are 1445 available, and chose the best AC with which to establish a CAPWAP 1446 session. The discovery phase occurs when the WTP enters the optional 1447 Discovery state. A WTP does not need to complete the AC Discovery 1448 phase if it uses a pre-configured AC. This section details the 1449 mechanism used by a WTP to dynamically discover candidate ACs. 1451 A WTP and an AC will frequently not reside in the same IP subnet 1452 (broadcast domain). When this occurs, the WTP must be capable of 1453 discovering the AC, without requiring that multicast services are 1454 enabled in the network. 1456 When the WTP attempts to establish communication with an AC, it sends 1457 the Discovery Request message and receives the Discovery Response 1458 message from the AC(s). The WTP MUST send the Discovery Request 1459 message to either the limited broadcast IP address (255.255.255.255), 1460 a well known multicast address or to the unicast IP address of the 1461 AC. For IPv6 networks, since broadcast does not exist, the use of 1462 "All ACs multicast address" is used instead. Upon receipt of the 1463 Discovery Request message, the AC sends a Discovery Response message 1464 to the unicast IP address of the WTP, regardless of whether the 1465 Discovery Request message was sent as a broadcast, multicast or 1466 unicast message. 1468 WTP use of a limited IP broadcast, multicast or unicast IP address is 1469 implementation dependent. 1471 When a WTP transmits a Discovery Request message to a unicast 1472 address, the WTP must first obtain the IP address of the AC. Any 1473 static configuration of an AC's IP address on the WTP non-volatile 1474 storage is implementation dependent. However, additional dynamic 1475 schemes are possible, for example: 1477 DHCP: See [13] for more information on the use of DHCP to discover 1478 AC IP addresses. 1480 DNS: The DNS name "CAPWAP-AC-Address" MAY be resolvable to one or 1481 more AC addresses. 1483 An AC MAY also communicate alternative ACs to the WTP within the 1484 Discovery Response message through the AC IPv4 List (see 1485 Section 4.6.2) and AC IPv6 List (see Section 4.6.2). The addresses 1486 provided in these two message elements are intended to help the WTP 1487 discover additional ACs through means other than those listed above. 1489 The AC Name with Index message element (see Section 4.6.5), is used 1490 to communicate a list of preferred ACs to the WTP. The WTP SHOULD 1491 attempt to utilize the ACs listed in the order provided by the AC. 1492 The Name to IP Address mapping is handled via the Discovery message 1493 exchange, in which the ACs provide their identity in the AC Name (see 1494 Section 4.6.4) message element in the Discovery Response message. 1496 Once the WTP has received Discovery Response messages from the 1497 candidate ACs, it MAY use other factors to determine the preferred 1498 AC. For instance, each binding defines a WTP Radio Information 1499 message element (see Section 2.1), which the AC includes in Discovery 1500 Response messages. The presence of one or more of these message 1501 elements is used to identify the CAPWAP bindings supported by the AC. 1502 A WTP MAY connect to an AC based on the supported bindings 1503 advertised. 1505 3.4. Fragmentation/Reassembly 1507 While fragmentation and reassembly services are provided by IP, the 1508 CAPWAP protocol also provides such services. Environments where the 1509 CAPWAP protocol is used involve firewall, NAT and "middle box" 1510 devices, which tend to drop IP fragments to minimize possible DoS 1511 attacks. By providing fragmentation and reassembly at the 1512 application layer, any fragmentation required due to the tunneling 1513 component of the CAPWAP protocol becomes transparent to these 1514 intermediate devices. Consequently, the CAPWAP protocol can be used 1515 in any network configuration. 1517 4. CAPWAP Packet Formats 1519 This section contains the CAPWAP protocol packet formats. A CAPWAP 1520 protocol packet consists of one or more CAPWAP Transport Layer packet 1521 headers followed by a CAPWAP message. The CAPWAP message can be 1522 either of type Control or Data, where Control packets carry 1523 signaling, and Data packets carry user payloads. The CAPWAP frame 1524 formats for CAPWAP Data packets, and for DTLS encapsulated CAPWAP 1525 Data and Control packets are defined below. 1527 The CAPWAP Control protocol includes two messages that are never 1528 protected by DTLS: the Discovery Request message and the Discovery 1529 Response message. These messages need to be in the clear to allow 1530 the CAPWAP protocol to properly identify and process them. The 1531 format of these packets are as follows: 1533 CAPWAP Control Packet (Discovery Request/Response): 1534 +-------------------------------------------+ 1535 | IP | UDP | CAPWAP | Control | Message | 1536 | Hdr | Hdr | Header | Header | Element(s) | 1537 +-------------------------------------------+ 1539 All other CAPWAP control protocol messages MUST be protected via the 1540 DTLS protocol, which ensures that the packets are both authenticated 1541 and encrypted. These packets include the CAPWAP DTLS Header, which 1542 is described in Section 4.2. The format of these packets is as 1543 follows: 1545 CAPWAP Control Packet (DTLS Security Required): 1546 +------------------------------------------------------------------+ 1547 | IP | UDP | CAPWAP | DTLS | CAPWAP | Control| Message | DTLS | 1548 | Hdr | Hdr | DTLS Hdr | Hdr | Header | Header | Element(s)| Trlr | 1549 +------------------------------------------------------------------+ 1550 \---------- authenticated -----------/ 1551 \------------- encrypted ------------/ 1553 The CAPWAP protocol allows optional protection of data packets, using 1554 DTLS. Use of data packet protection is determined by AC policy. 1555 When DTLS is utilized, the optional CAPWAP DTLS Header is present, 1556 which is described in Section 4.2. The format of CAPWAP data packets 1557 is shown below: 1559 CAPWAP Plain Text Data Packet : 1560 +-------------------------------+ 1561 | IP | UDP | CAPWAP | Wireless | 1562 | Hdr | Hdr | Header | Payload | 1563 +-------------------------------+ 1565 DTLS Secured CAPWAP Data Packet: 1566 +--------------------------------------------------------+ 1567 | IP | UDP | CAPWAP | DTLS | CAPWAP | Wireless | DTLS | 1568 | Hdr | Hdr | DTLS Hdr | Hdr | Hdr | Payload | Trlr | 1569 +--------------------------------------------------------+ 1570 \------ authenticated -----/ 1571 \------- encrypted --------/ 1573 UDP Header: All CAPWAP packets are encapsulated within either UDP, 1574 or UDP-Lite when used over IPv6. Section 3 defines the specific 1575 UDP or UDP-Lite usage. 1577 CAPWAP DTLS Header: All DTLS encrypted CAPWAP protocol packets are 1578 prefixed with the CAPWAP DTLS header (see Section 4.2). 1580 DTLS Header: The DTLS header provides authentication and encryption 1581 services to the CAPWAP payload it encapsulates. This protocol is 1582 defined in RFC 4347 [8]. 1584 CAPWAP Header: All CAPWAP protocol packets use a common header that 1585 immediately follows the CAPWAP preamble or DTLS header. The 1586 CAPWAP Header is defined in Section 4.3. 1588 Wireless Payload: A CAPWAP protocol packet that contains a wireless 1589 payload is a CAPWAP data packet. The CAPWAP protocol does not 1590 specify the format of the wireless payload, which is defined by 1591 the appropriate wireless standard. Additional information is in 1592 Section 4.4. 1594 Control Header: The CAPWAP protocol includes a signalling component, 1595 known as the CAPWAP control protocol. All CAPWAP control packets 1596 include a Control Header, which is defined in Section 4.5.1. 1597 CAPWAP data packets do not contain a Control Header field. 1599 Message Elements: A CAPWAP Control packet includes one or more 1600 message elements, which are found immediately following the 1601 Control Header. These message elements are in a Type/Length/value 1602 style header, defined in Section 4.6. 1604 A CAPWAP implementation MUST be capable of receiving a reassembled 1605 CAPWAP message of length 4096 bytes. A CAPWAP implementation MAY 1606 indicate that it supports a higher maximum message length, by 1607 including the Maximum Message Length message element, see 1608 Section 4.6.29 in the Join Request message or the Join Response 1609 message. 1611 4.1. CAPWAP Preamble 1613 The CAPWAP preamble is common to all CAPWAP transport headers and is 1614 used to identify the header type that immediately follows. The 1615 reason for this header is to avoid needing to perform byte 1616 comparisons in order to guess whether the frame is DTLS encrypted or 1617 not. It also provides an extensibility framework that can be used to 1618 support additional transport types. The format of the preamble is as 1619 follows: 1621 0 1622 0 1 2 3 4 5 6 7 1623 +-+-+-+-+-+-+-+-+ 1624 |Version| Type | 1625 +-+-+-+-+-+-+-+-+ 1627 Version: A 4 bit field which contains the version of CAPWAP used in 1628 this packet. The value for this specification is zero (0). 1630 Payload Type: A 4 bit field which specifies the payload type that 1631 follows the UDP header. The following values are supported: 1633 0 - CAPWAP Header. The CAPWAP Header (see Section 4.3) 1634 immediately follows the UDP header. If the packet is received 1635 on the CAPWAP data channel, the CAPWAP stack MUST treat the 1636 packet as a clear text CAPWAP data packet. If received on the 1637 CAPWAP control channel, the CAPWAP stack MUST treat the packet 1638 as a clear text CAPWAP control packet. If the control packet 1639 is not a Discovery Request or Discovery Response packet, the 1640 packet MUST be dropped. 1642 1 - CAPWAP DTLS Header. The CAPWAP DTLS Header, and DTLS packet, 1643 immediately follows the UDP header (see Section 4.2). 1645 4.2. CAPWAP DTLS Header 1647 The CAPWAP DTLS Header is used to identify the packet as a DTLS 1648 encrypted packet. The first eight bits includes the common CAPWAP 1649 Preamble. The remaining 24 bits are padding to ensure 4 byte 1650 alignment, and MAY be used in a future version of the protocol. The 1651 DTLS packet [8] always immediately follows this header. The format 1652 of the CAPWAP DTLS Header is as follows: 1654 0 1 2 3 1655 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 1656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1657 |CAPWAP Preamble| Reserved | 1658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1660 CAPWAP Preamble: The CAPWAP Preamble is defined in Section 4.1. The 1661 CAPWAP Preamble's Payload Type field MUST be set to one (1). 1663 Reserved: The 24-bit field is reserved for future use. All 1664 implementations complying with this protocol MUST set to zero any 1665 bits that are reserved in the version of the protocol supported by 1666 that implementation. Receivers MUST ignore all bits not defined 1667 for the version of the protocol they support. 1669 4.3. CAPWAP Header 1671 All CAPWAP protocol messages are encapsulated using a common header 1672 format, regardless of the CAPWAP Control or CAPWAP Data transport 1673 used to carry the messages. However, certain flags are not 1674 applicable for a given transport. Refer to the specific transport 1675 section in order to determine which flags are valid. 1677 Note that the optional fields defined in this section MUST be present 1678 in the precise order shown below. 1680 0 1 2 3 1681 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 1682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1683 |CAPWAP Preamble| HLEN | RID | WBID |T|F|L|W|M|K|Flags | 1684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1685 | Fragment ID | Frag Offset |Rsvd | 1686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1687 | (optional) Radio MAC Address | 1688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1689 | (optional) Wireless Specific Information | 1690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1691 | Payload .... | 1692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1694 CAPWAP Preamble: The CAPWAP Preamble is defined in Section 4.1. The 1695 CAPWAP Preamble's Payload Type field MUST be set to zero (0). If 1696 the CAPWAP DTLS Header is present, the version number in both 1697 CAPWAP Preambles MUST match. The reason for this duplicate field 1698 is to avoid any possible tampering of the version field in the 1699 preamble which is not encrypted or authenticated. 1701 HLEN: A 5 bit field containing the length of the CAPWAP transport 1702 header in 4 byte words (Similar to IP header length). This length 1703 includes the optional headers. 1705 RID: A 5 bit field which contains the Radio ID number for this 1706 packet. Given that MAC Addresses are not necessarily unique 1707 across physical radios in a WTP, the Radio Identifier (RID) field 1708 is used to indiciate which physical radio the message is 1709 associated with. 1711 WBID: A 5 bit field which is the wireless binding identifier. The 1712 identifier will indicate the type of wireless packet type 1713 associated with the radio. The following values are defined: 1715 1 - IEEE 802.11 1717 2 - IEEE 802.16 1719 3 - EPCGlobal 1721 T: The Type 'T' bit indicates the format of the frame being 1722 transported in the payload. When this bit is set to one (1), the 1723 payload has the native frame format indicated by the WBID field. 1724 When this bit is zero (0) the payload is an IEEE 802.3 frame. 1726 F: The Fragment 'F' bit indicates whether this packet is a fragment. 1727 When this bit is one (1), the packet is a fragment and MUST be 1728 combined with the other corresponding fragments to reassemble the 1729 complete information exchanged between the WTP and AC. 1731 L: The Last 'L' bit is valid only if the 'F' bit is set and indicates 1732 whether the packet contains the last fragment of a fragmented 1733 exchange between WTP and AC. When this bit is 1, the packet is 1734 the last fragment. When this bit is 0, the packet is not the last 1735 fragment. 1737 W: The Wireless 'W' bit is used to specify whether the optional 1738 Wireless Specific Information field is present in the header. A 1739 value of one (1) is used to represent the fact that the optional 1740 header is present. 1742 M: The M bit is used to indicate that the Radio MAC Address optional 1743 header is present. This is used to communicate the MAC address of 1744 the receiving radio. 1746 K: The 'Keep-alive' K bit indicates the packet is a Data Channel Keep 1747 Alive packet. This packet is used to map the data channel to the 1748 control channel for the specified Session ID and to maintain 1749 freshness of the data channel. The K bit MUST NOT be set for data 1750 packets containing user data. 1752 Flags: A set of reserved bits for future flags in the CAPWAP header. 1753 All implementations complying with this protocol MUST set to zero 1754 any bits that are reserved in the version of the protocol 1755 supported by that implementation. Receivers MUST ignore all bits 1756 not defined for the version of the protocol they support. 1758 Fragment ID: A 16 bit field whose value is assigned to each group of 1759 fragments making up a complete set. The fragment ID space is 1760 managed individually for every WTP/AC pair. The value of Fragment 1761 ID is incremented with each new set of fragments. The Fragment ID 1762 wraps to zero after the maximum value has been used to identify a 1763 set of fragments. 1765 Fragment Offset: A 13 bit field that indicates where in the payload 1766 this fragment belongs during re-assembly. This field is valid 1767 when the 'F' bit is set to 1. The fragment offset is measured in 1768 units of 8 octets (64 bits). The first fragment has offset zero. 1769 Note the CAPWAP protocol does not allow for overlapping fragments. 1771 Reserved: The 3-bit field is reserved for future use. All 1772 implementations complying with this protocol MUST set to zero any 1773 bits that are reserved in the version of the protocol supported by 1774 that implementation. Receivers MUST ignore all bits not defined 1775 for the version of the protocol they support. 1777 Radio MAC Address: This optional field contains the MAC address of 1778 the radio receiving the packet. This is useful in packets sent 1779 from the WTP to the AC, when the native wireless frame format is 1780 converted to 802.3 by the WTP. This field is only present if the 1781 'M' bit is set. The HLEN field assumes 4 byte alignment, and this 1782 field MUST be padded with zeroes (0x00) if it is not 4 byte 1783 aligned. 1785 The field contains the basic format: 1787 0 1 2 3 1788 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 1789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1790 | Length | MAC Address 1791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1793 Length: The length of the MAC Address field [18] [19]. 1795 MAC Address: The MAC Address of the receiving radio. 1797 Wireless Specific Information: This optional field contains 1798 technology specific information that may be used to carry per 1799 packet wireless information. This field is only present if the 1800 'W' bit is set. The HLEN field assumes 4 byte alignment, and this 1801 field MUST be padded with zeroes (0x00) if it is not 4 byte 1802 aligned. 1804 The Wireless Specific Information field uses the following format: 1806 0 1 2 3 1807 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 1808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1809 | Wireless ID | Length | Data 1810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1812 Wireless ID: The wireless binding identifier. The following 1813 values are defined: 1815 1 - IEEE 802.11 1817 2 - IEEE 802.16 1819 3 - EPCGlobal 1821 Length: The length of the data field 1823 Data: Wireless specific information, defined by the wireless 1824 specific binding. 1826 Payload: This field contains the header for a CAPWAP Data Message or 1827 CAPWAP Control Message, followed by the data contained in the 1828 message. 1830 4.4. CAPWAP Data Messages 1832 There are two different types of CAPWAP data packets, CAPWAP Data 1833 Channel Keep Alive packets and Data Payload packets. The first is 1834 used by the WTP to synchronize the control and data channels, and to 1835 maintain freshness of the data channel. The second is used to 1836 transmit user payloads between the AC and WTP. This section 1837 describes both types of CAPWAP data packet formats. 1839 Both CAPWAP data messages are transmitted on the CAPWAP data channel. 1841 4.4.1. CAPWAP Data Keepalive 1843 The CAPWAP Data Channel Keep Alive packet is used to bind the CAPWAP 1844 control channel with the data channel, and to maintain freshness of 1845 the data channel, ensuring that the channel is still functioning. 1846 The CAPWAP Data Channel Keep Alive packet is transmitted by the WTP 1847 when the DataChannelKeepAlive timer expires. When the CAPWAP Data 1848 Channel Keep Alive packet is transmitted, the WTP sets the 1849 DataChannelDeadInterval timer. 1851 In the CAPWAP Data Channel Keep Alive packet, all of the fields in 1852 the CAPWAP header, except the HLEN field and the K bit, are set to 1853 zero upon transmission. Upon receiving a CAPWAP Data Channel Keep 1854 Alive packet, the AC transmits a CAPWAP Data Channel Keep Alive 1855 packet back to the WTP. The contents of the transmitted packet are 1856 identical to the contents of the received packet. 1858 Upon receiving a CAPWAP Data Channel Keep Alive packet, the WTP 1859 cancels the DataChannelDeadInterval timer and resets the 1860 DataChannelKeepAlive timer. The CAPWAP Data Channel Keep Alive 1861 packet is retransmitted by the WTP in the same manner as the CAPWAP 1862 control messages. If the DataChannelDeadInterval timer expires, the 1863 WTP tears down the control DTLS session, and the data DTLS session if 1864 one existed. 1866 The CAPWAP Data Channel Keep Alive packet contains the following 1867 payload immediately following the CAPWAP Header (see Section 4.3) 1869 0 1 2 3 1870 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 1871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1872 | Message Element Length | Message Element [0..N] ... 1873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1875 Message Element Length: The Length field indicates the number of 1876 bytes following the CAPWAP Header. 1878 Message Element[0..N]: The message element(s) carry the information 1879 pertinent to each of the CAPWAP Data Keepalive message. The 1880 following message elements MUST be present in this CAPWAP message: 1882 Session ID, see Section 4.6.35 1884 4.4.2. Data Payload 1886 A CAPWAP protocol Data Payload packet encapsulates a forwarded 1887 wireless frame. The CAPWAP protocol defines two different modes of 1888 encapsulation; IEEE 802.3 and native wireless. IEEE 802.3 1889 encapsulation requires that the bridging function be performed in the 1890 WTP. An IEEE 802.3 encapsulated user payload frame has the following 1891 format: 1893 +------------------------------------------------------+ 1894 | IP Header | UDP Header | CAPWAP Header | 802.3 Frame | 1895 +------------------------------------------------------+ 1897 The CAPWAP protocol also defines the native wireless encapsulation 1898 mode. The format of the encapsulated CAPWAP data frame is subject to 1899 the rules defined by the specific wireless technology binding. Each 1900 wireless technology binding MUST contain a section entitled "Payload 1901 Encapsulation", which defines the format of the wireless payload that 1902 is encapsulated within CAPWAP Data packets. 1904 If the encapsulated frame would exceed the transport layer's MTU, the 1905 sender is responsible for fragmentation of the frame, as specified in 1906 Section 3.4. 1908 4.4.3. Establishment of a DTLS Data Channel 1910 If the AC and WTP are configured to tunnel the data channel over 1911 DTLS, the proper DTLS session must be initiated. To avoid having to 1912 reauthenticate and reauthorize an AC and WTP, the DTLS data channel 1913 MUST be initiated using the TLS session resumption feature [7]. 1915 When establishing the DTLS-encrypted data channel, the WTP MUST 1916 provide the identifier returned during the initialization of the 1917 control channel to the DTLS component so it can perform the 1918 resumption using the proper session information. 1920 The AC DTLS implementation MUST NOT accept a session resumption 1921 request for a DTLS session in which the control channel for the 1922 session has been torn down. 1924 4.5. CAPWAP Control Messages 1926 The CAPWAP Control protocol provides a control channel between the 1927 WTP and the AC. Control messages are divided into the following 1928 message types: 1930 Discovery: CAPWAP Discovery messages are used to identify potential 1931 ACs, their load and capabilities. 1933 Join: CAPWAP Join messages are used by a WTP to request service from 1934 an AC, and for the AC to respond to the WTP. 1936 Control Channel Management: CAPWAP control channel management 1937 messages are used to maintain the control channel. 1939 WTP Configuration Management: The WTP Configuration messages are 1940 used by the AC to deliver a specific configuration to the WTP. 1941 Messages which retrieve statistics from a WTP are also included in 1942 WTP Configuration Management. 1944 Station Session Management: Station Session Management messages are 1945 used by the AC to deliver specific station policies to the WTP. 1947 Device Management Operations: Device management operations are used 1948 to request and deliver a firmware image to the WTP. 1950 Binding Specific CAPWAP Management Messages: Messages in this 1951 category are used by the AC and the WTP to exchange protocol- 1952 specific CAPWAP management messages. These messages may or may 1953 not be used to change the link state of a station. 1955 Discovery, Join, Control Channel Management, WTP Configuration 1956 Management and Station Session Management CAPWAP control messages 1957 MUST be implemented. Device Management Operations messages MAY be 1958 implemented. 1960 CAPWAP control messages sent from the WTP to the AC indicate that the 1961 WTP is operational, providing an implicit keep-alive mechanism for 1962 the WTP. The Control Channel Management Echo Request and Echo 1963 Response messages provide an explicit keep-alive mechanism when other 1964 CAPWAP control messages are not exchanged. 1966 4.5.1. Control Message Format 1968 All CAPWAP control messages are sent encapsulated within the CAPWAP 1969 header (see Section 4.3). Immediately following the CAPWAP header, 1970 is the control header, which has the following format: 1972 0 1 2 3 1973 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 1974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1975 | Message Type | 1976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1977 | Seq Num | Msg Element Length | Flags | 1978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1979 | Msg Element [0..N] ... 1980 +-+-+-+-+-+-+-+-+-+-+-+-+ 1982 4.5.1.1. Message Type 1984 The Message Type field identifies the function of the CAPWAP control 1985 message. The Message Type field is comprised of an IANA Enterprise 1986 Number and an enterprise specific message type number. The first 1987 three octets contain the enterprise number in network byte order, 1988 with zero used for CAPWAP protocol defined message types and the IEEE 1989 802.11 IANA assigned enterprise number 13277 is used for IEEE 802.11 1990 technology specific message types. The last octet is the enterprise 1991 specific message type number, which has a range from 0 to 255. 1993 The message type field is defined as: 1995 Message Type = 1996 IANA Enterprise Number * 256 + 1997 Enterprise Specific Message Type Number 1999 The CAPWAP protocol reliability mechanism requires that messages be 2000 defined in pairs, consisting of both a Request and a Response 2001 message. The Response message MUST acknowledge the Request message. 2002 The assignment of CAPWAP control Message Type Values always occurs in 2003 pairs. All Request messages have odd numbered Message Type Values, 2004 and all Response messages have even numbered Message Type Values. 2005 The Request value MUST be assigned first. As an example, assigning a 2006 Message Type Value of 3 for a Request message and 4 for a Response 2007 message is valid, while assigning a Message Type Value of 4 for a 2008 Response message and 5 for the corresponding Request message is 2009 invalid. 2011 When a WTP or AC receives a message with a Message Type Value field 2012 that is not recognized and is an odd number, the number in the 2013 Message Type Value Field is incremented by one, and a Response 2014 message with a Message Type Value field containing the incremented 2015 value and containing the Result Code message element with the value 2016 (Unrecognized Request) is returned to the sender of the received 2017 message. If the unknown message type is even, the message is 2018 ignored. 2020 The valid values for CAPWAP Control Message Types are specified in 2021 the table below: 2023 CAPWAP Control Message Message Type 2024 Value 2025 Discovery Request 1 2026 Discovery Response 2 2027 Join Request 3 2028 Join Response 4 2029 Configuration Status 5 2030 Configuration Status Response 6 2031 Configuration Update Request 7 2032 Configuration Update Response 8 2033 WTP Event Request 9 2034 WTP Event Response 10 2035 Change State Event Request 11 2036 Change State Event Response 12 2037 Echo Request 13 2038 Echo Response 14 2039 Image Data Request 15 2040 Image Data Response 16 2041 Reset Request 17 2042 Reset Response 18 2043 Primary Discovery Request 19 2044 Primary Discovery Response 20 2045 Data Transfer Request 21 2046 Data Transfer Response 22 2047 Clear Configuration Request 23 2048 Clear Configuration Response 24 2049 Station Configuration Request 25 2050 Station Configuration Response 26 2052 4.5.1.2. Sequence Number 2054 The Sequence Number Field is an identifier value used to match 2055 Request and Response packets. When a CAPWAP packet with a Request 2056 Message Type Value is received, the value of the Sequence Number 2057 field is copied into the corresponding Response message. 2059 When a CAPWAP control message is sent, the sender's internal sequence 2060 number counter is monotonically incremented, ensuring that no two 2061 pending Request messages have the same Sequence Number. The Sequence 2062 Number field wraps back to zero. 2064 4.5.1.3. Message Element Length 2066 The Length field indicates the number of bytes following the Sequence 2067 Number field. 2069 4.5.1.4. Flags 2071 The Flags field MUST be set to zero. 2073 4.5.1.5. Message Element[0..N] 2075 The message element(s) carry the information pertinent to each of the 2076 control message types. Every control message in this specification 2077 specifies which message elements are permitted. 2079 When a WTP or AC receives a CAPWAP message without a message element 2080 that is specified as mandatory for the CAPWAP message, then the 2081 CAPWAP message is discarded. If the received message was a Request 2082 message for which the corresponding Response message carries message 2083 elements, then a corresponding Response message with a Result Code 2084 message element indicating "Failure - Missing Mandatory Message 2085 Element" is returned to the sender. 2087 When a WTP or AC receives a CAPWAP message with a message element 2088 that the WTP or AC does not recognize, the CAPWAP message is 2089 discarded. If the received message was a Request message for which 2090 the corresponding Response message carries message elements, then a 2091 corresponding Response message with a Result Code message element 2092 indicating "Failure - Unrecognized Message Element" and one or more 2093 Returned Message Element message elements is included, containing the 2094 unrecognized message element(s). 2096 4.5.2. Control Message Quality of Service 2098 It is recommended that CAPWAP control messages be sent by both the AC 2099 and the WTP with an appropriate Quality of Service precedence value, 2100 ensuring that congestion in the network minimizes occurrences of 2101 CAPWAP control channel disconnects. Therefore, a Quality of Service 2102 enabled CAPWAP device SHOULD use the following values: 2104 802.1P: The precedence value of 7 SHOULD be used. 2106 DSCP: The DSCP tag value of 46 SHOULD be used. 2108 4.5.3. Retransmissions 2110 The CAPWAP control protocol operates as a reliable transport. For 2111 each Request message, a Response message is defined, which is used to 2112 acknowledge receipt of the Request message. In addition, the control 2113 header Sequence Number field is used to pair the Request and Response 2114 messages (see Section 4.5.1). 2116 Response messages are not explicitly acknowledged, therefore if a 2117 Response message is not received, the original Request message is 2118 retransmitted. Implementations MAY cache Response messages to 2119 respond to a retransmitted Request messages with minimal local 2120 processing. Retransmitted Request messages MUST NOT be altered by 2121 the sender. The sender MUST assume that the original Request message 2122 was processed, but that the Response message was lost. Any 2123 alterations to the original Request message MUST have a new Sequence 2124 Number, and be treated as a new Request message by the receiver. 2126 After transmitting a Request message, the RetransmitInterval (see 2127 Section 4.7) timer and MaxRetransmit (see Section 4.8) variable are 2128 used to determine if the original Request message needs to be 2129 retransmitted. The RetransmitInterval timer is used the first time 2130 the Request is retransmitted. The timer is then doubled every 2131 subsequent time the same Request message is retransmitted, up to 2132 MaxRetransmit but no more than half the EchoInterval timer (see 2133 Section 4.7.5). Response messages are not subject to these timers. 2135 When a Request message is retransmitted, it MUST be re-encrypted via 2136 the DTLS stack. If the peer had received the Request message, and 2137 the corresponding Response message was lost, it is necessary to 2138 ensure that retransmitted Request messages are not identified as 2139 replays by the DTLS stack. Similarly, any cached Response messages 2140 that are retransmitted as a result of receiving a retransmitted 2141 Request message MUST be re-encrypted via DTLS. 2143 Duplicate Response messages, identified by the Sequence Number field 2144 in the CAPWAP control message header, SHOULD be discarded upon 2145 receipt. 2147 4.6. CAPWAP Protocol Message Elements 2149 This section defines the CAPWAP Protocol message elements which are 2150 included in CAPWAP protocol control messages. 2152 Message elements are used to carry information needed in control 2153 messages. Every message element is identified by the Type Value 2154 field, defined below. The total length of the message elements is 2155 indicated in the message element Length field. 2157 All of the message element definitions in this document use a diagram 2158 similar to the one below in order to depict its format. Note that to 2159 simplify this specification, these diagrams do not include the header 2160 fields (Type and Length). The header field values are defined in the 2161 message element descriptions. 2163 Unless otherwise specified, a control message that lists a set of 2164 supported (or expected) message elements MUST not expect the message 2165 elements to be in any specific order. The sender MAY include the 2166 message elements in any order. Unless otherwise noted, one message 2167 element of each type is present in a given control message. 2169 Additional message elements may be defined in separate IETF 2170 documents. 2172 The format of a message element uses the TLV format shown here: 2174 0 1 2 3 2175 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 2176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2177 | Type | Length | 2178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2179 | Value ... | 2180 +-+-+-+-+-+-+-+-+ 2182 The 16 bit Type field identifies the information carried in the Value 2183 field and Length (16 bits) indicates the number of bytes in the Value 2184 field. Type field values are allocated as follows: 2186 Usage Type Values 2188 CAPWAP Protocol Message Elements 1-1023 2189 IEEE 802.11 Message Elements 1024-2047 2190 IEEE 802.16 Message Elements 2048 - 3071 2191 EPCGlobal Message Elements 3072 - 4095 2192 Reserved for Future Use 4096 - 65024 2194 The table below lists the CAPWAP protocol Message Elements and their 2195 Type values. 2197 CAPWAP Message Element Type Value 2199 AC Descriptor 1 2200 AC IPv4 List 2 2201 AC IPv6 List 3 2202 AC Name 4 2203 AC Name with Index 5 2204 AC Timestamp 6 2205 Add MAC ACL Entry 7 2206 Add Station 8 2207 Add Static MAC ACL Entry 9 2208 CAPWAP Control IPV4 Address 10 2209 CAPWAP Control IPV6 Address 11 2210 CAPWAP Timers 12 2211 Data Transfer Data 13 2212 Data Transfer Mode 14 2213 Decryption Error Report 15 2214 Decryption Error Report Period 16 2215 Delete MAC ACL Entry 17 2216 Delete Station 18 2217 Delete Static MAC ACL Entry 19 2218 Discovery Type 20 2219 Duplicate IPv4 Address 21 2220 Duplicate IPv6 Address 22 2221 Idle Timeout 23 2222 Image Data 24 2223 Image Identifier 25 2224 Image Info 26 2225 Initiate Download 27 2226 Location Data 28 2227 Maximum Message Length 29 2228 MTU Discovery Padding 30 2229 Radio Administrative State 31 2230 Radio Operational State 32 2231 Result Code 33 2232 Returned Message Element 34 2233 Session ID 35 2234 Statistics Timer 36 2235 Vendor Specific Payload 37 2236 WTP Board Data 38 2237 WTP Descriptor 39 2238 WTP Fallback 40 2239 WTP Frame Tunnel Mode 41 2240 WTP IPv4 IP Address 42 2241 WTP IPv6 IP Address 43 2242 WTP MAC Type 44 2243 WTP Name 45 2244 WTP Operational Statistics 46 2245 WTP Radio Statistics 47 2246 WTP Reboot Statistics 48 2247 WTP Static IP Address Information 49 2249 4.6.1. AC Descriptor 2251 The AC Descriptor message element is used by the AC to communicate 2252 its current state. The value contains the following fields. 2254 0 1 2 3 2255 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 2256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2257 | Stations | Limit | 2258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2259 | Active WTPs | Max WTPs | 2260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2261 | Security | R-MAC Field | Reserved1 | DTLS Policy | 2262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2263 | Vendor Identifier | 2264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2265 | Type=4 | Length | 2266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2267 | Value... 2268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2269 | Vendor Identifier | 2270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2271 | Type=5 | Length | 2272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2273 | Value... 2274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2276 Type: 1 for AC Descriptor 2278 Length: >= 12 2280 Stations: The number of stations currently served by the AC 2282 Limit: The maximum number of stations supported by the AC 2284 Active WTPs: The number of WTPs currently attached to the AC 2286 Max WTPs: The maximum number of WTPs supported by the AC 2288 Security: A 8 bit bit mask specifying the authentication credential 2289 type supported by the AC. The following values are supported (see 2290 Section 2.4.4): 2292 1 - X.509 Certificate Based 2294 2 - Pre-Shared Secret 2296 R-MAC Field: The AC supports the optional Radio MAC Address field 2297 in the CAPWAP transport Header (see Section 4.3). 2299 Reserved: A set of reserved bits for future use. All 2300 implementations complying with this protocol MUST set to zero any 2301 bits that are reserved in the version of the protocol supported by 2302 that implementation. Receivers MUST ignore all bits not defined 2303 for the version of the protocol they support. 2305 DTLS Policy: The AC communicates its policy on the use of DTLS for 2306 the CAPWAP data channel. The AC MAY communicate more than one 2307 supported option, represented by the bit field below. The WTP 2308 MUST abide by one of the options communicated by AC. The 2309 following bit field values are supported: 2311 1 - Clear Text Data Channel Supported 2313 2 - DTLS Enabled Data Channel Supported 2315 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 2316 Network Management Private Enterprise Codes" 2318 Type: Vendor specific encoding of AC information. The following 2319 values are supported. The Hardware and Software Version values 2320 MUST be included. 2322 4 - Hardware Version: The AC's hardware version number. 2324 5 - Software Version: The AC's Software (firmware) version 2325 number. 2327 Length: Length of vendor specific encoding of AC information. 2329 Value: Vendor specific encoding of AC information. 2331 4.6.2. AC IPv4 List 2333 The AC IPv4 List message element is used to configure a WTP with the 2334 latest list of ACs available for the WTP to join. 2336 0 1 2 3 2337 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 2338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2339 | AC IP Address[] | 2340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2342 Type: 2 for AC IPv4 List 2344 Length: >= 4 2346 The AC IP Address: An array of 32-bit integers containing AC IPv4 2347 Addresses. 2349 4.6.3. AC IPv6 List 2351 The AC IPv6 List message element is used to configure a WTP with the 2352 latest list of ACs available for the WTP to join. 2354 0 1 2 3 2355 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 2356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2357 | AC IP Address[] | 2358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2359 | AC IP Address[] | 2360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2361 | AC IP Address[] | 2362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2363 | AC IP Address[] | 2364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2366 Type: 3 for AC IPV6 List 2368 Length: >= 16 2370 The AC IP Address: An array of 128-bit integers containing AC IPv6 2371 Addresses. 2373 4.6.4. AC Name 2375 The AC Name message element contains an UTF-8 representation of the 2376 AC identity. The value is a variable length byte string. The string 2377 is NOT zero terminated. 2379 0 2380 0 1 2 3 4 5 6 7 2381 +-+-+-+-+-+-+-+-+ 2382 | Name ... 2383 +-+-+-+-+-+-+-+-+ 2385 Type: 4 for AC Name 2387 Length: > 0 2389 Name: A variable length UTF-8 encoded string containing the AC's 2390 name 2392 4.6.5. AC Name with Index 2394 The AC Name with Index message element is sent by the AC to the WTP 2395 to configure preferred ACs. The number of instances of this message 2396 element is equal to the number of ACs configured on the WTP. 2398 0 1 2399 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2401 | Index | AC Name... 2402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2404 Type: 5 for AC Name with Index 2406 Length: > 2 2408 Index: The index of the preferred server (1=primary, 2=secondary). 2410 AC Name: A variable length UTF-8 encoded string containing the AC 2411 name. 2413 4.6.6. AC Timestamp 2415 The AC Timestamp message element is sent by the AC to synchronize the 2416 WTP clock. 2418 0 1 2 3 2419 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 2420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2421 | Timestamp | 2422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2424 Type: 6 for AC Timestamp 2426 Length: 4 2428 Timestamp: The AC's current time, allowing all of the WTPs to be 2429 time synchronized in the format defined by Network Time Protocol 2430 (NTP) in RFC 1305 [3]. 2432 4.6.7. Add MAC ACL Entry 2434 The Add MAC Access Control List (ACL) Entry message element is used 2435 by an AC to add a MAC ACL list entry on a WTP, ensuring that the WTP 2436 no longer provides service to the MAC addresses provided in the 2437 message. The MAC Addresses provided in this message element are not 2438 expected to be saved in non-volatile memory on the WTP. 2440 0 1 2 3 2441 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 2442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2443 | Num of Entries| Length | MAC Address ... 2444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2446 Type: 7 for Add MAC ACL Entry 2448 Length: >= 8 2450 Num of Entries: The number of instances of the Type/MAC Addresses 2451 fields in the array. 2453 Length: The length of the MAC Address field. 2455 MAC Address: MAC Addresses to add to the ACL. 2457 4.6.8. Add Station 2459 The Add Station message element is used by the AC to inform a WTP 2460 that it should forward traffic for a station. The Add Station 2461 message element is accompanied by technology specific binding 2462 information element(s) which may include security parameters. 2463 Consequently, the security parameters MUST be applied by the WTP for 2464 the station. 2466 After station policy has been delivered to the WTP through the Add 2467 Station message element, an AC MAY change any policies by sending a 2468 modified Add Station message element. When a WTP receives an Add 2469 Station message element for an existing station, it MUST override any 2470 existing state for the station. 2472 0 1 2 3 2473 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 2474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2475 | Radio ID | Length | MAC Address ... 2476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2477 | VLAN Name... 2478 +-+-+-+-+-+-+-+-+ 2480 Type: 8 for Add Station 2482 Length: >= 8 2484 Radio ID: An 8-bit value representing the radio 2486 Length: The length of the MAC Address field. 2488 MAC Address: The station's MAC Address 2490 VLAN Name: An optional variable length UTF-8 encoded string 2491 containing the VLAN Name on which the WTP is to locally bridge 2492 user data. Note this field is only valid with WTPs configured in 2493 Local MAC mode. 2495 4.6.9. Add Static MAC ACL Entry 2497 The Add Static MAC ACL Entry message element is used by an AC to add 2498 a permanent ACL entry on a WTP, ensuring that the WTP no longer 2499 provides any service to the MAC addresses provided in the message. 2500 The MAC Addresses provided in this message element are expected to be 2501 saved in non-volative memory on the WTP. 2503 0 1 2 3 2504 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 2505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2506 | Num of Entries| Length | MAC Address ... 2507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2509 Type: 9 for Add Static MAC ACL Entry 2511 Length: >= 8 2513 Num of Entries: The number of instances of the Type/MAC Addresses 2514 fields in the array. 2516 Length: The length of the MAC Address field. 2518 MAC Address: MAC Addresses to add to the permanent ACL. 2520 4.6.10. CAPWAP Control IPv4 Address 2522 The CAPWAP Control IPv4 Address message element is sent by the AC to 2523 the WTP during the discovery process and is used by the AC to provide 2524 the interfaces available on the AC, and the current number of WTPs 2525 connected. When multiple CAPWAP Control IPV4 Address message 2526 elements are returned, the WTP SHOULD perform load balancing across 2527 the multiple interfaces. 2529 0 1 2 3 2530 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 2531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2532 | IP Address | 2533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2534 | WTP Count | 2535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2537 Type: 10 for CAPWAP Control IPv4 Address 2539 Length: 6 2541 IP Address: The IP Address of an interface. 2543 WTP Count: The number of WTPs currently connected to the interface. 2545 4.6.11. CAPWAP Control IPv6 Address 2547 The CAPWAP Control IPv6 Address message element is sent by the AC to 2548 the WTP during the discovery process and is used by the AC to provide 2549 the interfaces available on the AC, and the current number of WTPs 2550 connected. This message element is useful for the WTP to perform 2551 load balancing across multiple interfaces. 2553 0 1 2 3 2554 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 2555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2556 | IP Address | 2557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2558 | IP Address | 2559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2560 | IP Address | 2561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2562 | IP Address | 2563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2564 | WTP Count | 2565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2567 Type: 11 for CAPWAP Control IPv6 Address 2569 Length: 18 2571 IP Address: The IP Address of an interface. 2573 WTP Count: The number of WTPs currently connected to the interface. 2575 4.6.12. CAPWAP Timers 2577 The CAPWAP Timers message element is used by an AC to configure 2578 CAPWAP timers on a WTP. 2580 0 1 2581 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2583 | Discovery | Echo Request | 2584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2586 Type: 12 for CAPWAP Timers 2588 Length: 2 2590 Discovery: The number of seconds between CAPWAP Discovery messages, 2591 when the WTP is in the discovery phase. 2593 Echo Request: The number of seconds between WTP Echo Request CAPWAP 2594 messages. The default value for this message element is specified 2595 in Section 4.7.5. 2597 4.6.13. Data Transfer Data 2599 The Data Transfer Data message element is used by the WTP to provide 2600 information to the AC for debugging purposes. 2602 0 1 2 2603 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2605 | Data Type | Data Length | Data .... 2606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2608 Type: 13 for Data Transfer Data 2610 Length: >= 3 2612 Data Type: An 8-bit value the type of information being sent. The 2613 following values are supported: 2615 1 - WTP Crash Data 2617 2 - WTP Memory Dump 2619 Data Length: Length of data field. 2621 Data: Debug information. 2623 4.6.14. Data Transfer Mode 2625 The Data Transfer Mode message element is used by the WTP to indicate 2626 the type of data transfer information it is sending to the AC for 2627 debugging purposes. 2629 0 2630 0 1 2 3 4 5 6 7 2631 +-+-+-+-+-+-+-+-+ 2632 | Data Type | 2633 +-+-+-+-+-+-+-+-+ 2635 Type: 14 for Data Transfer Mode 2637 Length: 1 2639 Data Type: An 8-bit value the type of information being requested. 2640 The following values are supported: 2642 1 - WTP Crash Data 2644 2 - WTP Memory Dump 2646 4.6.15. Decryption Error Report 2648 The Decryption Error Report message element value is used by the WTP 2649 to inform the AC of decryption errors that have occurred since the 2650 last report. Note that this error reporting mechanism is not used if 2651 encryption and decryption services are provided in the AC. 2653 0 1 2 2654 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2656 | Radio ID |Num Of Entries | Length |MAC Address... 2657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2659 Type: 15 for Decryption Error Report 2661 Length: >= 9 2663 Radio ID: The Radio Identifier refers to an interface index on the 2664 WTP. 2666 Num of Entries: The number of instances of the Type/MAC Addresses 2667 fields in the array. 2669 Length: The length of the MAC Address field. 2671 MAC Address: MAC addresses of the station that has caused 2672 decryption errors. 2674 4.6.16. Decryption Error Report Period 2676 The Decryption Error Report Period message element value is used by 2677 the AC to inform the WTP how frequently it should send decryption 2678 error report messages. Note that this error reporting mechanism is 2679 not used if encryption and decryption services are provided in the 2680 AC. 2682 0 1 2 2683 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2685 | Radio ID | Report Interval | 2686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2688 Type: 16 for Decryption Error Report Period 2690 Length: 3 2692 Radio ID: The Radio Identifier refers to an interface index on the 2693 WTP. 2695 Report Interval: A 16-bit unsigned integer indicating the time, in 2696 seconds. The default value for this message element can be found 2697 in Section 4.8.8. 2699 4.6.17. Delete MAC ACL Entry 2701 The Delete MAC ACL Entry message element is used by an AC to delete a 2702 MAC ACL entry on a WTP, ensuring that the WTP provides service to the 2703 MAC addresses provided in the message. 2705 0 1 2 3 2706 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 2707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2708 | Num of Entries| Length | MAC Address ... 2709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2711 Type: 17 for Delete MAC ACL Entry 2713 Length: >= 8 2715 Num of Entries: The number of instances of the Type/MAC Addresses 2716 fields in the array. 2718 Length: The length of the MAC Address field. 2720 MAC Address: An array of MAC Addresses to delete from the ACL. 2722 4.6.18. Delete Station 2724 The Delete Station message element is used by the AC to inform a WTP 2725 that it should no longer provide service to a particular station. 2726 The WTP MUST terminate service to the station immediately upon 2727 receiving this message element. 2729 The transmission of a Delete Station message element could occur for 2730 various reasons, including for administrative reasons, or if the 2731 station has roamed to another WTP. 2733 The Delete Station message element MAY be sent by the WTP, in the WTP 2734 Event Request message, to inform the AC that a particular station is 2735 no longer being provided service. This could occur as a result of an 2736 Idle Timeout (see section 4.4.43), due to internal resource shortages 2737 or for some other reason. 2739 0 1 2 3 2740 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 2741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2742 | Radio ID | Length | MAC Address... 2743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2745 Type: 18 for Delete Station 2747 Length: >= 8 2749 Radio ID: An 8-bit value representing the radio 2751 Length: The length of the MAC Address field. 2753 MAC Address: The station's MAC Address 2755 4.6.19. Delete Static MAC ACL Entry 2757 The Delete Static MAC ACL Entry message element is used by an AC to 2758 delete a previously added static MAC ACL entry on a WTP, ensuring 2759 that the WTP provides service to the MAC addresses provided in the 2760 message. 2762 0 1 2 3 2763 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2765 | Num of Entries| Length | MAC Address ... 2766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2768 Type: 19 for Delete Static MAC ACL Entry 2770 Length: >= 8 2772 Num of Entries: The number of instances of the Type/MAC Addresses 2773 fields in the array. 2775 Length: The length of the MAC Address field. 2777 MAC Address: An array of MAC Addresses to delete from the static 2778 MAC ACL entry. 2780 4.6.20. Discovery Type 2782 The Discovery Type message element is used by the WTP to indicate how 2783 it has come to know about the existence of the AC to which it is 2784 sending the Discovery Request message. 2786 0 2787 0 1 2 3 4 5 6 7 2788 +-+-+-+-+-+-+-+-+ 2789 | Discovery Type| 2790 +-+-+-+-+-+-+-+-+ 2792 Type: 20 for Discovery Type 2794 Length: 1 2796 Discovery Type: An 8-bit value indicating how the WTP discovered 2797 the AC. The following values are supported: 2799 0 - Unknown 2800 1 - Static Configuration 2802 2 - DHCP 2804 3 - DNS 2806 4 - AC Referral (used when the AC was configured either through 2807 the AC IPv4 List or AC IPv6 List message element) 2809 4.6.21. Duplicate IPv4 Address 2811 The Duplicate IPv4 Address message element is used by a WTP to inform 2812 an AC that it has detected another IP device using the same IP 2813 address that the WTP is currently using. 2815 The WTP MUST transmit this message element with the status set to 1 2816 after it has detected a duplicate IP address. When the WTP detects 2817 that the duplicate IP address has been cleared, it MUSY send this 2818 message element with the status set to 0. 2820 0 1 2 3 2821 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 2822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2823 | IP Address | 2824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2825 | Status | Length | MAC Address ... 2826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2828 Type: 21 for Duplicate IPv4 Address 2830 Length: >= 12 2832 IP Address: The IP Address currently used by the WTP. 2834 Status: The status of the duplicate IP address. The value MUST be 2835 set to 1 when a duplicate address is detected, and 0 when the 2836 duplicate address has been cleared. 2838 Length: The length of the MAC Address field. 2840 MAC Address: The MAC Address of the offending device. 2842 4.6.22. Duplicate IPv6 Address 2844 The Duplicate IPv6 Address message element is used by a WTP to inform 2845 an AC that it has detected another host using the same IP address 2846 that the WTP is currently using. 2848 The WTP MUST transmit this message element with the status set to 1 2849 after it has detected a duplicate IP address. When the WTP detects 2850 that the duplicate IP address has been cleared, it MUST send this 2851 message element with the status set to 0. 2853 0 1 2 3 2854 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 2855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2856 | IP Address | 2857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2858 | IP Address | 2859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2860 | IP Address | 2861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2862 | IP Address | 2863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2864 | Status | Length | MAC Address ... 2865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2867 Type: 23 for Duplicate IPv6 Address 2869 Length: >= 24 2871 IP Address: The IP Address currently used by the WTP. 2873 Status: The status of the duplicate IP address. The value MUST be 2874 set to 1 when a duplicate address is detected, and 0 when the 2875 duplicate address has been cleared. 2877 Length: The length of the MAC Address field. 2879 MAC Address: The MAC Address of the offending device. 2881 4.6.23. Idle Timeout 2883 The Idle Timeout message element is sent by the AC to the WTP to 2884 provide the idle timeout value that the WTP SHOULD enforce for its 2885 active stations. The value applies to all radios on the WTP. 2887 0 1 2 3 2888 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 2889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2890 | Timeout | 2891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2893 Type: 23 for Idle Timeout 2895 Length: 4 2897 Timeout: The current idle timeout to be enforced by the WTP. The 2898 default value for this message element is specified in 2899 Section 4.8.5. 2901 4.6.24. Image Data 2903 The Image Data message element is present in the Image Data Request 2904 message sent by the AC and contains the following fields. 2906 0 1 2 3 2907 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 2908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2909 | Opcode | Value ... 2910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2912 Type: 24 for Image Data 2914 Length: >= 1 2916 Opcode: An 8-bit value representing the transfer opcode. The 2917 following values are supported: 2919 1 - Image data is included 2921 2 - Last Image Data Block is included (EOF) 2923 5 - An error occurred. Transfer is aborted 2925 Value: The Image Data field contains up to 1024 characters. If the 2926 block being sent is the last one, the Opcode is set to 2. The AC 2927 MAY opt to abort the data transfer by setting the Opcode to 5. 2928 When the Opcode is 5, the Value field has a zero length. 2930 4.6.25. Image Identifier 2932 The Image Identifier message element is sent by the AC to the WTP and 2933 is used to indicate the expected active software version that is to 2934 be run on the WTP. The value is a variable length UTF-8 encoded 2935 string, which is NOT zero terminated. 2937 0 1 2 3 2938 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 2939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2940 | Vendor Identifier | 2941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2942 | Value... 2943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2945 Type: 25 for Image Identifier 2947 Length: >= 1 2949 Value: A variable length UTF-8 encoded string containing the 2950 firmware identifier to be run on the WTP. 2952 4.6.26. Image Information 2954 The Image Information message element is present in the Image Data 2955 Response message sent by the AC to the WTP and contains the following 2956 fields. 2958 0 1 2 3 2959 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 2960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2961 | File Size | Hash | 2962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2963 | Hash | 2964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2965 | Hash | 2966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2967 | Hash | 2968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2969 | Hash | 2970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2972 Type: 26 for Image Information 2974 Length: 18 2976 File Size: A 16-bit value containing the size of the file that will 2977 be transfered by the AC to the WTP. 2979 Hash: A 16 octet hash of the image. The hash is computed using 2980 MD5, using the following pseudo-code: 2982 #include 2983 CapwapCreateHash(char *hash, char *image, int image_len) 2984 { 2985 MD_CTX context; 2987 MDInit (&context); 2988 MDUpdate (&context, buffer, len); 2989 MDFinal (hash, &context); 2990 } 2992 4.6.27. Initiate Download 2994 The Initiate Download message element is used by the AC to inform the 2995 WTP that the WTP SHOULD initiate a firmware upgrade. The WTP 2996 subsequently transmits an Image Data Request message which includes 2997 the Image Download message element. This message element does not 2998 contain any data. 3000 Type: 27 for Initiate Download 3002 Length: 0 3004 4.6.28. Location Data 3006 The Location Data message element is a variable length byte UTF-8 3007 encoded string containing user defined location information (e.g. 3008 "Next to Fridge"). This information is configurable by the network 3009 administrator, and allows the WTP location to be determined. The 3010 string is not zero terminated. 3012 0 3013 0 1 2 3 4 5 6 7 3014 +-+-+-+-+-+-+-+-+- 3015 | Location ... 3016 +-+-+-+-+-+-+-+-+- 3018 Type: 28 for Location Data 3020 Length: > 0 3022 Location: A non-zero terminated UTF-8 encoded string containing the 3023 WTP location. 3025 4.6.29. Maximum Message Length 3027 The Maximum Message Length message element is included in the Join 3028 Request message by the WTP to indicate the maximum CAPWAP message 3029 length that it supports to the AC. The Maximum Message Length 3030 message element is optionally included in Join Response message by 3031 the AC to indicate the maximum CAPWAP message length that it supports 3032 to the WTP. 3034 0 1 2 3035 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 3037 | Maximum Message Length | 3038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 3040 Type: 29 for Maximim Message Length 3042 Length: 2 3044 Maximum Message Length An 16-bit unsigned integer indicating the 3045 maximum message length. 3047 4.6.30. MTU Discovery Padding 3049 The MTU Discovery Padding message element is used as padding to 3050 perform MTU discovery, and MUST contain octets of value 0xFF, of any 3051 length 3053 0 3054 0 1 2 3 4 5 6 7 3055 +-+-+-+-+-+-+-+-+ 3056 | Padding... 3057 +-+-+-+-+-+-+-+- 3059 Type: 30 for MTU Discovery Padding 3061 Length: variable 3063 Pad: A variable length pad. 3065 4.6.31. Radio Administrative State 3067 The Radio Administrative State message element is used to communicate 3068 the state of a particular radio. The Radio Administrative State 3069 message element is sent by the AC to change the state of the WTP. 3070 The WTP saves the value, to ensure that it remains across WTP resets. 3071 The WTP communicates this message element during the configuration 3072 phase, in the Configuration Status Request message, to ensure that AC 3073 has the WTP radio current administrative state settings. The message 3074 element contains the following fields. 3076 0 1 3077 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3079 | Radio ID | Admin State | 3080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3082 Type: 31 for Radio Administrative State 3084 Length: 2 3086 Radio ID: An 8-bit value representing the radio to configure. The 3087 Radio ID field MAY also include the value of 0xff, which is used 3088 to identify the WTP. If an AC wishes to change the administrative 3089 state of a WTP, it includes 0xff in the Radio ID field. 3091 Admin State: An 8-bit value representing the administrative state 3092 of the radio. The default value for the Admin State field is 3093 listed in Section 4.8.1. The following values are supported: 3095 1 - Enabled 3097 2 - Disabled 3099 4.6.32. Radio Operational State 3101 The Radio Operational State message element is sent by the WTP to the 3102 AC to communicate a radio's operational state. This message element 3103 is included in the Configuration Update Response message by the WTP 3104 if it was requested to change the state of its radio, via the Radio 3105 Administrative State message element, but was unable to comply to the 3106 request. This message element is included in the Change State Event 3107 message when a WTP radio state was changed unexpectedly. This could 3108 occur due to a hardware failure. Note that the operational state 3109 setting is not saved on the WTP, and therefore does not remain across 3110 WTP resets. The value contains three fields, as shown below. 3112 0 1 2 3113 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 3114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3115 | Radio ID | State | Cause | 3116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3118 Type: 32 for Radio Operational State 3120 Length: 3 3121 Radio ID: The Radio Identifier refers to an interface index on the 3122 WTP. A value of 0xFF is invalid, as it is not possible to change 3123 the WTP's operational state. 3125 State: An 8-bit boolean value representing the state of the radio. 3126 A value of one disables the radio, while a value of two enables 3127 it. 3129 Cause: When a radio is inoperable, the cause field contains the 3130 reason the radio is out of service. The following values are 3131 supported: 3133 0 - Normal 3135 1 - Radio Failure 3137 2 - Software Failure 3139 3 - Administratively Set 3141 4.6.33. Result Code 3143 The Result Code message element value is a 32-bit integer value, 3144 indicating the result of the Request message corresponding to the 3145 Sequence Number included in the Response message. 3147 0 1 2 3 3148 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 3149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3150 | Result Code | 3151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3153 Type: 33 for Result Code 3155 Length: 4 3157 Result Code: The following values are defined: 3159 0 Success 3161 1 Failure (AC List message element MUST be present) 3163 2 Success (NAT detected) 3165 3 Join Failure (unspecified) 3166 4 Join Failure (Resource Depletion) 3168 5 Join Failure (Unknown Source) 3170 6 Join Failure (Incorrect Data) 3172 7 Join Failure (Session ID already in use) 3174 8 Join Failure (WTP Hardware not supported) 3176 9 Join Failure (Binding Not Supported) 3178 10 Reset Failure (Unable to Reset) 3180 11 Reset Failure (Firmware Write Error) 3182 12 Configuration Failure (Unable to Apply Requested Configuration 3183 - Service Provided Anyhow) 3185 13 Configuration Failure (Unable to Apply Requested Configuration 3186 - Service Not Provided) 3188 14 Image Data Error (Invalid Checksum) 3190 15 Image Data Error (Invalid Data Length) 3192 16 Image Data Error (Other Error) 3194 17 Image Data Error (Image Already Present) 3196 18 Message Unexpected (Invalid in current state) 3198 19 Message Unexpected (Unrecognized Request) 3200 20 Failure - Missing Mandatory Message Element 3202 21 Failure - Unrecognized Message Element 3204 4.6.34. Returned Message Element 3206 The Returned Message Element is sent by the WTP in the Change State 3207 Event Request message to communicate to the AC which message elements 3208 in the Configuration Status Response it was unable to apply locally. 3209 The Returned Message Element message element contains a result code 3210 indicating the reason that the configuration could not be applied, 3211 and encapsulates the failed message element. 3213 0 1 2 3214 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 3215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3216 | Reason | Message Element... 3217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3219 Type: 34 for Returned Message Element 3221 Length: >= 1 3223 Reason: The reason why the configuration in the offending message 3224 element could not be applied by the WTP. 3226 1 - Unknown Message Element 3228 2 - Unsupported Message Element 3230 3 - Unknown Message Element Value 3232 4 - Unsupported Message Element Value 3234 Message Element: The Message Element field encapsulates the message 3235 element sent by the AC in the Configuration Status Response 3236 message that caused the error. 3238 4.6.35. Session ID 3240 The Session ID message element value contains a randomly generated 3241 unsigned 32-bit integer. 3243 0 1 2 3 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 4 5 6 7 8 9 0 1 3245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3246 | Session ID | 3247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3249 Type: 35 for Session ID 3251 Length: 16 3253 Session ID: A 32-bit unsigned integer used as a random session 3254 identifier 3256 4.6.36. Statistics Timer 3258 The Statistics Timer message element value is used by the AC to 3259 inform the WTP of the frequency with which it expects to receive 3260 updated statistics. 3262 0 1 3263 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3265 | Statistics Timer | 3266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3268 Type: 36 for Statistics Timer 3270 Length: 2 3272 Statistics Timer: A 16-bit unsigned integer indicating the time, in 3273 seconds. The default value for this timer is specified in 3274 Section 4.7.12. 3276 4.6.37. Vendor Specific Payload 3278 The Vendor Specific Payload message element is used to communicate 3279 vendor specific information between the WTP and the AC. The message 3280 element uses the following format: 3282 0 1 2 3 3283 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 3284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3285 | Vendor Identifier | 3286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3287 | Element ID | Value... | 3288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3290 Type: 37 for Vendor Specific 3292 Length: >= 7 3294 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 3295 Network Management Private Enterprise Codes" [14] 3297 Element ID: A 16-bit Element Identifier which is managed by the 3298 vendor. 3300 Value: The value associated with the vendor specific element. 3302 4.6.38. WTP Board Data 3304 The WTP Board Data message element is sent by the WTP to the AC and 3305 contains information about the hardware present. 3307 0 1 2 3 3308 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 3309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3310 | Vendor Identifier | 3311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3312 | Type=0 | Length | 3313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3314 | Value... 3315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3316 | Type=1 | Length | 3317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3318 | Value... 3319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3320 | Optional additional vendor specific WTP board data TLVs..... 3321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3323 Type: 38 for WTP Board Data 3325 Length: >=14 3327 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 3328 Network Management Private Enterprise Codes" 3330 Type: The following values are supported: 3332 0 - WTP Model Number: The WTP Model Number MUST be included in 3333 the WTP Board Data message element. 3335 1 - WTP Serial Number: The WTP Serial Number MUST be included in 3336 the WTP Board Data message element. 3338 2 - Board ID: A hardware identifier, which MAY be included in 3339 the WTP Board Data mesage element. 3341 3 - Board Revision A revision number of the board, which MAY be 3342 included in the WTP Board Data message element. 3344 4 - Base MAC Addres The WTP's Base MAC Address, which MAY be 3345 assigned to the primary Ethernet interface. 3347 4.6.39. WTP Descriptor 3349 The WTP Descriptor message element is used by a WTP to communicate 3350 its current hardware and software (firmware) configuration. The 3351 value contains the following fields. 3353 0 1 2 3 3354 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 3355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3356 | Max Radios | Radios in use | Encryption Capabilities | 3357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3358 | Vendor Identifier | 3359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3360 | Type=0 | Length | 3361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3362 | Value... 3363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3364 | Vendor Identifier | 3365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3366 | Type=1 | Length | 3367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3368 | Value... 3369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3370 | Vendor Identifier | 3371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3372 | Type=2 | Length | 3373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3374 | Value... 3375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3376 | Vendor Identifier | 3377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3378 | Type=3 | Length | 3379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3380 | Value... 3381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3383 Type: 39 for WTP Descriptor 3385 Length: >= 31 3387 Max Radios: An 8-bit value representing the number of radios (where 3388 each radio is identified via the Radio ID field) supported by the 3389 WTP. 3391 Radios in use: An 8-bit value representing the number of radios in 3392 use in the WTP. 3394 Encryption Capabilities: This 16-bit field is used by the WTP to 3395 communicate its capabilities to the AC. A WTP that does not have 3396 any encryption capabilities sets this field to zero (0). Refer to 3397 the specific wireless binding for further specification of the 3398 Encryption Capabilities field. 3400 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 3401 Network Management Private Enterprise Codes". 3403 Type: The following values are supported. The Hardware Version, 3404 Active Software Version, and Boot Version values MUST be included. 3405 Zero or more Other Software Version values MAY be included. 3407 0 - Hardware Version: The WTP hardware version number. 3409 1 - Active Software Version: The WTP running software version 3410 number. 3412 2 - Boot Version: The WTP boot loader version number. 3414 3 - Other Software Version: The WTP non-running software 3415 (firmware) version number. 3417 Length: Length of vendor specific encoding of WTP information. 3419 Value: Vendor specific data of WTP information encoded in the UTF-8 3420 format. 3422 4.6.40. WTP Fallback 3424 The WTP Fallback message element is sent by the AC to the WTP to 3425 enable or disable automatic CAPWAP fallback in the event that a WTP 3426 detects its preferred AC, and is not currently connected to it. 3428 0 3429 0 1 2 3 4 5 6 7 3430 +-+-+-+-+-+-+-+-+ 3431 | Mode | 3432 +-+-+-+-+-+-+-+-+ 3434 Type: 40 for WTP Fallback 3435 Length: 1 3437 Mode: The 8-bit value indicates the status of automatic CAPWAP 3438 fallback on the WTP. When enabled, if the WTP detects that its 3439 primary AC is available, and that the WTP is not connected to the 3440 primary AC, the WTP SHOULD automatically disconnect from its 3441 current AC and reconnect to its primary AC. If disabled, the WTP 3442 will only reconnect to its primary AC through manual intervention 3443 (e.g., through the Reset Request message). The default value for 3444 this field is specified in Section 4.8.10. The following values 3445 are supported: 3447 1 - Enabled 3449 2 - Disabled 3451 4.6.41. WTP Frame Tunnel Mode 3453 The WTP Frame Tunnel Mode message element allows the WTP to 3454 communicate the tunneling modes of operation which it supports to the 3455 AC. A WTP that advertises support for all types allows the AC to 3456 select which type will be used, based on its local policy. 3458 0 3459 0 1 2 3 4 5 6 7 3460 +-+-+-+-+-+-+-+-+ 3461 | Tunnel Mode | 3462 +-+-+-+-+-+-+-+-+ 3464 Type: 41 for WTP Frame Tunnel Mode 3466 Length: 1 3468 Frame Tunnel Mode: The Frame Tunnel mode specifies the tunneling 3469 modes for station data that are supported by the WTP. The 3470 following values are supported: 3472 1 - Local Bridging: When Local Bridging is used, the WTP does 3473 not tunnel user traffic to the AC; all user traffic is locally 3474 bridged. This value MUST NOT be used when the WTP MAC Type is 3475 set to Split-MAC. 3477 2 - 802.3 Frame Tunnel Mode: The 802.3 Frame Tunnel Mode 3478 requires the WTP and AC to encapsulate all user payload as 3479 native IEEE 802.3 frames (see Section 4.4). All user traffic 3480 is tunneled to the AC. This value MUST NOT be used when the 3481 WTP MAC Type is set to Split-MAC. 3483 4 - Native Frame Tunnel Mode: Native Frame Tunnel mode requires 3484 the WTP and AC to encapsulate all user payloads as native 3485 wireless frames, as defined by the wireless binding (see for 3486 example Section 4.4). 3488 7 - All: The WTP is capable of supporting all frame tunnel 3489 modes. 3491 4.6.42. WTP IPv4 IP Address 3493 The WTP IPv4 address is used to perform NAT detection. 3495 0 1 2 3 3496 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 3497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3498 | WTP IPv4 IP Address | 3499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3501 Type: 42 for WTP IPv4 IP Address 3503 Length: 4 3505 WTP IPv4 IP Address: The IPv4 address from which the WTP is sending 3506 packets. This field is used for NAT detection. 3508 4.6.43. WTP IPv6 IP Address 3510 The WTP IPv6 address is used to perform NAT detection (e.g., IPv4 to 3511 IPv6 NAT to help with technology transition). 3513 0 1 2 3 3514 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 3515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3516 | WTP IPv6 IP Address | 3517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3518 | WTP IPv6 IP Address | 3519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3520 | WTP IPv6 IP Address | 3521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3522 | WTP IPv6 IP Address | 3523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3525 Type: 43 for WTP IPv6 IP Address 3527 Length: 32 3529 WTP IPv6 IP Address: The IPv6 address from which the WTP is sending 3530 packets. This field is used for NAT detection. 3532 4.6.44. WTP MAC Type 3534 The WTP MAC-Type message element allows the WTP to communicate its 3535 mode of operation to the AC. A WTP that advertises support for both 3536 modes allows the AC to select the mode to use, based on local policy. 3538 0 3539 0 1 2 3 4 5 6 7 3540 +-+-+-+-+-+-+-+-+ 3541 | MAC Type | 3542 +-+-+-+-+-+-+-+-+ 3544 Type: 44 for WTP MAC Type 3546 Length: 1 3548 MAC Type: The MAC mode of operation supported by the WTP. The 3549 following values are supported 3551 0 - Local-MAC: Local-MAC is the default mode that MUST be 3552 supported by all WTPs. 3554 1 - Split-MAC: Split-MAC support is optional, and allows the AC 3555 to receive and process native wireless frames. 3557 2 - Both: WTP is capable of supporting both Local-MAC and Split- 3558 MAC. 3560 4.6.45. WTP Name 3562 The WTP Name message element is a variable length byte UTF-8 encoded 3563 string. The string is not zero terminated. 3565 0 3566 0 1 2 3 4 5 6 7 3567 +-+-+-+-+-+-+-+-+- 3568 | WTP Name ... 3569 +-+-+-+-+-+-+-+-+- 3571 Type: 45 for WTP Name 3573 Length: variable 3575 WTP Name: A non-zero terminated UTF-8 encoded string containing the 3576 WTP name. 3578 4.6.46. WTP Operational Statistics 3580 The WTP Operational Statistics message element is sent by the WTP to 3581 the AC to provide statistics related to the operation of the WTP. 3583 0 1 2 3 3584 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 3585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3586 | Radio ID | Tx Queue Level | Wireless Link Frames per Sec | 3587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3589 Type: 46 for WTP Operational Statistics 3591 Length: 4 3593 Radio ID: The radio ID of the radio to which the statistics apply. 3595 Wireless Transmit Queue Level: The percentage of Wireless Transmit 3596 queue utilization, calculated as the sum of utilized transmit 3597 queue lengths divided by the sum of maximum transmit queue 3598 lengths, multiplied by 100. The Wireless Transmit Queue Level is 3599 representative of congestion conditions over wireless interfaces 3600 between the WTP and stations. 3602 Wireless Link Frames per Sec: The number of frames transmitted or 3603 received per second by the WTP over the air interface. 3605 4.6.47. WTP Radio Statistics 3607 The WTP Radio Statistics message element is sent by the WTP to the AC 3608 to communicate statistics on radio behavior and reasons why the WTP 3609 radio has been reset. 3611 0 1 2 3 3612 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 3613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3614 | Radio ID | Last Fail Type| Reset Count | 3615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3616 | SW Failure Count | HW Failure Count | 3617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3618 | Other Failure Count | Unknown Failure Count | 3619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3620 | Config Update Count | Channel Change Count | 3621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3622 | Band Change Count | Current Noise Floor | 3623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3625 Type: 47 for WTP Radio Statistics 3627 Length: 20 3629 Radio ID: The radio ID of the radio to which the statistics apply. 3631 Last Failure Type: The last WTP failure. The following values are 3632 supported: 3634 0 - Statistic Not Supported 3636 1 - Software Failure 3638 2 - Hardware Failure 3640 3 - Other Failure 3642 255 - Unknown (e.g., WTP doesn't keep track of info) 3644 Reset Count: The number of times that that the radio has been 3645 reset. 3647 SW Failure Count: The number of times that the radio has failed due 3648 to software related reasons. 3650 HW Failure Count: The number of times that the radio has failed due 3651 to hardware related reasons. 3653 Other Failure Count: The number of times that the radio has failed 3654 due to known reasons, other than software or hardware failure. 3656 Unknown Failure Count: The number of times that the radio has 3657 failed for unknown reasons. 3659 Config Update Count: The number of times that the radio 3660 configuration has been updated. 3662 Channel Change Count: The number of times that the radio channel 3663 has been changed. 3665 Band Change Count: The number of times that the radio has changed 3666 frequency bands. 3668 Current Noise Floor: A signed integer which indicates the noise 3669 floor of the radio receiver in units of dBm. 3671 4.6.48. WTP Reboot Statistics 3673 The WTP Reboot Statistics message element is sent by the WTP to the 3674 AC to communicate reasons why WTP reboots have occurred. 3676 0 1 2 3 3677 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 3678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3679 | Reboot Count | AC Initiated Count | 3680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3681 | Link Failure Count | SW Failure Count | 3682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3683 | HW Failure Count | Other Failure Count | 3684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3685 | Unknown Failure Count |Last Failure Type| 3686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3688 Type: 48 for WTP Reboot Statistics 3690 Length: 15 3692 Reboot Count: The number of reboots that have occurred due to a WTP 3693 crash. A value of 65535 implies that this information is not 3694 available on the WTP. 3696 AC Initiated Count: The number of reboots that have occurred at the 3697 request of a CAPWAP protocol message, such as a change in 3698 configuration that required a reboot or an explicit CAPWAP 3699 protocol reset request. A value of 65535 implies that this 3700 information is not available on the WTP. 3702 Link Failure Count: The number of times that a CAPWAP protocol 3703 connection with an AC has failed due to link failure. 3705 SW Failure Count: The number of times that a CAPWAP protocol 3706 connection with an AC has failed due to software related reasons. 3708 HW Failure Count: The number of times that a CAPWAP protocol 3709 connection with an AC has failed due to hardware related reasons. 3711 Other Failure Count: The number of times that a CAPWAP protocol 3712 connection with an AC has failed due to known reasons, other than 3713 AC initiated, link, SW or HW failure. 3715 Unknown Failure Count: The number of times that a CAPWAP protocol 3716 connection with an AC has failed for unknown reasons. 3718 Last Failure Type: The failure type of the most recent WTP failure. 3719 The following values are supported: 3721 0 - Not Supported 3723 1 - AC Initiated (see Section 9.2) 3725 2 - Link Failure 3727 3 - Software Failure 3729 4 - Hardware Failure 3731 5 - Other Failure 3733 255 - Unknown (e.g., WTP doesn't keep track of info) 3735 4.6.49. WTP Static IP Address Information 3737 The WTP Static IP Address Information message element is used by an 3738 AC to configure or clear a previously configured static IP address on 3739 a WTP. 3741 0 1 2 3 3742 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 3743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3744 | IP Address | 3745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3746 | Netmask | 3747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3748 | Gateway | 3749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3750 | Static | 3751 +-+-+-+-+-+-+-+-+ 3753 Type: 49 for WTP Static IP Address Information 3755 Length: 13 3757 IP Address: The IP Address to assign to the WTP. This field is 3758 only valid if the static field is set to one. 3760 Netmask: The IP Netmask. This field is only valid if the static 3761 field is set to one. 3763 Gateway: The IP address of the gateway. This field is only valid 3764 if the static field is set to one. 3766 Netmask: The IP Netmask. This field is only valid if the static 3767 field is set to one. 3769 Static: An 8-bit boolean stating whether the WTP should use a 3770 static IP address or not. A value of zero disables the static IP 3771 address, while a value of one enables it. 3773 4.7. CAPWAP Protocol Timers 3775 This section contains the CAPWAP timers. 3777 4.7.1. ChangeStatePendingTimer 3779 The maximum time, in seconds, the AC will wait for the Change State 3780 Event Request from the WTP after having transmitted a successful 3781 Configuration Status Response message. The default value is 25 3782 seconds. 3784 4.7.2. DataChannelDeadInterval 3786 The minimum time, in seconds, a WTP MUST wait without having received 3787 a Data Channel Keep Alive packet before the destination for the Data 3788 Channel Keep Alive packets may be considered dead. The value of this 3789 timer MUST be no less than 2*DataChannelKeepAlive seconds and no 3790 greater that 240 seconds. 3792 Default: 5 3794 4.7.3. DiscoveryInterval 3796 The minimum time, in seconds, that a WTP MUST wait after receiving a 3797 Discovery Response message, before initiating a DTLS handshake. 3799 Default: 5 3801 4.7.4. DTLSSessionDelete 3803 The minimum time, in seconds, a WTP MUST wait for DTLS session 3804 deletion. 3806 Default: 5 3808 4.7.5. EchoInterval 3810 The minimum time, in seconds, between sending Echo Request messages 3811 to the AC with which the WTP has joined. 3813 Default: 30 3815 4.7.6. MaxDiscoveryInterval 3817 The maximum time allowed between sending Discovery Request messages, 3818 in seconds. This value MUST be no less than 2 seconds and no greater 3819 than 180 seconds. 3821 Default: 20 seconds. 3823 4.7.7. MaxFailedDTLSSessionRetry 3825 The maximum number of failed DTLS session establishment attempts 3826 before the CAPWAP device enters a silent period. 3828 Default: 3. 3830 4.7.8. NeighborDeadInterval 3832 The minimum time, in seconds, a WTP MUST wait without having received 3833 an Echo Response message to its Echo Request message, before the 3834 destination for the Echo Request may be considered dead. This value 3835 MUST be no less than 2*EchoInterval seconds and no greater than 240 3836 seconds. 3838 Default: 60 3840 4.7.9. ResponseTimeout 3842 The minimum time, in seconds, in which the WTP or AC MUST respond to 3843 a CAPWAP Request message. 3845 Default: 1 3847 4.7.10. RetransmitInterval 3849 The minimum time, in seconds, in which a non-acknowledged CAPWAP 3850 packet will be retransmitted. 3852 Default: 3 3854 4.7.11. SilentInterval 3856 For a WTP, this is the minimum time, in seconds, a WTP MUST wait 3857 before it MAY again send Discovery Request messages or attempt to a 3858 establish DTLS session. For an AC, this is the minimum time, in 3859 seconds, during which the AC SHOULD ignore all CAPWAP and DTLS 3860 packets received from the WTP that is in the Sulking state. 3862 Default: 30 3864 4.7.12. StatisticsTimer 3866 The default Statistics Interval is 120 seconds. 3868 4.7.13. WaitDTLS 3870 The maximum time, in seconds, a WTP MUST wait without having received 3871 a DTLS Handshake message from an AC. This timer MUST be greater than 3872 30 seconds. 3874 Default: 60 3876 4.7.14. WaitJoin 3878 The maximum time, in seconds, after which the DTLS session has been 3879 established that the AC will wait before receiving a Join Request 3880 message. This timer MUST be greater than 30 seconds. 3882 Default: 60 3884 4.8. CAPWAP Protocol Variables 3886 A WTP or AC that implements the CAPWAP Discovery phase MUST allow for 3887 the following variables to be configured by system management; 3888 default values are specified, making explicit configuration 3889 unnecessary in many cases. If the default values are explicitly 3890 overriden by the AC, the WTP MUST save the values sent by the AC. 3892 4.8.1. AdminState 3894 The default Administrative State value is enabled (1). 3896 4.8.2. DiscoveryCount 3898 The number of Discovery Request messages transmitted by a WTP to a 3899 single AC. This is a monotonically increasing counter. 3901 4.8.3. FailedDTLSAuthFailCount 3903 The number of failed DTLS session establishment attempts due to 3904 authentication failures. 3906 4.8.4. FailedDTLSSessionCount 3908 The number of failed DTLS session establishment attempts. 3910 4.8.5. IdleTimeout 3912 The default Idle Timeout is 300 seconds. 3914 4.8.6. MaxDiscoveries 3916 The maximum number of Discovery Request messages that will be sent 3917 after a WTP boots. 3919 Default: 10 3921 4.8.7. MaxRetransmit 3923 The maximum number of retransmissions for a given CAPWAP packet 3924 before the link layer considers the peer dead. 3926 Default: 5 3928 4.8.8. ReportInterval 3930 The default Report Interval is 120 seconds. 3932 4.8.9. RetransmitCount 3934 The number of retransmissions for a given CAPWAP packet. This is a 3935 monotonically increasing counter. 3937 4.8.10. WTPFallBack 3939 The default WTP Fallback value is enabled (1). 3941 4.9. WTP Saved Variables 3943 In addition to the values defined in Section 4.8, the following 3944 values SHOULD be saved on the WTP in non-volatile memory. CAPWAP 3945 wireless bindings MAY define additional values that SHOULD be stored 3946 on the WTP. 3948 4.9.1. AdminRebootCount 3950 The number of times the WTP has rebooted administratively, defined in 3951 Section 4.6.48. 3953 4.9.2. FrameEncapType 3955 For WTPs that support multiple Frame Encapsulation Types, it is 3956 useful to save the value configured by the AC. The Frame 3957 Encapsulation Type is defined in Section 4.6.41. 3959 4.9.3. LastRebootReason 3961 The reason why the WTP last rebooted, defined in Section 4.6.48. 3963 4.9.4. MacType 3965 For WTPs that support multiple MAC Types, it is useful to save the 3966 value configured by the AC. The MACType is defined in 3967 Section 4.6.44. 3969 4.9.5. PreferredACs 3971 The preferred ACs, with the index, defined in Section 4.6.5. 3973 4.9.6. RebootCount 3975 The number of times the WTP has rebooted, defined in Section 4.6.48. 3977 4.9.7. Static ACL Table 3979 The static ACL table saved on the WTP, as configured by the Add 3980 Static MAC ACL Entry message element, see Section 4.6.9. 3982 4.9.8. Static IP Address 3984 The static IP Address assigned to the WTP, as configured by the WTP 3985 Static IP Address Information message element (see Section 4.6.49). 3987 4.9.9. WTPLinkFailureCount 3989 The number of times the link to the AC has failed, see 3990 Section 4.6.48. 3992 4.9.10. WTPLocation 3994 The WTP Location, defined in Section 4.6.28. 3996 4.9.11. WTPName 3998 The WTP Name, defined in Section 4.6.45. 4000 5. CAPWAP Discovery Operations 4002 The Discovery messages are used by a WTP to determine which ACs are 4003 available to provide service, and the capabilities and load of the 4004 ACs. 4006 5.1. Discovery Request Message 4008 The Discovery Request message is used by the WTP to automatically 4009 discover potential ACs available in the network. The Discovery 4010 Request message provides ACs with the primary capabilities of the 4011 WTP. A WTP must exchange this information to ensure subsequent 4012 exchanges with the ACs are consistent with the WTP's functional 4013 characteristics. 4015 Discovery Request messages MUST be sent by a WTP in the Discover 4016 state after waiting for a random delay less than 4017 MaxDiscoveryInterval, after a WTP first comes up or is 4018 (re)initialized. A WTP MUST send no more than the maximum of 4019 MaxDiscoveries Discovery Request messages, waiting for a random delay 4020 less than MaxDiscoveryInterval between each successive message. 4022 This is to prevent an explosion of WTP Discovery Request messages. 4023 An example of this occurring is when many WTPs are powered on at the 4024 same time. 4026 Discovery Request messages MUST be sent by a WTP when no Echo 4027 Response messages are received for NeighborDeadInterval and the WTP 4028 returns to the Idle state. Discovery Request messages are sent after 4029 NeighborDeadInterval. They MUST be sent after waiting for a random 4030 delay less than MaxDiscoveryInterval. A WTP MAY send up to a maximum 4031 of MaxDiscoveries Discovery Request messages, waiting for a random 4032 delay less than MaxDiscoveryInterval between each successive message. 4034 If a Discovery Response message is not received after sending the 4035 maximum number of Discovery Request messages, the WTP enters the 4036 Sulking state and MUST wait for an interval equal to SilentInterval 4037 before sending further Discovery Request messages. 4039 Upon receiving a Discovery Request message, the AC will respond with 4040 a Discovery Response message sent to the address in the source 4041 address of the received Discovery Request message. 4043 It is possible for the AC to receive a cleartext Discovery Request 4044 message while a DTLS session is already active with the WTP. This is 4045 most likely the case if the WTP has rebooted, perhaps due to a 4046 software or power failure, but could also be caused by a DoS attack. 4047 In such cases, any WTP state, including the state machine instance, 4048 MUST NOT be cleared until another DTLS session has been successfully 4049 established, communicated via the DTLSSessionEstablished DTLS 4050 notification (see Section 2.3.2.2). 4052 The binding specific WTP Radio Information message element (see 4053 Section 2.1) is included in the Discovery Request message to 4054 advertise WTP support for one or more CAPWAP bindings. 4056 The Discovery Request message is sent by the WTP when in the 4057 Discovery State. The AC does not transmit this message. 4059 The following message elements MUST be included in the Discovery 4060 Request message: 4062 o Discovery Type, see Section 4.6.20 4064 o WTP Board Data, see Section 4.6.38 4066 o WTP Descriptor, see Section 4.6.39 4068 o WTP Frame Tunnel Mode, see Section 4.6.41 4070 o WTP MAC Type, see Section 4.6.44 4072 o WTP Radio Information message element(s)that the WTP supports; 4073 These are defined by the individual link layer CAPWAP Binding 4074 Protocols (see Section 2.1). 4076 5.2. Discovery Response Message 4078 The Discovery Response message provides a mechanism for an AC to 4079 advertise its services to requesting WTPs. 4081 When a WTP receives a Discovery Response message, it MUST wait for an 4082 interval not less than DiscoveryInterval for receipt of additional 4083 Discovery Response messages. After the DiscoveryInterval elapses, 4084 the WTP enters the DTLS-Init state and selects one of the ACs that 4085 sent a Discovery Response message and send a DTLS Handshake to that 4086 AC. 4088 One or more binding specific WTP Radio Information message elements 4089 (see Section 2.1) are included in the Discovery Request message to 4090 advertise AC support for the CAPWAP bindings. The AC MAY include 4091 only the bindings it shares in common with the WTP, known through the 4092 WTP Radio Information message elements received in the Discovery 4093 Request message, or it MAY include all of the bindings supported. 4094 The WTP MAY use the supported bindings in its AC decision process. 4095 Note that if the WTP joins an AC that does not support a specific 4096 CAPWAP binding, service for that binding MUST NOT be provided by the 4097 WTP. 4099 The Discovery Response message is sent by the AC when in the Idle 4100 State. The WTP does not transmit this message. 4102 The following message elements MUST be included in the Discovery 4103 Response Message: 4105 o AC Descriptor, see Section 4.6.1 4107 o AC Name, see Section 4.6.4 4109 o WTP Radio Information message element(s)that the AC supports; 4110 These are defined by the individual link layer CAPWAP Binding 4111 Protocols (see Section 2.1 for more information). 4113 o One of the following message elements MUST be included in the 4114 Discovery Response Message: 4116 * CAPWAP Control IPv4 Address, see Section 4.6.10 4118 * CAPWAP Control IPv6 Address, see Section 4.6.11 4120 5.3. Primary Discovery Request Message 4122 The Primary Discovery Request message is sent by the WTP to determine 4123 whether its preferred (or primary) AC is available. 4125 A Primary Discovery Request message is sent by a WTP when it has a 4126 primary AC configured, and is connected to another AC. This 4127 generally occurs as a result of a failover, and is used by the WTP as 4128 a means to discover when its primary AC becomes available. Since the 4129 WTP only has a single instance of the CAPWAP state machine, the 4130 Primary Discovery Request is sent by the WTP when in the Run State. 4131 The AC does not transmit this message. 4133 The frequency of the Primary Discovery Request messages should be no 4134 more often than the sending of the Echo Request message. 4136 Upon receipt of a Primary Discovery Request message, the AC responds 4137 with a Primary Discovery Response message sent to the address in the 4138 source address of the received Primary Discovery Request message. 4140 The following message elements MUST be included in the Primary 4141 Discovery Request message. 4143 o Discovery Type, see Section 4.6.20 4145 o WTP Board Data, see Section 4.6.38 4147 o WTP Descriptor, see Section 4.6.39 4149 o WTP Frame Tunnel Mode, see Section 4.6.41 4151 o WTP MAC Type, see Section 4.6.44 4153 o WTP Radio Information message element(s)that the WTP supports; 4154 These are defined by the individual link layer CAPWAP Binding 4155 Protocols (see Section 2.1 for more information). 4157 5.4. Primary Discovery Response 4159 The Primary Discovery Response message enables an AC to advertise its 4160 availability and services to requesting WTPs that are configured to 4161 have the AC as its primary AC. 4163 The Primary Discovery Response message is sent by an AC after 4164 receiving a Primary Discovery Request message. 4166 When a WTP receives a Primary Discovery Response message, it may 4167 establish a CAPWAP protocol connection to its primary AC, based on 4168 the configuration of the WTP Fallback Status message element on the 4169 WTP. 4171 The Primary Discovery Response message is sent by the AC when in the 4172 Idle State. The WTP does not transmit this message. 4174 The following message elements MUST be included in the Primary 4175 Discovery Response message. 4177 o AC Descriptor, see Section 4.6.1 4179 o AC Name, see Section 4.6.4 4181 o WTP Radio Information message element(s)that the AC supports; 4182 These are defined by the individual link layer CAPWAP Binding 4183 Protocols (see Section 2.1 for more information). 4185 One of the following message elements MUST be included in the 4186 Discovery Response Message: 4188 o CAPWAP Control IPv4 Address, see Section 4.6.10 4189 o CAPWAP Control IPv6 Address, see Section 4.6.11 4191 6. CAPWAP Join Operations 4193 The Join Request message is used by a WTP to request service from an 4194 AC after a DTLS connection is established to that AC. The Join 4195 Response message is used by the the AC to indicate that it will or 4196 will not provide service. 4198 6.1. Join Request 4200 The Join Request message is used by a WTP to request service through 4201 the AC. A Join Request message is sent by a WTP after (optionally) 4202 receiving one or more Discovery Response messages, and completion of 4203 DTLS session establishment. When an AC receives a Join Request 4204 message it responds with a Join Response message. 4206 Upon completion of the DTLS handshake, and receiving the 4207 DTLSEstablished notification, the WTP sends the Join Request message 4208 to the AC. When the AC is notified of the DTLS session 4209 establishment, it does not clear the WaitDTLS timer until it has 4210 received the Join Request message, at which time it sends a Join 4211 Response message to the WTP, indicating success or failure. 4213 One or more WTP Radio Information message elements (see Section 2.1) 4214 are included in the Join Request to request service for the CAPWAP 4215 bindings by the AC. Including a binding that is unsupported by the 4216 AC will result in a failed Join Response. 4218 If the AC rejects the Join Request, it sends a Join Response message 4219 with a failure indication and initiates an abort of the DTLS session 4220 via the DTLSAbort command. 4222 If an invalid (i.e. malformed) Join Request message is received, the 4223 message MUST be silently discarded by the AC. No response is sent to 4224 the WTP. The AC SHOULD log this event. 4226 The Join Request is sent by the WTP when in the Join State. The AC 4227 does not transmit this message. 4229 The following message elements MUST be included in the Join Request 4230 message. 4232 o Location Data, see Section 4.6.28 4234 o WTP Board Data, see Section 4.6.38 4236 o WTP Descriptor, see Section 4.6.39 4237 o WTP Name, see Section 4.6.45 4239 o Session ID, see Section 4.6.35 4241 o WTP Frame Tunnel Mode, see Section 4.6.41 4243 o WTP MAC Type, see Section 4.6.44 4245 o WTP Radio Information message element(s)that the WTP supports; 4246 These are defined by the individual link layer CAPWAP Binding 4247 Protocols (see Section 2.1 for more information). 4249 At least one of the following message element MUST be included in the 4250 Join Request message. 4252 o WTP IPv4 IP Address, see Section 4.6.42 4254 o WTP IPv6 IP Address, see Section 4.6.43 4256 The following message element MAY be included in the Join Request 4257 message. 4259 o Maximum Message Length, see Section 4.6.29 4261 o WTP Reboot Statistics, see Section 4.6.48 4263 o WTP IPv4 IP Address, see Section 4.6.42 4265 o WTP IPv6 IP Address, see Section 4.6.43 4267 6.2. Join Response 4269 The Join Response message is sent by the AC to indicate to a WTP that 4270 it is capable and willing to provide service to the WTP. 4272 The WTP, receiving a Join Response message, checks for success or 4273 failure. If the message indicates success, the WTP clears the 4274 WaitDTLS timer for the session and proceeds to the Configure state. 4276 If the WaitDTLS Timer expires prior to reception of the Join Response 4277 message, the WTP MUST terminate the handshake, deallocate session 4278 state and initiate the DTLSAbort command. 4280 If an invalid (malformed) Join Response message is received, the WTP 4281 SHOULD log an informative message detailing the error. This error 4282 MUST be treated in the same manner as AC non-responsiveness. The 4283 WaitDTLS timer will eventually expire, and the WTP MAY (if it is so 4284 configured) attempts to join a new AC. 4286 If one of the WTP Radio Information message elements (see 4287 Section 2.1) in the Join Request message requested support for a 4288 CAPWAP binding which the AC does not support, the AC sets the Result 4289 Code message element to "Binding Not Supported". 4291 The AC includes the Image Identifier message element to indicate the 4292 software version it expects the WTP to run. This information is used 4293 to determine whether the WTP MUST either change its currently running 4294 firmware image, or download a new version (see Section 9.1.1). 4296 The Join Response message is sent by the AC when in the Join State. 4297 The WTP does not transmit this message. 4299 The following message elements MAY be included in the Join Response 4300 message. 4302 o AC IPv4 List, see Section 4.6.2 4304 o AC IPv6 List, see Section 4.6.3 4306 o Image Identifier, see Section 4.6.25 4308 o Maximum Message Length, see Section 4.6.29 4310 The following message elements MUST be included in the Join Response 4311 message. 4313 o Result Code, see Section 4.6.33 4315 o AC Descriptor, see Section 4.6.1 4317 o AC Name, see Section 4.6.4 4319 o WTP Radio Information message element(s)that the AC supports; 4320 These are defined by the individual link layer CAPWAP Binding 4321 Protocols (see Section 2.1). 4323 One of the following message elements MUST be included in the 4324 Discovery Response Message: 4326 o CAPWAP Control IPv4 Address, see Section 4.6.10 4328 o CAPWAP Control IPv6 Address, see Section 4.6.11 4330 7. Control Channel Management 4332 The Control Channel Management messages are used by the WTP and AC to 4333 maintain a control communication channel. CAPWAP control messages, 4334 such as the WTP Event Request message sent from the WTP to the AC 4335 indicate to the AC that the WTP is operational. When such control 4336 messages are not being sent, the Echo Request and Echo Response 4337 messages are used to maintain the control communication channel. 4339 7.1. Echo Request 4341 The Echo Request message is a keep-alive mechanism for CAPWAP control 4342 messages. 4344 Echo Request messages are sent periodically by a WTP in the Run state 4345 (see Section 2.3) to determine the state of the control connection 4346 between the WTP and the AC. The Echo Request message is sent by the 4347 WTP when the EchoInterval timer expires. The WTP MUST start its 4348 NeighborDeadInterval timer when the EchoInterval timer expires. 4350 The Echo Request message is sent by the WTP when in the Run State. 4351 The AC does not transmit this message. 4353 The Echo Request message carries no message elements. 4355 When an AC receives an Echo Request message it responds with an Echo 4356 Response message. 4358 7.2. Echo Response 4360 The Echo Response message acknowledges the Echo Request message. 4362 An Echo Response message is sent by an AC after receiving an 4363 EchoRequest message. After transmitting the Echo Response message, 4364 the AC SHOULD reset its EchoInterval timer. If another Echo Request 4365 message or other control message is not received by the AC when the 4366 timer expires, the AC SHOULD consider the WTP to be no longer 4367 reachable. 4369 The Echo Response message is sent by the AC when in the Run State. 4370 The WTP does not transmit this message. 4372 The Echo Response message carries no message elements. 4374 When a WTP receives an Echo Response message it stops the 4375 NeighborDeadInterval timer, and initializes the EchoInterval to the 4376 configured value. 4378 If the NeighborDeadInterval timer expires prior to receiving an Echo 4379 Response message, or other control message, the WTP enters the Idle 4380 state. 4382 8. WTP Configuration Management 4384 WTP Configuration messages are used to exchange configuration 4385 information between the AC and the WTP. 4387 8.1. Configuration Consistency 4389 The CAPWAP protocol provides flexibility in how WTP configuration is 4390 managed. A WTP has two options: 4392 1. The WTP retains no configuration and accepts the configuration 4393 provided by the AC. 4395 2. The WTP retains the configuration of parameters provided by the AC 4396 that are non-default values. 4398 If the WTP opts to save configuration locally, the CAPWAP protocol 4399 state machine defines the Configure state, which allows for 4400 configuration exchange. In the Configure state, the WTP sends its 4401 current configuration overrides to the AC via the Configuration 4402 Status message. A configuration override is a non-default parameter. 4403 As an example, in the CAPWAP protocol, the default antenna 4404 configuration is internal omni antenna. A WTP that either has no 4405 internal antennas, or has been explicitly configured by the AC to use 4406 external antennas, sends its antenna configuration during the 4407 configure phase, allowing the AC to become aware of the WTP's current 4408 configuration. 4410 Once the WTP has provided its configuration to the AC, the AC sends 4411 its configuration to the WTP. This allows the WTP to receive 4412 configuration and policies from the AC. 4414 The AC maintains a copy of each active WTP configuration. There is 4415 no need for versioning or other means to identify configuration 4416 changes. If a WTP becomes inactive, the AC MAY delete the inactive 4417 WTP configuration. If a WTP fails, and connects to a new AC, the WTP 4418 provides its overridden configuration parameters, allowing the new AC 4419 to be aware of the WTP configuration. 4421 This model allows for resiliency in case of an AC failure, ensuring 4422 another AC can provide service to the WTP. A new AC would be 4423 automatically updated with WTP configuration changes, eliminating the 4424 need for inter-AC communication and the need for all ACs to be aware 4425 of the configuration of all WTPs in the network. 4427 Once the CAPWAP protocol enters the Run state, the WTPs begin to 4428 provide service. It is common for administrators to require that 4429 configuration changes be made while the network is operational. 4431 Therefore, the Configuration Update Request is sent by the AC to the 4432 WTP to make these changes at run-time. 4434 8.1.1. Configuration Flexibility 4436 The CAPWAP protocol provides the flexibility to configure and manage 4437 WTPs of varying design and functional characteristics. When a WTP 4438 first discovers an AC, it provides primary functional information 4439 relating to its type of MAC and to the nature of frames to be 4440 exchanged. The AC configures the WTP appropriately. The AC also 4441 establishes corresponding internal state for the WTP. 4443 8.2. Configuration Status 4445 The Configuration Status message is sent by a WTP to deliver its 4446 current configuration to the AC. 4448 The Configuration Status message carries binding specific message 4449 elements. Refer to the appropriate binding for the definition of 4450 this structure. 4452 When an AC receives a Configuration Status message it acts upon the 4453 content of the message and responds to the WTP with a Configuration 4454 Status Response message. 4456 The Configuration Status message includes multiple Radio 4457 Administrative State message elements, one for the WTP, and one for 4458 each radio in the WTP. 4460 The Configuration Status message is sent by the WTP when in the 4461 Configure State. The AC does not transmit this message. 4463 The following message elements MUST be included in the Configuration 4464 Status message. 4466 o AC Name, see Section 4.6.4 4468 o AC Name with Index, see Section 4.6.5 4470 o Radio Administrative State, see Section 4.6.31 4472 o Statistics Timer, see Section 4.6.36 4474 o WTP Reboot Statistics, see Section 4.6.48 4476 The following message elements MAY be included in the Configuration 4477 Status message. 4479 o WTP Static IP Address Information, see Section 4.6.49 4481 8.3. Configuration Status Response 4483 The Configuration Status Response message is sent by an AC and 4484 provides a mechanism for the AC to override a WTP's requested 4485 configuration. 4487 A Configuration Status Response message is sent by an AC after 4488 receiving a Configuration Request message. 4490 The Configuration Status Response message carries binding specific 4491 message elements. Refer to the appropriate binding for the 4492 definition of this structure. 4494 When a WTP receives a Configuration Status Response message it acts 4495 upon the content of the message, as appropriate. If the 4496 Configuration Status Response message includes a Radio Operational 4497 State message element that causes a change in the operational state 4498 of one of the radios, the WTP transmits a Change State Event to the 4499 AC, as an acknowledgement of the change in state. 4501 The Configuration Status Response message is sent by the AC when in 4502 the Configure State. The WTP does not transmit this message. 4504 The following message elements MUST be included in the Configuration 4505 Status Response message. 4507 o AC IPv4 List, see Section 4.6.2 4509 o AC IPv6 List, see Section 4.6.3 4511 o CAPWAP Timers, see Section 4.6.12 4513 o Decryption Error Report Period, see Section 4.6.16 4515 o Idle Timeout, see Section 4.6.23 4517 o WTP Fallback, see Section 4.6.40 4519 The following message element MAY be included in the Configuration 4520 Status Response message. 4522 o WTP Static IP Address Information, see Section 4.6.49 4524 8.4. Configuration Update Request 4526 Configuration Update Request messages are sent by the AC to provision 4527 the WTP while in the Run state. This is used to modify the 4528 configuration of the WTP while it is operational. 4530 When a WTP receives a Configuration Update Request message, it 4531 responds with a Configuration Update Response message, with a Result 4532 Code message element indicating the result of the configuration 4533 request. 4535 The AC includes the Image Identifier and Initiate Download message 4536 elements to force the WTP to update its firmware while in the Run 4537 state. The WTP MAY proceed to download the requested firmware if it 4538 determines the version specified in the Image Identifier message 4539 element is not in its non-volatile storage (see Section 9.1.1). 4541 The Configuration Update Request is sent by the AC when in the Run 4542 State. The WTP does not transmit this message. 4544 One or more of the following message elements MAY be included in the 4545 Configuration Update message. 4547 o AC Name with Index, see Section 4.6.5 4549 o AC Timestamp, see Section 4.6.6 4551 o Add MAC ACL Entry, see Section 4.6.7 4553 o Add Static MAC ACL Entry, see Section 4.6.9 4555 o CAPWAP Timers, see Section 4.6.12 4557 o Decryption Error Report Period, see Section 4.6.16 4559 o Delete MAC ACL Entry, see Section 4.6.17 4561 o Delete Static MAC ACL Entry, see Section 4.6.19 4563 o Idle Timeout, see Section 4.6.23 4565 o Location Data, see Section 4.6.28 4567 o Radio Administrative State, see Section 4.6.31 4569 o Statistics Timer, see Section 4.6.36 4570 o WTP Fallback, see Section 4.6.40 4572 o WTP Name, see Section 4.6.45 4574 o WTP Static IP Address Information, see Section 4.6.49 4576 o Image Identifier, see Section 4.6.25 4578 o Initiate Download, see Section 4.6.27 4580 8.5. Configuration Update Response 4582 The Configuration Update Response message is the acknowledgement 4583 message for the Configuration Update Request message. 4585 The Configuration Update Response message is sent by a WTP after 4586 receiving a Configuration Update Request message. 4588 When an AC receives a Configuration Update Response message the 4589 result code indicates if the WTP successfully accepted the 4590 configuration. 4592 The Configuration Update Response message is sent by the WTP when in 4593 the Run State. The AC does not transmit this message. 4595 The following message element MUST be present in the Configuration 4596 Update message. 4598 Result Code, see Section 4.6.33 4600 The following message elements MAY be present in the Configuration 4601 Update Response message. 4603 o Radio Operational State, see Section 4.6.32 4605 8.6. Change State Event Request 4607 The Change State Event Request message is used by the WTP for two 4608 main purposes: 4610 o When sent by the WTP following the reception of a Configuration 4611 Status Response message from the AC, the WTP uses the Change State 4612 Event Request message to provide an update on the WTP radio's 4613 operational state and to confirm that the configuration provided 4614 by the AC was successfully applied. 4616 o When sent during the Run state, the WTP uses the Change State 4617 Event Request message to notify the AC of an unexpected change in 4618 the WTP's radio operational state. 4620 When an AC receives a Change State Event Request message it responds 4621 with a Change State Event Response message and modifies its data 4622 structures for the WTP as needed. The AC MAY decide not to provide 4623 service to the WTP if it receives an error, based on local policy, 4624 and to transition to the Reset state. 4626 The Change State Event Request message is sent by a WTP to 4627 acknowledge or report an error condition to the AC for a requested 4628 configuration in the Configuration Status Response message. The 4629 Change State Event Request message includes the Result Code message 4630 element, which indicates whether the configuration was successfully 4631 applied. If the WTP is unable to apply a specfic configuration 4632 request, it indicates the failure by including one or more Returned 4633 Message Element message elements (see Section 4.6.34). 4635 The Change State Event Request message is sent by the WTP in the 4636 Configure or Run State. The AC does not transmit this message. 4638 The WTP MAY save its configuration to persistent storage prior to 4639 transmitting the response. However, this is implementation specific 4640 and is not required. 4642 The following message elements MUST be present in the Change State 4643 Event Request message. 4645 o Radio Operational State, see Section 4.6.32 4647 o Result Code, see Section 4.6.33 4649 One or more of the following message elements MAY be present in the 4650 Change State Event Request message. 4652 o Returned Message Element(s), see Section 4.6.34 4654 8.7. Change State Event Response 4656 The Change State Event Response message acknowledges the Change State 4657 Event Request message. 4659 A Change State Event Response message is sent by an AC in response to 4660 a Change State Event Request message. 4662 The Change State Event Response message is sent by the AC when in the 4663 Configure or Run state. The WTP does not transmit this message. 4665 The Change State Event Response message carries no message elements. 4667 The WTP does not take any action upon receipt of the Change State 4668 Event Response message. 4670 8.8. Clear Configuration Request 4672 The Clear Configuration Request message is used to reset the WTP 4673 configuration. 4675 The Clear Configuration Request message is sent by an AC to request 4676 that a WTP reset its configuration to the manufacturing default 4677 configuration. The Clear Config Request message is sent while in the 4678 Run state. 4680 The Clear Configuration Request is sent by the AC when in the Run 4681 State. The WTP does not transmit this message. 4683 The Clear Configuration Request message carries no message elements. 4685 When a WTP receives a Clear Configuration Request message it resets 4686 its configuration to the manufacturing default configuration. 4688 8.9. Clear Configuration Response 4690 The Clear Configuration Response message is sent by the WTP after 4691 receiving a Clear Configuration Request message and resetting its 4692 configuration parameters to the manufacturing default values. 4694 The Clear Configuration Response is sent by the WTP when in the Run 4695 State. The AC does not transmit this message. 4697 The Clear Configuration Request message MUST include the following 4698 message element. 4700 o Result Code, see Section 4.6.33 4702 9. Device Management Operations 4704 This section defines CAPWAP operations responsible for debugging, 4705 gathering statistics, logging, and firmware management. 4707 9.1. Firmware Management 4709 This section describes the firmware download procedures used by the 4710 CAPWAP protocol. Firmware download can occur during the Image Data 4711 or Run state. 4713 Figure 4 provides an example of a WTP that performs a firmware 4714 upgrade while in the Image Data state. In this example, the WTP does 4715 not already have the requested firmware (Image Identifier = x), and 4716 downloads the image from the AC. 4718 WTP AC 4720 Join Request 4721 --------------------------------------------------------> 4723 Join Response (Image Identifier = x) 4724 <------------------------------------------------------ 4726 Image Data Request (Image Identifier = x) 4727 --------------------------------------------------------> 4729 Image Data Response (Result Code = Success, 4730 Image Information = {size,hash}, 4731 Initiate Download) 4732 <------------------------------------------------------ 4734 Image Data Request (Image Data = Data) 4735 <------------------------------------------------------ 4737 Image Data Response (Result Code = Success) 4738 --------------------------------------------------------> 4740 ..... 4742 Image Data Request (Image Data = EOF) 4743 <------------------------------------------------------ 4745 Image Data Response (Result Code = Success) 4746 --------------------------------------------------------> 4748 (WTP enters the Reset State) 4750 Figure 4: WTP Firmware Download Case 1 4752 Figure 5 provides an example in which the WTP has the image specified 4753 by the AC in its non-volative storage. The WTP opts to NOT download 4754 the firmware and immediately reset. 4756 WTP AC 4758 Join Request 4759 --------------------------------------------------------> 4761 Join Response (Image Identifier = x) 4762 <------------------------------------------------------ 4764 (WTP enters the Reset State) 4766 Figure 5: WTP Firmware Download Case 2 4768 Figure 6 provides an example of a WTP that performs a firmware 4769 upgrade while in the Run state. This mode of firmware upgrade allows 4770 the WTP to download its image while continuing to provide service. 4771 The WTP will not automatically reset until it is notified by the AC, 4772 with a Reset Request message. 4774 WTP AC 4776 Configuration Update Request (Image Identifier = x) 4777 <------------------------------------------------------ 4779 Configuration Update Response (Result Code = Success) 4780 --------------------------------------------------------> 4782 Image Data Request (Image Identifier = x) 4783 --------------------------------------------------------> 4785 Image Data Response (Result Code = Success, 4786 Image Information = {size,hash}, 4787 Initiate Download) 4788 <------------------------------------------------------ 4790 Image Data Request (Image Data = Data) 4791 <------------------------------------------------------ 4793 Image Data Response (Result Code = Success) 4794 --------------------------------------------------------> 4796 ..... 4798 Image Data Request (Image Data = EOF) 4799 <------------------------------------------------------ 4801 Image Data Response (Result Code = Success) 4802 --------------------------------------------------------> 4804 ..... 4806 (administratively requested reboot request) 4807 Reset Request (Image Identifier = x) 4808 <------------------------------------------------------ 4810 Reset Response (Result Code = Success) 4811 --------------------------------------------------------> 4813 Figure 6: WTP Firmware Download Case 3 4815 Figure 7 provides another example of the firmware download while in 4816 the Run state. In this example, the WTP already has the image 4817 specified by the AC in its non-volative storage. The WTP opts to NOT 4818 download the firmware. The WTP resets upon receipt of a Reset 4819 Request message from the AC. 4821 WTP AC 4823 Configuration Update Request (Image Identifier = x, 4824 Image Information = {size,hash}, 4825 Initiate Download) 4826 <------------------------------------------------------ 4828 Configuration Update Response (Result Code = Already Have Image) 4829 --------------------------------------------------------> 4831 ..... 4833 (administratively requested reboot request) 4834 Reset Request (Image Identifier = x) 4835 <------------------------------------------------------ 4837 Reset Response (Result Code = Success) 4838 --------------------------------------------------------> 4840 Figure 7: WTP Firmware Download Case 4 4842 9.1.1. Image Data Request 4844 The Image Data Request message is used to update firmware on the WTP. 4845 This message and its companion Response message are used by the AC to 4846 ensure that the image being run on each WTP is appropriate. 4848 Image Data Request messages are exchanged between the WTP and the AC 4849 to download a new firmware image to the WTP. When a WTP or AC 4850 receives an Image Data Request message it responds with an Image Data 4851 Response message. The message elements contained within the Image 4852 Data Request message are required to determine the intent of the 4853 request. 4855 The decision that new firmware is to be downloaded to the WTP can 4856 occur in one of two ways: 4858 When the WTP joins the AC, the Join Response message includes the 4859 Image Identifier message element, which informs the WTP of the 4860 firmware it is expected to run. if the WTP does not currently have 4861 the requested firmware version, it transmits an Image Data Request 4862 message, with the appropriate Image Identifier message element. 4863 If the WTP already has the requested firmware, it simply resets. 4865 Once the WTP is in the Run state, it is possible for the AC to 4866 cause the WTP to initiate a firmware download by sending a 4867 Configuration Update Request message with the Initiate Download 4868 and and Image Identifier message elements. The WTP then transmits 4869 the Image Data Request message, which includes the Image 4870 Identifier message element to start the download process. Note 4871 that when the firmware is downloaded in this way, the WTP does not 4872 automatically reset after the download is complete. The WTP will 4873 only reset when it receives a Reset Request message from the AC. 4874 If the WTP already had the requested firmware version in its non- 4875 volatile storage, the WTP does not transmit the Image Data Request 4876 message and responds with a Configuration Update Response message 4877 with the Result Code set to Image Already Present. 4879 Regardless of how the download was initiated, once the AC receives an 4880 Image Data Request message with the Image Identifier message element, 4881 it begins the transfer process by transmitting an Image Data Request 4882 message that includes the Image Data message element. This continues 4883 until the firmware image has been transfered. 4885 The Image Data Request message is sent by the WTP or the AC when in 4886 the Image Data or Run State. 4888 The following message elements MAY be included in the Image Data 4889 Request message. 4891 o Image Data, see Section 4.6.24 4893 o Image Identifier, see Section 4.6.25 4895 9.1.2. Image Data Response 4897 The Image Data Response message acknowledges the Image Data Request 4898 message. 4900 An Image Data Response message is sent in response to a received 4901 Image Data Request message. Its purpose is to acknowledge the 4902 receipt of the Image Data Request message. The Result Code is 4903 included to indicate whether a previously sent Image Data Request 4904 message was invalid. 4906 The Image Data Response message is sent by the WTP or the AC when in 4907 the Image Data or Run State. 4909 The following message element MUST be included in the Image Data 4910 Response message. 4912 o Result Code, see Section 4.6.33 4914 The following message elements MAY be included in the Image Data 4915 Response message. 4917 o Image Information, see Section 4.6.26 4919 o Initiate Download, see Section 4.6.27 4921 Upon receiving an Image Data Response message indicating an error, 4922 the WTP MAY retransmit a previous Image Data Reqest message, or 4923 abandon the firmware download to the WTP by transitioning to the 4924 Reset state. 4926 9.2. Reset Request 4928 The Reset Request message is used to cause a WTP to reboot. 4930 A Reset Request message is sent by an AC to cause a WTP to 4931 reinitialize its operation. 4933 The Reset Request is sent by the AC when in the Run State. The WTP 4934 does not transmit this message. 4936 The following message elements MUST be included in the Reset Request 4937 message. 4939 o Image Identifier, see Section 4.6.25 4941 When a WTP receives a Reset Request message, it responds with a Reset 4942 Response message indicating success and then reinitialize itself. If 4943 the WTP is unable to write to its non-volatile storage, to ensure 4944 that it runs the requested software version indicated in the Image 4945 Identifier message element, it MAY send the appropriate Result Code 4946 message element, but MUST reboot. If the WTP is unable to reset, 4947 including a hardware reset, it sends a Reset Response message to the 4948 AC with a Result Code message element indicating failure. The AC no 4949 longer provides service to the WTP. 4951 9.3. Reset Response 4953 The Reset Response message acknowledges the Reset Request message. 4955 A Reset Response message is sent by the WTP after receiving a Reset 4956 Request message. 4958 The Reset Response is sent by the WTP when in the Run State. The AC 4959 does not transmit this message. 4961 The following message element MAY be included in the Image Data 4962 Request message. 4964 o Result Code, see Section 4.6.33 4966 When an AC receives a successful Reset Response message, it is 4967 notified that the WTP will reinitialize its operation. An AC that 4968 receives a Reset Response message indicating failure may opt to no 4969 longer provide service to the WTP. 4971 9.4. WTP Event Request 4973 The WTP Event Request message is used by a WTP to send information to 4974 its AC. The WTP Event Request message MAY be sent periodically, or 4975 sent in response to an asynchronous event on the WTP. For example, a 4976 WTP MAY collect statistics and use the WTP Event Request message to 4977 transmit the statistics to the AC. 4979 When an AC receives a WTP Event Request message it will respond with 4980 a WTP Event Response message. 4982 The presence of the Delete Station message element is used by the WTP 4983 to inform the AC that it is no longer providing service to the 4984 station. This could be the result of an Idle Timeout (see 4985 Section 4.6.23), due to to resource shortages, or some other reason. 4987 The WTP Event Request message is sent by the WTP when in the Run 4988 State. The AC does not transmit this message. 4990 The WTP Event Request message MUST contain one of the message 4991 elements listed below, or a message element that is defined for a 4992 specific wireless technology. More than one of each messsage element 4993 listed MAY be included in the WTP Event Request message. 4995 o Decryption Error Report, see Section 4.6.15 4997 o Duplicate IPv4 Address, see Section 4.6.21 4999 o Duplicate IPv6 Address, see Section 4.6.22 5001 o WTP Operational Statistics, see Section 4.6.46 5003 o WTP Radio Statistics, see Section 4.6.47 5005 o WTP Reboot Statistics, see Section 4.6.48 5007 o Delete Station, see Section 4.6.18 5009 9.5. WTP Event Response 5011 The WTP Event Response message acknowledges receipt of the WTP Event 5012 Request message. 5014 A WTP Event Response message is sent by an AC after receiving a WTP 5015 Event Request message. 5017 The WTP Event Response message is sent by the AC when in the Run 5018 State. The WTP does not transmit this message. 5020 The WTP Event Response message carries no message elements. 5022 9.6. Data Transfer Request 5024 The Data Transfer Request message is used to deliver debug 5025 information from the WTP to the AC. 5027 Data Transfer Request messages are sent by the WTP to the AC when the 5028 WTP determines that it has important information to send to the AC. 5029 For instance, if the WTP detects that its previous reboot was caused 5030 by a system crash, it can send the crash file to the AC. The remote 5031 debugger function in the WTP also uses the Data Transfer Request 5032 message to send console output to the AC for debugging purposes. 5034 When the AC receives a Data Transfer Request message it responds to 5035 the WTP with a Data Transfer Response message. The AC MAY log the 5036 information received. 5038 The Data Transfer Request message is sent by the WTP when in the Run 5039 State. The AC does not transmit this message. 5041 The Data Transfer Request message MUST contain one of the message 5042 elements listed below. 5044 o Data Transfer Data, see Section 4.6.13 5046 o Data Transfer Mode, see Section 4.6.14 5048 9.7. Data Transfer Response 5050 The Data Transfer Response message acknowledges the Data Transfer 5051 Request message. 5053 A Data Transfer Response message is sent in response to a received 5054 Data Transfer Request message. Its purpose is to acknowledge receipt 5055 of the Data Transfer Request message. 5057 The Data Transfer Response message is sent by the AC when in the Run 5058 State. The WTP does not transmit this message. 5060 The Data Transfer Response message carries no message elements. 5062 Upon receipt of a Data Transfer Response message, the WTP transmits 5063 more information, if more information is available. 5065 10. Station Session Management 5067 Messages in this section are used by the AC to create, modify or 5068 delete station session state on the WTPs. 5070 10.1. Station Configuration Request 5072 The Station Configuration Request message is used to create, modify 5073 or delete station session state on a WTP. The message is sent by the 5074 AC to the WTP, and MAY contain one or more message elements. The 5075 message elements for this CAPWAP control message include information 5076 that is generally highly technology specific. Refer to the 5077 appropriate binding document for definitions of the messages elements 5078 that are included in this control message. 5080 The Station Configuration Request message is sent by the AC when in 5081 the Run State. The WTP does not transmit this message. 5083 The following CAPWAP Control message elements MAY be included in the 5084 Station Configuration Request message. More than one of each message 5085 element listed MAY be included in the Station Configuration Request 5086 message. 5088 o Add Station, see Section 4.6.8 5090 o Delete Station, see Section 4.6.18 5092 10.2. Station Configuration Response 5094 The Station Configuration Response message is used to acknowledge a 5095 previously received Station Configuration Request message. 5097 The Station Configuration Response message is sent by the WTP when in 5098 the Run State. The AC does not transmit this message. 5100 The following message element MUST be present in the Station 5101 Configuration Response message. 5103 o Result Code, see Section 4.6.33 5105 The Result Code message element indicates that the requested 5106 configuration was successfully applied, or that an error related to 5107 processing of the Station Configuration Request message occurred on 5108 the WTP. 5110 11. NAT Considerations 5112 There are three specific situations in which a NAT deployment may be 5113 used in conjunction with a CAPWAP-enabled deployment. The first 5114 consists of a configuration in which a single WTP is behind a NAT 5115 system. Since all communication is initiated by the WTP, and all 5116 communication is performed over IP using two UDP ports, the protocol 5117 easily traverses NAT systems in this configuration. 5119 In the second case, two or more WTPs are deployed behind the same NAT 5120 system. Here, the AC would receive multiple connection requests from 5121 the same IP address, and cannot differentiate the originating WTP of 5122 the connection requests. The CAPWAP Data Check state, which 5123 establishes the data plane connection and communicates the Data 5124 Keepalive, includes the Session Identifier message element, which is 5125 used to bind the control and data plane. Use of the Session 5126 Identifier message element enables the AC to match the control and 5127 data plane flows from multiple WTPs behind the same NAT system 5128 (multiple WTPs sharing the same IP address). 5130 In the third configuration, the AC is deployed behind a NAT. Two 5131 issues exist in this situation. First, an AC communicates its 5132 interfaces and corresponding WTP load using the CAPWAP Control 5133 IP(v4/v6) Address message element. This message element is currently 5134 mandatory, and if NAT compliance becomes an issue, it is possible to 5135 either: 5137 1. Make the CAPWAP Control IP (v4/v6) Address optional, allowing the 5138 WTP to use the known IP Address. Note that this approach 5139 eliminates the ability to perform load balancing of WTP across 5140 ACs, and therefore is not the recommended approach. 5142 2. Allow an AC to configure a NAT'ed address for every AC that would 5143 otherwise be communicated in the CAPWAP Control IP (v4/v6) Address 5144 message element. 5146 3. Require that if a WTP determines that the AC List message element 5147 contains a set of IP Addresses that are different from the AC IP 5148 Address the WTP is currently using, then assume that NAT is 5149 present, and require that the WTP communicate with the AC IP 5150 Address (and ignore the CAPWAP Control IP (v4/v6) Address message 5151 element(s)). 5153 The CAPWAP protocol allows for all of the AC identities supporting a 5154 group of WTPs to be communicated through the AC List message element. 5155 This feature MUST be disabled when the AC is behind a NAT and the IP 5156 Address that is embedded is invalid. 5158 The CAPWAP protocol allows an AC to configure a static IP address on 5159 a WTP using the WTP Static IP Address Information message element. 5160 This message element SHOULD NOT be used in NAT'ed environments, 5161 unless the administrator is familiar with the internal IP addressing 5162 scheme within the WTP's private network, and does not rely on the 5163 public address seen by the AC. 5165 When a WTP detects the duplicate address condition, it generates a 5166 message to the AC, which includes the Duplicate IP Address message 5167 element. The IP Address embedded within this message element is 5168 different from the public IP address seen by the AC. 5170 When CAPWAP is run over IPv6, NAT support can only be provided if the 5171 IPv6 NAT system is capable of performing address translation over the 5172 UDP-Lite 3828 protocol [11]. A protocol interoperability issues will 5173 exist if the NAT system is being utilized for IPv4/IPv6 address 5174 translation. 5176 12. Security Considerations 5178 This section describes security considerations for the CAPWAP 5179 protocol. It also provides security recommendations for protocols 5180 used in conjunction with CAPWAP. 5182 12.1. CAPWAP Security 5184 As it is currently specified, the CAPWAP protocol sits between the 5185 security mechanisms specified by the wireless link layer protocol 5186 (e.g.IEEE 802.11i) and AAA. One goal of CAPWAP is to bootstrap trust 5187 between the STA and WTP using a series of preestablished trust 5188 relationships: 5190 STA WTP AC AAA 5191 ============================================== 5193 DTLS Cred AAA Cred 5194 <------------><-------------> 5196 EAP Credential 5197 <------------------------------------------> 5199 wireless link layer 5200 (e.g.802.11 PTK) 5201 <--------------> or 5202 <---------------------------> 5203 (derived) 5205 Within CAPWAP, DTLS is used to secure the link between the WTP and 5206 AC. In addition to securing control messages, it's also a link in 5207 this chain of trust for establishing link layer keys. Consequently, 5208 much rests on the security of DTLS. 5210 In some CAPWAP deployment scenarios, there are two channels between 5211 the WTP and AC: the control channel, carrying CAPWAP control 5212 messages, and the data channel, over which client data packets are 5213 tunneled between the AC and WTP. Typically, the control channel is 5214 secured by DTLS, while the data channel is not. 5216 The use of parallel protected and unprotected channels deserves 5217 special consideration, but does not create a threat. There are two 5218 potential concerns: attempting to convert protected data into un- 5219 protected data and attempting to convert un-protected data into 5220 protected data. These concerns are addressed below. 5222 12.1.1. Converting Protected Data into Unprotected Data 5224 Since CAPWAP does not support authentication-only ciphers (i.e. all 5225 supported ciphersuites include encryption and authentication), it is 5226 not possible to convert protected data into unprotected data. Since 5227 encrypted data is (ideally) indistinguishable from random data, the 5228 probability of an encrypted packet passing for a well-formed packet 5229 is effectively zero. 5231 12.1.2. Converting Unprotected Data into Protected Data (Insertion) 5233 The use of message authentication makes it impossible for the 5234 attacker to forge protected records. This makes conversion of 5235 unprotected records to protected records impossible. 5237 12.1.3. Deletion of Protected Records 5239 An attacker could remove protected records from the stream, though 5240 not undetectably so, due the built-in reliability of the underlying 5241 CAPWAP protocol. In the worst case, the attacker would remove the 5242 same record repeatedly, resulting in a CAPWAP session timeout and 5243 restart. This is effectively a DoS attack, and could be accomplished 5244 by a man in the middle regardless of the CAPWAP protocol security 5245 mechanisms chosen. 5247 12.1.4. Insertion of Unprotected Records 5249 An attacker could inject packets into the unprotected channel, but 5250 this may become evident if sequence number desynchronization occurs 5251 as a result. Only if the attacker is a MiM can packets be inserted 5252 undetectably. This is a consequence of that channel's lack of 5253 protection, and not a new threat resulting from the CAPWAP security 5254 mechanism. 5256 12.2. Session ID Security 5258 Since DTLS does not export a unique session identifier, there can be 5259 no explicit protocol binding between the DTLS layer and CAPWAP layer. 5260 As a result, implementations MUST provide a mechanism for performing 5261 this binding. For example, an AC MUST NOT associate decrypted DTLS 5262 control packets with a particular WTP session based solely on the 5263 Session ID in the packet header. Instead, identification should be 5264 done based on which DTLS session decrypted the packet. Otherwise one 5265 authenticated WTP could spoof another authenticated WTP by altering 5266 the Session ID in the encrypted CAPWAP header. 5268 It should be noted that when the CAPWAP data channel is unencrypted, 5269 the WTP Session ID is exposed and possibly known to adversaries and 5270 other WTPs. This would allow the forgery of the source of data- 5271 channel traffic. This, however, should not be a surprise for 5272 unencrypted data channels. When the data channel is encrypted, the 5273 Session ID is not exposed, and therefore can safely be used to 5274 associate a data and control channel. The 64-bit length of the 5275 Session ID mitigates online guessing attacks where an adversarial, 5276 authenticated WTP tries to correlate his own data channel with 5277 another WTP's control channel. Note that for encrypted data 5278 channels, the Session ID should only be used for correlation for the 5279 first packet immediately after the initial DTLS handshake. Future 5280 correlation should instead be done via identification of a packet's 5281 DTLS session. 5283 12.3. Discovery Attacks 5285 Since the Discovery Request messages are sent in the clear, it is 5286 important that AC implementations NOT assume that receiving such a 5287 request from a WTP implies that it has rebooted, and consequently 5288 tear down any active DTLS sessions. Discovery Request messages can 5289 easily be spoofed by malicious devices, so it is important that the 5290 AC maintain two separate sets of states for the WTP until the 5291 DTLSSessionEstablished notification is received, indicating that the 5292 WTP was authenticated. Once a new DTLS session is successfully 5293 established, any state referring to the old session can be cleared. 5295 12.4. Interference with a DTLS Session 5297 If a WTP or AC repeatedly receives packets which fail DTLS 5298 authentication or decryption, this could indicate a DTLS 5299 desynchronization between the AC and WTP, a link prone to 5300 undetectable bit errors, or an attacker trying to disrupt a DTLS 5301 session. 5303 In the state machine (section 2.3), transitions to the DTLS tear down 5304 state can be triggered by frequently receiving DTLS packets with 5305 authentication or decryption errors. The threshold or technique for 5306 deciding when to move to the tear down state should be chosen 5307 carefully. Being able to easily transition to DTLS TD allows easy 5308 detection of malfunctioning devices, but allows for denial of service 5309 attacks. Making it difficult to transition to DTLS TD prevents 5310 denial of service attacks, but makes it more difficult to detect and 5311 reset a malfunctioning session. Implementers should set this policy 5312 with care. 5314 12.5. Use of Preshared Keys in CAPWAP 5316 While use of preshared keys may provide deployment and provisioning 5317 advantages not found in public key based deployments, it also 5318 introduces a number of operational and security concerns. In 5319 particular, because the keys must typically be entered manually, it 5320 is common for people to base them on memorable words or phrases. 5321 These are referred to as "low entropy passwords/passphrases". 5323 Use of low-entropy preshared keys, coupled with the fact that the 5324 keys are often not frequently updated, tends to significantly 5325 increase exposure. For these reasons, the following recommendations 5326 are made: 5328 o When DTLS is used with a preshared-key (PSK) ciphersuite, each WTP 5329 SHOULD have a unique PSK. Since WTPs will likely be widely 5330 deployed, their physical security is not guaranteed. If PSKs are 5331 not unique for each WTP, key reuse would allow the compromise of 5332 one WTP to result in the compromise of others 5334 o Generating PSKs from low entropy passwords is NOT RECOMMENDED. 5336 o It is RECOMMENDED that implementations that allow the 5337 administrator to manually configure the PSK also provide a 5338 capability for generation of new random PSKs, taking RFC 4086 [2] 5339 into account. 5341 o Preshared keys SHOULD be periodically updated. Implementations 5342 MAY facilitate this by providing an administrative interface for 5343 automatic key generation and periodic update, or it MAY be 5344 accomplished manually instead. 5346 Every pairwise combination of WTP and AC on the network SHOULD have a 5347 unqiue PSK. This prevents the domino effect (see Guidance for AAA 5348 Key Management [16]). If PSKs are tied to specific WTPs, then 5349 knowledge of the PSK implies a binding to a specified identity that 5350 can be authorized. 5352 If PSKs are shared, this binding between device and identity is no 5353 longer possible. Compromise of one WTP can yield compromise of 5354 another WTP, violating the CAPWAP security hierarchy. Consequently, 5355 sharing keys between WTPs is NOT RECOMMENDED. 5357 12.6. Use of Certificates in CAPWAP 5359 For public-key-based DTLS deployments, each device SHOULD have unique 5360 credentials, with an extended key usage authorizing the device to act 5361 as either a WTP or AC. If devices do not have unique credentials, it 5362 is possible that by compromising one device, any other device using 5363 the same credential may also be considered to be compromised. 5365 Certificate validation involves checking a large variety of things. 5367 Since the necessary things to validate are often environment- 5368 specific, many are beyond the scope of this document. In this 5369 section, we provide some basic guidance on certificate validation. 5371 Each device is responsible for authenticating and authorizing devices 5372 with which they communicate. Authentication entails validation of 5373 the chain of trust leading to the peer certificate, followed by the 5374 the peer certificate itself. At a minimum, devices SHOULD use SSH- 5375 style certificate caching to guarantee consistency. If devices have 5376 access to a certificate authority, they SHOULD properly validate the 5377 trust chain. Implementations SHOULD also provide a secure method for 5378 verifying that the credential in question has not been revoked. 5380 Note that if the WTP relies on the AC for network connectivity (e.g. 5381 the AC is a layer 2 switch to which the WTP is directly connected), 5382 the WTP may not be able to contact an OCSP server or otherwise obtain 5383 an up to date CRL if a compromised AC doesn't explicitly permit this. 5384 This cannot be avoided, except through effective physical security 5385 and monitoring measures at the AC. 5387 Proper validation of certificates typically requires checking to 5388 ensure the certificate has not yet expired. If devices have a real- 5389 time clock, they SHOULD verify the certificate validity dates. If no 5390 real-time clock is available, the device SHOULD make a best-effort 5391 attempt to validate the certificate validity dates through other 5392 means. Failure to check a certificate's temporal validity can make a 5393 device vulnerable to man-in-the-middle attacks launched using 5394 compromised, expired certificates, and therefore devices should make 5395 every effort to perform this validation. 5397 12.7. AAA Security 5399 The AAA protocol is used to distribute EAP keys to the ACs, and 5400 consequently its security is important to the overall system 5401 security. When used with TLS or IPsec, security guidelines specified 5402 in RFC 3539 [5] SHOULD be followed. 5404 In general, the link between the AC and AAA server SHOULD be secured 5405 using a strong ciphersuite keyed with mutually authenticated session 5406 keys. Implementations SHOULD NOT rely solely on Basic RADIUS shared 5407 secret authentication as it is often vulnerable to dictionary 5408 attacks, but rather SHOULD use stronger underlying security 5409 mechanisms. 5411 13. Management Considerations 5413 The CAPWAP protocol assumes that it is the only configuration 5414 interface to the WTP to configure parameters that are specified in 5415 the CAPWAP specifications. While the use of a separate management 5416 protocol MAY be used for the purposes of monitoring the WTP directly, 5417 configuring the WTP through a separate management interface is not 5418 recommended. Configuring the WTP through a separate protocol, such 5419 as via a CLI or SNMP, could lead to the AC state being out of sync 5420 with the WTP. 5422 14. IANA Considerations 5424 A separate UDP port for data channel communications is (currently) 5425 the selected demultiplexing mechanism, and a port must be assigned 5426 for this purpose in Section 3.1. The UDP port numbers are listed by 5427 IANA at http://www.iana.org/assignments/port-numbers. 5429 IANA needs to assign an organization local multicast address called 5430 the "All ACs multicast address" from the IPv6 multicast address 5431 registry in Section 3.3 5433 14.1. CAPWAP Message Types 5435 The Message Type field in the CAPWAP header (Section 4.5.1.1) is used 5436 to identify the operation performed by the message. There are 5437 multiple namespaces, which is identified via the first three octets 5438 of the field containing the IANA Enterprise Number [10]. When the 5439 Enterprise Number is set to zero, the message types are reserved for 5440 use by the base CAPWAP specification which are controlled and 5441 maintained by IANA and requires a Standards Action. 5443 14.2. Wireless Binding Identifiers 5445 The Wireless Binding Identifier (WBID) field in the CAPWAP header 5446 (Section 4.3) is used to identify the wireless technology associated 5447 with the packet. Due to the limited address space available, a new 5448 WBID request requires Standards Action. 5450 15. Acknowledgements 5452 The following individuals are acknowledged for their contributions to 5453 this protocol specification: Puneet Agarwal, Saravanan Govindan, 5454 Peter Nilsson, and David Perkins. 5456 Michael Vakulenko contributed text to describe how CAPWAP can be used 5457 over layer 3 (IP/UDP) networks. 5459 16. References 5461 16.1. Normative References 5463 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 5464 Levels", BCP 14, RFC 2119, March 1997. 5466 [2] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 5467 Requirements for Security", BCP 106, RFC 4086, June 2005. 5469 [3] Mills, D., "Network Time Protocol (Version 3) Specification, 5470 Implementation", RFC 1305, March 1992. 5472 [4] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 5473 Public Key Infrastructure Certificate and Certificate 5474 Revocation List (CRL) Profile", RFC 3280, April 2002. 5476 [5] Aboba, B. and J. Wood, "Authentication, Authorization and 5477 Accounting (AAA) Transport Profile", RFC 3539, June 2003. 5479 [6] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for 5480 Transport Layer Security (TLS)", RFC 4279, December 2005. 5482 [7] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 5483 Protocol Version 1.1", RFC 4346, April 2006. 5485 [8] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 5486 Security", RFC 4347, April 2006. 5488 [9] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 5489 Extensions", RFC 2132, March 1997. 5491 [10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 5492 Considerations Section in RFCs", BCP 26, RFC 2434, 5493 October 1998. 5495 [11] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. 5496 Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)", 5497 RFC 3828, July 2004. 5499 [12] Calhoun, P., Montemurro, M., Stanley, D., "CAPWAP Protocol 5500 Binding for IEEE 802.11", draft-ietf-capwap-protocol- 5501 binding-ieee80211-04 (work in progress), June 2007. 5503 [13] Calhoun, P., "CAPWAP Access Controller DHCP Option", 5504 draft-ietf-capwap-dhc-ac-option-00 (work in progress), 5505 June 2007. 5507 16.2. Informational References 5509 [14] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On- 5510 line Database", RFC 3232, January 2002. 5512 [15] Manner, J. and M. Kojo, "Mobility Related Terminology", 5513 RFC 3753, June 2004. 5515 [16] Housley, R. and B. Aboba, "Guidance for AAA Key Management", 5516 draft-housley-aaa-key-mgmt-09 (work in progress), 5517 February 2007. 5519 [17] Modadugu et al, N., "The Design and Implementation of Datagram 5520 TLS", Feb 2004. 5522 [18] IEEE, "Guidelines for use of a 48-bit Extended Unique 5523 Identifier", Dec 2005. 5525 [19] IEEE, "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) 5526 REGISTRATION AUTHORITY". 5528 Editors' Addresses 5530 Pat R. Calhoun 5531 Cisco Systems, Inc. 5532 170 West Tasman Drive 5533 San Jose, CA 95134 5535 Phone: +1 408-853-5269 5536 Email: pcalhoun@cisco.com 5538 Michael P. Montemurro 5539 Research In Motion 5540 5090 Commerce Blvd 5541 Mississauga, ON L4W 5M4 5542 Canada 5544 Phone: +1 905-629-4746 x4999 5545 Email: mmontemurro@rim.com 5547 Dorothy Stanley 5548 Aruba Networks 5549 1322 Crossman Ave 5550 Sunnyvale, CA 94089 5552 Phone: +1 630-363-1389 5553 Email: dstanley@arubanetworks.com 5555 Full Copyright Statement 5557 Copyright (C) The IETF Trust (2007). 5559 This document is subject to the rights, licenses and restrictions 5560 contained in BCP 78, and except as set forth therein, the authors 5561 retain all their rights. 5563 This document and the information contained herein are provided on an 5564 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 5565 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 5566 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 5567 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 5568 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 5569 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 5571 Intellectual Property 5573 The IETF takes no position regarding the validity or scope of any 5574 Intellectual Property Rights or other rights that might be claimed to 5575 pertain to the implementation or use of the technology described in 5576 this document or the extent to which any license under such rights 5577 might or might not be available; nor does it represent that it has 5578 made any independent effort to identify any such rights. Information 5579 on the procedures with respect to rights in RFC documents can be 5580 found in BCP 78 and BCP 79. 5582 Copies of IPR disclosures made to the IETF Secretariat and any 5583 assurances of licenses to be made available, or the result of an 5584 attempt made to obtain a general license or permission for the use of 5585 such proprietary rights by implementers or users of this 5586 specification can be obtained from the IETF on-line IPR repository at 5587 http://www.ietf.org/ipr. 5589 The IETF invites any interested party to bring to its attention any 5590 copyrights, patents or patent applications, or other proprietary 5591 rights that may cover technology that may be required to implement 5592 this standard. Please address the information to the IETF at 5593 ietf-ipr@ietf.org. 5595 Acknowledgment 5597 Funding for the RFC Editor function is provided by the IETF 5598 Administrative Support Activity (IASA).