From ecef08edfe5174998ff16c06ec3494ade1e9e329 Mon Sep 17 00:00:00 2001 From: "7u83@mail.ru" <7u83@mail.ru@noemail.net> Date: Mon, 23 Mar 2015 20:21:18 +0000 Subject: [PATCH] More files. FossilOrigin-Name: 1280d5fea1f5b7b657d0997f27388c5022edea08827371ae7caec27b92a45e0a --- ...ietf-capwap-protocol-specification-07.html | 7558 +++++++++++++++++ doc/rfc5416.txt | 4259 ++++++++++ 2 files changed, 11817 insertions(+) create mode 100644 doc/draft-ietf-capwap-protocol-specification-07.html create mode 100644 doc/rfc5416.txt diff --git a/doc/draft-ietf-capwap-protocol-specification-07.html b/doc/draft-ietf-capwap-protocol-specification-07.html new file mode 100644 index 00000000..ef7ecde5 --- /dev/null +++ b/doc/draft-ietf-capwap-protocol-specification-07.html @@ -0,0 +1,7558 @@ + + +
+ + + + + + + + + + + + + + + ++Network Working Group P. Calhoun, Editor +Internet-Draft Cisco Systems, Inc. +Expires: December 13, 2007 M. Montemurro, Editor + Research In Motion + D. Stanley, Editor + Aruba Networks + June 11, 2007 + + + CAPWAP Protocol Specification + draft-ietf-capwap-protocol-specification-07 + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on December 13, 2007. + +Copyright Notice + + Copyright (C) The IETF Trust (2007). + + + + + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 1] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + +Abstract + + This specification defines the Control And Provisioning of Wireless + Access Points (CAPWAP) Protocol. The CAPWAP protocol meets the IETF + CAPWAP working group protocol requirements. The CAPWAP protocol is + designed to be flexible, allowing it to be used for a variety of + wireless technologies. This document describes the base CAPWAP + protocol. The CAPWAP protocol binding which defines extensions for + use with the IEEE 802.11 wireless LAN protocol is available in [12]. + Extensions are expected to be defined to enable use of the CAPWAP + protocol with additional wireless technologies. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 2] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + +1. Introduction + + This document describes the CAPWAP Protocol, a standard, + interoperable protocol which enables an Access Controller (AC) to + manage a collection of Wireless Termination Points (WTPs). The + CAPWAP protocol is defined to be independent of layer 2 technology. + + The emergence of centralized IEEE 802.11 Wireless Local Area Network + (WLAN) architectures, in which simple IEEE 802.11 WTPs are managed by + an Access Controller (AC) suggested that a standards based, + interoperable protocol could radically simplify the deployment and + management of wireless networks. WTPs require a set of dynamic + management and control functions related to their primary task of + connecting the wireless and wired mediums. Traditional protocols for + managing WTPs are either manual static configuration via HTTP, + proprietary Layer 2 specific or non-existent (if the WTPs are self- + contained). An IEEE 802.11 binding is defined in [12] to support use + of the CAPWAP protocol with IEEE 802.11 WLAN networks. + + CAPWAP assumes a network configuration consisting of multiple WTPs + communicating via the Internet Protocol (IP) to an AC. WTPs are + viewed as remote RF interfaces controlled by the AC. The CAPWAP + protocol supports two modes of operation: Split and Local MAC. In + Split MAC mode all L2 wireless data and management frames are + encapsulated via the CAPWAP protocol and exchanged between the AC and + the WTP. As shown in Figure 1, the wireless frames received from a + mobile device, which is referred to in this specification as a + Station (STA), are directly encapsulated by the WTP and forwarded to + the AC. + + +-+ wireless frames +-+ + | |--------------------------------| | + | | +-+ | | + | |--------------| |---------------| | + | |wireless PHY/ | | CAPWAP | | + | | MAC sublayer | | | | + +-+ +-+ +-+ + STA WTP AC + + Figure 1: Representative CAPWAP Architecture for Split MAC + + The Local MAC mode of operation allows for the data frames to be + either locally bridged, or tunneled as 802.3 frames. The latter + implies that the WTP performs the 802 bridging function. In either + case the L2 wireless management frames are processed locally by the + WTP, and then forwarded to the AC. Figure 2 shows the Local MAC + mode, in which a station transmits a wireless frame which is + encapsulated in an 802.3 frame and forwarded to the AC. + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 3] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + +-+wireless frames +-+ 802.3 frames +-+ + | |----------------| |--------------| | + | | | | | | + | |----------------| |--------------| | + | |wireless PHY/ | | CAPWAP | | + | | MAC sublayer | | | | + +-+ +-+ +-+ + STA WTP AC + + Figure 2: Representative CAPWAP Architecture for Local MAC + + Provisioning WTPs with security credentials, and managing which WTPs + are authorized to provide service are traditionally handled by + proprietary solutions. Allowing these functions to be performed from + a centralized AC in an interoperable fashion increases manageability + and allows network operators to more tightly control their wireless + network infrastructure. + +1.1. Goals + + The goals for the CAPWAP protocol are listed below: + + 1. To centralize the authentication and policy enforcement functions + for a wireless network. The AC may also provide centralized + bridging, forwarding, and encryption of user traffic. + Centralization of these functions will enable reduced cost and + higher efficiency by applying the capabilities of network + processing silicon to the wireless network, as in wired LANs. + + 2. To enable shifting of the higher level protocol processing from + the WTP. This leaves the time critical applications of wireless + control and access in the WTP, making efficient use of the + computing power available in WTPs which are the subject to severe + cost pressure. + + 3. To provide a generic encapsulation and transport mechanism, + enabling the CAPWAP protocol to be applied to many access point + types in the future, via a specific wireless binding. + + The CAPWAP protocol concerns itself solely with the interface between + the WTP and the AC. Inter-AC and station-to AC-communication are + strictly outside the scope of this document. + +1.2. Conventions used in this document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [1]. + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 4] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + +1.3. Contributing Authors + + This section lists and acknowledges the authors of significant text + and concepts included in this specification. + + The CAPWAP Working Group selected the Lightweight Access Point + Protocol (LWAPP) [add reference, when available] to be used as the + basis of the CAPWAP protocol specification. The following people are + authors of the LWAPP document: + + Bob O'Hara, Cisco Systems, Inc. + 170 West Tasman Drive, San Jose, CA 95134 + Phone: +1 408-853-5513, Email: bob.ohara@cisco.com + + Pat Calhoun, Cisco Systems, Inc. + 170 West Tasman Drive, San Jose, CA 95134 + Phone: +1 408-853-5269, Email: pcalhoun@cisco.com + + Rohit Suri, Cisco Systems, Inc. + 170 West Tasman Drive, San Jose, CA 95134 + Phone: +1 408-853-5548, Email: rsuri@cisco.com + + Nancy Cam Winget, Cisco Systems, Inc. + 170 West Tasman Drive, San Jose, CA 95134 + Phone: +1 408-853-0532, Email: ncamwing@cisco.com + + Scott Kelly, Aruba Networks + 1322 Crossman Ave, Sunnyvale, CA 94089 + Phone: +1 408-754-8408, Email: skelly@arubanetworks.com + + Michael Glenn Williams, Nokia, Inc. + 313 Fairchild Drive, Mountain View, CA 94043 + Phone: +1 650-714-7758, Email: Michael.G.Williams@Nokia.com + + Sue Hares, Nexthop Technologies, Inc. + 825 Victors Way, Suite 100, Ann Arbor, MI 48108 + Phone: +1 734 222 1610, Email: shares@nexthop.com + + DTLS is used as the security solution for the CAPWAP protocol. The + following people are authors of significant DTLS-related text + included in this document: + + Scott Kelly, Aruba Networks + 1322 Crossman Ave, Sunnyvale, CA 94089 + Phone: +1 408-754-8408, Email: skelly@arubanetworks.com + + Eric Rescorla, Network Resonance + 2483 El Camino Real, #212,Palo Alto CA, 94303 + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 5] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + Email: ekr@networkresonance.com + + The concept of using DTLS to secure the CAPWAP protocol was part of + the Secure Light Access Point Protocol (SLAPP) proposal [add + reference when available]. The following people are authors of the + SLAPP proposal: + + Partha Narasimhan, Aruba Networks + 1322 Crossman Ave, Sunnyvale, CA 94089 + Phone: +1 408-480-4716, Email: partha@arubanetworks.com + + Dan Harkins, Tropos Networks + 555 Del Rey Avenue, Sunnyvale, CA, 95085 + Phone: +1 408 470 7372, Email: dharkins@tropos.com + + Subbu Ponnuswamy, Aruba Networks + 1322 Crossman Ave, Sunnyvale, CA 94089 + Phone: +1 408-754-1213, Email: subbu@arubanetworks.com + + + The following individuals contributed significant security related + text to the draft: + + T. Charles Clancy, Laboratory for Telecommunications Sciences, + 8080 Greenmead Drive, College Park, MD 20740 + Phone: +1 240-373-5069, Email: clancy@ltsnet.net + + Scott Kelly, Aruba Networks + 1322 Crossman Ave, Sunnyvale, CA 94089 + Phone: +1 408-754-8408, Email: skelly@arubanetworks.com + +1.4. Terminology + + Access Controller (AC): The network entity that provides WTPs access + to the network infrastructure in the data plane, control plane, + management plane, or a combination therein. + + CAPWAP Control Channel: A bi-directional flow defined by the AC IP + Address, WTP IP Address, AC control port, WTP control port and the + transport-layer protocol (UDP or UDP-Lite) over which CAPWAP control + packets are sent and received. + + CAPWAP Data Channel: A bi-directional flow defined by the AC IP + Address, WTP IP Address, AC data port, WTP data port, and the + transport-layer protocol (UDP or UDP-Lite) over which CAPWAP data + packets are sent and received. + + Station (STA): A device that contains an IEEE 802.11 conformant + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 6] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + medium access control (MAC) and physical layer (PHY) interface to the + wireless medium (WM). + + Wireless Termination Point (WTP): The physical or network entity that + contains an RF antenna and wireless PHY to transmit and receive + station traffic for wireless access networks. + + This document uses additional terminology defined in [15]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 7] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + +2. Protocol Overview + + The CAPWAP protocol is a generic protocol defining AC and WTP control + and data plane communication via a CAPWAP protocol transport + mechanism. CAPWAP control messages, and optionally CAPWAP data + messages, are secured using Datagram Transport Layer Security (DTLS) + [7]. DTLS is a standards-track IETF protocol based upon TLS. The + underlying security-related protocol mechanisms of TLS have been + successfully deployed for many years. + + The CAPWAP protocol Transport layer carries two types of payload, + CAPWAP Data messages and CAPWAP Control messages. CAPWAP Data + messages encapsulate forwarded wireless frames. CAPWAP protocol + Control messages are management messages exchanged between a WTP and + an AC. The CAPWAP Data and Control packets are sent over separate + UDP ports. Since both data and control packets can exceed the + Maximum Transmission Unit (MTU) length, the payload of a CAPWAP data + or control message can be fragmented. The fragmentation behavior is + defined in Section 3. + + The CAPWAP Protocol begins with a discovery phase. The WTPs send a + Discovery Request message, causing any Access Controller (AC) + receiving the message to respond with a Discovery Response message. + From the Discovery Response messages received, a WTP selects an AC + with which to establish a secure DTLS session. CAPWAP protocol + messages will be fragmented to the maximum length discovered to be + supported by the network. + + Once the WTP and the AC have completed DTLS session establishment, a + configuration exchange occurs in which both devices agree on version + information. During this exchange the WTP may receive provisioning + settings. The WTP is then enabled for operation. + + When the WTP and AC have completed the version and provision exchange + and the WTP is enabled, the CAPWAP protocol is used to encapsulate + the wireless data frames sent between the WTP and AC. The CAPWAP + protocol will fragment the L2 frames if the size of the encapsulated + wireless user data (Data) or protocol control (Management) frames + causes the resulting CAPWAP protocol packet to exceed the MTU + supported between the WTP and AC. Fragmented CAPWAP packets are + reassembled to reconstitute the original encapsulated payload. + + The CAPWAP protocol provides for the delivery of commands from the AC + to the WTP for the management of stations that are communicating with + the WTP. This may include the creation of local data structures in + the WTP for the stations and the collection of statistical + information about the communication between the WTP and the stations. + The CAPWAP protocol provides a mechanism for the AC to obtain + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 8] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + statistical information collected by the WTP. + + The CAPWAP protocol provides for a keep alive feature that preserves + the communication channel between the WTP and AC. If the AC fails to + appear alive, the WTP will try to discover a new AC. + +2.1. Wireless Binding Definition + + The CAPWAP protocol is independent of a specific WTP radio + technology. Elements of the CAPWAP protocol are designed to + accommodate the specific needs of each wireless technology in a + standard way. Implementation of the CAPWAP protocol for a particular + wireless technology MUST follow the binding requirements defined for + that technology. + + When defining a binding for wireless technologies, the authors MUST + include any necessary definitions for technology-specific messages + and all technology-specific message elements for those messages. At + a minimum, a binding MUST provide: + + 1 - The definition for a binding-specific Statistics message + element, carried in the WTP Event Request message + + 2 - A message element carried in the Station Configuration Request + message to configure station information on the WTP + + 3 - A WTP Radio Information message element carried in the + Discovery, Primary Discovery and Join Request and Response + messages, indicating the binding specific radio types supported at + the WTP and AC. + + If technology specific message elements are required for any of the + existing CAPWAP messages defined in this specification, they MUST + also be defined in the technology binding document. + + The naming of binding-specific message elements MUST begin with the + name of the technology type, e.g., the binding for IEEE 802.11, + provided in [12], begins with "IEEE 802.11". + + The CAPWAP binding concept is also used in any future specifications + that add functionality to either the base CAPWAP protocol + specification, or any published CAPWAP binding specification. A + separate WTP Radio Information message element MUST be created to + properly advertise support for the specification. This mechanism + allows for future protocol extensibility, while providing the + necessary capabilities advertisement, through the WTP Radio + Information message element, to ensure WTP/AC interoperability. + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 9] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + +2.2. CAPWAP Session Establishment Overview + + This section describes the session establishment process message + exchanges in the ideal case. The annotated ladder diagram shows the + AC on the right, the WTP on the left, and assumes the use of + certificates for DTLS authentication. The CAPWAP Protocol State + Machine is described in detail in Section 2.3. Note that DTLS allows + certain messages to be aggregated into a single frame, which is + denoted via an asterix in the following figure. + + ============ ============ + WTP AC + ============ ============ + [----------- begin optional discovery ------------] + + Discover Request + ------------------------------------> + Discover Response + <------------------------------------ + + [----------- end optional discovery ------------] + + (-- begin DTLS handshake --) + + ClientHello + ------------------------------------> + HelloVerifyRequest (with cookie) + <------------------------------------ + + + ClientHello (with cookie) + ------------------------------------> + ServerHello, + Certificate, + ServerHelloDone* + <------------------------------------ + + (-- WTP callout for AC authorization --) + + Certificate (optional), + ClientKeyExchange, + CertificateVerify (optional), + ChangeCipherSpec, + Finished* + ------------------------------------> + + (-- AC callout for WTP authorization --) + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 10] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + ChangeCipherSpec, + Finished* + <------------------------------------ + + (-- DTLS session is established now --) + + Join Request + ------------------------------------> + Join Response + <------------------------------------ + + (-- assume image is up to date --) + + Configuration Status Request + ------------------------------------> + Configuration Status Response + <------------------------------------ + + (-- enter RUN state --) + + : + : + + Echo Request + ------------------------------------> + Echo Response + <------------------------------------ + + : + : + + Event Request + ------------------------------------> + Event Response + <------------------------------------ + + : + : + + At the end of the illustrated CAPWAP message exchange, the AC and WTP + are securely exchanging CAPWAP control messages. This is an + idealized illustration, provided to clarify protocol operation. + Section 2.3 provides a detailed description of the corresponding + state machine. + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 11] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + +2.3. CAPWAP State Machine Definition + + The following state diagram represents the lifecycle of a WTP-AC + session. Use of DTLS by the CAPWAP protocol results in the + juxtaposition of two nominally separate yet tightly bound state + machines. The DTLS and CAPWAP state machines are coupled through an + API consisting of commands (see Section 2.3.2.1) and notifications + (see Section 2.3.2.2). Certain transitions in the DTLS state machine + are triggered by commands from the CAPWAP state machine, while + certain transitions in the CAPWAP state machine are triggered by + notifications from the DTLS state machine. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 12] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + /-------------------------\ + w| | + 5+----------+ x +------------+ | + | Run |-->| Reset |-\| + +----------+ +------------+ || + u ^ ^ ^ y|| + +------------+--------/ | | || + | Data Check | /-------/ | || + +------------+<-------\ | | || + | | || + /------------------+--------\ | || + r| t| s| 4 v o| || + +--------+ +-----------+ +--------------+|| + | Join |---->| Configure | | Image Data ||| + +--------+ q +-----------+ +--------------+|| + ^ p| V| x| || + | | \-------------------\ | || + | \--------------------------------------\| | || + \------------------------\ || | || + /--------------<----------------+--------------\ || | || + | /------------<-------------\ | | || | || + | | m| |n z| vv v vv + | | +----------------+ +--------------+ +-----------+ + | | | DTLS Setup | | DTLS Connect | | DTLS TD | + | | +----------------+ +--------------+ +-----------+ + | | g| ^ ^ |h ^ ^ + v v | | | | | | + | | | | | \-------\ | /-----------/ + | | | | | | | | + | | v |e f| 2 v |j |k + | \->+------+ +------+ +-----------+ + | | Idle |-->| Disc | | Authorize | + \--->+------+ a +------+ +-----------+ + b| ^ |c + | | /----/ + v d| | + +---------+ | + | Sulking |<-/ + 3 +---------+ + + Figure 3: CAPWAP Integrated State Machine + + The CAPWAP protocol state machine, depicted above, is used by both + the AC and the WTP. In cases where states are not shared (i.e. not + implemented in one or the other of the AC or WTP), this is explicitly + called out in the transition descriptions below. For every state + defined, only certain messages are permitted to be sent and received. + The CAPWAP control messages definitions specify the state(s) in which + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 13] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + each message is valid. + + Since the WTP only communicates with a single AC, it only has a + single instance of the CAPWAP state machine. The AC has a separate + instance of the CAPWAP state machine per WTP it is communicating + with. + +2.3.1. CAPWAP Protocol State Transitions + + This section describes the various state transitions, and the events + that cause them. This section does not discuss interactions between + DTLS- and CAPWAP-specific states. Those interactions, and DTLS- + specific states and transitions, are discussed in Section 2.3.2. + + Idle to Discovery (a): This transition occurs once device + initialization is complete. + + WTP: The WTP enters the Discovery state prior to transmitting the + first Discovery Request message (see Section 5.1). Upon + entering this state, the WTP sets the DiscoveryInterval timer + (see Section 4.7). The WTP resets the DiscoveryCount counter + to zero (0) (see Section 4.8). The WTP also clears all + information from ACs it may have received during a previous + Discovery phase. + + AC: The AC does not maintain state information for the WTP upon + reception of the Discovery Request message, but it SHOULD + respond with a Discovery Response message (see Section 5.2). + This transition is a no-op for the AC. + + Idle to Sulking (b): This transition occurs to force the WTP and AC + to enter a quiet period to avoid repeatedly attempting to + establish a connection. + + WTP: The WTP enters this state when the FailedDTLSSessionCount or + the FailedDTLSAuthFailCount counter reaches + MaxFailedDTLSSessionRetry variable (see Section 4.8). Upon + entering this state, the WTP MUST start the SilentInterval + timer. While in the Sulking state, all received CAPWAP and + DTLS protocol messages received MUST be ignored. + + AC: The AC enters this state with the specific WTP when the + FailedDTLSSessionCount or the FailedDTLSAuthFailCount counter + reaches MaxFailedDTLSSessionRetry variable (see Section 4.8). + Upon entering this state, the AC MUST start the SilentInterval + timer. While in the Sulking state, all received CAPWAP and + DTLS protocol messages received from the WTP MUST be ignored. + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 14] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + Discovery to Discovery (2): In the Discovery state, the WTP + determines which AC to connect to. + + WTP: This transition occurs when the DiscoveryInterval timer + expires. If the WTP is configured with a list of ACs, it + transmits a Discovery Request message to every AC from which it + has not received a Discovery Response message. For every + transition to this event, the WTP increments the DiscoveryCount + counter. See Section 5.1 for more information on how the WTP + knows the ACs to which it should transmit the Discovery Request + messages. The WTP restarts the DiscoveryInterval timer + whenever it transmits Discovery Request messages. + + AC: This is a no-op. + + Discovery to Sulking (c): This transition occurs on a WTP when + Discovery or connectivity to the AC fails. + + WTP: The WTP enters this state when the DiscoveryInterval timer + expires or the DiscoveryCount variable is equal to the + MaxDiscoveries variable (see Section 4.8). Upon entering this + state, the WTP MUST start the SilentInterval timer. While in + the Sulking state, all received CAPWAP protocol messages + received MUST be ignored. + + AC: This is a no-op. + + Sulking to Idle (d): This transition occurs on a WTP when it must + restart the discovery phase. + + WTP: The WTP enters this state when the SilentInterval timer (see + Section 4.7) expires. The FailedDTLSSessionCount, + DiscoveryCount and FailedDTLSAuthFailCount counters are reset + to zero. + + AC: The AC enters this state when the SilentInterval timer (see + Section 4.7) expires. The FailedDTLSSessionCount, + DiscoveryCount and FailedDTLSAuthFailCount counters are reset + to zero. + + Sulking to Sulking (3): The Sulking state provides the silent + period, minimizing the possibility for Denial of Service (DoS) + attacks. + + WTP: All packets received from the AC while in the sulking state + are ignored. + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 15] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + AC: All packets receive from the WTP while in the sulking state + are ignored. + + Idle to DTLS Setup (e): This transition occurs to establish a secure + DTLS session with the peer. + + WTP: The WTP initiates this transition by invoking the DTLSStart + command, which starts the DTLS session establishment with the + chosen AC. When the discovery phase is bypassed, it is assumed + the WTP has a locally configured AC. + + AC: The AC initiates this transition by invoking the DTLSListen + command, which informs the DTLS stack that it is willing to + listen for an incoming session. The AC MAY provide optional + qualifiers in the DTLSListen command to only accept session + requests from specific WTPs. + + Discovery to DTLS Setup (f): This transition occurs to establish a + secure DTLS session with the peer. + + WTP: The WTP initiates this transition by invoking the DTLSStart + command (see Section 2.3.2.1), which starts the DTLS session + establishment with the chosen AC. The decision of which AC to + connect to is the result of the discovery phase, which is + described in Section 3.3. + + AC: The AC initiates this transition by invoking the DTLSListen + command (see Section 2.3.2.1), which informs the DTLS stack + that it is willing to listen for an incoming session. The AC + MAY have maintained state information when it received the + Discovery Request message to provide optional qualifiers in the + DTLSListen command to only accept session requests from a + specific WTP. Note that maintaining state information based on + an unsecured Discovery Request message MAY lead to a Denial of + Service attack. Therefore the AC SHOULD ensure that the state + information is freed after a period, which is implementation + specific. + + DTLS Setup to Idle (g): This transition occurs when the DTLS Session + failed to be established. + + WTP: The WTP initiates this state transition when it receives a + DTLSEstablishFail notification from DTLS (see Section 2.3.2.2). + This error notification aborts the secure DTLS session + establishment. When this notification is received, the + FailedDTLSSessionCount counter is incremented. + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 16] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + AC: The WTP initiates this state transition when it receives a + DTLSEstablishFail notification from DTLS (see Section 2.3.2.2). + This error notification aborts the secure DTLS session + establishment. When this notification is received, the + FailedDTLSSessionCount counter is incremented. + + DTLS Setup to Authorize (h): This transition occurs when an incoming + DTLS session is being established, and the DTLS stack needs + authorization to proceed with the session establishment. + + WTP: This state transition occurs when the WTP receives the + DTLSPeerAuthorize notification (see Section 2.3.2.2). Upon + entering this state, the WTP performs an authorization check + against the AC credentials. See Section 2.4.4 for more + information on AC authorization. + + AC: This state transition occurs when the AC receives the + DTLSPeerAuthorize notification (see Section 2.3.2.2). Upon + entering this state, the AC performs an authorization check + against the WTP credentials. See Section 2.4.4 for more + information on WTP authorization. + + Authorize to DTLS Connect (j): This transition occurs to notify the + DTLS stack that the session should be established. + + WTP: This state transition occurs when the WTP has either opted + to forgo the authorization check of the AC's credentials, or + the credentials were successfully authorized. This is done by + invoking the DTLSAccept DTLS command (see Section 2.3.2.1). + + AC: This state transition occurs when the AC has either opted to + forgo the authorization check of the WTP's credentials, or the + credentials were successfully authorized. This is done by + invoking the DTLSAccept DTLS command (see Section 2.3.2.1). + + Authorize to DTLS Teardown (k): This transition occurs to notify the + DTLS stack that the session should be aborted. + + WTP: This state transition occurs when the WTP was unable to + authorize the AC, using the AC credentials. The WTP then + aborts the DTLS session by invoking the DTLSAbortSession + command (see Section 2.3.2.1). + + AC: This state transition occurs when the AC was unable to + authorize the WTP, using the WTP credentials. The AC then + aborts the DTLS session by invoking the DTLSAbortSession + command (see Section 2.3.2.1). + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 17] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + DTLS Connect to Idle (m): This transition occurs when the DTLS + Session failed to be established. + + WTP: This state transition occurs when the WTP receives either a + DTLSAborted or DTLSAuthenticateFail notification (see + Section 2.3.2.2), indicating that the DTLS session was not + successfully established. When this transition occurs due to + the DTLSAuthenticateFail notification, the + FailedDTLSAuthFailCount is incremented, otherwise the + FailedDTLSSessionCount counter is incremented. + + AC: This state transition occurs when the AC receives either a + DTLSAborted or DTLSAuthenticateFail notification (see + Section 2.3.2.2), indicating that the DTLS session was not + successfully established. When this transition occurs due to + the DTLSAuthenticateFail notification, the + FailedDTLSAuthFailCount is incremented, otherwise the + FailedDTLSSessionCount counter is incremented. + + DTLS Connect to Join (n): This transition occurs when the DTLS + Session is successfully established. + + WTP: This state transition occurs when the WTP receives the + DTLSEstablished notification (see Section 2.3.2.2), indicating + that the DTLS session was successfully established. When this + notification is received, the FailedDTLSSessionCount counter is + set to zero. + + AC: This state transition occurs when the AC receives the + DTLSEstablished notification (see Section 2.3.2.2), indicating + that the DTLS session was successfully established. When this + notification is received, the FailedDTLSSessionCount counter is + set to zero, and the WaitJoin timer is started (see + Section 4.7). + + Join to DTLS Teardown (p): This transition occurs when the join + process failed. + + WTP: This state transition occurs when the WTP receives a Join + Response message with a Result Code message element containing + an error, if the Image Identifier provided by the AC in the + Join Response message differs from the WTP's currently running + firmware version and the WTP has the requested image in its + non-volatile memory, or if the WaitDTLS timer expires. This + causes the WTP to initiate the DTLSShutdown command (see + Section 2.3.2.1). This transition also occurs if the WTP + receives one of the following DTLS notifications: DTLSAborted, + DTLSReassemblyFailure or DTLSPeerDisconnect. + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 18] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + AC: This state transition occurs either if the WaitJoin timer + expires or if the AC transmits a Join Response message with a + Result Code message element containing an error. This causes + the AC to initiate the DTLSShutdown command (see + Section 2.3.2.1). This transition also occurs if the AC + receives one of the following DTLS notifications: DTLSAborted, + DTLSReassemblyFailure or DTLSPeerDisconnect. + + Join to Image Data (r): This state transition is used by the WTP and + the AC to download executable firmware. + + WTP: The WTP enters the Image Data state when it receives a + successful Join Response message and determines and the + included Image Identifier message element is not the same as + its currently running image. The WTP also detects that the + requested image version is not currently available in the WTP's + non-volatile storage (see Section 9.1 for a full description of + the firmware download process). The WTP initializes the + EchoInterval timer (see Section 4.7), and transmits the Image + Data Request message (see Section 9.1.1) requesting the start + of the firmware download. + + AC: This state transition occurs when the AC receives the Image + Data Request message from the WTP. The AC MUST transmit an + Image Data Response message (see Section 9.1.2) to the WTP, + which includes a portion of the firmware. The AC MUST start + the NeighborDeadInterval timer (see Section 4.7). + + Join to Configure (q): This state transition is used by the WTP and + the AC to exchange configuration information. + + WTP: The WTP enters the Configure state when it receives a + successful Join Response, and determines that the included + Image Identifier message element is the same as its currently + running image. The WTP transmits the Configuration Status + message (see Section 8.2) to the AC with message elements + describing its current configuration. The WTP also starts the + ResponseTimeout timer (see Section 4.7). + + AC: This state transition occurs immediately after the AC + transmits the Join Response message to the WTP. If the AC + receives the Configuration Status message from the WTP, the AC + MUST transmit a Configuration Status Response message (see + Section 8.3) to the WTP, and MAY include specific message + elements to override the WTP's configuration. The WTP also + starts the ChangeStatePendingTimer timer (see Section 4.7). + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 19] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + Configure to Reset (s): This state transition is used to reset the + connection either due to an error during the configuration phase, + or when the WTP determines it needs to reset in order for the new + configuration to take effect. + + WTP: The WTP enters the Reset state when it receives a + Configuration Status Response indicating an error or when it + determines that a reset of the WTP is required, due to the + characteristics of a new configuration. + + AC: The AC transitions to the Reset state when it receives a + Change State Event message from the WTP that contains an error + for which AC policy does not permit the WTP to provide service. + This state transition also occurs when the AC + ChangeStatePendingTimer timer expires. + + Configure to DTLS Teardown (V): This transition occurs when the + configuration process aborts due to a DTLS error. + + WTP: The WTP enters this state when it receives one of the + following DTLS notifications: DTLSAborted, + DTLSReassemblyFailure or DTLSPeerDisconnect (see + Section 2.3.2.2). The WTP MAY tear down the DTLS session if it + receives frequent DTLSDecapFailure notifications. + + AC: The AC enters this state when it receives one of the + following DTLS notifications: DTLSAborted, + DTLSReassemblyFailure or DTLSPeerDisconnect (see + Section 2.3.2.2). The WTP MAY tear down the DTLS session if it + receives frequent DTLSDecapFailure notifications. + + Image Data to Image Data (4): The Image Data state is used by the + WTP and the AC during the firmware download phase. + + WTP: The WTP enters the Image Data state when it receives an + Image Data Response message indicating that the AC has more + data to send. + + AC: This state transition occurs when the AC receives the Image + Data Request message from the WTP while already in the Image + Data state, and it detects that the firmware download has not + completed. + + Image Data to Reset (o): This state transition is used to reset the + DTLS connection prior to restarting the WTP after an image + download. + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 20] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + WTP: When an image download completes, the WTP enters the Reset + state. The WTP MAY also transition to this state upon + receiving an Image Data Response message from the AC (see + Section 9.1.2) indicating a failure. + + AC: The AC enters the Reset state when the image download is + complete, or if an error occurs during the image download + process. + + Image Data to DTLS Teardown (x): This transition occurs when the + firmware download process aborts due to a DTLS error. + + WTP: The WTP enters this state when it receives one of the + following DTLS notifications: DTLSAborted, + DTLSReassemblyFailure or DTLSPeerDisconnect (see + Section 2.3.2.2). The WTP MAY tear down the DTLS session if it + receives frequent DTLSDecapFailure notifications. + + AC: The AC enters this state when it receives one of the + following DTLS notifications: DTLSAborted, + DTLSReassemblyFailure or DTLSPeerDisconnect (see + Section 2.3.2.2). The WTP MAY tear down the DTLS session if it + receives frequent DTLSDecapFailure notifications. + + Configure to Data Check (t): This state transition occurs when the + WTP and AC confirm the configuration. + + WTP: The WTP enters this state when it receives a successful + Configuration Status Response message from the AC. The WTP + initializes the EchoInterval timer (see Section 4.7), and + transmits the Change State Event Request message (see + Section 8.6). + + AC: This state transition occurs when the AC receives the Change + State Event Request message (see Section 8.6) from the WTP. + The AC responds with a Change State Event Response message (see + Section 8.7). The AC MUST start the NeighborDeadInterval timer + (see Section 4.7). + + Data Check to Run (u): This state transition occurs when the linkage + between the control and data channels has occured, causing the WTP + and AC to enter their normal state of operation. + + WTP: The WTP enters this state when it receives a successful + Change State Event Response message from the AC. The WTP + initiates the data channel, which MAY require the establishment + of a DTLS session, starts the DataChannelKeepAlive timer (see + Section 4.7) and transmits a Data Channel Keep Alive packet + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 21] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + (see Section 4.4.1). The WTP then starts the + DataChannelDeadInterval timer (see Section 4.7). + + AC: This state transition occurs when the AC receives the Data + Channel Keep Alive packet (see Section 4.4.1), with a Session + ID message element matching that included by the WTP in the + Join Request message. Note that if AC policy is to require the + data channel to be encrypted, this process would also require + the establishment of a data channel DTLS session. Upon + receiving the Data Channel Keep Alive packet, the AC transmits + its own Data Channel Keep Alive packet. + + Run to DTLS Teardown (u): This state transition occurs when an error + has occured in the DTLS stack, causing the DTLS session to be + torndown. + + WTP: The WTP enters this state when it receives one of the + following DTLS notifications: DTLSAborted, + DTLSReassemblyFailure or DTLSPeerDisconnect (see + Section 2.3.2.2). The WTP MAY tear down the DTLS session if it + receives frequent DTLSDecapFailure notifications. The WTP also + transitions to this state if the underlying reliable + transport's RetransmitCount counter has reached the + MaxRetransmit variable (see Section 4.7). + + AC: The AC enters this state when it receives one of the + following DTLS notifications: DTLSAborted, + DTLSReassemblyFailure or DTLSPeerDisconnect (see + Section 2.3.2.2). The WTP MAY tear down the DTLS session if it + receives frequent DTLSDecapFailure notifications. The AC + transitions to this state if the underlying reliable + transport's RetransmitCount counter has reached the + MaxRetransmit variable (see Section 4.7). + + Run to Run (5): This is the normal state of operation. + + WTP: This is the WTP's normal state of operation. There are many + events that result this state transition: + + Configuration Update: The WTP receives a Configuration Update + Request message(see Section 8.4). The WTP MUST respond with + a Configuration Update Response message (see Section 8.5). + + Change State Event: The WTP receives a Change State Event + Response message, or determines that it must initiate a + Change State Event Request message, as a result of a failure + or change in the state of a radio. + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 22] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + Echo Request: The WTP sends an Echo Request message + (Section 7.1) or receives the corresponding Echo Response + message, (see Section 7.2) from the AC. + + Clear Config Request: The WTP receives a Clear Configuration + Request message (see Section 8.8). The WTP MUST reset its + configuration back to manufacturer defaults. + + WTP Event: The WTP sends a WTP Event Request message, + delivering information to the AC (see Section 9.4). The WTP + receives a WTP Event Response message from the AC (see + Section 9.5). + + Data Transfer: The WTP sends a Data Transfer Request message + to the AC (see Section 9.6). The WTP receives a Data + Transfer Response message from the AC (see Section 9.7). + + Station Configuration Request: The WTP receives a Station + Configuration Request message (see Section 10.1), to which + it MUST respond with a Station Configuration Response + message (see Section 10.2). + + AC: This is the AC's normal state of operation: + + Configuration Update: The AC sends a Configuration Update + Request message (see Section 8.4) to the WTP to update its + configuration. The AC receives a Configuration Update + Response message (see Section 8.5) from the WTP. + + Change State Event: The AC receives a Change State Event + Request message (see Section 8.6), to which it MUST respond + with the Change State Event Response message (see + Section 8.7). + + Echo Request: The AC receives an Echo Request message (see + Section 7.1), to which it MUST respond with an Echo Response + message(see Section 7.2). + + Clear Config Response: The AC receives a Clear Configuration + Response message from the WTP (see Section 8.9). + + WTP Event: The AC receives a WTP Event Request message from + the WTP (see Section 9.4) and MUST generate a corresponding + WTP Event Response message (see Section 9.5). + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 23] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + Data Transfer: The AC receives a Data Transfer Request message + from the WTP (see Section 9.6) and MUST generate a + corresponding Data Transfer Response message (see + Section 9.7). + + Station Configuration Request: The AC sends a Station + Configuration Request message (see Section 10.1) or receives + the corresponding Station Configuration Response message + (see Section 10.2) from the WTP. + + Run to Reset (x): This state transition is used when either the AC + or WTP tear down the connection. This may occur as part of normal + operation, or due to error conditions. + + WTP: The WTP enters the Reset state when it receives a Reset + Request message from the AC. + + AC: The AC enters the Reset state when it transmits a Reset + Request message to the WTP. + + Reset to DTLS Teardown (y): This transition occurs when the CAPWAP + reset is complete, to terminate the DTLS session. + + WTP: This state transition occurs when the WTP receives a Reset + Response message. This causes the WTP to initiate the + DTLSShutdown command (see Section 2.3.2.1). + + AC: This state transition occurs when the AC transmits a Reset + Response message. The AC does not invoke the DTLSShutdown + command (see Section 2.3.2.1). + + DTLS Teardown to Idle (z): This transition occurs when the DTLS + session has been shutdown. + + WTP: This state transition occurs when the WTP has successfully + cleaned up all resources associated with the control plane DTLS + session. The data plane DTLS session is also shutdown, and all + resources freed, if a DTLS session was established for the data + plane. Any timers set for the current instance of the state + machine are also cleared. + + AC: This state transition occurs when the AC has successfully + cleaned up all resources associated with the control plane DTLS + session. The data plane DTLS session is also shutdown, and all + resources freed, if a DTLS session was established for the data + plane. Any timers set for the current instance of the state + machine are also cleared. + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 24] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + +2.3.2. CAPWAP/DTLS Interface + + This section describes the DTLS Commands used by CAPWAP, and the + notifications received from DTLS to the CAPWAP protocol stack. + +2.3.2.1. CAPWAP to DTLS Commands + + Six commands are defined for the CAPWAP to DTLS API. These + "commands" are conceptual, and may be implemented as one or more + function calls. This API definition is provided to clarify + interactions between the DTLS and CAPWAP components of the integrated + CAPWAP state machine. + + Below is a list of the minimal command API: + + o DTLSStart is sent to the DTLS component to cause a DTLS session to + be established. Upon invoking the DTLSStart command, the WaitDTLS + timer is started. The WTP initiates this DTLS command, as the AC + does not initiate DTLS sessions. + + o DTLSListen is sent to the DTLS component to allow the DTLS + component to listen for incoming DTLS session requests. + + o DTLSAccept is sent to the DTLS component to allow the DTLS session + establishment to continue successfully. + + o DTLSAbortSession is sent to the DTLS component to cause the + session that is in the process of being established to be aborted. + This command is also sent when the WaitDTLS timer expires. When + this command is executed, the FailedDTLSSessionCount counter is + incremented. + + o DTLSShutdown is sent to the DTLS component to cause session + teardown. + + o DTLSMtuUpdate is sent by the CAPWAP component to modify the MTU + size used by the DTLS component. The default size is 1468 bytes. + +2.3.2.2. DTLS to CAPWAP Notifications + + DTLS notifications are defined for the DTLS to CAPWAP API. These + "notifications" are conceptual, and may be implemented in numerous + ways (e.g. as function return values). This API definition is + provided to clarify interactions between the DTLS and CAPWAP + components of the integrated CAPWAP state machine. It is important + to note that the notifications listed below MAY cause the CAPWAP + state machine to jump from one state to another using a state + transition not listed in Section 2.3.1. When a notification listed + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 25] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + below occurs, the target CAPWAP state shown in Figure 3 becomes the + current state. + + Below is a list of the API notifications: + + o DTLSPeerAuthorize is sent to the CAPWAP component during DTLS + session establishment once the peer's identity has been received. + This notification MAY be used by the CAPWAP component to authorize + the session, based on the peer's identity. The authorization + process will lead to the CAPWAP component initiating either the + DTLSAccept or DTLSAbortSession commands. + + o DTLSEstablished is sent to the CAPWAP component to indicate that + that a secure channel now exists, using the parameters provided + during the DTLS initialization process. When this notification is + received, the FailedDTLSSessionCount counter is reset to zero. + When this notification is received, the WaitDTLS timer is stopped. + + o DTLSEstablishFail is sent when the DTLS session establishment has + failed, either due to a local error, or due to the peer rejecting + the session establishment. When this notification is received, + the FailedDTLSSessionCount counter is incremented. + + o DTLSAuthenticateFail is sent when DTLS session establishment + failed due to an authentication error. When this notification is + received, the FailedDTLSAuthFailCount counter is incremented. + + o DTLSAborted is sent to the CAPWAP component to indicate that + session abort (as requested by CAPWAP) is complete; this occurs to + confirm a DTLS session abort, or when the WaitDTLS timer expires. + When this notification is received, the WaitDTLS timer is stopped. + + o DTLSReassemblyFailure MAY be sent to the CAPWAP component to + indicate DTLS fragment reassembly failure. + + o DTLSDecapFailure MAY be sent to the CAPWAP module to indicate a + decapsulation failure. DTLSDecapFailure MAY be sent to the CAPWAP + module to indicate an encryption/authentication failure. This + notification is intended for informative purposes only, and is not + intended to cause a change in the CAPWAP state machine (see + Section 12.4). + + o DTLSPeerDisconnect is sent to the CAPWAP component to indicate the + DTLS session has been torn down. Note that this notification is + only received if the DTLS session has been established. + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 26] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + +2.4. Use of DTLS in the CAPWAP Protocol + + DTLS is used as a tightly-integrated, secure wrapper for the CAPWAP + protocol. In this document DTLS and CAPWAP are discussed as + nominally distinct entitites; however they are very closely coupled, + and may even be implemented inseparably. Since there are DTLS + library implementations currently available, and since security + protocols (e.g. IPsec, TLS) are often implemented in widely + available acceleration hardware, it is both convenient and forward- + looking to maintain a modular distinction in this document. + + This section describes a detailed walk-through of the interactions + between the DTLS module and the CAPWAP module, via 'commands' (CAPWAP + to DTLS) and 'notifications' (DTLS to CAPWAP) as they would be + encountered during the normal course of operation. + +2.4.1. DTLS Handshake Processing + + Details of the DTLS handshake process are specified in [8]. This + section describes the interactions between the DTLS session + establishment process and the CAPWAP protocol. Note that the + conceptual DTLS state is shown below to help understand the point at + which the DTLS states transition. In the normal case, the DTLS + handshake will proceed as follows (NOTE: this example uses + certificates, but preshared keys are also supported): + + + + + + + + + + + + + + + + + + + + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 27] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + ============ ============ + WTP AC + ============ ============ + ClientHello ------> + <------ HelloVerifyRequest + (with cookie) + + ClientHello ------> + (with cookie) + <------ ServerHello + <------ Certificate + <------ ServerHelloDone + + (WTP callout for AC authorization + occurs in CAPWAP Auth state) + + Certificate* + ClientKeyExchange + CertificateVerify* + [ChangeCipherSpec] + Finished ------> + + (AC callout for WTP authorization + occurs in CAPWAP Auth state) + + [ChangeCipherSpec] + <------ Finished + + + DTLS, as specified, provides its own retransmit timers with an + exponential back-off. However, DTLS will never terminate the + handshake due to non-responsiveness; instead, DTLS will continue to + increase its back-off timer period. Hence, timing out incomplete + DTLS handshakes is entirely the responsiblity of the CAPWAP module. + + The DTLS implementation used by CAPWAP MUST support TLS Session + Resumption. Session resumption is used to establish the DTLS session + used for the data channel. The DTLS implementation on the WTP MUST + return some unique identifier to the CAPWAP module to enable + subsequent establishment of a DTLS-encrypted data channel, if + necessary. + +2.4.2. DTLS Session Establishment + + The WTP, either through the Discovery process, or through pre- + configuration, determines the AC to connect to. The WTP uses the + DTLSStart command to request that a secure connection be established + to the selected AC. Prior to initiation of the DTLS handshake, the + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 28] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + WTP sets the WaitDTLS timer. Upon receiving the DTLSPeerAuthorize + DTLS notification, the AC sets the WaitDTLS timer. If the + DTLSEstablished notification is not received prior to timer + expiration, the DTLS session is aborted by issuing the + DTLSAbortSession DTLS command. This notification causes the CAPWAP + module to transition to the Idle state. Upon receiving a + DTLSEstablished notification, the WaitDTLS timer is deactivated. + +2.4.3. DTLS Error Handling + + If the AC does not respond to any DTLS messages sent by the WTP, the + DTLS specification calls for the WTP to retransmit these messages. + If the WaitDTLS timer expires, CAPWAP will issue the DTLSAbortSession + command, causing DTLS to terminate the handshake and remove any + allocated session context. Note that DTLS MAY send a single TLS + Alert message to the AC to indicate session termination. + + If the WTP does not respond to any DTLS messages sent by the AC, the + CAPWAP protocol allows for three possiblities, listed below. Note + that DTLS MAY send a single TLS Alert message to the AC to indicate + session termination. + + o The message was lost in transit; in this case, the WTP will re- + transmit its last outstanding message, since it did not receive a + reply. + + o The WTP sent a DTLS Alert, which was lost in transit; in this + case, the AC's WaitDTLS timer will expire, and the session will be + terminated. + + o Communication with the WTP has completely failed; in this case, + the AC's WaitDTLS timer will expire, and the session will be + terminated. + + The DTLS specification provides for retransmission of unacknowledged + requests. If retransmissions remain unacknowledged, the WaitDTLS + timer will eventually expire, at which time the CAPWAP component will + terminate the session. + + If a cookie fails to validate, this could represent a WTP error, or + it could represent a DoS attack. Hence, AC resource utilization + SHOULD be minimized. The AC MAY log a message indicating the + failure, but SHOULD NOT attempt to reply to the WTP. + + Since DTLS handshake messages are potentially larger than the maximum + record size, DTLS supports fragmenting of handshake messages across + multiple records. There are several potential causes of re-assembly + errors, including overlapping and/or lost fragments. The DTLS + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 29] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + component MUST send a DTLSReassemblyFailure notification to the + CAPWAP component. Whether precise information is given along with + notification is an implementation issue, and hence is beyond the + scope of this document. Upon receipt of such an error, the CAPWAP + component SHOULD log an appropriate error message. Whether + processing continues or the DTLS session is terminated is + implementation dependent. + + DTLS decapsulation errors consist of three types: decryption errors, + authentication errors, and malformed DTLS record headers. Since DTLS + authenticates the data prior to encapsulation, if decryption fails, + it is difficult to detect this without first attempting to + authenticate the packet. If authentication fails, a decryption error + is also likely, but not guaranteed. Rather than attempt to derive + (and require the implementation of) algorithms for detecting + decryption failures, decryption failures are reported as + authentication failures. The DTLS component MUST provide a + DTLSDecapFailure notification to the CAPWAP component when such + errors occur. If a malformed DTLS record header is detected, the + packets SHOULD be silently discarded, and the receiver MAY log an + error message. + + There is currently only one encapsulation error defined: MTU + exceeded. As part of DTLS session establishment, the CAPWAP + component informs the DTLS component of the MTU size. This may be + dynamically modified at any time when the CAPWAP component sends the + DTLSMtuUpdate command to the DTLS component (see Section 2.3.2.1). + The DTLS component returns this notification to the CAPWAP component + whenever a transmission request will result in a packet which exceeds + the MTU. + +2.4.4. DTLS EndPoint Authentication and Authorization + + DTLS supports endpoint authentication with certificates or preshared + keys. The TLS algorithm suites for each endpoint authentication + method are described below. + +2.4.4.1. Authenticating with Certificates + + Note that only block ciphers are currently recommended for use with + DTLS. To understand the reasoning behind this, see [17]. At + present, the following algorithms MUST be supported when using + certificates for CAPWAP authentication: + + o TLS_RSA_WITH_AES_128_CBC_SHA + + The following algorithms SHOULD be supported when using certificates: + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 30] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + o TLS_DH_RSA_WITH_AES_128_CBC_SHA + + The following algorithms MAY be supported when using certificates: + + o TLS_RSA_WITH_AES_256_CBC_SHA + + o TLS_DH_RSA_WITH_AES_256_CBC_SHA + +2.4.4.2. Authenticating with Preshared Keys + + Pre-shared keys present significant challenges from a security + perspective, and for that reason, their use is strongly discouraged. + Several methods for authenticating with preshared keys are defined + [6], and we focus on the following two: + + o PSK key exchange algorithm - simplest method, ciphersuites use + only symmetric key algorithms + + o DHE_PSK key exchange algorithm - use a PSK to authenticate a + Diffie-Hellman exchange. These ciphersuites give some additional + protection against dictionary attacks and also provide Perfect + Forward Secrecy (PFS). + + The first approach (plain PSK) is susceptible to passive dictionary + attacks; hence, while this alorithm MUST be supported, special care + should be taken when choosing that method. In particular, user- + readable passphrases SHOULD NOT be used, and use of short PSKs SHOULD + be strongly discouraged. + + The following cryptographic algorithms MUST be supported when using + preshared keys: + + o TLS_PSK_WITH_AES_128_CBC_SHA + + o TLS_DHE_PSK_WITH_AES_128_CBC_SHA + + The following algorithms MAY be supported when using preshared keys: + + o TLS_PSK_WITH_AES_256_CBC_SHA + + o TLS_DHE_PSK_WITH_AES_256_CBC_SHA + +2.4.4.3. Certificate Usage + + Certificate authorization by the AC and WTP is required so that only + an AC may perform the functions of an AC and that only a WTP may + perform the functions of a WTP. This restriction of functions to the + AC or WTP requires that the certificates used by the AC MUST be + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 31] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + distinguishable from the certificate used by the WTP. To accomplish + this differentiation, the x.509 certificates MUST include the + Extended Key Usage (EKU) certificate extension [4]. + + The EKU field indicates one or more purposes for which a certificate + may be used. It is an essential part in authorization. Its syntax + is as follows: + + ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId + + KeyPurposeId ::= OBJECT IDENTIFIER + + + Here we define two KeyPurposeId values, one for the WTP and one for + the AC. Inclusion of one of these two values indicates a certificate + is authorized for use by a WTP or AC, respectively. These values are + formatted as id-kp fields. + + id-kp OBJECT IDENTIFIER ::= + { iso(1) identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) 3 } + + id-kp-capwapAC OBJECT IDENTIFIER ::= { id-kp 18 } + + id-kp-capwapWTP OBJECT IDENTIFIER ::= { id-kp 19 } + + + + For an AC, the id-kp-capwapAC EKU MUST be present in the certificate. + For a WTP, the id-kp-capwapWTP EKU MUST be present in the + certificate. + + Part of the CAPWAP certificate validation process includes ensuring + that the proper EKU is included and allowing the CAPWAP session to be + established only if the extension properly represents the device. + + The certificate common name (CN) for both the WTP and AC MUST be the + MAC address of that device. The MAC address MUST be formatted as + ASCII HEX, e.g. 01:23:45:67:89:ab. + + ACs and WTPs SHOULD authorize (e.g. through access control lists) + certificates of devices to which they are connecting, based on the + MAC address and organizational information specified in the O and OU + fields. The identities specified in the certificates bind a + particular DTLS session to a specific pair of mutually-authenticated + and authorized MAC addresses. + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 32] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + +2.4.4.4. PSK Usage + + When DTLS uses PSK Ciphersuites, the ServerKeyExchange message MUST + contain the "PSK identity hint" field and the ClientKeyExchange + message MUST contain the "PSK identity" field. These fields are used + to help the WTP select the appropriate PSK for use with the AC, and + then indicate to the AC which key is being used. When PSKs are + provisioned to WTPs and ACs, both the PSK Hint and PSK Identity for + the key MUST be specified. + + The PSK Hint SHOULD uniquely identify the AC and the PSK Identity + SHOULD uniquely identify the WTP. It is RECOMMENDED that these hints + and identities be the ASCII HEX-formatted MAC addresses of the + respective devices, since each pairwise combination of WTP and AC + SHOULD have a unique PSK. The PSK hint and identity SHOULD be + sufficient to perform authorization, as simply having knowledge of a + PSK does not necessarily imply authorization. + + If a single PSK is being used for multiple devices on a CAPWAP + network, which is NOT RECOMMENDED, the PSK Hint and Identity can no + longer be a MAC address, so appropriate hints and identities SHOULD + be selected to identify the group of devices to which the PSK is + provisioned. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 33] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + +3. CAPWAP Transport + + Communication between a WTP and an AC is established using the + standard UDP client/server model. The CAPWAP protocol supports both + UDP and UDP-Lite [11] transport protocols. The UDP protocol is used + with IPv4. When CAPWAP is used over IPv6, the UDP-Lite protocol is + used. This section describes how the CAPWAP protocol is carried over + IP and UDP/UDP-Lite transport protocols. + +3.1. UDP Transport + + One of the CAPWAP protocol requirements is to allow a WTP to reside + behind a firewall and/or Network Address Translation (NAT) device. + Since a CAPWAP session is initiated by the WTP (client) to the well- + known UDP port of the AC (server), the use of UDP is a logical + choice. The UDP checksum field in CAPWAP packets MUST be set to + zero. + + CAPWAP protocol control packets sent from the WTP to the AC use the + CAPWAP control channel, as defined in Section 1.4. The CAPWAP + control port at the AC is the well known UDP port [to be IANA + assigned]. The CAPWAP control port at the WTP can be any port + selected by the WTP. + + CAPWAP protocol data packets sent from the WTP to the AC use the + CAPWAP data channel, as defined in Section 1.4. The CAPWAP data port + at the AC is the well known UDP port [to be IANA assigned]. The + CAPWAP data port at the WTP can be any port selected by the WTP. + +3.2. UDP-Lite Transport + + When CAPWAP is run over IPv6, UDP-Lite is used as the transport + protocol, reducing the checksum processing required for each packet + (compared to UDP and IPv6). When UDP-Lite is used, the checksum + field MUST have a coverage of 8 [11]. + + UDP-Lite uses the same port assignments as UDP. + +3.3. AC Discovery + + The AC discovery phase allows the WTP to determine which ACs are + available, and chose the best AC with which to establish a CAPWAP + session. The discovery phase occurs when the WTP enters the optional + Discovery state. A WTP does not need to complete the AC Discovery + phase if it uses a pre-configured AC. This section details the + mechanism used by a WTP to dynamically discover candidate ACs. + + A WTP and an AC will frequently not reside in the same IP subnet + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 34] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + (broadcast domain). When this occurs, the WTP must be capable of + discovering the AC, without requiring that multicast services are + enabled in the network. + + When the WTP attempts to establish communication with an AC, it sends + the Discovery Request message and receives the Discovery Response + message from the AC(s). The WTP MUST send the Discovery Request + message to either the limited broadcast IP address (255.255.255.255), + a well known multicast address or to the unicast IP address of the + AC. For IPv6 networks, since broadcast does not exist, the use of + "All ACs multicast address" is used instead. Upon receipt of the + Discovery Request message, the AC sends a Discovery Response message + to the unicast IP address of the WTP, regardless of whether the + Discovery Request message was sent as a broadcast, multicast or + unicast message. + + WTP use of a limited IP broadcast, multicast or unicast IP address is + implementation dependent. + + When a WTP transmits a Discovery Request message to a unicast + address, the WTP must first obtain the IP address of the AC. Any + static configuration of an AC's IP address on the WTP non-volatile + storage is implementation dependent. However, additional dynamic + schemes are possible, for example: + + DHCP: See [13] for more information on the use of DHCP to discover + AC IP addresses. + + DNS: The DNS name "CAPWAP-AC-Address" MAY be resolvable to one or + more AC addresses. + + An AC MAY also communicate alternative ACs to the WTP within the + Discovery Response message through the AC IPv4 List (see + Section 4.6.2) and AC IPv6 List (see Section 4.6.2). The addresses + provided in these two message elements are intended to help the WTP + discover additional ACs through means other than those listed above. + + The AC Name with Index message element (see Section 4.6.5), is used + to communicate a list of preferred ACs to the WTP. The WTP SHOULD + attempt to utilize the ACs listed in the order provided by the AC. + The Name to IP Address mapping is handled via the Discovery message + exchange, in which the ACs provide their identity in the AC Name (see + Section 4.6.4) message element in the Discovery Response message. + + Once the WTP has received Discovery Response messages from the + candidate ACs, it MAY use other factors to determine the preferred + AC. For instance, each binding defines a WTP Radio Information + message element (see Section 2.1), which the AC includes in Discovery + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 35] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + Response messages. The presence of one or more of these message + elements is used to identify the CAPWAP bindings supported by the AC. + A WTP MAY connect to an AC based on the supported bindings + advertised. + +3.4. Fragmentation/Reassembly + + While fragmentation and reassembly services are provided by IP, the + CAPWAP protocol also provides such services. Environments where the + CAPWAP protocol is used involve firewall, NAT and "middle box" + devices, which tend to drop IP fragments to minimize possible DoS + attacks. By providing fragmentation and reassembly at the + application layer, any fragmentation required due to the tunneling + component of the CAPWAP protocol becomes transparent to these + intermediate devices. Consequently, the CAPWAP protocol can be used + in any network configuration. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 36] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + +4. CAPWAP Packet Formats + + This section contains the CAPWAP protocol packet formats. A CAPWAP + protocol packet consists of one or more CAPWAP Transport Layer packet + headers followed by a CAPWAP message. The CAPWAP message can be + either of type Control or Data, where Control packets carry + signaling, and Data packets carry user payloads. The CAPWAP frame + formats for CAPWAP Data packets, and for DTLS encapsulated CAPWAP + Data and Control packets are defined below. + + The CAPWAP Control protocol includes two messages that are never + protected by DTLS: the Discovery Request message and the Discovery + Response message. These messages need to be in the clear to allow + the CAPWAP protocol to properly identify and process them. The + format of these packets are as follows: + + CAPWAP Control Packet (Discovery Request/Response): + +-------------------------------------------+ + | IP | UDP | CAPWAP | Control | Message | + | Hdr | Hdr | Header | Header | Element(s) | + +-------------------------------------------+ + + All other CAPWAP control protocol messages MUST be protected via the + DTLS protocol, which ensures that the packets are both authenticated + and encrypted. These packets include the CAPWAP DTLS Header, which + is described in Section 4.2. The format of these packets is as + follows: + + CAPWAP Control Packet (DTLS Security Required): + +------------------------------------------------------------------+ + | IP | UDP | CAPWAP | DTLS | CAPWAP | Control| Message | DTLS | + | Hdr | Hdr | DTLS Hdr | Hdr | Header | Header | Element(s)| Trlr | + +------------------------------------------------------------------+ + \---------- authenticated -----------/ + \------------- encrypted ------------/ + + The CAPWAP protocol allows optional protection of data packets, using + DTLS. Use of data packet protection is determined by AC policy. + When DTLS is utilized, the optional CAPWAP DTLS Header is present, + which is described in Section 4.2. The format of CAPWAP data packets + is shown below: + + + + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 37] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + CAPWAP Plain Text Data Packet : + +-------------------------------+ + | IP | UDP | CAPWAP | Wireless | + | Hdr | Hdr | Header | Payload | + +-------------------------------+ + + DTLS Secured CAPWAP Data Packet: + +--------------------------------------------------------+ + | IP | UDP | CAPWAP | DTLS | CAPWAP | Wireless | DTLS | + | Hdr | Hdr | DTLS Hdr | Hdr | Hdr | Payload | Trlr | + +--------------------------------------------------------+ + \------ authenticated -----/ + \------- encrypted --------/ + + UDP Header: All CAPWAP packets are encapsulated within either UDP, + or UDP-Lite when used over IPv6. Section 3 defines the specific + UDP or UDP-Lite usage. + + CAPWAP DTLS Header: All DTLS encrypted CAPWAP protocol packets are + prefixed with the CAPWAP DTLS header (see Section 4.2). + + DTLS Header: The DTLS header provides authentication and encryption + services to the CAPWAP payload it encapsulates. This protocol is + defined in RFC 4347 [8]. + + CAPWAP Header: All CAPWAP protocol packets use a common header that + immediately follows the CAPWAP preamble or DTLS header. The + CAPWAP Header is defined in Section 4.3. + + Wireless Payload: A CAPWAP protocol packet that contains a wireless + payload is a CAPWAP data packet. The CAPWAP protocol does not + specify the format of the wireless payload, which is defined by + the appropriate wireless standard. Additional information is in + Section 4.4. + + Control Header: The CAPWAP protocol includes a signalling component, + known as the CAPWAP control protocol. All CAPWAP control packets + include a Control Header, which is defined in Section 4.5.1. + CAPWAP data packets do not contain a Control Header field. + + Message Elements: A CAPWAP Control packet includes one or more + message elements, which are found immediately following the + Control Header. These message elements are in a Type/Length/value + style header, defined in Section 4.6. + + A CAPWAP implementation MUST be capable of receiving a reassembled + CAPWAP message of length 4096 bytes. A CAPWAP implementation MAY + indicate that it supports a higher maximum message length, by + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 38] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + including the Maximum Message Length message element, see + Section 4.6.29 in the Join Request message or the Join Response + message. + +4.1. CAPWAP Preamble + + The CAPWAP preamble is common to all CAPWAP transport headers and is + used to identify the header type that immediately follows. The + reason for this header is to avoid needing to perform byte + comparisons in order to guess whether the frame is DTLS encrypted or + not. It also provides an extensibility framework that can be used to + support additional transport types. The format of the preamble is as + follows: + + 0 + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + |Version| Type | + +-+-+-+-+-+-+-+-+ + + Version: A 4 bit field which contains the version of CAPWAP used in + this packet. The value for this specification is zero (0). + + Payload Type: A 4 bit field which specifies the payload type that + follows the UDP header. The following values are supported: + + 0 - CAPWAP Header. The CAPWAP Header (see Section 4.3) + immediately follows the UDP header. If the packet is received + on the CAPWAP data channel, the CAPWAP stack MUST treat the + packet as a clear text CAPWAP data packet. If received on the + CAPWAP control channel, the CAPWAP stack MUST treat the packet + as a clear text CAPWAP control packet. If the control packet + is not a Discovery Request or Discovery Response packet, the + packet MUST be dropped. + + 1 - CAPWAP DTLS Header. The CAPWAP DTLS Header, and DTLS packet, + immediately follows the UDP header (see Section 4.2). + +4.2. CAPWAP DTLS Header + + The CAPWAP DTLS Header is used to identify the packet as a DTLS + encrypted packet. The first eight bits includes the common CAPWAP + Preamble. The remaining 24 bits are padding to ensure 4 byte + alignment, and MAY be used in a future version of the protocol. The + DTLS packet [8] always immediately follows this header. The format + of the CAPWAP DTLS Header is as follows: + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 39] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |CAPWAP Preamble| Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + CAPWAP Preamble: The CAPWAP Preamble is defined in Section 4.1. The + CAPWAP Preamble's Payload Type field MUST be set to one (1). + + Reserved: The 24-bit field is reserved for future use. All + implementations complying with this protocol MUST set to zero any + bits that are reserved in the version of the protocol supported by + that implementation. Receivers MUST ignore all bits not defined + for the version of the protocol they support. + +4.3. CAPWAP Header + + All CAPWAP protocol messages are encapsulated using a common header + format, regardless of the CAPWAP Control or CAPWAP Data transport + used to carry the messages. However, certain flags are not + applicable for a given transport. Refer to the specific transport + section in order to determine which flags are valid. + + Note that the optional fields defined in this section MUST be present + in the precise order shown below. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |CAPWAP Preamble| HLEN | RID | WBID |T|F|L|W|M|K|Flags | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Fragment ID | Frag Offset |Rsvd | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | (optional) Radio MAC Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | (optional) Wireless Specific Information | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Payload .... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + CAPWAP Preamble: The CAPWAP Preamble is defined in Section 4.1. The + CAPWAP Preamble's Payload Type field MUST be set to zero (0). If + the CAPWAP DTLS Header is present, the version number in both + CAPWAP Preambles MUST match. The reason for this duplicate field + is to avoid any possible tampering of the version field in the + preamble which is not encrypted or authenticated. + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 40] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + HLEN: A 5 bit field containing the length of the CAPWAP transport + header in 4 byte words (Similar to IP header length). This length + includes the optional headers. + + RID: A 5 bit field which contains the Radio ID number for this + packet. Given that MAC Addresses are not necessarily unique + across physical radios in a WTP, the Radio Identifier (RID) field + is used to indiciate which physical radio the message is + associated with. + + WBID: A 5 bit field which is the wireless binding identifier. The + identifier will indicate the type of wireless packet type + associated with the radio. The following values are defined: + + 1 - IEEE 802.11 + + 2 - IEEE 802.16 + + 3 - EPCGlobal + + T: The Type 'T' bit indicates the format of the frame being + transported in the payload. When this bit is set to one (1), the + payload has the native frame format indicated by the WBID field. + When this bit is zero (0) the payload is an IEEE 802.3 frame. + + F: The Fragment 'F' bit indicates whether this packet is a fragment. + When this bit is one (1), the packet is a fragment and MUST be + combined with the other corresponding fragments to reassemble the + complete information exchanged between the WTP and AC. + + L: The Last 'L' bit is valid only if the 'F' bit is set and indicates + whether the packet contains the last fragment of a fragmented + exchange between WTP and AC. When this bit is 1, the packet is + the last fragment. When this bit is 0, the packet is not the last + fragment. + + W: The Wireless 'W' bit is used to specify whether the optional + Wireless Specific Information field is present in the header. A + value of one (1) is used to represent the fact that the optional + header is present. + + M: The M bit is used to indicate that the Radio MAC Address optional + header is present. This is used to communicate the MAC address of + the receiving radio. + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 41] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + K: The 'Keep-alive' K bit indicates the packet is a Data Channel Keep + Alive packet. This packet is used to map the data channel to the + control channel for the specified Session ID and to maintain + freshness of the data channel. The K bit MUST NOT be set for data + packets containing user data. + + Flags: A set of reserved bits for future flags in the CAPWAP header. + All implementations complying with this protocol MUST set to zero + any bits that are reserved in the version of the protocol + supported by that implementation. Receivers MUST ignore all bits + not defined for the version of the protocol they support. + + Fragment ID: A 16 bit field whose value is assigned to each group of + fragments making up a complete set. The fragment ID space is + managed individually for every WTP/AC pair. The value of Fragment + ID is incremented with each new set of fragments. The Fragment ID + wraps to zero after the maximum value has been used to identify a + set of fragments. + + Fragment Offset: A 13 bit field that indicates where in the payload + this fragment belongs during re-assembly. This field is valid + when the 'F' bit is set to 1. The fragment offset is measured in + units of 8 octets (64 bits). The first fragment has offset zero. + Note the CAPWAP protocol does not allow for overlapping fragments. + + Reserved: The 3-bit field is reserved for future use. All + implementations complying with this protocol MUST set to zero any + bits that are reserved in the version of the protocol supported by + that implementation. Receivers MUST ignore all bits not defined + for the version of the protocol they support. + + Radio MAC Address: This optional field contains the MAC address of + the radio receiving the packet. This is useful in packets sent + from the WTP to the AC, when the native wireless frame format is + converted to 802.3 by the WTP. This field is only present if the + 'M' bit is set. The HLEN field assumes 4 byte alignment, and this + field MUST be padded with zeroes (0x00) if it is not 4 byte + aligned. + + The field contains the basic format: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | MAC Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 42] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + Length: The length of the MAC Address field [18] [19]. + + MAC Address: The MAC Address of the receiving radio. + + Wireless Specific Information: This optional field contains + technology specific information that may be used to carry per + packet wireless information. This field is only present if the + 'W' bit is set. The HLEN field assumes 4 byte alignment, and this + field MUST be padded with zeroes (0x00) if it is not 4 byte + aligned. + + The Wireless Specific Information field uses the following format: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Wireless ID | Length | Data + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Wireless ID: The wireless binding identifier. The following + values are defined: + + 1 - IEEE 802.11 + + 2 - IEEE 802.16 + + 3 - EPCGlobal + + Length: The length of the data field + + Data: Wireless specific information, defined by the wireless + specific binding. + + Payload: This field contains the header for a CAPWAP Data Message or + CAPWAP Control Message, followed by the data contained in the + message. + +4.4. CAPWAP Data Messages + + There are two different types of CAPWAP data packets, CAPWAP Data + Channel Keep Alive packets and Data Payload packets. The first is + used by the WTP to synchronize the control and data channels, and to + maintain freshness of the data channel. The second is used to + transmit user payloads between the AC and WTP. This section + describes both types of CAPWAP data packet formats. + + Both CAPWAP data messages are transmitted on the CAPWAP data channel. + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 43] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + +4.4.1. CAPWAP Data Keepalive + + The CAPWAP Data Channel Keep Alive packet is used to bind the CAPWAP + control channel with the data channel, and to maintain freshness of + the data channel, ensuring that the channel is still functioning. + The CAPWAP Data Channel Keep Alive packet is transmitted by the WTP + when the DataChannelKeepAlive timer expires. When the CAPWAP Data + Channel Keep Alive packet is transmitted, the WTP sets the + DataChannelDeadInterval timer. + + In the CAPWAP Data Channel Keep Alive packet, all of the fields in + the CAPWAP header, except the HLEN field and the K bit, are set to + zero upon transmission. Upon receiving a CAPWAP Data Channel Keep + Alive packet, the AC transmits a CAPWAP Data Channel Keep Alive + packet back to the WTP. The contents of the transmitted packet are + identical to the contents of the received packet. + + Upon receiving a CAPWAP Data Channel Keep Alive packet, the WTP + cancels the DataChannelDeadInterval timer and resets the + DataChannelKeepAlive timer. The CAPWAP Data Channel Keep Alive + packet is retransmitted by the WTP in the same manner as the CAPWAP + control messages. If the DataChannelDeadInterval timer expires, the + WTP tears down the control DTLS session, and the data DTLS session if + one existed. + + The CAPWAP Data Channel Keep Alive packet contains the following + payload immediately following the CAPWAP Header (see Section 4.3) + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Message Element Length | Message Element [0..N] ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Message Element Length: The Length field indicates the number of + bytes following the CAPWAP Header. + + Message Element[0..N]: The message element(s) carry the information + pertinent to each of the CAPWAP Data Keepalive message. The + following message elements MUST be present in this CAPWAP message: + + Session ID, see Section 4.6.35 + +4.4.2. Data Payload + + A CAPWAP protocol Data Payload packet encapsulates a forwarded + wireless frame. The CAPWAP protocol defines two different modes of + encapsulation; IEEE 802.3 and native wireless. IEEE 802.3 + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 44] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + encapsulation requires that the bridging function be performed in the + WTP. An IEEE 802.3 encapsulated user payload frame has the following + format: + + +------------------------------------------------------+ + | IP Header | UDP Header | CAPWAP Header | 802.3 Frame | + +------------------------------------------------------+ + + The CAPWAP protocol also defines the native wireless encapsulation + mode. The format of the encapsulated CAPWAP data frame is subject to + the rules defined by the specific wireless technology binding. Each + wireless technology binding MUST contain a section entitled "Payload + Encapsulation", which defines the format of the wireless payload that + is encapsulated within CAPWAP Data packets. + + If the encapsulated frame would exceed the transport layer's MTU, the + sender is responsible for fragmentation of the frame, as specified in + Section 3.4. + +4.4.3. Establishment of a DTLS Data Channel + + If the AC and WTP are configured to tunnel the data channel over + DTLS, the proper DTLS session must be initiated. To avoid having to + reauthenticate and reauthorize an AC and WTP, the DTLS data channel + MUST be initiated using the TLS session resumption feature [7]. + + When establishing the DTLS-encrypted data channel, the WTP MUST + provide the identifier returned during the initialization of the + control channel to the DTLS component so it can perform the + resumption using the proper session information. + + The AC DTLS implementation MUST NOT accept a session resumption + request for a DTLS session in which the control channel for the + session has been torn down. + +4.5. CAPWAP Control Messages + + The CAPWAP Control protocol provides a control channel between the + WTP and the AC. Control messages are divided into the following + message types: + + Discovery: CAPWAP Discovery messages are used to identify potential + ACs, their load and capabilities. + + Join: CAPWAP Join messages are used by a WTP to request service from + an AC, and for the AC to respond to the WTP. + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 45] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + Control Channel Management: CAPWAP control channel management + messages are used to maintain the control channel. + + WTP Configuration Management: The WTP Configuration messages are + used by the AC to deliver a specific configuration to the WTP. + Messages which retrieve statistics from a WTP are also included in + WTP Configuration Management. + + Station Session Management: Station Session Management messages are + used by the AC to deliver specific station policies to the WTP. + + Device Management Operations: Device management operations are used + to request and deliver a firmware image to the WTP. + + Binding Specific CAPWAP Management Messages: Messages in this + category are used by the AC and the WTP to exchange protocol- + specific CAPWAP management messages. These messages may or may + not be used to change the link state of a station. + + Discovery, Join, Control Channel Management, WTP Configuration + Management and Station Session Management CAPWAP control messages + MUST be implemented. Device Management Operations messages MAY be + implemented. + + CAPWAP control messages sent from the WTP to the AC indicate that the + WTP is operational, providing an implicit keep-alive mechanism for + the WTP. The Control Channel Management Echo Request and Echo + Response messages provide an explicit keep-alive mechanism when other + CAPWAP control messages are not exchanged. + +4.5.1. Control Message Format + + All CAPWAP control messages are sent encapsulated within the CAPWAP + header (see Section 4.3). Immediately following the CAPWAP header, + is the control header, which has the following format: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Seq Num | Msg Element Length | Flags | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Msg Element [0..N] ... + +-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 46] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + +4.5.1.1. Message Type + + The Message Type field identifies the function of the CAPWAP control + message. The Message Type field is comprised of an IANA Enterprise + Number and an enterprise specific message type number. The first + three octets contain the enterprise number in network byte order, + with zero used for CAPWAP protocol defined message types and the IEEE + 802.11 IANA assigned enterprise number 13277 is used for IEEE 802.11 + technology specific message types. The last octet is the enterprise + specific message type number, which has a range from 0 to 255. + + The message type field is defined as: + + Message Type = + IANA Enterprise Number * 256 + + Enterprise Specific Message Type Number + + The CAPWAP protocol reliability mechanism requires that messages be + defined in pairs, consisting of both a Request and a Response + message. The Response message MUST acknowledge the Request message. + The assignment of CAPWAP control Message Type Values always occurs in + pairs. All Request messages have odd numbered Message Type Values, + and all Response messages have even numbered Message Type Values. + The Request value MUST be assigned first. As an example, assigning a + Message Type Value of 3 for a Request message and 4 for a Response + message is valid, while assigning a Message Type Value of 4 for a + Response message and 5 for the corresponding Request message is + invalid. + + When a WTP or AC receives a message with a Message Type Value field + that is not recognized and is an odd number, the number in the + Message Type Value Field is incremented by one, and a Response + message with a Message Type Value field containing the incremented + value and containing the Result Code message element with the value + (Unrecognized Request) is returned to the sender of the received + message. If the unknown message type is even, the message is + ignored. + + The valid values for CAPWAP Control Message Types are specified in + the table below: + + + + + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 47] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + CAPWAP Control Message Message Type + Value + Discovery Request 1 + Discovery Response 2 + Join Request 3 + Join Response 4 + Configuration Status 5 + Configuration Status Response 6 + Configuration Update Request 7 + Configuration Update Response 8 + WTP Event Request 9 + WTP Event Response 10 + Change State Event Request 11 + Change State Event Response 12 + Echo Request 13 + Echo Response 14 + Image Data Request 15 + Image Data Response 16 + Reset Request 17 + Reset Response 18 + Primary Discovery Request 19 + Primary Discovery Response 20 + Data Transfer Request 21 + Data Transfer Response 22 + Clear Configuration Request 23 + Clear Configuration Response 24 + Station Configuration Request 25 + Station Configuration Response 26 + +4.5.1.2. Sequence Number + + The Sequence Number Field is an identifier value used to match + Request and Response packets. When a CAPWAP packet with a Request + Message Type Value is received, the value of the Sequence Number + field is copied into the corresponding Response message. + + When a CAPWAP control message is sent, the sender's internal sequence + number counter is monotonically incremented, ensuring that no two + pending Request messages have the same Sequence Number. The Sequence + Number field wraps back to zero. + +4.5.1.3. Message Element Length + + The Length field indicates the number of bytes following the Sequence + Number field. + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 48] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + +4.5.1.4. Flags + + The Flags field MUST be set to zero. + +4.5.1.5. Message Element[0..N] + + The message element(s) carry the information pertinent to each of the + control message types. Every control message in this specification + specifies which message elements are permitted. + + When a WTP or AC receives a CAPWAP message without a message element + that is specified as mandatory for the CAPWAP message, then the + CAPWAP message is discarded. If the received message was a Request + message for which the corresponding Response message carries message + elements, then a corresponding Response message with a Result Code + message element indicating "Failure - Missing Mandatory Message + Element" is returned to the sender. + + When a WTP or AC receives a CAPWAP message with a message element + that the WTP or AC does not recognize, the CAPWAP message is + discarded. If the received message was a Request message for which + the corresponding Response message carries message elements, then a + corresponding Response message with a Result Code message element + indicating "Failure - Unrecognized Message Element" and one or more + Returned Message Element message elements is included, containing the + unrecognized message element(s). + +4.5.2. Control Message Quality of Service + + It is recommended that CAPWAP control messages be sent by both the AC + and the WTP with an appropriate Quality of Service precedence value, + ensuring that congestion in the network minimizes occurrences of + CAPWAP control channel disconnects. Therefore, a Quality of Service + enabled CAPWAP device SHOULD use the following values: + + 802.1P: The precedence value of 7 SHOULD be used. + + DSCP: The DSCP tag value of 46 SHOULD be used. + +4.5.3. Retransmissions + + The CAPWAP control protocol operates as a reliable transport. For + each Request message, a Response message is defined, which is used to + acknowledge receipt of the Request message. In addition, the control + header Sequence Number field is used to pair the Request and Response + messages (see Section 4.5.1). + + Response messages are not explicitly acknowledged, therefore if a + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 49] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + Response message is not received, the original Request message is + retransmitted. Implementations MAY cache Response messages to + respond to a retransmitted Request messages with minimal local + processing. Retransmitted Request messages MUST NOT be altered by + the sender. The sender MUST assume that the original Request message + was processed, but that the Response message was lost. Any + alterations to the original Request message MUST have a new Sequence + Number, and be treated as a new Request message by the receiver. + + After transmitting a Request message, the RetransmitInterval (see + Section 4.7) timer and MaxRetransmit (see Section 4.8) variable are + used to determine if the original Request message needs to be + retransmitted. The RetransmitInterval timer is used the first time + the Request is retransmitted. The timer is then doubled every + subsequent time the same Request message is retransmitted, up to + MaxRetransmit but no more than half the EchoInterval timer (see + Section 4.7.5). Response messages are not subject to these timers. + + When a Request message is retransmitted, it MUST be re-encrypted via + the DTLS stack. If the peer had received the Request message, and + the corresponding Response message was lost, it is necessary to + ensure that retransmitted Request messages are not identified as + replays by the DTLS stack. Similarly, any cached Response messages + that are retransmitted as a result of receiving a retransmitted + Request message MUST be re-encrypted via DTLS. + + Duplicate Response messages, identified by the Sequence Number field + in the CAPWAP control message header, SHOULD be discarded upon + receipt. + +4.6. CAPWAP Protocol Message Elements + + This section defines the CAPWAP Protocol message elements which are + included in CAPWAP protocol control messages. + + Message elements are used to carry information needed in control + messages. Every message element is identified by the Type Value + field, defined below. The total length of the message elements is + indicated in the message element Length field. + + All of the message element definitions in this document use a diagram + similar to the one below in order to depict its format. Note that to + simplify this specification, these diagrams do not include the header + fields (Type and Length). The header field values are defined in the + message element descriptions. + + Unless otherwise specified, a control message that lists a set of + supported (or expected) message elements MUST not expect the message + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 50] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + 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. + + Additional message elements may be defined in separate IETF + documents. + + The format of a message element uses the TLV format shown here: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value ... | + +-+-+-+-+-+-+-+-+ + + The 16 bit Type field identifies the information carried in the Value + field and Length (16 bits) indicates the number of bytes in the Value + field. Type field values are allocated as follows: + + Usage Type Values + + CAPWAP Protocol Message Elements 1-1023 + IEEE 802.11 Message Elements 1024-2047 + IEEE 802.16 Message Elements 2048 - 3071 + EPCGlobal Message Elements 3072 - 4095 + Reserved for Future Use 4096 - 65024 + + The table below lists the CAPWAP protocol Message Elements and their + Type values. + + CAPWAP Message Element Type Value + + AC Descriptor 1 + AC IPv4 List 2 + AC IPv6 List 3 + AC Name 4 + AC Name with Index 5 + AC Timestamp 6 + Add MAC ACL Entry 7 + Add Station 8 + Add Static MAC ACL Entry 9 + CAPWAP Control IPV4 Address 10 + CAPWAP Control IPV6 Address 11 + CAPWAP Timers 12 + Data Transfer Data 13 + Data Transfer Mode 14 + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 51] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + Decryption Error Report 15 + Decryption Error Report Period 16 + Delete MAC ACL Entry 17 + Delete Station 18 + Delete Static MAC ACL Entry 19 + Discovery Type 20 + Duplicate IPv4 Address 21 + Duplicate IPv6 Address 22 + Idle Timeout 23 + Image Data 24 + Image Identifier 25 + Image Info 26 + Initiate Download 27 + Location Data 28 + Maximum Message Length 29 + MTU Discovery Padding 30 + Radio Administrative State 31 + Radio Operational State 32 + Result Code 33 + Returned Message Element 34 + Session ID 35 + Statistics Timer 36 + Vendor Specific Payload 37 + WTP Board Data 38 + WTP Descriptor 39 + WTP Fallback 40 + WTP Frame Tunnel Mode 41 + WTP IPv4 IP Address 42 + WTP IPv6 IP Address 43 + WTP MAC Type 44 + WTP Name 45 + WTP Operational Statistics 46 + WTP Radio Statistics 47 + WTP Reboot Statistics 48 + WTP Static IP Address Information 49 + + +4.6.1. AC Descriptor + + The AC Descriptor message element is used by the AC to communicate + its current state. The value contains the following fields. + + + + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 52] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Stations | Limit | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Active WTPs | Max WTPs | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Security | R-MAC Field | Reserved1 | DTLS Policy | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type=4 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type=5 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Type: 1 for AC Descriptor + + Length: >= 12 + + Stations: The number of stations currently served by the AC + + Limit: The maximum number of stations supported by the AC + + Active WTPs: The number of WTPs currently attached to the AC + + Max WTPs: The maximum number of WTPs supported by the AC + + Security: A 8 bit bit mask specifying the authentication credential + type supported by the AC. The following values are supported (see + Section 2.4.4): + + 1 - X.509 Certificate Based + + 2 - Pre-Shared Secret + + R-MAC Field: The AC supports the optional Radio MAC Address field + in the CAPWAP transport Header (see Section 4.3). + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 53] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + Reserved: A set of reserved bits for future use. All + implementations complying with this protocol MUST set to zero any + bits that are reserved in the version of the protocol supported by + that implementation. Receivers MUST ignore all bits not defined + for the version of the protocol they support. + + DTLS Policy: The AC communicates its policy on the use of DTLS for + the CAPWAP data channel. The AC MAY communicate more than one + supported option, represented by the bit field below. The WTP + MUST abide by one of the options communicated by AC. The + following bit field values are supported: + + 1 - Clear Text Data Channel Supported + + 2 - DTLS Enabled Data Channel Supported + + Vendor Identifier: A 32-bit value containing the IANA assigned "SMI + Network Management Private Enterprise Codes" + + Type: Vendor specific encoding of AC information. The following + values are supported. The Hardware and Software Version values + MUST be included. + + 4 - Hardware Version: The AC's hardware version number. + + 5 - Software Version: The AC's Software (firmware) version + number. + + Length: Length of vendor specific encoding of AC information. + + Value: Vendor specific encoding of AC information. + +4.6.2. AC IPv4 List + + The AC IPv4 List message element is used to configure a WTP with the + latest list of ACs available for the WTP to join. + + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AC IP Address[] | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 54] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + Type: 2 for AC IPv4 List + + Length: >= 4 + + The AC IP Address: An array of 32-bit integers containing AC IPv4 + Addresses. + +4.6.3. AC IPv6 List + + The AC IPv6 List message element is used to configure a WTP with the + latest list of ACs available for the WTP to join. + + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AC IP Address[] | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AC IP Address[] | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AC IP Address[] | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AC IP Address[] | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Type: 3 for AC IPV6 List + + Length: >= 16 + + The AC IP Address: An array of 128-bit integers containing AC IPv6 + Addresses. + +4.6.4. AC Name + + The AC Name message element contains an UTF-8 representation of the + AC identity. The value is a variable length byte string. The string + is NOT zero terminated. + + 0 + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + | Name ... + +-+-+-+-+-+-+-+-+ + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 55] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + Type: 4 for AC Name + + Length: > 0 + + Name: A variable length UTF-8 encoded string containing the AC's + name + +4.6.5. AC Name with Index + + The AC Name with Index message element is sent by the AC to the WTP + to configure preferred ACs. The number of instances of this message + element is equal to the number of ACs configured on the WTP. + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Index | AC Name... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 5 for AC Name with Index + + Length: > 2 + + Index: The index of the preferred server (1=primary, 2=secondary). + + AC Name: A variable length UTF-8 encoded string containing the AC + name. + +4.6.6. AC Timestamp + + The AC Timestamp message element is sent by the AC to synchronize the + WTP clock. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Timestamp | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 6 for AC Timestamp + + Length: 4 + + Timestamp: The AC's current time, allowing all of the WTPs to be + time synchronized in the format defined by Network Time Protocol + (NTP) in RFC 1305 [3]. + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 56] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + +4.6.7. Add MAC ACL Entry + + The Add MAC Access Control List (ACL) Entry message element is used + by an AC to add a MAC ACL list entry on a WTP, ensuring that the WTP + no longer provides service to the MAC addresses provided in the + message. The MAC Addresses provided in this message element are not + expected to be saved in non-volatile memory on the WTP. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Num of Entries| Length | MAC Address ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 7 for Add MAC ACL Entry + + Length: >= 8 + + Num of Entries: The number of instances of the Type/MAC Addresses + fields in the array. + + Length: The length of the MAC Address field. + + MAC Address: MAC Addresses to add to the ACL. + +4.6.8. Add Station + + The Add Station message element is used by the AC to inform a WTP + that it should forward traffic for a station. The Add Station + message element is accompanied by technology specific binding + information element(s) which may include security parameters. + Consequently, the security parameters MUST be applied by the WTP for + the station. + + After station policy has been delivered to the WTP through the Add + Station message element, an AC MAY change any policies by sending a + modified Add Station message element. When a WTP receives an Add + Station message element for an existing station, it MUST override any + existing state for the station. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Radio ID | Length | MAC Address ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | VLAN Name... + +-+-+-+-+-+-+-+-+ + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 57] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + Type: 8 for Add Station + + Length: >= 8 + + Radio ID: An 8-bit value representing the radio + + Length: The length of the MAC Address field. + + MAC Address: The station's MAC Address + + VLAN Name: An optional variable length UTF-8 encoded string + containing the VLAN Name on which the WTP is to locally bridge + user data. Note this field is only valid with WTPs configured in + Local MAC mode. + +4.6.9. Add Static MAC ACL Entry + + The Add Static MAC ACL Entry message element is used by an AC to add + a permanent ACL entry on a WTP, ensuring that the WTP no longer + provides any service to the MAC addresses provided in the message. + The MAC Addresses provided in this message element are expected to be + saved in non-volative memory on the WTP. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Num of Entries| Length | MAC Address ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 9 for Add Static MAC ACL Entry + + Length: >= 8 + + Num of Entries: The number of instances of the Type/MAC Addresses + fields in the array. + + Length: The length of the MAC Address field. + + MAC Address: MAC Addresses to add to the permanent ACL. + +4.6.10. CAPWAP Control IPv4 Address + + The CAPWAP Control IPv4 Address message element is sent by the AC to + the WTP during the discovery process and is used by the AC to provide + the interfaces available on the AC, and the current number of WTPs + connected. When multiple CAPWAP Control IPV4 Address message + elements are returned, the WTP SHOULD perform load balancing across + the multiple interfaces. + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 58] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IP Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | WTP Count | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 10 for CAPWAP Control IPv4 Address + + Length: 6 + + IP Address: The IP Address of an interface. + + WTP Count: The number of WTPs currently connected to the interface. + +4.6.11. CAPWAP Control IPv6 Address + + The CAPWAP Control IPv6 Address message element is sent by the AC to + the WTP during the discovery process and is used by the AC to provide + the interfaces available on the AC, and the current number of WTPs + connected. This message element is useful for the WTP to perform + load balancing across multiple interfaces. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IP Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IP Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IP Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IP Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | WTP Count | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 11 for CAPWAP Control IPv6 Address + + Length: 18 + + IP Address: The IP Address of an interface. + + WTP Count: The number of WTPs currently connected to the interface. + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 59] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + +4.6.12. CAPWAP Timers + + The CAPWAP Timers message element is used by an AC to configure + CAPWAP timers on a WTP. + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Discovery | Echo Request | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 12 for CAPWAP Timers + + Length: 2 + + Discovery: The number of seconds between CAPWAP Discovery messages, + when the WTP is in the discovery phase. + + Echo Request: The number of seconds between WTP Echo Request CAPWAP + messages. The default value for this message element is specified + in Section 4.7.5. + +4.6.13. Data Transfer Data + + The Data Transfer Data message element is used by the WTP to provide + information to the AC for debugging purposes. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data Type | Data Length | Data .... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 13 for Data Transfer Data + + Length: >= 3 + + Data Type: An 8-bit value the type of information being sent. The + following values are supported: + + 1 - WTP Crash Data + + 2 - WTP Memory Dump + + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 60] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + Data Length: Length of data field. + + Data: Debug information. + +4.6.14. Data Transfer Mode + + The Data Transfer Mode message element is used by the WTP to indicate + the type of data transfer information it is sending to the AC for + debugging purposes. + + 0 + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + | Data Type | + +-+-+-+-+-+-+-+-+ + + Type: 14 for Data Transfer Mode + + Length: 1 + + Data Type: An 8-bit value the type of information being requested. + The following values are supported: + + 1 - WTP Crash Data + + 2 - WTP Memory Dump + +4.6.15. Decryption Error Report + + The Decryption Error Report message element value is used by the WTP + to inform the AC of decryption errors that have occurred since the + last report. Note that this error reporting mechanism is not used if + encryption and decryption services are provided in the AC. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Radio ID |Num Of Entries | Length |MAC Address... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 15 for Decryption Error Report + + Length: >= 9 + + Radio ID: The Radio Identifier refers to an interface index on the + WTP. + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 61] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + Num of Entries: The number of instances of the Type/MAC Addresses + fields in the array. + + Length: The length of the MAC Address field. + + MAC Address: MAC addresses of the station that has caused + decryption errors. + +4.6.16. Decryption Error Report Period + + The Decryption Error Report Period message element value is used by + the AC to inform the WTP how frequently it should send decryption + error report messages. Note that this error reporting mechanism is + not used if encryption and decryption services are provided in the + AC. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Radio ID | Report Interval | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 16 for Decryption Error Report Period + + Length: 3 + + Radio ID: The Radio Identifier refers to an interface index on the + WTP. + + Report Interval: A 16-bit unsigned integer indicating the time, in + seconds. The default value for this message element can be found + in Section 4.8.8. + +4.6.17. Delete MAC ACL Entry + + The Delete MAC ACL Entry message element is used by an AC to delete a + MAC ACL entry on a WTP, ensuring that the WTP provides service to the + MAC addresses provided in the message. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Num of Entries| Length | MAC Address ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 62] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + Type: 17 for Delete MAC ACL Entry + + Length: >= 8 + + Num of Entries: The number of instances of the Type/MAC Addresses + fields in the array. + + Length: The length of the MAC Address field. + + MAC Address: An array of MAC Addresses to delete from the ACL. + +4.6.18. Delete Station + + The Delete Station message element is used by the AC to inform a WTP + that it should no longer provide service to a particular station. + The WTP MUST terminate service to the station immediately upon + receiving this message element. + + The transmission of a Delete Station message element could occur for + various reasons, including for administrative reasons, or if the + station has roamed to another WTP. + + The Delete Station message element MAY be sent by the WTP, in the WTP + Event Request message, to inform the AC that a particular station is + no longer being provided service. This could occur as a result of an + Idle Timeout (see section 4.4.43), due to internal resource shortages + or for some other reason. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Radio ID | Length | MAC Address... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 18 for Delete Station + + Length: >= 8 + + Radio ID: An 8-bit value representing the radio + + Length: The length of the MAC Address field. + + MAC Address: The station's MAC Address + + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 63] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + +4.6.19. Delete Static MAC ACL Entry + + The Delete Static MAC ACL Entry message element is used by an AC to + delete a previously added static MAC ACL entry on a WTP, ensuring + that the WTP provides service to the MAC addresses provided in the + message. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Num of Entries| Length | MAC Address ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 19 for Delete Static MAC ACL Entry + + Length: >= 8 + + Num of Entries: The number of instances of the Type/MAC Addresses + fields in the array. + + Length: The length of the MAC Address field. + + MAC Address: An array of MAC Addresses to delete from the static + MAC ACL entry. + +4.6.20. Discovery Type + + The Discovery Type message element is used by the WTP to indicate how + it has come to know about the existence of the AC to which it is + sending the Discovery Request message. + + 0 + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + | Discovery Type| + +-+-+-+-+-+-+-+-+ + + Type: 20 for Discovery Type + + Length: 1 + + Discovery Type: An 8-bit value indicating how the WTP discovered + the AC. The following values are supported: + + 0 - Unknown + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 64] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + 1 - Static Configuration + + 2 - DHCP + + 3 - DNS + + 4 - AC Referral (used when the AC was configured either through + the AC IPv4 List or AC IPv6 List message element) + +4.6.21. Duplicate IPv4 Address + + The Duplicate IPv4 Address message element is used by a WTP to inform + an AC that it has detected another IP device using the same IP + address that the WTP is currently using. + + The WTP MUST transmit this message element with the status set to 1 + after it has detected a duplicate IP address. When the WTP detects + that the duplicate IP address has been cleared, it MUSY send this + message element with the status set to 0. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IP Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Status | Length | MAC Address ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 21 for Duplicate IPv4 Address + + Length: >= 12 + + IP Address: The IP Address currently used by the WTP. + + Status: The status of the duplicate IP address. The value MUST be + set to 1 when a duplicate address is detected, and 0 when the + duplicate address has been cleared. + + Length: The length of the MAC Address field. + + MAC Address: The MAC Address of the offending device. + +4.6.22. Duplicate IPv6 Address + + The Duplicate IPv6 Address message element is used by a WTP to inform + an AC that it has detected another host using the same IP address + that the WTP is currently using. + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 65] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + The WTP MUST transmit this message element with the status set to 1 + after it has detected a duplicate IP address. When the WTP detects + that the duplicate IP address has been cleared, it MUST send this + message element with the status set to 0. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IP Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IP Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IP Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IP Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Status | Length | MAC Address ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 23 for Duplicate IPv6 Address + + Length: >= 24 + + IP Address: The IP Address currently used by the WTP. + + Status: The status of the duplicate IP address. The value MUST be + set to 1 when a duplicate address is detected, and 0 when the + duplicate address has been cleared. + + Length: The length of the MAC Address field. + + MAC Address: The MAC Address of the offending device. + +4.6.23. Idle Timeout + + The Idle Timeout message element is sent by the AC to the WTP to + provide the idle timeout value that the WTP SHOULD enforce for its + active stations. The value applies to all radios on the WTP. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Timeout | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 66] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + Type: 23 for Idle Timeout + + Length: 4 + + Timeout: The current idle timeout to be enforced by the WTP. The + default value for this message element is specified in + Section 4.8.5. + +4.6.24. Image Data + + The Image Data message element is present in the Image Data Request + message sent by the AC and contains the following fields. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Opcode | Value ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 24 for Image Data + + Length: >= 1 + + Opcode: An 8-bit value representing the transfer opcode. The + following values are supported: + + 1 - Image data is included + + 2 - Last Image Data Block is included (EOF) + + 5 - An error occurred. Transfer is aborted + + Value: The Image Data field contains up to 1024 characters. If the + block being sent is the last one, the Opcode is set to 2. The AC + MAY opt to abort the data transfer by setting the Opcode to 5. + When the Opcode is 5, the Value field has a zero length. + +4.6.25. Image Identifier + + The Image Identifier message element is sent by the AC to the WTP and + is used to indicate the expected active software version that is to + be run on the WTP. The value is a variable length UTF-8 encoded + string, which is NOT zero terminated. + + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 67] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 25 for Image Identifier + + Length: >= 1 + + Value: A variable length UTF-8 encoded string containing the + firmware identifier to be run on the WTP. + +4.6.26. Image Information + + The Image Information message element is present in the Image Data + Response message sent by the AC to the WTP and contains the following + fields. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | File Size | Hash | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Hash | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Hash | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Hash | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Hash | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 26 for Image Information + + Length: 18 + + File Size: A 16-bit value containing the size of the file that will + be transfered by the AC to the WTP. + + Hash: A 16 octet hash of the image. The hash is computed using + MD5, using the following pseudo-code: + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 68] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + #include <md5.h> + CapwapCreateHash(char *hash, char *image, int image_len) + { + MD_CTX context; + + MDInit (&context); + MDUpdate (&context, buffer, len); + MDFinal (hash, &context); + } + +4.6.27. Initiate Download + + The Initiate Download message element is used by the AC to inform the + WTP that the WTP SHOULD initiate a firmware upgrade. The WTP + subsequently transmits an Image Data Request message which includes + the Image Download message element. This message element does not + contain any data. + + Type: 27 for Initiate Download + + Length: 0 + +4.6.28. Location Data + + The Location Data message element is a variable length byte UTF-8 + encoded string containing user defined location information (e.g. + "Next to Fridge"). This information is configurable by the network + administrator, and allows the WTP location to be determined. The + string is not zero terminated. + + 0 + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+- + | Location ... + +-+-+-+-+-+-+-+-+- + + Type: 28 for Location Data + + Length: > 0 + + Location: A non-zero terminated UTF-8 encoded string containing the + WTP location. + +4.6.29. Maximum Message Length + + The Maximum Message Length message element is included in the Join + Request message by the WTP to indicate the maximum CAPWAP message + length that it supports to the AC. The Maximum Message Length + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 69] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + message element is optionally included in Join Response message by + the AC to indicate the maximum CAPWAP message length that it supports + to the WTP. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Maximum Message Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + + Type: 29 for Maximim Message Length + + Length: 2 + + Maximum Message Length An 16-bit unsigned integer indicating the + maximum message length. + +4.6.30. MTU Discovery Padding + + The MTU Discovery Padding message element is used as padding to + perform MTU discovery, and MUST contain octets of value 0xFF, of any + length + + 0 + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + | Padding... + +-+-+-+-+-+-+-+- + + + Type: 30 for MTU Discovery Padding + + Length: variable + + Pad: A variable length pad. + +4.6.31. Radio Administrative State + + The Radio Administrative State message element is used to communicate + the state of a particular radio. The Radio Administrative State + message element is sent by the AC to change the state of the WTP. + The WTP saves the value, to ensure that it remains across WTP resets. + The WTP communicates this message element during the configuration + phase, in the Configuration Status Request message, to ensure that AC + has the WTP radio current administrative state settings. The message + element contains the following fields. + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 70] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Radio ID | Admin State | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 31 for Radio Administrative State + + Length: 2 + + Radio ID: An 8-bit value representing the radio to configure. The + Radio ID field MAY also include the value of 0xff, which is used + to identify the WTP. If an AC wishes to change the administrative + state of a WTP, it includes 0xff in the Radio ID field. + + Admin State: An 8-bit value representing the administrative state + of the radio. The default value for the Admin State field is + listed in Section 4.8.1. The following values are supported: + + 1 - Enabled + + 2 - Disabled + +4.6.32. Radio Operational State + + The Radio Operational State message element is sent by the WTP to the + AC to communicate a radio's operational state. This message element + is included in the Configuration Update Response message by the WTP + if it was requested to change the state of its radio, via the Radio + Administrative State message element, but was unable to comply to the + request. This message element is included in the Change State Event + message when a WTP radio state was changed unexpectedly. This could + occur due to a hardware failure. Note that the operational state + setting is not saved on the WTP, and therefore does not remain across + WTP resets. The value contains three fields, as shown below. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Radio ID | State | Cause | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 32 for Radio Operational State + + Length: 3 + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 71] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + Radio ID: The Radio Identifier refers to an interface index on the + WTP. A value of 0xFF is invalid, as it is not possible to change + the WTP's operational state. + + State: An 8-bit boolean value representing the state of the radio. + A value of one disables the radio, while a value of two enables + it. + + Cause: When a radio is inoperable, the cause field contains the + reason the radio is out of service. The following values are + supported: + + 0 - Normal + + 1 - Radio Failure + + 2 - Software Failure + + 3 - Administratively Set + +4.6.33. Result Code + + The Result Code message element value is a 32-bit integer value, + indicating the result of the Request message corresponding to the + Sequence Number included in the Response message. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Result Code | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 33 for Result Code + + Length: 4 + + Result Code: The following values are defined: + + 0 Success + + 1 Failure (AC List message element MUST be present) + + 2 Success (NAT detected) + + 3 Join Failure (unspecified) + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 72] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + 4 Join Failure (Resource Depletion) + + 5 Join Failure (Unknown Source) + + 6 Join Failure (Incorrect Data) + + 7 Join Failure (Session ID already in use) + + 8 Join Failure (WTP Hardware not supported) + + 9 Join Failure (Binding Not Supported) + + 10 Reset Failure (Unable to Reset) + + 11 Reset Failure (Firmware Write Error) + + 12 Configuration Failure (Unable to Apply Requested Configuration + - Service Provided Anyhow) + + 13 Configuration Failure (Unable to Apply Requested Configuration + - Service Not Provided) + + 14 Image Data Error (Invalid Checksum) + + 15 Image Data Error (Invalid Data Length) + + 16 Image Data Error (Other Error) + + 17 Image Data Error (Image Already Present) + + 18 Message Unexpected (Invalid in current state) + + 19 Message Unexpected (Unrecognized Request) + + 20 Failure - Missing Mandatory Message Element + + 21 Failure - Unrecognized Message Element + +4.6.34. Returned Message Element + + The Returned Message Element is sent by the WTP in the Change State + Event Request message to communicate to the AC which message elements + in the Configuration Status Response it was unable to apply locally. + The Returned Message Element message element contains a result code + indicating the reason that the configuration could not be applied, + and encapsulates the failed message element. + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 73] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reason | Message Element... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 34 for Returned Message Element + + Length: >= 1 + + Reason: The reason why the configuration in the offending message + element could not be applied by the WTP. + + 1 - Unknown Message Element + + 2 - Unsupported Message Element + + 3 - Unknown Message Element Value + + 4 - Unsupported Message Element Value + + Message Element: The Message Element field encapsulates the message + element sent by the AC in the Configuration Status Response + message that caused the error. + +4.6.35. Session ID + + The Session ID message element value contains a randomly generated + unsigned 32-bit integer. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Session ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Type: 35 for Session ID + + Length: 16 + + Session ID: A 32-bit unsigned integer used as a random session + identifier + + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 74] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + +4.6.36. Statistics Timer + + The Statistics Timer message element value is used by the AC to + inform the WTP of the frequency with which it expects to receive + updated statistics. + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Statistics Timer | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 36 for Statistics Timer + + Length: 2 + + Statistics Timer: A 16-bit unsigned integer indicating the time, in + seconds. The default value for this timer is specified in + Section 4.7.12. + +4.6.37. Vendor Specific Payload + + The Vendor Specific Payload message element is used to communicate + vendor specific information between the WTP and the AC. The message + element uses the following format: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Element ID | Value... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 37 for Vendor Specific + + Length: >= 7 + + Vendor Identifier: A 32-bit value containing the IANA assigned "SMI + Network Management Private Enterprise Codes" [14] + + Element ID: A 16-bit Element Identifier which is managed by the + vendor. + + Value: The value associated with the vendor specific element. + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 75] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + +4.6.38. WTP Board Data + + The WTP Board Data message element is sent by the WTP to the AC and + contains information about the hardware present. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type=0 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type=1 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Optional additional vendor specific WTP board data TLVs..... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Type: 38 for WTP Board Data + + Length: >=14 + + Vendor Identifier: A 32-bit value containing the IANA assigned "SMI + Network Management Private Enterprise Codes" + + Type: The following values are supported: + + 0 - WTP Model Number: The WTP Model Number MUST be included in + the WTP Board Data message element. + + 1 - WTP Serial Number: The WTP Serial Number MUST be included in + the WTP Board Data message element. + + 2 - Board ID: A hardware identifier, which MAY be included in + the WTP Board Data mesage element. + + 3 - Board Revision A revision number of the board, which MAY be + included in the WTP Board Data message element. + + 4 - Base MAC Addres The WTP's Base MAC Address, which MAY be + assigned to the primary Ethernet interface. + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 76] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + +4.6.39. WTP Descriptor + + The WTP Descriptor message element is used by a WTP to communicate + its current hardware and software (firmware) configuration. The + value contains the following fields. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Max Radios | Radios in use | Encryption Capabilities | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type=0 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type=1 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type=2 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type=3 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Type: 39 for WTP Descriptor + + Length: >= 31 + + Max Radios: An 8-bit value representing the number of radios (where + each radio is identified via the Radio ID field) supported by the + WTP. + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 77] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + Radios in use: An 8-bit value representing the number of radios in + use in the WTP. + + Encryption Capabilities: This 16-bit field is used by the WTP to + communicate its capabilities to the AC. A WTP that does not have + any encryption capabilities sets this field to zero (0). Refer to + the specific wireless binding for further specification of the + Encryption Capabilities field. + + Vendor Identifier: A 32-bit value containing the IANA assigned "SMI + Network Management Private Enterprise Codes". + + Type: The following values are supported. The Hardware Version, + Active Software Version, and Boot Version values MUST be included. + Zero or more Other Software Version values MAY be included. + + 0 - Hardware Version: The WTP hardware version number. + + 1 - Active Software Version: The WTP running software version + number. + + 2 - Boot Version: The WTP boot loader version number. + + 3 - Other Software Version: The WTP non-running software + (firmware) version number. + + Length: Length of vendor specific encoding of WTP information. + + Value: Vendor specific data of WTP information encoded in the UTF-8 + format. + +4.6.40. WTP Fallback + + The WTP Fallback message element is sent by the AC to the WTP to + enable or disable automatic CAPWAP fallback in the event that a WTP + detects its preferred AC, and is not currently connected to it. + + 0 + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + | Mode | + +-+-+-+-+-+-+-+-+ + + Type: 40 for WTP Fallback + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 78] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + Length: 1 + + Mode: The 8-bit value indicates the status of automatic CAPWAP + fallback on the WTP. When enabled, if the WTP detects that its + primary AC is available, and that the WTP is not connected to the + primary AC, the WTP SHOULD automatically disconnect from its + current AC and reconnect to its primary AC. If disabled, the WTP + will only reconnect to its primary AC through manual intervention + (e.g., through the Reset Request message). The default value for + this field is specified in Section 4.8.10. The following values + are supported: + + 1 - Enabled + + 2 - Disabled + +4.6.41. WTP Frame Tunnel Mode + + The WTP Frame Tunnel Mode message element allows the WTP to + communicate the tunneling modes of operation which it supports to the + AC. A WTP that advertises support for all types allows the AC to + select which type will be used, based on its local policy. + + 0 + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + | Tunnel Mode | + +-+-+-+-+-+-+-+-+ + + Type: 41 for WTP Frame Tunnel Mode + + Length: 1 + + Frame Tunnel Mode: The Frame Tunnel mode specifies the tunneling + modes for station data that are supported by the WTP. The + following values are supported: + + 1 - Local Bridging: When Local Bridging is used, the WTP does + not tunnel user traffic to the AC; all user traffic is locally + bridged. This value MUST NOT be used when the WTP MAC Type is + set to Split-MAC. + + 2 - 802.3 Frame Tunnel Mode: The 802.3 Frame Tunnel Mode + requires the WTP and AC to encapsulate all user payload as + native IEEE 802.3 frames (see Section 4.4). All user traffic + is tunneled to the AC. This value MUST NOT be used when the + WTP MAC Type is set to Split-MAC. + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 79] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + 4 - Native Frame Tunnel Mode: Native Frame Tunnel mode requires + the WTP and AC to encapsulate all user payloads as native + wireless frames, as defined by the wireless binding (see for + example Section 4.4). + + 7 - All: The WTP is capable of supporting all frame tunnel + modes. + +4.6.42. WTP IPv4 IP Address + + The WTP IPv4 address is used to perform NAT detection. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | WTP IPv4 IP Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Type: 42 for WTP IPv4 IP Address + + Length: 4 + + WTP IPv4 IP Address: The IPv4 address from which the WTP is sending + packets. This field is used for NAT detection. + +4.6.43. WTP IPv6 IP Address + + The WTP IPv6 address is used to perform NAT detection (e.g., IPv4 to + IPv6 NAT to help with technology transition). + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | WTP IPv6 IP Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | WTP IPv6 IP Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | WTP IPv6 IP Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | WTP IPv6 IP Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 80] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + Type: 43 for WTP IPv6 IP Address + + Length: 32 + + WTP IPv6 IP Address: The IPv6 address from which the WTP is sending + packets. This field is used for NAT detection. + +4.6.44. WTP MAC Type + + The WTP MAC-Type message element allows the WTP to communicate its + mode of operation to the AC. A WTP that advertises support for both + modes allows the AC to select the mode to use, based on local policy. + + 0 + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + | MAC Type | + +-+-+-+-+-+-+-+-+ + + Type: 44 for WTP MAC Type + + Length: 1 + + MAC Type: The MAC mode of operation supported by the WTP. The + following values are supported + + 0 - Local-MAC: Local-MAC is the default mode that MUST be + supported by all WTPs. + + 1 - Split-MAC: Split-MAC support is optional, and allows the AC + to receive and process native wireless frames. + + 2 - Both: WTP is capable of supporting both Local-MAC and Split- + MAC. + +4.6.45. WTP Name + + The WTP Name message element is a variable length byte UTF-8 encoded + string. The string is not zero terminated. + + 0 + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+- + | WTP Name ... + +-+-+-+-+-+-+-+-+- + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 81] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + Type: 45 for WTP Name + + Length: variable + + WTP Name: A non-zero terminated UTF-8 encoded string containing the + WTP name. + +4.6.46. WTP Operational Statistics + + The WTP Operational Statistics message element is sent by the WTP to + the AC to provide statistics related to the operation of the WTP. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Radio ID | Tx Queue Level | Wireless Link Frames per Sec | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Type: 46 for WTP Operational Statistics + + Length: 4 + + Radio ID: The radio ID of the radio to which the statistics apply. + + Wireless Transmit Queue Level: The percentage of Wireless Transmit + queue utilization, calculated as the sum of utilized transmit + queue lengths divided by the sum of maximum transmit queue + lengths, multiplied by 100. The Wireless Transmit Queue Level is + representative of congestion conditions over wireless interfaces + between the WTP and stations. + + Wireless Link Frames per Sec: The number of frames transmitted or + received per second by the WTP over the air interface. + +4.6.47. WTP Radio Statistics + + The WTP Radio Statistics message element is sent by the WTP to the AC + to communicate statistics on radio behavior and reasons why the WTP + radio has been reset. + + + + + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 82] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Radio ID | Last Fail Type| Reset Count | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | SW Failure Count | HW Failure Count | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Other Failure Count | Unknown Failure Count | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Config Update Count | Channel Change Count | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Band Change Count | Current Noise Floor | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 47 for WTP Radio Statistics + + Length: 20 + + Radio ID: The radio ID of the radio to which the statistics apply. + + Last Failure Type: The last WTP failure. The following values are + supported: + + 0 - Statistic Not Supported + + 1 - Software Failure + + 2 - Hardware Failure + + 3 - Other Failure + + 255 - Unknown (e.g., WTP doesn't keep track of info) + + Reset Count: The number of times that that the radio has been + reset. + + SW Failure Count: The number of times that the radio has failed due + to software related reasons. + + HW Failure Count: The number of times that the radio has failed due + to hardware related reasons. + + Other Failure Count: The number of times that the radio has failed + due to known reasons, other than software or hardware failure. + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 83] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + Unknown Failure Count: The number of times that the radio has + failed for unknown reasons. + + Config Update Count: The number of times that the radio + configuration has been updated. + + Channel Change Count: The number of times that the radio channel + has been changed. + + Band Change Count: The number of times that the radio has changed + frequency bands. + + Current Noise Floor: A signed integer which indicates the noise + floor of the radio receiver in units of dBm. + +4.6.48. WTP Reboot Statistics + + The WTP Reboot Statistics message element is sent by the WTP to the + AC to communicate reasons why WTP reboots have occurred. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reboot Count | AC Initiated Count | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Link Failure Count | SW Failure Count | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | HW Failure Count | Other Failure Count | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Unknown Failure Count |Last Failure Type| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Type: 48 for WTP Reboot Statistics + + Length: 15 + + Reboot Count: The number of reboots that have occurred due to a WTP + crash. A value of 65535 implies that this information is not + available on the WTP. + + AC Initiated Count: The number of reboots that have occurred at the + request of a CAPWAP protocol message, such as a change in + configuration that required a reboot or an explicit CAPWAP + protocol reset request. A value of 65535 implies that this + information is not available on the WTP. + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 84] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + Link Failure Count: The number of times that a CAPWAP protocol + connection with an AC has failed due to link failure. + + SW Failure Count: The number of times that a CAPWAP protocol + connection with an AC has failed due to software related reasons. + + HW Failure Count: The number of times that a CAPWAP protocol + connection with an AC has failed due to hardware related reasons. + + Other Failure Count: The number of times that a CAPWAP protocol + connection with an AC has failed due to known reasons, other than + AC initiated, link, SW or HW failure. + + Unknown Failure Count: The number of times that a CAPWAP protocol + connection with an AC has failed for unknown reasons. + + Last Failure Type: The failure type of the most recent WTP failure. + The following values are supported: + + 0 - Not Supported + + 1 - AC Initiated (see Section 9.2) + + 2 - Link Failure + + 3 - Software Failure + + 4 - Hardware Failure + + 5 - Other Failure + + 255 - Unknown (e.g., WTP doesn't keep track of info) + +4.6.49. WTP Static IP Address Information + + The WTP Static IP Address Information message element is used by an + AC to configure or clear a previously configured static IP address on + a WTP. + + + + + + + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 85] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IP Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Netmask | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Gateway | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Static | + +-+-+-+-+-+-+-+-+ + + Type: 49 for WTP Static IP Address Information + + Length: 13 + + IP Address: The IP Address to assign to the WTP. This field is + only valid if the static field is set to one. + + Netmask: The IP Netmask. This field is only valid if the static + field is set to one. + + Gateway: The IP address of the gateway. This field is only valid + if the static field is set to one. + + Netmask: The IP Netmask. This field is only valid if the static + field is set to one. + + Static: An 8-bit boolean stating whether the WTP should use a + static IP address or not. A value of zero disables the static IP + address, while a value of one enables it. + +4.7. CAPWAP Protocol Timers + + This section contains the CAPWAP timers. + +4.7.1. ChangeStatePendingTimer + + The maximum time, in seconds, the AC will wait for the Change State + Event Request from the WTP after having transmitted a successful + Configuration Status Response message. The default value is 25 + seconds. + +4.7.2. DataChannelDeadInterval + + The minimum time, in seconds, a WTP MUST wait without having received + a Data Channel Keep Alive packet before the destination for the Data + Channel Keep Alive packets may be considered dead. The value of this + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 86] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + timer MUST be no less than 2*DataChannelKeepAlive seconds and no + greater that 240 seconds. + + Default: 5 + +4.7.3. DiscoveryInterval + + The minimum time, in seconds, that a WTP MUST wait after receiving a + Discovery Response message, before initiating a DTLS handshake. + + Default: 5 + +4.7.4. DTLSSessionDelete + + The minimum time, in seconds, a WTP MUST wait for DTLS session + deletion. + + Default: 5 + +4.7.5. EchoInterval + + The minimum time, in seconds, between sending Echo Request messages + to the AC with which the WTP has joined. + + Default: 30 + +4.7.6. MaxDiscoveryInterval + + The maximum time allowed between sending Discovery Request messages, + in seconds. This value MUST be no less than 2 seconds and no greater + than 180 seconds. + + Default: 20 seconds. + +4.7.7. MaxFailedDTLSSessionRetry + + The maximum number of failed DTLS session establishment attempts + before the CAPWAP device enters a silent period. + + Default: 3. + +4.7.8. NeighborDeadInterval + + The minimum time, in seconds, a WTP MUST wait without having received + an Echo Response message to its Echo Request message, before the + destination for the Echo Request may be considered dead. This value + MUST be no less than 2*EchoInterval seconds and no greater than 240 + seconds. + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 87] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + Default: 60 + +4.7.9. ResponseTimeout + + The minimum time, in seconds, in which the WTP or AC MUST respond to + a CAPWAP Request message. + + Default: 1 + +4.7.10. RetransmitInterval + + The minimum time, in seconds, in which a non-acknowledged CAPWAP + packet will be retransmitted. + + Default: 3 + +4.7.11. SilentInterval + + For a WTP, this is the minimum time, in seconds, a WTP MUST wait + before it MAY again send Discovery Request messages or attempt to a + establish DTLS session. For an AC, this is the minimum time, in + seconds, during which the AC SHOULD ignore all CAPWAP and DTLS + packets received from the WTP that is in the Sulking state. + + Default: 30 + +4.7.12. StatisticsTimer + + The default Statistics Interval is 120 seconds. + +4.7.13. WaitDTLS + + The maximum time, in seconds, a WTP MUST wait without having received + a DTLS Handshake message from an AC. This timer MUST be greater than + 30 seconds. + + Default: 60 + +4.7.14. WaitJoin + + The maximum time, in seconds, after which the DTLS session has been + established that the AC will wait before receiving a Join Request + message. This timer MUST be greater than 30 seconds. + + Default: 60 + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 88] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + +4.8. CAPWAP Protocol Variables + + A WTP or AC that implements the CAPWAP Discovery phase MUST allow for + the following variables to be configured by system management; + default values are specified, making explicit configuration + unnecessary in many cases. If the default values are explicitly + overriden by the AC, the WTP MUST save the values sent by the AC. + +4.8.1. AdminState + + The default Administrative State value is enabled (1). + +4.8.2. DiscoveryCount + + The number of Discovery Request messages transmitted by a WTP to a + single AC. This is a monotonically increasing counter. + +4.8.3. FailedDTLSAuthFailCount + + The number of failed DTLS session establishment attempts due to + authentication failures. + +4.8.4. FailedDTLSSessionCount + + The number of failed DTLS session establishment attempts. + +4.8.5. IdleTimeout + + The default Idle Timeout is 300 seconds. + +4.8.6. MaxDiscoveries + + The maximum number of Discovery Request messages that will be sent + after a WTP boots. + + Default: 10 + +4.8.7. MaxRetransmit + + The maximum number of retransmissions for a given CAPWAP packet + before the link layer considers the peer dead. + + Default: 5 + +4.8.8. ReportInterval + + The default Report Interval is 120 seconds. + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 89] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + +4.8.9. RetransmitCount + + The number of retransmissions for a given CAPWAP packet. This is a + monotonically increasing counter. + +4.8.10. WTPFallBack + + The default WTP Fallback value is enabled (1). + +4.9. WTP Saved Variables + + In addition to the values defined in Section 4.8, the following + values SHOULD be saved on the WTP in non-volatile memory. CAPWAP + wireless bindings MAY define additional values that SHOULD be stored + on the WTP. + +4.9.1. AdminRebootCount + + The number of times the WTP has rebooted administratively, defined in + Section 4.6.48. + +4.9.2. FrameEncapType + + For WTPs that support multiple Frame Encapsulation Types, it is + useful to save the value configured by the AC. The Frame + Encapsulation Type is defined in Section 4.6.41. + +4.9.3. LastRebootReason + + The reason why the WTP last rebooted, defined in Section 4.6.48. + +4.9.4. MacType + + For WTPs that support multiple MAC Types, it is useful to save the + value configured by the AC. The MACType is defined in + Section 4.6.44. + +4.9.5. PreferredACs + + The preferred ACs, with the index, defined in Section 4.6.5. + +4.9.6. RebootCount + + The number of times the WTP has rebooted, defined in Section 4.6.48. + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 90] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + +4.9.7. Static ACL Table + + The static ACL table saved on the WTP, as configured by the Add + Static MAC ACL Entry message element, see Section 4.6.9. + +4.9.8. Static IP Address + + The static IP Address assigned to the WTP, as configured by the WTP + Static IP Address Information message element (see Section 4.6.49). + +4.9.9. WTPLinkFailureCount + + The number of times the link to the AC has failed, see + Section 4.6.48. + +4.9.10. WTPLocation + + The WTP Location, defined in Section 4.6.28. + +4.9.11. WTPName + + The WTP Name, defined in Section 4.6.45. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 91] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + +5. CAPWAP Discovery Operations + + The Discovery messages are used by a WTP to determine which ACs are + available to provide service, and the capabilities and load of the + ACs. + +5.1. Discovery Request Message + + The Discovery Request message is used by the WTP to automatically + discover potential ACs available in the network. The Discovery + Request message provides ACs with the primary capabilities of the + WTP. A WTP must exchange this information to ensure subsequent + exchanges with the ACs are consistent with the WTP's functional + characteristics. + + Discovery Request messages MUST be sent by a WTP in the Discover + state after waiting for a random delay less than + MaxDiscoveryInterval, after a WTP first comes up or is + (re)initialized. A WTP MUST send no more than the maximum of + MaxDiscoveries Discovery Request messages, waiting for a random delay + less than MaxDiscoveryInterval between each successive message. + + This is to prevent an explosion of WTP Discovery Request messages. + An example of this occurring is when many WTPs are powered on at the + same time. + + Discovery Request messages MUST be sent by a WTP when no Echo + Response messages are received for NeighborDeadInterval and the WTP + returns to the Idle state. Discovery Request messages are sent after + NeighborDeadInterval. They MUST be sent after waiting for a random + delay less than MaxDiscoveryInterval. A WTP MAY send up to a maximum + of MaxDiscoveries Discovery Request messages, waiting for a random + delay less than MaxDiscoveryInterval between each successive message. + + If a Discovery Response message is not received after sending the + maximum number of Discovery Request messages, the WTP enters the + Sulking state and MUST wait for an interval equal to SilentInterval + before sending further Discovery Request messages. + + Upon receiving a Discovery Request message, the AC will respond with + a Discovery Response message sent to the address in the source + address of the received Discovery Request message. + + It is possible for the AC to receive a cleartext Discovery Request + message while a DTLS session is already active with the WTP. This is + most likely the case if the WTP has rebooted, perhaps due to a + software or power failure, but could also be caused by a DoS attack. + In such cases, any WTP state, including the state machine instance, + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 92] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + MUST NOT be cleared until another DTLS session has been successfully + established, communicated via the DTLSSessionEstablished DTLS + notification (see Section 2.3.2.2). + + The binding specific WTP Radio Information message element (see + Section 2.1) is included in the Discovery Request message to + advertise WTP support for one or more CAPWAP bindings. + + The Discovery Request message is sent by the WTP when in the + Discovery State. The AC does not transmit this message. + + The following message elements MUST be included in the Discovery + Request message: + + o Discovery Type, see Section 4.6.20 + + o WTP Board Data, see Section 4.6.38 + + o WTP Descriptor, see Section 4.6.39 + + o WTP Frame Tunnel Mode, see Section 4.6.41 + + o WTP MAC Type, see Section 4.6.44 + + o WTP Radio Information message element(s)that the WTP supports; + These are defined by the individual link layer CAPWAP Binding + Protocols (see Section 2.1). + +5.2. Discovery Response Message + + The Discovery Response message provides a mechanism for an AC to + advertise its services to requesting WTPs. + + When a WTP receives a Discovery Response message, it MUST wait for an + interval not less than DiscoveryInterval for receipt of additional + Discovery Response messages. After the DiscoveryInterval elapses, + the WTP enters the DTLS-Init state and selects one of the ACs that + sent a Discovery Response message and send a DTLS Handshake to that + AC. + + One or more binding specific WTP Radio Information message elements + (see Section 2.1) are included in the Discovery Request message to + advertise AC support for the CAPWAP bindings. The AC MAY include + only the bindings it shares in common with the WTP, known through the + WTP Radio Information message elements received in the Discovery + Request message, or it MAY include all of the bindings supported. + The WTP MAY use the supported bindings in its AC decision process. + Note that if the WTP joins an AC that does not support a specific + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 93] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + CAPWAP binding, service for that binding MUST NOT be provided by the + WTP. + + The Discovery Response message is sent by the AC when in the Idle + State. The WTP does not transmit this message. + + The following message elements MUST be included in the Discovery + Response Message: + + o AC Descriptor, see Section 4.6.1 + + o AC Name, see Section 4.6.4 + + o WTP Radio Information message element(s)that the AC supports; + These are defined by the individual link layer CAPWAP Binding + Protocols (see Section 2.1 for more information). + + o One of the following message elements MUST be included in the + Discovery Response Message: + + * CAPWAP Control IPv4 Address, see Section 4.6.10 + + * CAPWAP Control IPv6 Address, see Section 4.6.11 + +5.3. Primary Discovery Request Message + + The Primary Discovery Request message is sent by the WTP to determine + whether its preferred (or primary) AC is available. + + A Primary Discovery Request message is sent by a WTP when it has a + primary AC configured, and is connected to another AC. This + generally occurs as a result of a failover, and is used by the WTP as + a means to discover when its primary AC becomes available. Since the + WTP only has a single instance of the CAPWAP state machine, the + Primary Discovery Request is sent by the WTP when in the Run State. + The AC does not transmit this message. + + The frequency of the Primary Discovery Request messages should be no + more often than the sending of the Echo Request message. + + Upon receipt of a Primary Discovery Request message, the AC responds + with a Primary Discovery Response message sent to the address in the + source address of the received Primary Discovery Request message. + + The following message elements MUST be included in the Primary + Discovery Request message. + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 94] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + o Discovery Type, see Section 4.6.20 + + o WTP Board Data, see Section 4.6.38 + + o WTP Descriptor, see Section 4.6.39 + + o WTP Frame Tunnel Mode, see Section 4.6.41 + + o WTP MAC Type, see Section 4.6.44 + + o WTP Radio Information message element(s)that the WTP supports; + These are defined by the individual link layer CAPWAP Binding + Protocols (see Section 2.1 for more information). + +5.4. Primary Discovery Response + + The Primary Discovery Response message enables an AC to advertise its + availability and services to requesting WTPs that are configured to + have the AC as its primary AC. + + The Primary Discovery Response message is sent by an AC after + receiving a Primary Discovery Request message. + + When a WTP receives a Primary Discovery Response message, it may + establish a CAPWAP protocol connection to its primary AC, based on + the configuration of the WTP Fallback Status message element on the + WTP. + + The Primary Discovery Response message is sent by the AC when in the + Idle State. The WTP does not transmit this message. + + The following message elements MUST be included in the Primary + Discovery Response message. + + o AC Descriptor, see Section 4.6.1 + + o AC Name, see Section 4.6.4 + + o WTP Radio Information message element(s)that the AC supports; + These are defined by the individual link layer CAPWAP Binding + Protocols (see Section 2.1 for more information). + + One of the following message elements MUST be included in the + Discovery Response Message: + + o CAPWAP Control IPv4 Address, see Section 4.6.10 + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 95] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + o CAPWAP Control IPv6 Address, see Section 4.6.11 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 96] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + +6. CAPWAP Join Operations + + The Join Request message is used by a WTP to request service from an + AC after a DTLS connection is established to that AC. The Join + Response message is used by the the AC to indicate that it will or + will not provide service. + +6.1. Join Request + + The Join Request message is used by a WTP to request service through + the AC. A Join Request message is sent by a WTP after (optionally) + receiving one or more Discovery Response messages, and completion of + DTLS session establishment. When an AC receives a Join Request + message it responds with a Join Response message. + + Upon completion of the DTLS handshake, and receiving the + DTLSEstablished notification, the WTP sends the Join Request message + to the AC. When the AC is notified of the DTLS session + establishment, it does not clear the WaitDTLS timer until it has + received the Join Request message, at which time it sends a Join + Response message to the WTP, indicating success or failure. + + One or more WTP Radio Information message elements (see Section 2.1) + are included in the Join Request to request service for the CAPWAP + bindings by the AC. Including a binding that is unsupported by the + AC will result in a failed Join Response. + + If the AC rejects the Join Request, it sends a Join Response message + with a failure indication and initiates an abort of the DTLS session + via the DTLSAbort command. + + If an invalid (i.e. malformed) Join Request message is received, the + message MUST be silently discarded by the AC. No response is sent to + the WTP. The AC SHOULD log this event. + + The Join Request is sent by the WTP when in the Join State. The AC + does not transmit this message. + + The following message elements MUST be included in the Join Request + message. + + o Location Data, see Section 4.6.28 + + o WTP Board Data, see Section 4.6.38 + + o WTP Descriptor, see Section 4.6.39 + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 97] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + o WTP Name, see Section 4.6.45 + + o Session ID, see Section 4.6.35 + + o WTP Frame Tunnel Mode, see Section 4.6.41 + + o WTP MAC Type, see Section 4.6.44 + + o WTP Radio Information message element(s)that the WTP supports; + These are defined by the individual link layer CAPWAP Binding + Protocols (see Section 2.1 for more information). + + At least one of the following message element MUST be included in the + Join Request message. + + o WTP IPv4 IP Address, see Section 4.6.42 + + o WTP IPv6 IP Address, see Section 4.6.43 + + The following message element MAY be included in the Join Request + message. + + o Maximum Message Length, see Section 4.6.29 + + o WTP Reboot Statistics, see Section 4.6.48 + + o WTP IPv4 IP Address, see Section 4.6.42 + + o WTP IPv6 IP Address, see Section 4.6.43 + +6.2. Join Response + + The Join Response message is sent by the AC to indicate to a WTP that + it is capable and willing to provide service to the WTP. + + The WTP, receiving a Join Response message, checks for success or + failure. If the message indicates success, the WTP clears the + WaitDTLS timer for the session and proceeds to the Configure state. + + If the WaitDTLS Timer expires prior to reception of the Join Response + message, the WTP MUST terminate the handshake, deallocate session + state and initiate the DTLSAbort command. + + If an invalid (malformed) Join Response message is received, the WTP + SHOULD log an informative message detailing the error. This error + MUST be treated in the same manner as AC non-responsiveness. The + WaitDTLS timer will eventually expire, and the WTP MAY (if it is so + configured) attempts to join a new AC. + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 98] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + If one of the WTP Radio Information message elements (see + Section 2.1) in the Join Request message requested support for a + CAPWAP binding which the AC does not support, the AC sets the Result + Code message element to "Binding Not Supported". + + The AC includes the Image Identifier message element to indicate the + software version it expects the WTP to run. This information is used + to determine whether the WTP MUST either change its currently running + firmware image, or download a new version (see Section 9.1.1). + + The Join Response message is sent by the AC when in the Join State. + The WTP does not transmit this message. + + The following message elements MAY be included in the Join Response + message. + + o AC IPv4 List, see Section 4.6.2 + + o AC IPv6 List, see Section 4.6.3 + + o Image Identifier, see Section 4.6.25 + + o Maximum Message Length, see Section 4.6.29 + + The following message elements MUST be included in the Join Response + message. + + o Result Code, see Section 4.6.33 + + o AC Descriptor, see Section 4.6.1 + + o AC Name, see Section 4.6.4 + + o WTP Radio Information message element(s)that the AC supports; + These are defined by the individual link layer CAPWAP Binding + Protocols (see Section 2.1). + + One of the following message elements MUST be included in the + Discovery Response Message: + + o CAPWAP Control IPv4 Address, see Section 4.6.10 + + o CAPWAP Control IPv6 Address, see Section 4.6.11 + + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 99] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + +7. Control Channel Management + + The Control Channel Management messages are used by the WTP and AC to + maintain a control communication channel. CAPWAP control messages, + such as the WTP Event Request message sent from the WTP to the AC + indicate to the AC that the WTP is operational. When such control + messages are not being sent, the Echo Request and Echo Response + messages are used to maintain the control communication channel. + +7.1. Echo Request + + The Echo Request message is a keep-alive mechanism for CAPWAP control + messages. + + Echo Request messages are sent periodically by a WTP in the Run state + (see Section 2.3) to determine the state of the control connection + between the WTP and the AC. The Echo Request message is sent by the + WTP when the EchoInterval timer expires. The WTP MUST start its + NeighborDeadInterval timer when the EchoInterval timer expires. + + The Echo Request message is sent by the WTP when in the Run State. + The AC does not transmit this message. + + The Echo Request message carries no message elements. + + When an AC receives an Echo Request message it responds with an Echo + Response message. + +7.2. Echo Response + + The Echo Response message acknowledges the Echo Request message. + + An Echo Response message is sent by an AC after receiving an + EchoRequest message. After transmitting the Echo Response message, + the AC SHOULD reset its EchoInterval timer. If another Echo Request + message or other control message is not received by the AC when the + timer expires, the AC SHOULD consider the WTP to be no longer + reachable. + + The Echo Response message is sent by the AC when in the Run State. + The WTP does not transmit this message. + + The Echo Response message carries no message elements. + + When a WTP receives an Echo Response message it stops the + NeighborDeadInterval timer, and initializes the EchoInterval to the + configured value. + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 100] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + If the NeighborDeadInterval timer expires prior to receiving an Echo + Response message, or other control message, the WTP enters the Idle + state. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 101] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + +8. WTP Configuration Management + + WTP Configuration messages are used to exchange configuration + information between the AC and the WTP. + +8.1. Configuration Consistency + + The CAPWAP protocol provides flexibility in how WTP configuration is + managed. A WTP has two options: + + 1. The WTP retains no configuration and accepts the configuration + provided by the AC. + + 2. The WTP retains the configuration of parameters provided by the AC + that are non-default values. + + If the WTP opts to save configuration locally, the CAPWAP protocol + state machine defines the Configure state, which allows for + configuration exchange. In the Configure state, the WTP sends its + current configuration overrides to the AC via the Configuration + Status message. A configuration override is a non-default parameter. + As an example, in the CAPWAP protocol, the default antenna + configuration is internal omni antenna. A WTP that either has no + internal antennas, or has been explicitly configured by the AC to use + external antennas, sends its antenna configuration during the + configure phase, allowing the AC to become aware of the WTP's current + configuration. + + Once the WTP has provided its configuration to the AC, the AC sends + its configuration to the WTP. This allows the WTP to receive + configuration and policies from the AC. + + The AC maintains a copy of each active WTP configuration. There is + no need for versioning or other means to identify configuration + changes. If a WTP becomes inactive, the AC MAY delete the inactive + WTP configuration. If a WTP fails, and connects to a new AC, the WTP + provides its overridden configuration parameters, allowing the new AC + to be aware of the WTP configuration. + + This model allows for resiliency in case of an AC failure, ensuring + another AC can provide service to the WTP. A new AC would be + automatically updated with WTP configuration changes, eliminating the + need for inter-AC communication and the need for all ACs to be aware + of the configuration of all WTPs in the network. + + Once the CAPWAP protocol enters the Run state, the WTPs begin to + provide service. It is common for administrators to require that + configuration changes be made while the network is operational. + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 102] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + Therefore, the Configuration Update Request is sent by the AC to the + WTP to make these changes at run-time. + +8.1.1. Configuration Flexibility + + The CAPWAP protocol provides the flexibility to configure and manage + WTPs of varying design and functional characteristics. When a WTP + first discovers an AC, it provides primary functional information + relating to its type of MAC and to the nature of frames to be + exchanged. The AC configures the WTP appropriately. The AC also + establishes corresponding internal state for the WTP. + +8.2. Configuration Status + + The Configuration Status message is sent by a WTP to deliver its + current configuration to the AC. + + The Configuration Status message carries binding specific message + elements. Refer to the appropriate binding for the definition of + this structure. + + When an AC receives a Configuration Status message it acts upon the + content of the message and responds to the WTP with a Configuration + Status Response message. + + The Configuration Status message includes multiple Radio + Administrative State message elements, one for the WTP, and one for + each radio in the WTP. + + The Configuration Status message is sent by the WTP when in the + Configure State. The AC does not transmit this message. + + The following message elements MUST be included in the Configuration + Status message. + + o AC Name, see Section 4.6.4 + + o AC Name with Index, see Section 4.6.5 + + o Radio Administrative State, see Section 4.6.31 + + o Statistics Timer, see Section 4.6.36 + + o WTP Reboot Statistics, see Section 4.6.48 + + The following message elements MAY be included in the Configuration + Status message. + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 103] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + o WTP Static IP Address Information, see Section 4.6.49 + +8.3. Configuration Status Response + + The Configuration Status Response message is sent by an AC and + provides a mechanism for the AC to override a WTP's requested + configuration. + + A Configuration Status Response message is sent by an AC after + receiving a Configuration Request message. + + The Configuration Status Response message carries binding specific + message elements. Refer to the appropriate binding for the + definition of this structure. + + When a WTP receives a Configuration Status Response message it acts + upon the content of the message, as appropriate. If the + Configuration Status Response message includes a Radio Operational + State message element that causes a change in the operational state + of one of the radios, the WTP transmits a Change State Event to the + AC, as an acknowledgement of the change in state. + + The Configuration Status Response message is sent by the AC when in + the Configure State. The WTP does not transmit this message. + + The following message elements MUST be included in the Configuration + Status Response message. + + o AC IPv4 List, see Section 4.6.2 + + o AC IPv6 List, see Section 4.6.3 + + o CAPWAP Timers, see Section 4.6.12 + + o Decryption Error Report Period, see Section 4.6.16 + + o Idle Timeout, see Section 4.6.23 + + o WTP Fallback, see Section 4.6.40 + + The following message element MAY be included in the Configuration + Status Response message. + + o WTP Static IP Address Information, see Section 4.6.49 + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 104] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + +8.4. Configuration Update Request + + Configuration Update Request messages are sent by the AC to provision + the WTP while in the Run state. This is used to modify the + configuration of the WTP while it is operational. + + When a WTP receives a Configuration Update Request message, it + responds with a Configuration Update Response message, with a Result + Code message element indicating the result of the configuration + request. + + The AC includes the Image Identifier and Initiate Download message + elements to force the WTP to update its firmware while in the Run + state. The WTP MAY proceed to download the requested firmware if it + determines the version specified in the Image Identifier message + element is not in its non-volatile storage (see Section 9.1.1). + + The Configuration Update Request is sent by the AC when in the Run + State. The WTP does not transmit this message. + + One or more of the following message elements MAY be included in the + Configuration Update message. + + o AC Name with Index, see Section 4.6.5 + + o AC Timestamp, see Section 4.6.6 + + o Add MAC ACL Entry, see Section 4.6.7 + + o Add Static MAC ACL Entry, see Section 4.6.9 + + o CAPWAP Timers, see Section 4.6.12 + + o Decryption Error Report Period, see Section 4.6.16 + + o Delete MAC ACL Entry, see Section 4.6.17 + + o Delete Static MAC ACL Entry, see Section 4.6.19 + + o Idle Timeout, see Section 4.6.23 + + o Location Data, see Section 4.6.28 + + o Radio Administrative State, see Section 4.6.31 + + o Statistics Timer, see Section 4.6.36 + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 105] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + o WTP Fallback, see Section 4.6.40 + + o WTP Name, see Section 4.6.45 + + o WTP Static IP Address Information, see Section 4.6.49 + + o Image Identifier, see Section 4.6.25 + + o Initiate Download, see Section 4.6.27 + +8.5. Configuration Update Response + + The Configuration Update Response message is the acknowledgement + message for the Configuration Update Request message. + + The Configuration Update Response message is sent by a WTP after + receiving a Configuration Update Request message. + + When an AC receives a Configuration Update Response message the + result code indicates if the WTP successfully accepted the + configuration. + + The Configuration Update Response message is sent by the WTP when in + the Run State. The AC does not transmit this message. + + The following message element MUST be present in the Configuration + Update message. + + Result Code, see Section 4.6.33 + + The following message elements MAY be present in the Configuration + Update Response message. + + o Radio Operational State, see Section 4.6.32 + +8.6. Change State Event Request + + The Change State Event Request message is used by the WTP for two + main purposes: + + o When sent by the WTP following the reception of a Configuration + Status Response message from the AC, the WTP uses the Change State + Event Request message to provide an update on the WTP radio's + operational state and to confirm that the configuration provided + by the AC was successfully applied. + + o When sent during the Run state, the WTP uses the Change State + Event Request message to notify the AC of an unexpected change in + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 106] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + the WTP's radio operational state. + + When an AC receives a Change State Event Request message it responds + with a Change State Event Response message and modifies its data + structures for the WTP as needed. The AC MAY decide not to provide + service to the WTP if it receives an error, based on local policy, + and to transition to the Reset state. + + The Change State Event Request message is sent by a WTP to + acknowledge or report an error condition to the AC for a requested + configuration in the Configuration Status Response message. The + Change State Event Request message includes the Result Code message + element, which indicates whether the configuration was successfully + applied. If the WTP is unable to apply a specfic configuration + request, it indicates the failure by including one or more Returned + Message Element message elements (see Section 4.6.34). + + The Change State Event Request message is sent by the WTP in the + Configure or Run State. The AC does not transmit this message. + + The WTP MAY save its configuration to persistent storage prior to + transmitting the response. However, this is implementation specific + and is not required. + + The following message elements MUST be present in the Change State + Event Request message. + + o Radio Operational State, see Section 4.6.32 + + o Result Code, see Section 4.6.33 + + One or more of the following message elements MAY be present in the + Change State Event Request message. + + o Returned Message Element(s), see Section 4.6.34 + +8.7. Change State Event Response + + The Change State Event Response message acknowledges the Change State + Event Request message. + + A Change State Event Response message is sent by an AC in response to + a Change State Event Request message. + + The Change State Event Response message is sent by the AC when in the + Configure or Run state. The WTP does not transmit this message. + + The Change State Event Response message carries no message elements. + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 107] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + The WTP does not take any action upon receipt of the Change State + Event Response message. + +8.8. Clear Configuration Request + + The Clear Configuration Request message is used to reset the WTP + configuration. + + The Clear Configuration Request message is sent by an AC to request + that a WTP reset its configuration to the manufacturing default + configuration. The Clear Config Request message is sent while in the + Run state. + + The Clear Configuration Request is sent by the AC when in the Run + State. The WTP does not transmit this message. + + The Clear Configuration Request message carries no message elements. + + When a WTP receives a Clear Configuration Request message it resets + its configuration to the manufacturing default configuration. + +8.9. Clear Configuration Response + + The Clear Configuration Response message is sent by the WTP after + receiving a Clear Configuration Request message and resetting its + configuration parameters to the manufacturing default values. + + The Clear Configuration Response is sent by the WTP when in the Run + State. The AC does not transmit this message. + + The Clear Configuration Request message MUST include the following + message element. + + o Result Code, see Section 4.6.33 + + + + + + + + + + + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 108] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + +9. Device Management Operations + + This section defines CAPWAP operations responsible for debugging, + gathering statistics, logging, and firmware management. + +9.1. Firmware Management + + This section describes the firmware download procedures used by the + CAPWAP protocol. Firmware download can occur during the Image Data + or Run state. + + Figure 4 provides an example of a WTP that performs a firmware + upgrade while in the Image Data state. In this example, the WTP does + not already have the requested firmware (Image Identifier = x), and + downloads the image from the AC. + + WTP AC + + Join Request + --------------------------------------------------------> + + Join Response (Image Identifier = x) + <------------------------------------------------------ + + Image Data Request (Image Identifier = x) + --------------------------------------------------------> + + Image Data Response (Result Code = Success, + Image Information = {size,hash}, + Initiate Download) + <------------------------------------------------------ + + Image Data Request (Image Data = Data) + <------------------------------------------------------ + + Image Data Response (Result Code = Success) + --------------------------------------------------------> + + ..... + + Image Data Request (Image Data = EOF) + <------------------------------------------------------ + + Image Data Response (Result Code = Success) + --------------------------------------------------------> + + (WTP enters the Reset State) + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 109] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + Figure 4: WTP Firmware Download Case 1 + + Figure 5 provides an example in which the WTP has the image specified + by the AC in its non-volative storage. The WTP opts to NOT download + the firmware and immediately reset. + + WTP AC + + Join Request + --------------------------------------------------------> + + Join Response (Image Identifier = x) + <------------------------------------------------------ + + (WTP enters the Reset State) + + Figure 5: WTP Firmware Download Case 2 + + Figure 6 provides an example of a WTP that performs a firmware + upgrade while in the Run state. This mode of firmware upgrade allows + the WTP to download its image while continuing to provide service. + The WTP will not automatically reset until it is notified by the AC, + with a Reset Request message. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 110] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + WTP AC + + Configuration Update Request (Image Identifier = x) + <------------------------------------------------------ + + Configuration Update Response (Result Code = Success) + --------------------------------------------------------> + + + Image Data Request (Image Identifier = x) + --------------------------------------------------------> + + Image Data Response (Result Code = Success, + Image Information = {size,hash}, + Initiate Download) + <------------------------------------------------------ + + Image Data Request (Image Data = Data) + <------------------------------------------------------ + + Image Data Response (Result Code = Success) + --------------------------------------------------------> + + ..... + + Image Data Request (Image Data = EOF) + <------------------------------------------------------ + + Image Data Response (Result Code = Success) + --------------------------------------------------------> + + ..... + + (administratively requested reboot request) + Reset Request (Image Identifier = x) + <------------------------------------------------------ + + Reset Response (Result Code = Success) + --------------------------------------------------------> + + Figure 6: WTP Firmware Download Case 3 + + Figure 7 provides another example of the firmware download while in + the Run state. In this example, the WTP already has the image + specified by the AC in its non-volative storage. The WTP opts to NOT + download the firmware. The WTP resets upon receipt of a Reset + Request message from the AC. + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 111] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + WTP AC + + Configuration Update Request (Image Identifier = x, + Image Information = {size,hash}, + Initiate Download) + <------------------------------------------------------ + + Configuration Update Response (Result Code = Already Have Image) + --------------------------------------------------------> + + ..... + + (administratively requested reboot request) + Reset Request (Image Identifier = x) + <------------------------------------------------------ + + Reset Response (Result Code = Success) + --------------------------------------------------------> + + Figure 7: WTP Firmware Download Case 4 + +9.1.1. Image Data Request + + The Image Data Request message is used to update firmware on the WTP. + This message and its companion Response message are used by the AC to + ensure that the image being run on each WTP is appropriate. + + Image Data Request messages are exchanged between the WTP and the AC + to download a new firmware image to the WTP. When a WTP or AC + receives an Image Data Request message it responds with an Image Data + Response message. The message elements contained within the Image + Data Request message are required to determine the intent of the + request. + + The decision that new firmware is to be downloaded to the WTP can + occur in one of two ways: + + When the WTP joins the AC, the Join Response message includes the + Image Identifier message element, which informs the WTP of the + firmware it is expected to run. if the WTP does not currently have + the requested firmware version, it transmits an Image Data Request + message, with the appropriate Image Identifier message element. + If the WTP already has the requested firmware, it simply resets. + + Once the WTP is in the Run state, it is possible for the AC to + cause the WTP to initiate a firmware download by sending a + Configuration Update Request message with the Initiate Download + and and Image Identifier message elements. The WTP then transmits + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 112] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + the Image Data Request message, which includes the Image + Identifier message element to start the download process. Note + that when the firmware is downloaded in this way, the WTP does not + automatically reset after the download is complete. The WTP will + only reset when it receives a Reset Request message from the AC. + If the WTP already had the requested firmware version in its non- + volatile storage, the WTP does not transmit the Image Data Request + message and responds with a Configuration Update Response message + with the Result Code set to Image Already Present. + + Regardless of how the download was initiated, once the AC receives an + Image Data Request message with the Image Identifier message element, + it begins the transfer process by transmitting an Image Data Request + message that includes the Image Data message element. This continues + until the firmware image has been transfered. + + The Image Data Request message is sent by the WTP or the AC when in + the Image Data or Run State. + + The following message elements MAY be included in the Image Data + Request message. + + o Image Data, see Section 4.6.24 + + o Image Identifier, see Section 4.6.25 + +9.1.2. Image Data Response + + The Image Data Response message acknowledges the Image Data Request + message. + + An Image Data Response message is sent in response to a received + Image Data Request message. Its purpose is to acknowledge the + receipt of the Image Data Request message. The Result Code is + included to indicate whether a previously sent Image Data Request + message was invalid. + + The Image Data Response message is sent by the WTP or the AC when in + the Image Data or Run State. + + The following message element MUST be included in the Image Data + Response message. + + o Result Code, see Section 4.6.33 + + The following message elements MAY be included in the Image Data + Response message. + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 113] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + o Image Information, see Section 4.6.26 + + o Initiate Download, see Section 4.6.27 + + Upon receiving an Image Data Response message indicating an error, + the WTP MAY retransmit a previous Image Data Reqest message, or + abandon the firmware download to the WTP by transitioning to the + Reset state. + +9.2. Reset Request + + The Reset Request message is used to cause a WTP to reboot. + + A Reset Request message is sent by an AC to cause a WTP to + reinitialize its operation. + + The Reset Request is sent by the AC when in the Run State. The WTP + does not transmit this message. + + The following message elements MUST be included in the Reset Request + message. + + o Image Identifier, see Section 4.6.25 + + When a WTP receives a Reset Request message, it responds with a Reset + Response message indicating success and then reinitialize itself. If + the WTP is unable to write to its non-volatile storage, to ensure + that it runs the requested software version indicated in the Image + Identifier message element, it MAY send the appropriate Result Code + message element, but MUST reboot. If the WTP is unable to reset, + including a hardware reset, it sends a Reset Response message to the + AC with a Result Code message element indicating failure. The AC no + longer provides service to the WTP. + +9.3. Reset Response + + The Reset Response message acknowledges the Reset Request message. + + A Reset Response message is sent by the WTP after receiving a Reset + Request message. + + The Reset Response is sent by the WTP when in the Run State. The AC + does not transmit this message. + + The following message element MAY be included in the Image Data + Request message. + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 114] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + o Result Code, see Section 4.6.33 + + When an AC receives a successful Reset Response message, it is + notified that the WTP will reinitialize its operation. An AC that + receives a Reset Response message indicating failure may opt to no + longer provide service to the WTP. + +9.4. WTP Event Request + + The WTP Event Request message is used by a WTP to send information to + its AC. The WTP Event Request message MAY be sent periodically, or + sent in response to an asynchronous event on the WTP. For example, a + WTP MAY collect statistics and use the WTP Event Request message to + transmit the statistics to the AC. + + When an AC receives a WTP Event Request message it will respond with + a WTP Event Response message. + + The presence of the Delete Station message element is used by the WTP + to inform the AC that it is no longer providing service to the + station. This could be the result of an Idle Timeout (see + Section 4.6.23), due to to resource shortages, or some other reason. + + The WTP Event Request message is sent by the WTP when in the Run + State. The AC does not transmit this message. + + The WTP Event Request message MUST contain one of the message + elements listed below, or a message element that is defined for a + specific wireless technology. More than one of each messsage element + listed MAY be included in the WTP Event Request message. + + o Decryption Error Report, see Section 4.6.15 + + o Duplicate IPv4 Address, see Section 4.6.21 + + o Duplicate IPv6 Address, see Section 4.6.22 + + o WTP Operational Statistics, see Section 4.6.46 + + o WTP Radio Statistics, see Section 4.6.47 + + o WTP Reboot Statistics, see Section 4.6.48 + + o Delete Station, see Section 4.6.18 + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 115] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + +9.5. WTP Event Response + + The WTP Event Response message acknowledges receipt of the WTP Event + Request message. + + A WTP Event Response message is sent by an AC after receiving a WTP + Event Request message. + + The WTP Event Response message is sent by the AC when in the Run + State. The WTP does not transmit this message. + + The WTP Event Response message carries no message elements. + +9.6. Data Transfer Request + + The Data Transfer Request message is used to deliver debug + information from the WTP to the AC. + + Data Transfer Request messages are sent by the WTP to the AC when the + WTP determines that it has important information to send to the AC. + For instance, if the WTP detects that its previous reboot was caused + by a system crash, it can send the crash file to the AC. The remote + debugger function in the WTP also uses the Data Transfer Request + message to send console output to the AC for debugging purposes. + + When the AC receives a Data Transfer Request message it responds to + the WTP with a Data Transfer Response message. The AC MAY log the + information received. + + The Data Transfer Request message is sent by the WTP when in the Run + State. The AC does not transmit this message. + + The Data Transfer Request message MUST contain one of the message + elements listed below. + + o Data Transfer Data, see Section 4.6.13 + + o Data Transfer Mode, see Section 4.6.14 + +9.7. Data Transfer Response + + The Data Transfer Response message acknowledges the Data Transfer + Request message. + + A Data Transfer Response message is sent in response to a received + Data Transfer Request message. Its purpose is to acknowledge receipt + of the Data Transfer Request message. + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 116] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + The Data Transfer Response message is sent by the AC when in the Run + State. The WTP does not transmit this message. + + The Data Transfer Response message carries no message elements. + + Upon receipt of a Data Transfer Response message, the WTP transmits + more information, if more information is available. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 117] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + +10. Station Session Management + + Messages in this section are used by the AC to create, modify or + delete station session state on the WTPs. + +10.1. Station Configuration Request + + The Station Configuration Request message is used to create, modify + or delete station session state on a WTP. The message is sent by the + AC to the WTP, and MAY contain one or more message elements. The + message elements for this CAPWAP control message include information + that is generally highly technology specific. Refer to the + appropriate binding document for definitions of the messages elements + that are included in this control message. + + The Station Configuration Request message is sent by the AC when in + the Run State. The WTP does not transmit this message. + + The following CAPWAP Control message elements MAY be included in the + Station Configuration Request message. More than one of each message + element listed MAY be included in the Station Configuration Request + message. + + o Add Station, see Section 4.6.8 + + o Delete Station, see Section 4.6.18 + +10.2. Station Configuration Response + + The Station Configuration Response message is used to acknowledge a + previously received Station Configuration Request message. + + The Station Configuration Response message is sent by the WTP when in + the Run State. The AC does not transmit this message. + + The following message element MUST be present in the Station + Configuration Response message. + + o Result Code, see Section 4.6.33 + + The Result Code message element indicates that the requested + configuration was successfully applied, or that an error related to + processing of the Station Configuration Request message occurred on + the WTP. + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 118] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + +11. NAT Considerations + + There are three specific situations in which a NAT deployment may be + used in conjunction with a CAPWAP-enabled deployment. The first + consists of a configuration in which a single WTP is behind a NAT + system. Since all communication is initiated by the WTP, and all + communication is performed over IP using two UDP ports, the protocol + easily traverses NAT systems in this configuration. + + In the second case, two or more WTPs are deployed behind the same NAT + system. Here, the AC would receive multiple connection requests from + the same IP address, and cannot differentiate the originating WTP of + the connection requests. The CAPWAP Data Check state, which + establishes the data plane connection and communicates the Data + Keepalive, includes the Session Identifier message element, which is + used to bind the control and data plane. Use of the Session + Identifier message element enables the AC to match the control and + data plane flows from multiple WTPs behind the same NAT system + (multiple WTPs sharing the same IP address). + + In the third configuration, the AC is deployed behind a NAT. Two + issues exist in this situation. First, an AC communicates its + interfaces and corresponding WTP load using the CAPWAP Control + IP(v4/v6) Address message element. This message element is currently + mandatory, and if NAT compliance becomes an issue, it is possible to + either: + + 1. Make the CAPWAP Control IP (v4/v6) Address optional, allowing the + WTP to use the known IP Address. Note that this approach + eliminates the ability to perform load balancing of WTP across + ACs, and therefore is not the recommended approach. + + 2. Allow an AC to configure a NAT'ed address for every AC that would + otherwise be communicated in the CAPWAP Control IP (v4/v6) Address + message element. + + 3. Require that if a WTP determines that the AC List message element + contains a set of IP Addresses that are different from the AC IP + Address the WTP is currently using, then assume that NAT is + present, and require that the WTP communicate with the AC IP + Address (and ignore the CAPWAP Control IP (v4/v6) Address message + element(s)). + + The CAPWAP protocol allows for all of the AC identities supporting a + group of WTPs to be communicated through the AC List message element. + This feature MUST be disabled when the AC is behind a NAT and the IP + Address that is embedded is invalid. + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 119] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + The CAPWAP protocol allows an AC to configure a static IP address on + a WTP using the WTP Static IP Address Information message element. + This message element SHOULD NOT be used in NAT'ed environments, + unless the administrator is familiar with the internal IP addressing + scheme within the WTP's private network, and does not rely on the + public address seen by the AC. + + When a WTP detects the duplicate address condition, it generates a + message to the AC, which includes the Duplicate IP Address message + element. The IP Address embedded within this message element is + different from the public IP address seen by the AC. + + When CAPWAP is run over IPv6, NAT support can only be provided if the + IPv6 NAT system is capable of performing address translation over the + UDP-Lite 3828 protocol [11]. A protocol interoperability issues will + exist if the NAT system is being utilized for IPv4/IPv6 address + translation. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 120] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + +12. Security Considerations + + This section describes security considerations for the CAPWAP + protocol. It also provides security recommendations for protocols + used in conjunction with CAPWAP. + +12.1. CAPWAP Security + + As it is currently specified, the CAPWAP protocol sits between the + security mechanisms specified by the wireless link layer protocol + (e.g.IEEE 802.11i) and AAA. One goal of CAPWAP is to bootstrap trust + between the STA and WTP using a series of preestablished trust + relationships: + + + STA WTP AC AAA + ============================================== + + DTLS Cred AAA Cred + <------------><-------------> + + EAP Credential + <------------------------------------------> + + wireless link layer + (e.g.802.11 PTK) + <--------------> or + <---------------------------> + (derived) + + Within CAPWAP, DTLS is used to secure the link between the WTP and + AC. In addition to securing control messages, it's also a link in + this chain of trust for establishing link layer keys. Consequently, + much rests on the security of DTLS. + + In some CAPWAP deployment scenarios, there are two channels between + the WTP and AC: the control channel, carrying CAPWAP control + messages, and the data channel, over which client data packets are + tunneled between the AC and WTP. Typically, the control channel is + secured by DTLS, while the data channel is not. + + The use of parallel protected and unprotected channels deserves + special consideration, but does not create a threat. There are two + potential concerns: attempting to convert protected data into un- + protected data and attempting to convert un-protected data into + protected data. These concerns are addressed below. + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 121] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + +12.1.1. Converting Protected Data into Unprotected Data + + Since CAPWAP does not support authentication-only ciphers (i.e. all + supported ciphersuites include encryption and authentication), it is + not possible to convert protected data into unprotected data. Since + encrypted data is (ideally) indistinguishable from random data, the + probability of an encrypted packet passing for a well-formed packet + is effectively zero. + +12.1.2. Converting Unprotected Data into Protected Data (Insertion) + + The use of message authentication makes it impossible for the + attacker to forge protected records. This makes conversion of + unprotected records to protected records impossible. + +12.1.3. Deletion of Protected Records + + An attacker could remove protected records from the stream, though + not undetectably so, due the built-in reliability of the underlying + CAPWAP protocol. In the worst case, the attacker would remove the + same record repeatedly, resulting in a CAPWAP session timeout and + restart. This is effectively a DoS attack, and could be accomplished + by a man in the middle regardless of the CAPWAP protocol security + mechanisms chosen. + +12.1.4. Insertion of Unprotected Records + + An attacker could inject packets into the unprotected channel, but + this may become evident if sequence number desynchronization occurs + as a result. Only if the attacker is a MiM can packets be inserted + undetectably. This is a consequence of that channel's lack of + protection, and not a new threat resulting from the CAPWAP security + mechanism. + +12.2. Session ID Security + + Since DTLS does not export a unique session identifier, there can be + no explicit protocol binding between the DTLS layer and CAPWAP layer. + As a result, implementations MUST provide a mechanism for performing + this binding. For example, an AC MUST NOT associate decrypted DTLS + control packets with a particular WTP session based solely on the + Session ID in the packet header. Instead, identification should be + done based on which DTLS session decrypted the packet. Otherwise one + authenticated WTP could spoof another authenticated WTP by altering + the Session ID in the encrypted CAPWAP header. + + It should be noted that when the CAPWAP data channel is unencrypted, + the WTP Session ID is exposed and possibly known to adversaries and + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 122] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + other WTPs. This would allow the forgery of the source of data- + channel traffic. This, however, should not be a surprise for + unencrypted data channels. When the data channel is encrypted, the + Session ID is not exposed, and therefore can safely be used to + associate a data and control channel. The 64-bit length of the + Session ID mitigates online guessing attacks where an adversarial, + authenticated WTP tries to correlate his own data channel with + another WTP's control channel. Note that for encrypted data + channels, the Session ID should only be used for correlation for the + first packet immediately after the initial DTLS handshake. Future + correlation should instead be done via identification of a packet's + DTLS session. + +12.3. Discovery Attacks + + Since the Discovery Request messages are sent in the clear, it is + important that AC implementations NOT assume that receiving such a + request from a WTP implies that it has rebooted, and consequently + tear down any active DTLS sessions. Discovery Request messages can + easily be spoofed by malicious devices, so it is important that the + AC maintain two separate sets of states for the WTP until the + DTLSSessionEstablished notification is received, indicating that the + WTP was authenticated. Once a new DTLS session is successfully + established, any state referring to the old session can be cleared. + +12.4. Interference with a DTLS Session + + If a WTP or AC repeatedly receives packets which fail DTLS + authentication or decryption, this could indicate a DTLS + desynchronization between the AC and WTP, a link prone to + undetectable bit errors, or an attacker trying to disrupt a DTLS + session. + + In the state machine (section 2.3), transitions to the DTLS tear down + state can be triggered by frequently receiving DTLS packets with + authentication or decryption errors. The threshold or technique for + deciding when to move to the tear down state should be chosen + carefully. Being able to easily transition to DTLS TD allows easy + detection of malfunctioning devices, but allows for denial of service + attacks. Making it difficult to transition to DTLS TD prevents + denial of service attacks, but makes it more difficult to detect and + reset a malfunctioning session. Implementers should set this policy + with care. + +12.5. Use of Preshared Keys in CAPWAP + + While use of preshared keys may provide deployment and provisioning + advantages not found in public key based deployments, it also + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 123] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + introduces a number of operational and security concerns. In + particular, because the keys must typically be entered manually, it + is common for people to base them on memorable words or phrases. + These are referred to as "low entropy passwords/passphrases". + + Use of low-entropy preshared keys, coupled with the fact that the + keys are often not frequently updated, tends to significantly + increase exposure. For these reasons, the following recommendations + are made: + + o When DTLS is used with a preshared-key (PSK) ciphersuite, each WTP + SHOULD have a unique PSK. Since WTPs will likely be widely + deployed, their physical security is not guaranteed. If PSKs are + not unique for each WTP, key reuse would allow the compromise of + one WTP to result in the compromise of others + + o Generating PSKs from low entropy passwords is NOT RECOMMENDED. + + o It is RECOMMENDED that implementations that allow the + administrator to manually configure the PSK also provide a + capability for generation of new random PSKs, taking RFC 4086 [2] + into account. + + o Preshared keys SHOULD be periodically updated. Implementations + MAY facilitate this by providing an administrative interface for + automatic key generation and periodic update, or it MAY be + accomplished manually instead. + + Every pairwise combination of WTP and AC on the network SHOULD have a + unqiue PSK. This prevents the domino effect (see Guidance for AAA + Key Management [16]). If PSKs are tied to specific WTPs, then + knowledge of the PSK implies a binding to a specified identity that + can be authorized. + + If PSKs are shared, this binding between device and identity is no + longer possible. Compromise of one WTP can yield compromise of + another WTP, violating the CAPWAP security hierarchy. Consequently, + sharing keys between WTPs is NOT RECOMMENDED. + +12.6. Use of Certificates in CAPWAP + + For public-key-based DTLS deployments, each device SHOULD have unique + credentials, with an extended key usage authorizing the device to act + as either a WTP or AC. If devices do not have unique credentials, it + is possible that by compromising one device, any other device using + the same credential may also be considered to be compromised. + + Certificate validation involves checking a large variety of things. + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 124] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + + Since the necessary things to validate are often environment- + specific, many are beyond the scope of this document. In this + section, we provide some basic guidance on certificate validation. + + Each device is responsible for authenticating and authorizing devices + with which they communicate. Authentication entails validation of + the chain of trust leading to the peer certificate, followed by the + the peer certificate itself. At a minimum, devices SHOULD use SSH- + style certificate caching to guarantee consistency. If devices have + access to a certificate authority, they SHOULD properly validate the + trust chain. Implementations SHOULD also provide a secure method for + verifying that the credential in question has not been revoked. + + Note that if the WTP relies on the AC for network connectivity (e.g. + the AC is a layer 2 switch to which the WTP is directly connected), + the WTP may not be able to contact an OCSP server or otherwise obtain + an up to date CRL if a compromised AC doesn't explicitly permit this. + This cannot be avoided, except through effective physical security + and monitoring measures at the AC. + + Proper validation of certificates typically requires checking to + ensure the certificate has not yet expired. If devices have a real- + time clock, they SHOULD verify the certificate validity dates. If no + real-time clock is available, the device SHOULD make a best-effort + attempt to validate the certificate validity dates through other + means. Failure to check a certificate's temporal validity can make a + device vulnerable to man-in-the-middle attacks launched using + compromised, expired certificates, and therefore devices should make + every effort to perform this validation. + +12.7. AAA Security + + The AAA protocol is used to distribute EAP keys to the ACs, and + consequently its security is important to the overall system + security. When used with TLS or IPsec, security guidelines specified + in RFC 3539 [5] SHOULD be followed. + + In general, the link between the AC and AAA server SHOULD be secured + using a strong ciphersuite keyed with mutually authenticated session + keys. Implementations SHOULD NOT rely solely on Basic RADIUS shared + secret authentication as it is often vulnerable to dictionary + attacks, but rather SHOULD use stronger underlying security + mechanisms. + + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 125] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + +13. Management Considerations + + The CAPWAP protocol assumes that it is the only configuration + interface to the WTP to configure parameters that are specified in + the CAPWAP specifications. While the use of a separate management + protocol MAY be used for the purposes of monitoring the WTP directly, + configuring the WTP through a separate management interface is not + recommended. Configuring the WTP through a separate protocol, such + as via a CLI or SNMP, could lead to the AC state being out of sync + with the WTP. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 126] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + +14. IANA Considerations + + A separate UDP port for data channel communications is (currently) + the selected demultiplexing mechanism, and a port must be assigned + for this purpose in Section 3.1. The UDP port numbers are listed by + IANA at http://www.iana.org/assignments/port-numbers. + + IANA needs to assign an organization local multicast address called + the "All ACs multicast address" from the IPv6 multicast address + registry in Section 3.3 + +14.1. CAPWAP Message Types + + The Message Type field in the CAPWAP header (Section 4.5.1.1) is used + to identify the operation performed by the message. There are + multiple namespaces, which is identified via the first three octets + of the field containing the IANA Enterprise Number [10]. When the + Enterprise Number is set to zero, the message types are reserved for + use by the base CAPWAP specification which are controlled and + maintained by IANA and requires a Standards Action. + +14.2. Wireless Binding Identifiers + + The Wireless Binding Identifier (WBID) field in the CAPWAP header + (Section 4.3) is used to identify the wireless technology associated + with the packet. Due to the limited address space available, a new + WBID request requires Standards Action. + + + + + + + + + + + + + + + + + + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 127] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + +15. Acknowledgements + + The following individuals are acknowledged for their contributions to + this protocol specification: Puneet Agarwal, Saravanan Govindan, + Peter Nilsson, and David Perkins. + + Michael Vakulenko contributed text to describe how CAPWAP can be used + over layer 3 (IP/UDP) networks. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 128] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + +16. References + +16.1. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Eastlake, D., Schiller, J., and S. Crocker, "Randomness + Requirements for Security", BCP 106, RFC 4086, June 2005. + + [3] Mills, D., "Network Time Protocol (Version 3) Specification, + Implementation", RFC 1305, March 1992. + + [4] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 + Public Key Infrastructure Certificate and Certificate + Revocation List (CRL) Profile", RFC 3280, April 2002. + + [5] Aboba, B. and J. Wood, "Authentication, Authorization and + Accounting (AAA) Transport Profile", RFC 3539, June 2003. + + [6] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for + Transport Layer Security (TLS)", RFC 4279, December 2005. + + [7] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) + Protocol Version 1.1", RFC 4346, April 2006. + + [8] Rescorla, E. and N. Modadugu, "Datagram Transport Layer + Security", RFC 4347, April 2006. + + [9] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor + Extensions", RFC 2132, March 1997. + + [10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, + October 1998. + + [11] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. + Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)", + RFC 3828, July 2004. + + [12] Calhoun, P., Montemurro, M., Stanley, D., "CAPWAP Protocol + Binding for IEEE 802.11", draft-ietf-capwap-protocol- + binding-ieee80211-04 (work in progress), June 2007. + + [13] Calhoun, P., "CAPWAP Access Controller DHCP Option", + draft-ietf-capwap-dhc-ac-option-00 (work in progress), + June 2007. + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 129] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + +16.2. Informational References + + [14] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On- + line Database", RFC 3232, January 2002. + + [15] Manner, J. and M. Kojo, "Mobility Related Terminology", + RFC 3753, June 2004. + + [16] Housley, R. and B. Aboba, "Guidance for AAA Key Management", + draft-housley-aaa-key-mgmt-09 (work in progress), + February 2007. + + [17] Modadugu et al, N., "The Design and Implementation of Datagram + TLS", Feb 2004. + + [18] IEEE, "Guidelines for use of a 48-bit Extended Unique + Identifier", Dec 2005. + + [19] IEEE, "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) + REGISTRATION AUTHORITY". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 130] +
+Internet-Draft CAPWAP Protocol Specification June 2007 + + +Editors' Addresses + + Pat R. Calhoun + Cisco Systems, Inc. + 170 West Tasman Drive + San Jose, CA 95134 + + Phone: +1 408-853-5269 + Email: pcalhoun@cisco.com + + + Michael P. Montemurro + Research In Motion + 5090 Commerce Blvd + Mississauga, ON L4W 5M4 + Canada + + Phone: +1 905-629-4746 x4999 + Email: mmontemurro@rim.com + + + Dorothy Stanley + Aruba Networks + 1322 Crossman Ave + Sunnyvale, CA 94089 + + Phone: +1 630-363-1389 + Email: dstanley@arubanetworks.com + + + + + + + + + + + + + + + + + + + + + + + +Calhoun, Editor, et al. Expires December 13, 2007 [Page 131] +
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2007).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 132]
+
+