planix.org/actube
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
359b0045cb
actube/doc/rfc5415.txt
7u83@mail.ru ccd226aeba Updated docs. 
FossilOrigin-Name: 17747fba31475f32e5b65fd1874e69f2703d49efffbe1eeb01dc31274b1cd39c
2015-03-23 06:47:44 +00:00

8684 lines
337 KiB
Plaintext
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Network Working Group P. Calhoun, Ed.
Request for Comments: 5415 Cisco Systems, Inc.
Category: Standards Track M. Montemurro, Ed.
Research In Motion
D. Stanley, Ed.
Aruba Networks
March 2009
Control And Provisioning of Wireless Access Points (CAPWAP)
Protocol Specification
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Calhoun, et al. Standards Track [Page 1]
RFC 5415 CAPWAP Protocol Specification March 2009
Abstract
This specification defines the Control And Provisioning of Wireless
Access Points (CAPWAP) Protocol, meeting the objectives defined by
the CAPWAP Working Group in RFC 4564. 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, while separate binding extensions will enable its use with
additional wireless technologies.
Table of Contents
1. Introduction ....................................................7
1.1. Goals ......................................................8
1.2. Conventions Used in This Document ..........................9
1.3. Contributing Authors .......................................9
1.4. Terminology ...............................................10
2. Protocol Overview ..............................................11
2.1. Wireless Binding Definition ...............................12
2.2. CAPWAP Session Establishment Overview .....................13
2.3. CAPWAP State Machine Definition ...........................15
2.3.1. CAPWAP Protocol State Transitions ..................17
2.3.2. CAPWAP/DTLS Interface ..............................31
2.4. Use of DTLS in the CAPWAP Protocol ........................33
2.4.1. DTLS Handshake Processing ..........................33
2.4.2. DTLS Session Establishment .........................35
2.4.3. DTLS Error Handling ................................35
2.4.4. DTLS Endpoint Authentication and Authorization .....36
3. CAPWAP Transport ...............................................40
3.1. UDP Transport .............................................40
3.2. UDP-Lite Transport ........................................41
3.3. AC Discovery ..............................................41
3.4. Fragmentation/Reassembly ..................................42
3.5. MTU Discovery .............................................43
4. CAPWAP Packet Formats ..........................................43
4.1. CAPWAP Preamble ...........................................46
4.2. CAPWAP DTLS Header ........................................46
4.3. CAPWAP Header .............................................47
4.4. CAPWAP Data Messages ......................................50
4.4.1. CAPWAP Data Channel Keep-Alive .....................51
4.4.2. Data Payload .......................................52
4.4.3. Establishment of a DTLS Data Channel ...............52
4.5. CAPWAP Control Messages ...................................52
4.5.1. Control Message Format .............................53
4.5.2. Quality of Service .................................56
4.5.3. Retransmissions ....................................57
4.6. CAPWAP Protocol Message Elements ..........................58
4.6.1. AC Descriptor ......................................61
Calhoun, et al. Standards Track [Page 2]
RFC 5415 CAPWAP Protocol Specification March 2009
4.6.2. AC IPv4 List .......................................64
4.6.3. AC IPv6 List .......................................64
4.6.4. AC Name ............................................65
4.6.5. AC Name with Priority ..............................65
4.6.6. AC Timestamp .......................................66
4.6.7. Add MAC ACL Entry ..................................66
4.6.8. Add Station ........................................67
4.6.9. CAPWAP Control IPv4 Address ........................68
4.6.10. CAPWAP Control IPv6 Address .......................68
4.6.11. CAPWAP Local IPv4 Address .........................69
4.6.12. CAPWAP Local IPv6 Address .........................69
4.6.13. CAPWAP Timers .....................................70
4.6.14. CAPWAP Transport Protocol .........................71
4.6.15. Data Transfer Data ................................72
4.6.16. Data Transfer Mode ................................73
4.6.17. Decryption Error Report ...........................73
4.6.18. Decryption Error Report Period ....................74
4.6.19. Delete MAC ACL Entry ..............................74
4.6.20. Delete Station ....................................75
4.6.21. Discovery Type ....................................75
4.6.22. Duplicate IPv4 Address ............................76
4.6.23. Duplicate IPv6 Address ............................77
4.6.24. Idle Timeout ......................................78
4.6.25. ECN Support .......................................78
4.6.26. Image Data ........................................79
4.6.27. Image Identifier ..................................79
4.6.28. Image Information .................................80
4.6.29. Initiate Download .................................81
4.6.30. Location Data .....................................81
4.6.31. Maximum Message Length ............................81
4.6.32. MTU Discovery Padding .............................82
4.6.33. Radio Administrative State ........................82
4.6.34. Radio Operational State ...........................83
4.6.35. Result Code .......................................84
4.6.36. Returned Message Element ..........................85
4.6.37. Session ID ........................................86
4.6.38. Statistics Timer ..................................87
4.6.39. Vendor Specific Payload ...........................87
4.6.40. WTP Board Data ....................................88
4.6.41. WTP Descriptor ....................................89
4.6.42. WTP Fallback ......................................92
4.6.43. WTP Frame Tunnel Mode .............................92
4.6.44. WTP MAC Type ......................................93
4.6.45. WTP Name ..........................................94
4.6.46. WTP Radio Statistics ..............................94
4.6.47. WTP Reboot Statistics .............................96
4.6.48. WTP Static IP Address Information .................97
4.7. CAPWAP Protocol Timers ....................................98
Calhoun, et al. Standards Track [Page 3]
RFC 5415 CAPWAP Protocol Specification March 2009
4.7.1. ChangeStatePendingTimer ............................98
4.7.2. DataChannelKeepAlive ...............................98
4.7.3. DataChannelDeadInterval ............................99
4.7.4. DataCheckTimer .....................................99
4.7.5. DiscoveryInterval ..................................99
4.7.6. DTLSSessionDelete ..................................99
4.7.7. EchoInterval .......................................99
4.7.8. IdleTimeout ........................................99
4.7.9. ImageDataStartTimer ...............................100
4.7.10. MaxDiscoveryInterval .............................100
4.7.11. ReportInterval ...................................100
4.7.12. RetransmitInterval ...............................100
4.7.13. SilentInterval ...................................100
4.7.14. StatisticsTimer ..................................100
4.7.15. WaitDTLS .........................................101
4.7.16. WaitJoin .........................................101
4.8. CAPWAP Protocol Variables ................................101
4.8.1. AdminState ........................................101
4.8.2. DiscoveryCount ....................................101
4.8.3. FailedDTLSAuthFailCount ...........................101
4.8.4. FailedDTLSSessionCount ............................101
4.8.5. MaxDiscoveries ....................................102
4.8.6. MaxFailedDTLSSessionRetry .........................102
4.8.7. MaxRetransmit .....................................102
4.8.8. RetransmitCount ...................................102
4.8.9. WTPFallBack .......................................102
4.9. WTP Saved Variables ......................................102
4.9.1. AdminRebootCount ..................................102
4.9.2. FrameEncapType ....................................102
4.9.3. LastRebootReason ..................................103
4.9.4. MacType ...........................................103
4.9.5. PreferredACs ......................................103
4.9.6. RebootCount .......................................103
4.9.7. Static IP Address .................................103
4.9.8. WTPLinkFailureCount ...............................103
4.9.9. WTPLocation .......................................103
4.9.10. WTPName ..........................................103
5. CAPWAP Discovery Operations ...................................103
5.1. Discovery Request Message ................................103
5.2. Discovery Response Message ...............................105
5.3. Primary Discovery Request Message ........................106
5.4. Primary Discovery Response ...............................107
6. CAPWAP Join Operations ........................................108
6.1. Join Request .............................................108
6.2. Join Response ............................................110
7. Control Channel Management ....................................111
7.1. Echo Request .............................................111
7.2. Echo Response ............................................112
Calhoun, et al. Standards Track [Page 4]
RFC 5415 CAPWAP Protocol Specification March 2009
8. WTP Configuration Management ..................................112
8.1. Configuration Consistency ................................112
8.1.1. Configuration Flexibility .........................113
8.2. Configuration Status Request .............................114
8.3. Configuration Status Response ............................115
8.4. Configuration Update Request .............................116
8.5. Configuration Update Response ............................117
8.6. Change State Event Request ...............................117
8.7. Change State Event Response ..............................118
8.8. Clear Configuration Request ..............................119
8.9. Clear Configuration Response .............................119
9. Device Management Operations ..................................120
9.1. Firmware Management ......................................120
9.1.1. Image Data Request ................................124
9.1.2. Image Data Response ...............................125
9.2. Reset Request ............................................126
9.3. Reset Response ...........................................127
9.4. WTP Event Request ........................................127
9.5. WTP Event Response .......................................128
9.6. Data Transfer ............................................128
9.6.1. Data Transfer Request .............................130
9.6.2. Data Transfer Response ............................131
10. Station Session Management ...................................131
10.1. Station Configuration Request ...........................131
10.2. Station Configuration Response ..........................132
11. NAT Considerations ...........................................132
12. Security Considerations ......................................134
12.1. CAPWAP Security .........................................134
12.1.1. Converting Protected Data into Unprotected Data ..135
12.1.2. Converting Unprotected Data into
Protected Data (Insertion) .......................135
12.1.3. Deletion of Protected Records ....................135
12.1.4. Insertion of Unprotected Records .................135
12.1.5. Use of MD5 .......................................136
12.1.6. CAPWAP Fragmentation .............................136
12.2. Session ID Security .....................................136
12.3. Discovery or DTLS Setup Attacks .........................137
12.4. Interference with a DTLS Session ........................137
12.5. CAPWAP Pre-Provisioning .................................138
12.6. Use of Pre-Shared Keys in CAPWAP ........................139
12.7. Use of Certificates in CAPWAP ...........................140
12.8. Use of MAC Address in CN Field ..........................140
12.9. AAA Security ............................................141
12.10. WTP Firmware ...........................................141
13. Operational Considerations ...................................141
14. Transport Considerations .....................................142
15. IANA Considerations ..........................................143
15.1. IPv4 Multicast Address ..................................143
Calhoun, et al. Standards Track [Page 5]
RFC 5415 CAPWAP Protocol Specification March 2009
15.2. IPv6 Multicast Address ..................................144
15.3. UDP Port ................................................144
15.4. CAPWAP Message Types ....................................144
15.5. CAPWAP Header Flags .....................................144
15.6. CAPWAP Control Message Flags ............................145
15.7. CAPWAP Message Element Type .............................145
15.8. CAPWAP Wireless Binding Identifiers .....................145
15.9. AC Security Types .......................................146
15.10. AC DTLS Policy .........................................146
15.11. AC Information Type ....................................146
15.12. CAPWAP Transport Protocol Types ........................146
15.13. Data Transfer Type .....................................147
15.14. Data Transfer Mode .....................................147
15.15. Discovery Types ........................................147
15.16. ECN Support ............................................148
15.17. Radio Admin State ......................................148
15.18. Radio Operational State ................................148
15.19. Radio Failure Causes ...................................148
15.20. Result Code ............................................149
15.21. Returned Message Element Reason ........................149
15.22. WTP Board Data Type ....................................149
15.23. WTP Descriptor Type ....................................149
15.24. WTP Fallback Mode ......................................150
15.25. WTP Frame Tunnel Mode ..................................150
15.26. WTP MAC Type ...........................................150
15.27. WTP Radio Stats Failure Type ...........................151
15.28. WTP Reboot Stats Failure Type ..........................151
16. Acknowledgments ..............................................151
17. References ...................................................151
17.1. Normative References ....................................151
17.2. Informative References ..................................153
Calhoun, et al. Standards Track [Page 6]
RFC 5415 CAPWAP Protocol Specification March 2009
1. Introduction
This document describes the CAPWAP protocol, a standard,
interoperable protocol that 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 (L2)
technology, and meets the objectives in "Objectives for Control and
Provisioning of Wireless Access Points (CAPWAP)" [RFC4564].
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 [RFC5416] 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 radio frequency (RF) interfaces controlled by the
AC. The CAPWAP protocol supports two modes of operation: Split and
Local MAC (medium access control). 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.11 Integration function. In
either case, the L2 wireless management frames are processed locally
Calhoun, et al. Standards Track [Page 7]
RFC 5415 CAPWAP Protocol Specification March 2009
by the WTP and then forwarded to the AC. Figure 2 shows the Local
MAC mode, in which a station transmits a wireless frame that is
encapsulated in an 802.3 frame and forwarded to the AC.
+-+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 subject to severe
cost pressure.
3. To provide an extensible protocol that is not bound to a specific
wireless technology. Extensibility is provided via 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.
Calhoun, et al. Standards Track [Page 8]
RFC 5415 CAPWAP Protocol Specification March 2009
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 [RFC2119].
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) [LWAPP] to be used as the basis of the CAPWAP
protocol specification. The following people are authors of the
LWAPP document:
Bob O'Hara
Email: bob.ohara@computer.org
Pat Calhoun, Cisco Systems, Inc.
170 West Tasman Drive, San Jose, CA 95134
Phone: +1 408-902-3240, 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, Green Hills Software
825 Victors Way, Suite 100, Ann Arbor, MI 48108
Phone: +1 734 222 1610, Email: shares@ndzh.com
Datagram Transport Layer Security (DTLS) [RFC4347] is used as the
security solution for the CAPWAP protocol. The following people are
authors of significant DTLS-related text included in this document:
Calhoun, et al. Standards Track [Page 9]
RFC 5415 CAPWAP Protocol Specification March 2009
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
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 [SLAPP]. 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
Trapeze Networks
5753 W. Las Positas Blvd, Pleasanton, CA 94588
Phone: +1-925-474-2212
EMail: dharkins@trpz.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 document [RFC5418]:
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: scott@hyperthought.com
1.4. Terminology
Access Controller (AC): The network entity that provides WTP access
to the network infrastructure in the data plane, control plane,
management plane, or a combination therein.
Calhoun, et al. Standards Track [Page 10]
RFC 5415 CAPWAP Protocol Specification March 2009
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 interface to a wireless
medium (WM).
Wireless Termination Point (WTP): The physical or network entity that
contains an RF antenna and wireless Physical Layer (PHY) to transmit
and receive station traffic for wireless access networks.
This document uses additional terminology defined in [RFC3753].
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)
[RFC4347]. 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. In order to establish
the secure DTLS connection, the WTP will need some amount of pre-
provisioning, which is specified in Section 12.5. CAPWAP protocol
messages will be fragmented to the maximum length discovered to be
supported by the network.
Calhoun, et al. Standards Track [Page 11]
RFC 5415 CAPWAP Protocol Specification March 2009
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. MTU
Discovery and Fragmentation are described in Section 3.
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
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, as well its associated wireless link layer protocol.
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.
Calhoun, et al. Standards Track [Page 12]
RFC 5415 CAPWAP Protocol Specification March 2009
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 [RFC5416], begins with "IEEE 802.11".
The CAPWAP binding concept MUST also be 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.
2.2. CAPWAP Session Establishment Overview
This section describes the session establishment process message
exchanges between a CAPWAP WTP and AC. 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 asterisk in Figure 3.
============ ============
WTP AC
============ ============
[----------- begin optional discovery ------------]
Discover Request
------------------------------------>
Discover Response
<------------------------------------
[----------- end optional discovery ------------]
(-- begin DTLS handshake --)
ClientHello
------------------------------------>
Calhoun, et al. Standards Track [Page 13]
RFC 5415 CAPWAP Protocol Specification March 2009
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 --)
ChangeCipherSpec,
Finished*
<------------------------------------
(-- DTLS session is established now --)
Join Request
------------------------------------>
Join Response
<------------------------------------
[-- Join State Complete --]
(-- assume image is up to date --)
Configuration Status Request
------------------------------------>
Configuration Status Response
<------------------------------------
[-- Configure State Complete --]
Change State Event Request
------------------------------------>
Change State Event Response
<------------------------------------
[-- Data Check State Complete --]
Calhoun, et al. Standards Track [Page 14]
RFC 5415 CAPWAP Protocol Specification March 2009
(-- enter RUN state --)
:
:
Echo Request
------------------------------------>
Echo Response
<------------------------------------
:
:
Event Request
------------------------------------>
Event Response
<------------------------------------
:
:
Figure 3: CAPWAP Control Protocol Exchange
At the end of the illustrated CAPWAP message exchange, the AC and WTP
are securely exchanging CAPWAP Control messages. This illustration
is provided to clarify protocol operation, and does not include any
possible error conditions. Section 2.3 provides a detailed
description of the corresponding state machine.
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, et al. Standards Track [Page 15]
RFC 5415 CAPWAP Protocol Specification March 2009
/-------------------------------------\
| /-------------------------\|
| p| ||
| q+----------+ r +------------+ ||
| | Run |-->| Reset |-\||
| +----------+ +------------+ |||
n| o ^ ^ ^ s|||
+------------+--------/ | | |||
| Data Check | /-------/ | |||
+------------+<-------\ | | |||
| | | |||
/------------------+--------\ | |||
f| m| h| j v k| |||
+--------+ +-----------+ +--------------+|||
| Join |---->| Configure | | Image Data ||||
+--------+ n +-----------+ +--------------+|||
^ |g i| l| |||
| | \-------------------\ | |||
| \--------------------------------------\| | |||
\------------------------\ || | |||
/--------------<----------------+---------------\ || | |||
| /------------<----------------+-------------\ | || | |||
| | 4 |d t| | vv v vvv
| | +----------------+ +--------------+ +-----------+
| | | DTLS Setup | | DTLS Connect |-->| DTLS TD |
/-|-|---+----------------+ +--------------+ e +-----------+
| | | |$ ^ ^ |5 ^6 ^ ^ |w
v v v | | | | \-------\ | | |
| | | | | | \---------\ | | /-----------/ |
| | | | | \--\ | | | | |
| | | | | | | | | | |
| | | v 3| 1 |% # v | |a |b v
| | \->+------+-->+------+ +-----------+ +--------+
| | | Idle | | Disc | | Authorize | | Dead |
| | +------+<--+------+ +-----------+ +--------+
| | ^ 0^ 2 |!
| | | | | +-------+
*| |u | \---------+---| Start |
| | |@ | +-------+
| \->+---------+<------/
\--->| Sulking |
+---------+&
Figure 4: 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
Calhoun, et al. Standards Track [Page 16]
RFC 5415 CAPWAP Protocol Specification March 2009
called out in the transition descriptions below. For every state
defined, only certain messages are permitted to be sent and received.
The CAPWAP Control message definitions specify the state(s) in which
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 state machine works
differently on the AC since it communicates with many WTPs. The AC
uses the concept of three threads. Note that the term thread used
here does not necessarily imply that implementers must use threads,
but it is one possible way of implementing the AC's state machine.
Listener Thread: The AC's Listener thread handles inbound DTLS
session establishment requests, through the DTLSListen command.
Upon creation, the Listener thread starts in the DTLS Setup state.
Once a DTLS session has been validated, which occurs when the
state machine enters the "Authorize" state, the Listener thread
creates a WTP session-specific Service thread and state context.
The state machine transitions in Figure 4 are represented by
numerals. It is necessary for the AC to protect itself against
various attacks that exist with non-authenticated frames. See
Section 12 for more information.
Discovery Thread: The AC's Discovery thread is responsible for
receiving, and responding to, Discovery Request messages. The
state machine transitions in Figure 4 are represented by numerals.
Note that the Discovery thread does not maintain any per-WTP-
specific context information, and a single state context exists.
It is necessary for the AC to protect itself against various
attacks that exist with non-authenticated frames. See Section 12
for more information.
Service Thread: The AC's Service thread handles the per-WTP states,
and one such thread exists per-WTP connection. This thread is
created by the Listener thread when the Authorize state is
reached. When created, the Service thread inherits a copy of the
state machine context from the Listener thread. When
communication with the WTP is complete, the Service thread is
terminated and all associated resources are released. The state
machine transitions in Figure 4 are represented by alphabetic and
punctuation characters.
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.
Calhoun, et al. Standards Track [Page 17]
RFC 5415 CAPWAP Protocol Specification March 2009
Start to Idle (0): This transition occurs once device initialization
is complete.
WTP: This state transition is used to start the WTP's CAPWAP
state machine.
AC: The AC creates the Discovery and Listener threads and starts
the CAPWAP state machine.
Idle to Discovery (1): This transition occurs to support the CAPWAP
discovery process.
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: This state transition is executed by the AC's Discovery
thread, and occurs when a Discovery Request message is
received. The AC SHOULD respond with a Discovery Response
message (see Section 5.2).
Discovery to Discovery (#): In the Discovery state, the WTP
determines to which AC to connect.
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 an invalid state transition for the AC.
Discovery to Idle (2): This transition occurs on the AC's Discovery
thread when the Discovery processing is complete.
WTP: This is an invalid state transition for the WTP.
Calhoun, et al. Standards Track [Page 18]
RFC 5415 CAPWAP Protocol Specification March 2009
AC: This state transition is executed by the AC's Discovery
thread when it has transmitted the Discovery Response, in
response to a Discovery Request.
Discovery to Sulking (!): This transition occurs on a WTP when AC
Discovery fails.
WTP: The WTP enters this state when the DiscoveryInterval timer
expires and 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 MUST be ignored.
AC: This is an invalid state transition for the AC.
Sulking to Idle (@): 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: This is an invalid state transition for the AC.
Sulking to Sulking (&): 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.
AC: This is an invalid state transition for the AC.
Idle to DTLS Setup (3): 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 and the WaitDTLS timer is
started (see Section 4.7). When the Discovery phase is
bypassed, it is assumed the WTP has locally configured ACs.
Calhoun, et al. Standards Track [Page 19]
RFC 5415 CAPWAP Protocol Specification March 2009
AC: Upon entering the Idle state from the Start state, the newly
created Listener thread automatically transitions to the
DTLS Setup and invokes the DTLSListen command (see
Section 2.3.2.1), and the WaitDTLS timer is started (see
Section 4.7).
Discovery to DTLS Setup (%): 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 to which
AC to connect is the result of the Discovery phase, which is
described in Section 3.3.
AC: This is an invalid state transition for the AC.
DTLS Setup to Idle ($): This transition occurs when the DTLS
connection setup fails.
WTP: The WTP initiates this state transition when it receives a
DTLSEstablishFail notification from DTLS (see
Section 2.3.2.2), and the FailedDTLSSessionCount or the
FailedDTLSAuthFailCount counter have not reached the value
of the MaxFailedDTLSSessionRetry variable (see Section 4.8).
This error notification aborts the secure DTLS session
establishment. When this notification is received, the
FailedDTLSSessionCount counter is incremented. This state
transition also occurs if the WaitDTLS timer has expired.
AC: This is an invalid state transition for the AC.
DTLS Setup to Sulking (*): This transition occurs when repeated
attempts to set up the DTLS connection have failed.
WTP: The WTP enters this state when the FailedDTLSSessionCount or
the FailedDTLSAuthFailCount counter reaches the value of the
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: This is an invalid state transition for the AC.
DTLS Setup to DTLS Setup (4): This transition occurs when the DTLS
Session failed to be established.
WTP: This is an invalid state transition for the WTP.
Calhoun, et al. Standards Track [Page 20]
RFC 5415 CAPWAP Protocol Specification March 2009
AC: The AC's Listener 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.
The Listener thread then invokes the DTLSListen command (see
Section 2.3.2.1).
DTLS Setup to Authorize (5): 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 is handled by the AC's Listener thread
when the DTLS module initiates the DTLSPeerAuthorize
notification (see Section 2.3.2.2). The Listener thread
forks an instance of the Service thread, along with a copy
of the state context. Once created, the Service thread
performs an authorization check against the WTP credentials.
See Section 2.4.4 for more information on WTP authorization.
Authorize to DTLS Setup (6): This transition is executed by the
Listener thread to enable it to listen for new incoming sessions.
WTP: This is an invalid state transition for the WTP.
AC: This state transition occurs when the AC's Listener thread
has created the WTP context and the Service thread. The
Listener thread then invokes the DTLSListen command (see
Section 2.3.2.1).
Authorize to DTLS Connect (a): This transition occurs to notify the
DTLS stack that the session should be established.
WTP: This state transition occurs when the WTP has successfully
authorized the AC's credentials (see Section 2.4.4). This
is done by invoking the DTLSAccept DTLS command (see
Section 2.3.2.1).
AC: This state transition occurs when the AC has successfully
authorized the WTP's credentials (see Section 2.4.4). This
is done by invoking the DTLSAccept DTLS command (see
Section 2.3.2.1).
Calhoun, et al. Standards Track [Page 21]
RFC 5415 CAPWAP Protocol Specification March 2009
Authorize to DTLS Teardown (b): This transition occurs to notify the
DTLS stack that the session should be aborted.
WTP: This state transition occurs when the WTP has been 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). This state transition also
occurs if the WaitDTLS timer has expired. The WTP starts
the DTLSSessionDelete timer (see Section 4.7.6).
AC: This state transition occurs when the AC has been 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). This state transition also
occurs if the WaitDTLS timer has expired. The AC starts the
DTLSSessionDelete timer (see Section 4.7.6).
DTLS Connect to DTLS Teardown (c): 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. This state
transition also occurs if the WaitDTLS timer has expired.
The WTP starts the DTLSSessionDelete timer (see
Section 4.7.6).
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, and both of the
FailedDTLSAuthFailCount and FailedDTLSSessionCount counters
have not reached the value of the MaxFailedDTLSSessionRetry
variable (see Section 4.8). This state transition also
occurs if the WaitDTLS timer has expired. The AC starts the
DTLSSessionDelete timer (see Section 4.7.6).
DTLS Connect to Join (d): 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
Calhoun, et al. Standards Track [Page 22]
RFC 5415 CAPWAP Protocol Specification March 2009
FailedDTLSSessionCount counter is set to zero. The WTP
enters the Join state by transmitting the Join Request to
the AC. The WTP stops the WaitDTLS timer.
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. The AC stops
the WaitDTLS timer, and starts the WaitJoin timer.
Join to DTLS Teardown (e): This transition occurs when the join
process has failed.
WTP: This state transition occurs when the WTP receives a Join
Response message with a Result Code message element
containing an error, or 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. 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.
The WTP starts the DTLSSessionDelete timer (see
Section 4.7.6).
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.
The AC starts the DTLSSessionDelete timer (see
Section 4.7.6).
Join to Image Data (f): 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 that the
software version in the 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
Calhoun, et al. Standards Track [Page 23]
RFC 5415 CAPWAP Protocol Specification March 2009
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, after having sent its
Join Response to the WTP. The AC stops the WaitJoin timer.
The AC MUST transmit an Image Data Response message (see
Section 9.1.2) to the WTP, which includes a portion of the
firmware.
Join to Configure (g): 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 message, and determines that the
included Image Identifier message element is the same as its
currently running image. The WTP transmits the
Configuration Status Request message (see Section 8.2) to
the AC with message elements describing its current
configuration.
AC: This state transition occurs when it receives the
Configuration Status Request message from the WTP (see
Section 8.2), which MAY include specific message elements to
override the WTP's configuration. The AC stops the WaitJoin
timer. The AC transmits the Configuration Status Response
message (see Section 8.3) and starts the
ChangeStatePendingTimer timer (see Section 4.7).
Configure to Reset (h): 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. The CAPWAP Reset command is used to
indicate to the peer that it will initiate a DTLS teardown.
WTP: The WTP enters the Reset state when it receives a
Configuration Status Response message 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.
Calhoun, et al. Standards Track [Page 24]
RFC 5415 CAPWAP Protocol Specification March 2009
Configure to DTLS Teardown (i): 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. The
WTP starts the DTLSSessionDelete timer (see Section 4.7.6).
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 AC MAY tear down the DTLS session if
it receives frequent DTLSDecapFailure notifications. The AC
starts the DTLSSessionDelete timer (see Section 4.7.6).
Image Data to Image Data (j): 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. This state transition also occurs when the
WTP receives the subsequent Image Data Requests, at which
time it resets the ImageDataStartTimer time to ensure it
receives the next expected Image Data Request from the AC.
This state transition can also occur when the WTP's
EchoInterval timer (see Section 4.7.7) expires, in which
case the WTP transmits an Echo Request message (see
Section 7.1), and resets its EchoInterval timer. The state
transition also occurs when the WTP receives an Echo
Response from the AC (see Section 7.2).
AC: This state transition occurs when the AC receives the Image
Data Response message from the WTP while already in the
Image Data state. This state transition also occurs when
the AC receives an Echo Request (see Section 7.1) from the
WTP, in which case it responds with an Echo Response (see
Section 7.2), and resets its EchoInterval timer (see
Section 4.7.7).
Calhoun, et al. Standards Track [Page 25]
RFC 5415 CAPWAP Protocol Specification March 2009
Image Data to Reset (k): This state transition is used to reset the
DTLS connection prior to restarting the WTP after an image
download.
WTP: When an image download completes, or if the
ImageDataStartTimer timer expires, 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 either when the image transfer
has successfully completed or an error occurs during the
image download process.
Image Data to DTLS Teardown (l): 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. The
WTP starts the DTLSSessionDelete timer (see Section 4.7.6).
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 AC MAY tear down the DTLS session if
it receives frequent DTLSDecapFailure notifications. The AC
starts the DTLSSessionDelete timer (see Section 4.7.6).
Configure to Data Check (m): 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
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 DataCheckTimer
timer and stops the ChangeStatePendingTimer timer (see
Section 4.7).
Data Check to DTLS Teardown (n): This transition occurs when the WTP
does not complete the Data Check exchange.
Calhoun, et al. Standards Track [Page 26]
RFC 5415 CAPWAP Protocol Specification March 2009
WTP: This state transition occurs if the WTP does not receive the
Change State Event Response message before a CAPWAP
retransmission timeout occurs. The WTP also transitions to
this state if the underlying reliable transport's
RetransmitCount counter has reached the MaxRetransmit
variable (see Section 4.7). The WTP starts the
DTLSSessionDelete timer (see Section 4.7.6).
AC: The AC enters this state when the DataCheckTimer timer
expires (see Section 4.7). The AC starts the
DTLSSessionDelete timer (see Section 4.7.6).
Data Check to Run (o): This state transition occurs when the linkage
between the control and data channels is established, 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.2) and transmits
a Data Channel Keep-Alive packet (see Section 4.4.1). The
WTP then starts the EchoInterval timer and
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. The AC disables the
DataCheckTimer timer. 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 (p): This state transition occurs when an error
has occurred in the DTLS stack, causing the DTLS session to be
torn down.
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). The WTP starts
the DTLSSessionDelete timer (see Section 4.7.6).
Calhoun, et al. Standards Track [Page 27]
RFC 5415 CAPWAP Protocol Specification March 2009
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 AC 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). This state
transition also occurs when the AC's EchoInterval timer (see
Section 4.7.7) expires. The AC starts the DTLSSessionDelete
timer (see Section 4.7.6).
Run to Run (q): This is the normal state of operation.
WTP: This is the WTP's normal state of operation. The WTP resets
its EchoInterval timer whenever it transmits a request to
the AC. There are many events that result in 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.
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. When
the WTP receives the Echo Response, it resets its
EchoInterval timer (see Section 4.7.7).
Clear Config Request: The WTP receives a Clear
Configuration Request message (see Section 8.8) and
MUST generate a corresponding Clear Configuration
Response message (see Section 8.9). 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).
Calhoun, et al. Standards Track [Page 28]
RFC 5415 CAPWAP Protocol Specification March 2009
Data Transfer: The WTP sends a Data Transfer Request or
Data Transfer Response message to the AC (see
Section 9.6). The WTP receives a Data Transfer
Request or Data Transfer Response message from the AC
(see Section 9.6). Upon receipt of a Data Transfer
Request, the WTP transmits a Data Transfer Response to
the AC.
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. Note that the
receipt of any Request from the WTP causes the AC to reset
its EchoInterval timer (see Section 4.7.7).
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 sends a Clear Configuration
Request message (see Section 8.8) to the WTP to clear
its configuration. 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).
Data Transfer: The AC sends a Data Transfer Request or Data
Transfer Response message to the WTP (see
Section 9.6). The AC receives a Data Transfer Request
Calhoun, et al. Standards Track [Page 29]
RFC 5415 CAPWAP Protocol Specification March 2009
or Data Transfer Response message from the WTP (see
Section 9.6). Upon receipt of a Data Transfer
Request, the AC transmits a Data Transfer Response to
the WTP.
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 (r): This state transition is used when either the AC
or WTP tears 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 (s): This transition occurs when the CAPWAP
reset is complete to terminate the DTLS session.
WTP: This state transition occurs when the WTP transmits a Reset
Response message. The WTP does not invoke the DTLSShutdown
command (see Section 2.3.2.1). The WTP starts the
DTLSSessionDelete timer (see Section 4.7.6).
AC: This state transition occurs when the AC receives a Reset
Response message. This causes the AC to initiate the
DTLSShutdown command (see Section 2.3.2.1). The AC starts
the DTLSSessionDelete timer (see Section 4.7.6).
DTLS Teardown to Idle (t): This transition occurs when the DTLS
session has been shut down.
WTP: This state transition occurs when the WTP has successfully
cleaned up all resources associated with the control plane
DTLS session, or if the DTLSSessionDelete timer (see
Section 4.7.6) expires. The data plane DTLS session is also
shut down, and all resources released, 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 is an invalid state transition for the AC.
Calhoun, et al. Standards Track [Page 30]
RFC 5415 CAPWAP Protocol Specification March 2009
DTLS Teardown to Sulking (u): This transition occurs when repeated
attempts to setup the DTLS connection have failed.
WTP: The WTP enters this state when the FailedDTLSSessionCount or
the FailedDTLSAuthFailCount counter reaches the value of the
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: This is an invalid state transition for the AC.
DTLS Teardown to Dead (w): This transition occurs when the DTLS
session has been shut down.
WTP: This is an invalid state transition for the WTP.
AC: This state transition occurs when the AC has successfully
cleaned up all resources associated with the control plane
DTLS session , or if the DTLSSessionDelete timer (see
Section 4.7.6) expires. The data plane DTLS session is also
shut down, and all resources released, if a DTLS session was
established for the data plane. Any timers set for the
current instance of the state machine are also cleared. The
AC's Service thread is terminated.
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 APIs:
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.
Calhoun, et al. Standards Track [Page 31]
RFC 5415 CAPWAP Protocol Specification March 2009
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. See Section 3.5 for more
information on MTU Discovery. 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
below occurs, the target CAPWAP state shown in Figure 4 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 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.
Calhoun, et al. Standards Track [Page 32]
RFC 5415 CAPWAP Protocol Specification March 2009
o DTLSAuthenticateFail is sent when DTLS session establishment has
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.
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 entities; 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 [RFC4347].
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 shown in Figure 5. (NOTE: this example
uses certificates, but pre-shared keys are also supported.)
Calhoun, et al. Standards Track [Page 33]
RFC 5415 CAPWAP Protocol Specification March 2009
============ ============
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
Figure 5: DTLS Handshake
DTLS, as specified, provides its own retransmit timers with an
exponential back-off. [RFC4347] does not specify how long
retransmissions should continue. Consequently, timing out incomplete
DTLS handshakes is entirely the responsibility of the CAPWAP module.
The DTLS implementation used by CAPWAP MUST support TLS Session
Resumption. Session resumption is typically used to establish the
DTLS session used for the data channel. Since the data channel uses
different port numbers than the control channel, the DTLS
implementation on the WTP MUST provide an interface that allows the
CAPWAP module to request session resumption despite the use of the
different port numbers (TLS implementations usually attempt session
resumption only when connecting to the same IP address and port
number). Note that session resumption is not guaranteed to occur,
and a full DTLS handshake may occur instead.
Calhoun, et al. Standards Track [Page 34]
RFC 5415 CAPWAP Protocol Specification March 2009
The DTLS implementation used by CAPWAP MUST use replay detection, per
Section 3.3 of [RFC4347]. Since the CAPWAP protocol handles
retransmissions by re-encrypting lost frames, any duplicate DTLS
frames are either unintentional or malicious and should be silently
discarded.
2.4.2. DTLS Session Establishment
The WTP, either through the Discovery process or through pre-
configuration, determines to which AC to connect. 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
WTP sets the WaitDTLS timer. Upon invoking the DTLSStart or
DTLSListen commands, the WTP and AC, respectively, set 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 or WTP does not respond to any DTLS handshake messages sent
by its peer, the DTLS specification calls for the message to be
retransmitted. Note that during the handshake, when both the AC and
the WTP are expecting additional handshake messages, they both
retransmit if an expected message has not been received (note that
retransmissions for CAPWAP Control messages work differently: all
CAPWAP Control messages are either requests or responses, and the
peer who sent the request is responsible for retransmissions).
If the WTP or the AC does not receive an expected DTLS handshake
message despite of retransmissions, the WaitDTLS timer will
eventually expire, and the session will be terminated. This can
happen if communication between the peers has completely failed, or
if one of the peers sent a DTLS Alert message that was lost in
transit (DTLS does not retransmit Alert messages).
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, and SHOULD treat the message as though no cookie were
present.
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
Calhoun, et al. Standards Track [Page 35]
RFC 5415 CAPWAP Protocol Specification March 2009
errors, including overlapping and/or lost fragments. The DTLS
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 value provided to the DTLS stack is the result of the MTU
Discovery process, which is described in Section 3.5. The DTLS
component returns this notification to the CAPWAP component whenever
a transmission request will result in a packet that exceeds the MTU.
2.4.4. DTLS Endpoint Authentication and Authorization
DTLS supports endpoint authentication with certificates or pre-shared
keys. The TLS algorithm suites for each endpoint authentication
method are described below.
2.4.4.1. Authenticating with Certificates
CAPWAP implementations only use cipher suites that are recommended
for use with DTLS, see [DTLS-DESIGN]. At present, the following
algorithms MUST be supported when using certificates for CAPWAP
authentication:
o TLS_RSA_WITH_AES_128_CBC_SHA [RFC5246]
Calhoun, et al. Standards Track [Page 36]
RFC 5415 CAPWAP Protocol Specification March 2009
The following algorithms SHOULD be supported when using certificates:
o TLS_DHE_RSA_WITH_AES_128_CBC_SHA [RFC5246]
The following algorithms MAY be supported when using certificates:
o TLS_RSA_WITH_AES_256_CBC_SHA [RFC5246]
o TLS_DHE_RSA_WITH_AES_256_CBC_SHA [RFC5246]
Additional ciphers MAY be defined in subsequent CAPWAP
specifications.
2.4.4.2. Authenticating with Pre-Shared 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 pre-shared keys are defined
[RFC4279], and we focus on the following two:
o Pre-Shared Key (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 algorithm 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
pre-shared keys:
o TLS_PSK_WITH_AES_128_CBC_SHA [RFC5246]
o TLS_DHE_PSK_WITH_AES_128_CBC_SHA [RFC5246]
The following algorithms MAY be supported when using pre-shared keys:
o TLS_PSK_WITH_AES_256_CBC_SHA [RFC5246]
o TLS_DHE_PSK_WITH_AES_256_CBC_SHA [RFC5246]
Additional ciphers MAY be defined in following CAPWAP specifications.
Calhoun, et al. Standards Track [Page 37]
RFC 5415 CAPWAP Protocol Specification March 2009
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
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 [RFC5280].
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 described in [RFC5280] and [ISO.9834-1.1993] and 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 }
All capwap devices MUST support the ExtendedKeyUsage certificate
extension if it is present in a certificate. If the extension is
present, then the certificate MUST have either the id-kp-capwapAC or
the id-kp-anyExtendedKeyUsage keyPurposeID to act as an AC.
Similarly, if the extension is present, a device MUST have the id-kp-
capwapWTP or id-kp-anyExtendedKeyUsage keyPurposeID to act as a WTP.
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.
For instance, an AC SHOULD NOT accept a connection request from
another AC, and therefore MUST verify that the id-kp-capwapWTP EKU is
present in the certificate.
CAPWAP implementations MUST support certificates where the common
name (CN) for both the WTP and AC is the MAC address of that device.
Calhoun, et al. Standards Track [Page 38]
RFC 5415 CAPWAP Protocol Specification March 2009
The MAC address MUST be encoded in the PrintableString format, using
the well-recognized MAC address format of 01:23:45:67:89:ab. The CN
field MAY contain either of the EUI-48 [EUI-48] or EUI-64 [EUI-64]
MAC Address formats. This seemingly unconventional use of the CN
field is consistent with other standards that rely on device
certificates that are provisioned during the manufacturing process,
such as Packet Cable [PacketCable], Cable Labs [CableLabs], and WiMAX
[WiMAX]. See Section 12.8 for more information on the use of the MAC
address in the CN field.
ACs and WTPs MUST authorize (e.g., through access control lists)
certificates of devices to which they are connecting, e.g., based on
the issuer, MAC address, or organizational information specified in
the certificate. The identities specified in the certificates bind a
particular DTLS session to a specific pair of mutually authenticated
and authorized MAC addresses. The particulars of authorization
filter construction are implementation details which are, for the
most part, not within the scope of this specification. However, at
minimum, all devices MUST verify that the appropriate EKU bit is set
according to the role of the peer device (AC versus WTP), and that
the issuer of the certificate is appropriate for the domain in
question.
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, et al. Standards Track [Page 39]
RFC 5415 CAPWAP Protocol Specification March 2009
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 [RFC3828] transport protocols. When run over IPv4,
UDP is used for the CAPWAP Control and Data channels.
When run over IPv6, the CAPWAP Control channel always uses UDP, while
the CAPWAP Data channel may use either UDP or UDP-Lite. UDP-Lite is
the default transport protocol for the CAPWAP Data channel. However,
if a middlebox or IPv4 to IPv6 gateway has been discovered, UDP is
used for the CAPWAP Data channel.
This section describes how the CAPWAP protocol is carried over IP and
UDP/UDP-Lite transport protocols. The CAPWAP Transport Protocol
message element, Section 4.6.14, describes the rules to use in
determining which transport protocol is to be used.
In order for CAPWAP to be compatible with potential middleboxes in
the network, CAPWAP implementations MUST send return traffic from the
same port on which they received traffic from a given peer. Further,
any unsolicited requests generated by a CAPWAP node MUST be sent on
the same port.
3.1. UDP Transport
One of the CAPWAP protocol requirements is to allow a WTP to reside
behind a middlebox, 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. When CAPWAP is run over IPv4, 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 5246. 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 5247. If an AC permits the
administrator to change the CAPWAP control port, the CAPWAP data port
MUST be the next consecutive port number. The CAPWAP data port at
the WTP can be any port selected by the WTP.
Calhoun, et al. Standards Track [Page 40]
RFC 5415 CAPWAP Protocol Specification March 2009
3.2. UDP-Lite Transport
When CAPWAP is run over IPv6, UDP-Lite is the default transport
protocol, which reduces the checksum processing required for each
packet (compared to the use of UDP over IPv6 [RFC2460]). When UDP-
Lite is used, the checksum field MUST have a coverage of 8 [RFC3828].
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 choose 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
(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),
the well-known CAPWAP multicast address (224.0.1.140), or to the
unicast IP address of the AC. For IPv6 networks, since broadcast
does not exist, the use of "All ACs multicast address" (FF0X:0:0:0:0:
0:0:18C) 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. ACs, on the other hand, MUST support
broadcast, multicast, and unicast discovery.
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:
Calhoun, et al. Standards Track [Page 41]
RFC 5415 CAPWAP Protocol Specification March 2009
DHCP: See [RFC5417] for more information on the use of DHCP to
discover AC IP addresses.
DNS: The WTP MAY support use of DNS Service Records (SRVs) [RFC2782]
to discover the AC address(es). In this case, the WTP first
obtains (e.g., from local configuration) the correct domain name
suffix (e.g., "example.com") and performs an SRV lookup with
Service name "capwap-control" and Proto "udp". Thus, the name
resolved in DNS would be, e.g., "_capwap-
control._udp.example.com". Note that the SRV record MAY specify a
non-default port number for the control channel; the port number
for the data channel is the next port number (control channel port
+ 1).
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 Priority 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
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 "middlebox"
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 topology including firewall, NAT, and middlebox
devices.
Calhoun, et al. Standards Track [Page 42]
RFC 5415 CAPWAP Protocol Specification March 2009
It is important to note that the fragmentation mechanism employed by
CAPWAP has known limitations and deficiencies, which are similar to
those described in [RFC4963]. The limited size of the Fragment ID
field (see Section 4.3) can cause wrapping of the field, and hence
cause fragments from different datagrams to be incorrectly spliced
together (known as "mis-associated"). For example, a 100Mpbs link
with an MTU of 1500 (causing fragmentation at 1450 bytes) would cause
the Fragment ID field wrap in 8 seconds. Consequently, CAPWAP
implementers are warned to properly size their buffers for reassembly
purposes based on the expected wireless technology throughput.
CAPWAP implementations SHOULD perform MTU Discovery (see
Section 3.5), which can avoid the need for fragmentation. At the
time of writing of this specification, most enterprise switching and
routing infrastructure were capable of supporting "mini-jumbo" frames
(1800 bytes), which eliminates the need for fragmentation (assuming
the station's MTU is 1500 bytes). The need for fragmentation
typically continues to exist when the WTP communicates with the AC
over a Wide Area Network (WAN). Therefore, future versions of the
CAPWAP protocol SHOULD consider either increasing the size of the
Fragment ID field or providing alternative extensions.
3.5. MTU Discovery
Once a WTP has discovered the AC with which it wishes to establish a
CAPWAP session, it SHOULD perform a Path MTU (PMTU) discovery. One
recommendation for performing PMTU discovery is to have the WTP
transmit Discovery Request (see Section 5.1) messages, and include
the MTU Discovery Padding message element (see Section 4.6.32). The
actual procedures used for PMTU discovery are described in [RFC1191]
for IPv4; for IPv6, [RFC1981] SHOULD be used. Alternatively,
implementers MAY use the procedures defined in [RFC4821]. The WTP
SHOULD also periodically re-evaluate the PMTU using the guidelines
provided in these two RFCs, using the Primary Discovery Request (see
Section 5.3) along with the MTU Discovery Padding message element
(see Section 4.6.32). When the MTU is initially known, or updated in
the case where an existing session already exists, the discovered
PMTU is used to configure the DTLS component (see Section 2.3.2.1),
while non-DTLS frames need to be fragmented to fit the MTU, defined
in Section 3.4.
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
Calhoun, et al. Standards Track [Page 43]
RFC 5415 CAPWAP Protocol Specification March 2009
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, et al. Standards Track [Page 44]
RFC 5415 CAPWAP Protocol Specification March 2009
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 [RFC4347].
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 signaling 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, et al. Standards Track [Page 45]
RFC 5415 CAPWAP Protocol Specification March 2009
including the Maximum Message Length message element, see
Section 4.6.31, 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 preamble is to avoid needing to perform byte
comparisons in order to guess whether or not the frame is DTLS
encrypted. 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 that contains the version of CAPWAP used in
this packet. The value for this specification is zero (0).
Type: A 4-bit field that 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 include 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 [RFC4347] always immediately follows this header. The
format of the CAPWAP DTLS Header is as follows:
Calhoun, et al. Standards Track [Page 46]
RFC 5415 CAPWAP Protocol Specification March 2009
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 that is not encrypted or authenticated.
Calhoun, et al. Standards Track [Page 47]
RFC 5415 CAPWAP Protocol Specification March 2009
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 that contains the Radio ID number for this
packet, whose value is between one (1) and 31. Given that MAC
Addresses are not necessarily unique across physical radios in a
WTP, the Radio Identifier (RID) field is used to indicate with
which physical radio the message is associated.
WBID: A 5-bit field that is the wireless binding identifier. The
identifier will indicate the type of wireless packet associated
with the radio. The following values are defined:
0 - Reserved
1 - IEEE 802.11
2 - Reserved
3 - EPCGlobal [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 one (1), the packet
is the last fragment. When this bit is (zero) 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 Radio MAC '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, et al. Standards Track [Page 48]
RFC 5415 CAPWAP Protocol Specification March 2009
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 each direction 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 that 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. Because the native wireless frame
format to IEEE 802.3 format causes the MAC address of the WTP's
radio to be lost, this field allows the address to be communicated
to the AC. 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.
Calhoun, et al. Standards Track [Page 49]
RFC 5415 CAPWAP Protocol Specification March 2009
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: The length of the MAC address field. The formats and
lengths specified in [EUI-48] and [EUI-64] are supported.
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 WBID field in the CAPWAP Header is used to
identify the format of the Wireless-Specific Information optional
field. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: The 8-bit field contains the length of the data field,
with a maximum size of 255.
Data: Wireless-specific information, defined by the wireless-
specific binding specified in the CAPWAP Header's WBID field.
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.
Calhoun, et al. Standards Track [Page 50]
RFC 5415 CAPWAP Protocol Specification March 2009
Both CAPWAP Data messages are transmitted on the CAPWAP Data channel.
4.4.1. CAPWAP Data Channel Keep-Alive
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 (see Section 4.7.2).
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 16-bit Length field indicates the
number of bytes following the CAPWAP Header, with a maximum size
of 65535.
Message Element[0..N]: The message element(s) carry the information
pertinent to each of the CAPWAP Data Channel Keep-Alive message.
The following message elements MUST be present in this CAPWAP
message:
Session ID, see Section 4.6.37.
Calhoun, et al. Standards Track [Page 51]
RFC 5415 CAPWAP Protocol Specification March 2009
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
encapsulation requires that for 802.11 frames, the 802.11
*Integration* 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.
For 802.3 payload frames, the 802.3 frame is encapsulated (excluding
the IEEE 802.3 Preamble, Start Frame Delimiter (SFD), and Frame Check
Sequence (FCS) fields). If the encapsulated frame would exceed the
transport layer's MTU, the sender is responsible for the
fragmentation of the frame, as specified in Section 3.4. The CAPWAP
protocol can support IEEE 802.3 frames whose length is defined in the
IEEE 802.3as specification [FRAME-EXT].
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
SHOULD be initiated using the TLS session resumption feature
[RFC5246].
The AC DTLS implementation MUST NOT initiate a data channel session
for a DTLS session for which there is no active control channel
session.
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.
Calhoun, et al. Standards Track [Page 52]
RFC 5415 CAPWAP Protocol Specification March 2009
Join: CAPWAP Join messages are used by a WTP to request service from
an AC, and for the AC to respond to the WTP.
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 that 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, et al. Standards Track [Page 53]
RFC 5415 CAPWAP Protocol Specification March 2009
4.5.1.1. Message Type
The Message Type field identifies the function of the CAPWAP Control
message. To provide extensibility, the Message Type field is
comprised of an IANA Enterprise Number [RFC3232] and an enterprise-
specific message type number. The first three octets contain the
IANA Enterprise Number in network byte order, with zero used for
CAPWAP base protocol (this specification) defined 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.
Calhoun, et al. Standards Track [Page 54]
RFC 5415 CAPWAP Protocol Specification March 2009
The valid values for CAPWAP Control Message Types are specified in
the table below:
CAPWAP Control Message Message Type
Value
Discovery Request 1
Discovery Response 2
Join Request 3
Join Response 4
Configuration Status Request 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, et al. Standards Track [Page 55]
RFC 5415 CAPWAP Protocol Specification March 2009
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. Quality of Service
The CAPWAP base protocol does not provide any Quality of Service
(QoS) recommendations for use with the CAPWAP Data messages. Any
wireless-specific CAPWAP binding specification that has QoS
requirements MUST define the application of QoS to the CAPWAP Data
messages.
The IP header also includes the Explicit Congestion Notification
(ECN) bits [RFC3168]. Section 9.1.1 of [RFC3168] describes two
levels of ECN functionality: full functionality and limited
functionality. CAPWAP ACs and WTPs SHALL implement the limited
functionality and are RECOMMENDED to implement the full functionality
described in [RFC3168].
Calhoun, et al. Standards Track [Page 56]
RFC 5415 CAPWAP Protocol Specification March 2009
4.5.2.1. Applying QoS to CAPWAP Control Message
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 QoS-enabled CAPWAP
device SHOULD use the following values:
802.1Q: The priority tag of 7 SHOULD be used.
DSCP: The CS6 per-hop behavior Service Class SHOULD be used, which
is described in [RFC2474]).
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
Response message is not received, the original Request message is
retransmitted.
Implementations MUST keep track of the sequence number of the last
received Request message, and MUST cache the corresponding Response
message. If a retransmission with the same sequence number is
received, the cached Response message MUST be retransmitted without
re-processing the Request. If an older Request message is received,
meaning one where the sequence number is smaller, it MUST be ignored.
A newer Request message, meaning one whose sequence number is larger,
is processed as usual.
Note: A sequence number is considered "smaller" when s1 is smaller
than s2 modulo 256 if and only if (s1<s2 and (s2-s1)<128) or
(s1>s2 and (s1-s2)>128).
Both the WTP and the AC can only have a single request outstanding at
any given time. Retransmitted Request messages MUST NOT be altered
by the sender.
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
Calhoun, et al. Standards Track [Page 57]
RFC 5415 CAPWAP Protocol Specification March 2009
subsequent time the same Request message is retransmitted, up to
MaxRetransmit but no more than half the EchoInterval timer (see
Section 4.7.7). Response messages are not subject to these timers.
If the sender stops retransmitting a Request message before reaching
MaxRetransmit retransmissions (which leads to transition to DTLS
Teardown, as described in Section 2.3.1), it cannot know whether the
recipient received and processed the Request or not. In most
situations, the sender SHOULD NOT do this, and instead continue
retransmitting until a Response message is received, or transition to
DTLS Teardown occurs. However, if the sender does decide to continue
the connection with a new or modified Request message, the new
message MUST have a new sequence number, and be treated as a new
Request message by the receiver. Note that there is a high chance
that both the WTP and the AC's sequence numbers will become out of
sync.
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 that 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's 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.
Calhoun, et al. Standards Track [Page 58]
RFC 5415 CAPWAP Protocol Specification March 2009
Unless otherwise specified, a control message that lists a set of
supported (or expected) message elements MUST NOT expect the message
elements to be in any specific order. The sender MAY include the
message elements in any order. Unless otherwise noted, one message
element of each type is present in a given control message.
Unless otherwise specified, any configuration information sent by the
AC to the WTP MAY be saved to non-volatile storage (see Section 8.1)
for more information).
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. The value of zero (0) is reserved and MUST NOT be used. The
rest of the Type field values are allocated as follows:
Usage Type Values
CAPWAP Protocol Message Elements 1 - 1023
IEEE 802.11 Message Elements 1024 - 2047
Reserved for Future Use 2048 - 3071
EPCGlobal Message Elements 3072 - 4095
Reserved for Future Use 4096 - 65535
The table below lists the CAPWAP protocol Message Elements and their
Type values.
Calhoun, et al. Standards Track [Page 59]
RFC 5415 CAPWAP Protocol Specification March 2009
CAPWAP Message Element Type Value
AC Descriptor 1
AC IPv4 List 2
AC IPv6 List 3
AC Name 4
AC Name with Priority 5
AC Timestamp 6
Add MAC ACL Entry 7
Add Station 8
Reserved 9
CAPWAP Control IPV4 Address 10
CAPWAP Control IPV6 Address 11
CAPWAP Local IPV4 Address 30
CAPWAP Local IPV6 Address 50
CAPWAP Timers 12
CAPWAP Transport Protocol 51
Data Transfer Data 13
Data Transfer Mode 14
Decryption Error Report 15
Decryption Error Report Period 16
Delete MAC ACL Entry 17
Delete Station 18
Reserved 19
Discovery Type 20
Duplicate IPv4 Address 21
Duplicate IPv6 Address 22
ECN Support 53
Idle Timeout 23
Image Data 24
Image Identifier 25
Image Information 26
Initiate Download 27
Location Data 28
Maximum Message Length 29
MTU Discovery Padding 52
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
Reserved 42
Calhoun, et al. Standards Track [Page 60]
RFC 5415 CAPWAP Protocol Specification March 2009
Reserved 43
WTP MAC Type 44
WTP Name 45
Unused/Reserved 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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC Information Sub-Element...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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: An 8-bit mask specifying the authentication credential
type supported by the AC (see Section 2.4.4). The field has the
following format:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Reserved |S|X|R|
+-+-+-+-+-+-+-+-+
Calhoun, et al. Standards Track [Page 61]
RFC 5415 CAPWAP Protocol Specification March 2009
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.
S: The AC supports the pre-shared secret authentication, as
described in Section 12.6.
X: The AC supports X.509 Certificate authentication, as
described in Section 12.7.
R: A reserved bit 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.
R-MAC Field: The AC supports the optional Radio MAC Address field
in the CAPWAP transport header (see Section 4.3). The following
enumerated values are supported:
0 - Reserved
1 - Supported
2 - Not Supported
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 field
has the following format:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Reserved |D|C|R|
+-+-+-+-+-+-+-+-+
Calhoun, et al. Standards Track [Page 62]
RFC 5415 CAPWAP Protocol Specification March 2009
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.
D: DTLS-Enabled Data Channel Supported
C: Clear Text Data Channel Supported
R: A reserved bit 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.
AC Information Sub-Element: The AC Descriptor message element
contains multiple AC Information sub-elements, and defines two
sub-types, each of which MUST be present. The AC Information sub-
element 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC Information Vendor Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC Information Type | AC Information Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC Information Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AC Information Vendor Identifier: A 32-bit value containing the
IANA-assigned "Structure of Management Information (SMI)
Network Management Private Enterprise Codes".
AC Information Type: Vendor-specific encoding of AC information
in the UTF-8 format [RFC3629]. The following enumerated values
are supported. Both the Hardware and Software Version sub-
elements MUST be included in the AC Descriptor message element.
The values listed below are used in conjunction with the AC
Information Vendor Identifier field, whose value MUST be set to
zero (0). This field, combined with the AC Information Vendor
Identifier set to a non-zero (0) value, allows vendors to use a
private namespace.
Calhoun, et al. Standards Track [Page 63]
RFC 5415 CAPWAP Protocol Specification March 2009
4 - Hardware Version: The AC's hardware version number.
5 - Software Version: The AC's Software (firmware) version
number.
AC Information Length: Length of vendor-specific encoding of AC
information, with a maximum size of 1024.
AC Information Data: 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[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 2 for AC IPv4 List
Length: >= 4
AC IP Address: An array of 32-bit integers containing AC IPv4
Addresses, containing no more than 1024 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[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Calhoun, et al. Standards Track [Page 64]
RFC 5415 CAPWAP Protocol Specification March 2009
Type: 3 for AC IPV6 List
Length: >= 16
AC IP Address: An array of 128-bit integers containing AC IPv6
Addresses, containing no more than 1024 addresses.
4.6.4. AC Name
The AC Name message element contains an UTF-8 [RFC3629]
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 ...
+-+-+-+-+-+-+-+-+
Type: 4 for AC Name
Length: >= 1
Name: A variable-length UTF-8 encoded string [RFC3629] containing
the AC's name, whose maximum size MUST NOT exceed 512 bytes.
4.6.5. AC Name with Priority
The AC Name with Priority 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.
The WTP also uses this message element to send its configuration to
the AC.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority | AC Name...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 5 for AC Name with Priority
Length: >= 2
Priority: A value between 1 and 255 specifying the priority order
of the preferred AC. For instance, the value of one (1) is used
to set the primary AC, the value of two (2) is used to set the
secondary, etc.
Calhoun, et al. Standards Track [Page 65]
RFC 5415 CAPWAP Protocol Specification March 2009
AC Name: A variable-length UTF-8 encoded string [RFC3629]
containing the AC name, whose maximum size MUST NOT exceed 512
bytes.
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 [RFC1305]. Only the most significant 32 bits of
the NTP time are included in this field.
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. The MAC ACL
table on the WTP is cleared every time the WTP establishes a new
session with an AC.
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 Length/MAC Address
fields in the array. This value MUST NOT exceed 255.
Calhoun, et al. Standards Track [Page 66]
RFC 5415 CAPWAP Protocol Specification March 2009
Length: The length of the MAC Address field. The formats and
lengths specified in [EUI-48] and [EUI-64] are supported.
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...
+-+-+-+-+-+-+-+-+
Type: 8 for Add Station
Length: >= 8
Radio ID: An 8-bit value representing the radio, whose value is
between one (1) and 31.
Length: The length of the MAC Address field. The formats and
lengths specified in [EUI-48] and [EUI-64] are supported.
MAC Address: The station's MAC address.
VLAN Name: An optional variable-length UTF-8 encoded string
[RFC3629], with a maximum length of 512 octets, 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.
Calhoun, et al. Standards Track [Page 67]
RFC 5415 CAPWAP Protocol Specification March 2009
4.6.9. 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 (see Section 6.1).
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,
with a maximum value of 65535.
4.6.10. 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 (see Section 6.1).
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Calhoun, et al. Standards Track [Page 68]
RFC 5415 CAPWAP Protocol Specification March 2009
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,
with a maximum value of 65535.
4.6.11. CAPWAP Local IPv4 Address
The CAPWAP Local IPv4 Address message element is sent by either the
WTP, in the Join Request, or by the AC, in the Join Response. The
CAPWAP Local IPv4 Address message element is used to communicate the
IP Address of the transmitter. The receiver uses this to determine
whether a middlebox exists between the two peers, by comparing the
source IP address of the packet against the value of the message
element.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 30 for CAPWAP Local IPv4 Address
Length: 4
IP Address: The IP address of the sender.
4.6.12. CAPWAP Local IPv6 Address
The CAPWAP Local IPv6 Address message element is sent by either the
WTP, in the Join Request, or by the AC, in the Join Response. The
CAPWAP Local IPv6 Address message element is used to communicate the
IP Address of the transmitter. The receiver uses this to determine
whether a middlebox exists between the two peers, by comparing the
source IP address of the packet against the value of the message
element.
Calhoun, et al. Standards Track [Page 69]
RFC 5415 CAPWAP Protocol Specification March 2009
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 50 for CAPWAP Local IPv6 Address
Length: 16
IP Address: The IP address of the sender.
4.6.13. 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. This value is used to
configure the MaxDiscoveryInterval timer (see Section 4.7.10).
Echo Request: The number of seconds between WTP Echo Request CAPWAP
messages. This value is used to configure the EchoInterval timer
(see Section 4.7.7). The AC sets its EchoInterval timer to this
value, plus the maximum retransmission time as described in
Section 4.5.3.
Calhoun, et al. Standards Track [Page 70]
RFC 5415 CAPWAP Protocol Specification March 2009
4.6.14. CAPWAP Transport Protocol
When CAPWAP is run over IPv6, the UDP-Lite or UDP transports MAY be
used (see Section 3). The CAPWAP IPv6 Transport Protocol message
element is used by either the WTP or the AC to signal which transport
protocol is to be used for the CAPWAP data channel.
Upon receiving the Join Request, the AC MAY set the CAPWAP Transport
Protocol to UDP-Lite in the Join Response message if the CAPWAP
message was received over IPv6, and the CAPWAP Local IPv6 Address
message element (see Section 4.6.12) is present and no middlebox was
detected (see Section 11).
Upon receiving the Join Response, the WTP MAY set the CAPWAP
Transport Protocol to UDP-Lite in the Configuration Status Request or
Image Data Request message if the AC advertised support for UDP-Lite,
the message was received over IPv6, the CAPWAP Local IPv6 Address
message element (see Section 4.6.12) and no middlebox was detected
(see Section 11). Upon receiving either the Configuration Status
Request or the Image Data Request, the AC MUST observe the preference
indicated by the WTP in the CAPWAP Transport Protocol, as long as it
is consistent with what the AC advertised in the Join Response.
For any other condition, the CAPWAP Transport Protocol MUST be set to
UDP.
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Transport |
+-+-+-+-+-+-+-+-+
Type: 51 for CAPWAP Transport Protocol
Length: 1
Transport: The transport to use for the CAPWAP Data channel. The
following enumerated values are supported:
1 - UDP-Lite: The UDP-Lite transport protocol is to be used for
the CAPWAP Data channel. Note that this option MUST NOT be
used if the CAPWAP Control channel is being used over IPv4.
2 - UDP: The UDP transport protocol is to be used for the CAPWAP
Data channel.
Calhoun, et al. Standards Track [Page 71]
RFC 5415 CAPWAP Protocol Specification March 2009
4.6.15. 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Type | Data Mode | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ....
+-+-+-+-+-+-+-+-+
Type: 13 for Data Transfer Data
Length: >= 5
Data Type: An 8-bit value representing the transfer Data Type. The
following enumerated values are supported:
1 - Transfer data is included.
2 - Last Transfer Data Block is included (End of File (EOF)).
5 - An error occurred. Transfer is aborted.
Data Mode: An 8-bit value describing the type of information being
transmitted. The following enumerated values are supported:
0 - Reserved
1 - WTP Crash Data
2 - WTP Memory Dump
Data Length: Length of data field, with a maximum size of 65535.
Data: Data being transferred from the WTP to the AC, whose type is
identified via the Data Mode field.
Calhoun, et al. Standards Track [Page 72]
RFC 5415 CAPWAP Protocol Specification March 2009
4.6.16. 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 Mode |
+-+-+-+-+-+-+-+-+
Type: 14 for Data Transfer Mode
Length: 1
Data Mode: An 8-bit value describing the type of information being
requested. The following enumerated values are supported:
0 - Reserved
1 - WTP Crash Data
2 - WTP Memory Dump
4.6.17. 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, whose value is between one (1) and 31.
Num of Entries: The number of instances of the Length/MAC Address
fields in the array. This field MUST NOT exceed the value of 255.
Calhoun, et al. Standards Track [Page 73]
RFC 5415 CAPWAP Protocol Specification March 2009
Length: The length of the MAC Address field. The formats and
lengths specified in [EUI-48] and [EUI-64] are supported.
MAC Address: MAC address of the station that has caused decryption
errors.
4.6.18. 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, whose value is between one (1) and 31.
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.7.11.
4.6.19. 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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 17 for Delete MAC ACL Entry
Length: >= 8
Calhoun, et al. Standards Track [Page 74]
RFC 5415 CAPWAP Protocol Specification March 2009
Num of Entries: The number of instances of the Length/MAC Address
fields in the array. This field MUST NOT exceed the value of 255.
Length: The length of the MAC Address field. The formats and
lengths specified in [EUI-48] and [EUI-64] are supported.
MAC Address: An array of MAC addresses to delete from the ACL.
4.6.20. 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, whose value is
between one (1) and 31.
Length: The length of the MAC Address field. The formats and
lengths specified in [EUI-48] and [EUI-64] are supported.
MAC Address: The station's MAC address.
4.6.21. 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.
Calhoun, et al. Standards Track [Page 75]
RFC 5415 CAPWAP Protocol Specification March 2009
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 enumerated values are supported:
0 - Unknown
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.22. 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 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Length | MAC Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 21 for Duplicate IPv4 Address
Length: >= 12
IP Address: The IP address currently used by the WTP.
Calhoun, et al. Standards Track [Page 76]
RFC 5415 CAPWAP Protocol Specification March 2009
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. The formats and
lengths specified in [EUI-48] and [EUI-64] are supported.
MAC Address: The MAC address of the offending device.
4.6.23. 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.
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: 22 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. The formats and
lengths specified in [EUI-48] and [EUI-64] are supported.
MAC Address: The MAC address of the offending device.
Calhoun, et al. Standards Track [Page 77]
RFC 5415 CAPWAP Protocol Specification March 2009
4.6.24. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 23 for Idle Timeout
Length: 4
Timeout: The current Idle Timeout, in seconds, to be enforced by
the WTP. The default value for this message element is specified
in Section 4.7.8.
4.6.25. ECN Support
The ECN Support message element is sent by both the WTP and the AC to
indicate their support for the Explicit Congestion Notification (ECN)
bits, as defined in [RFC3168].
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| ECN Support |
+-+-+-+-+-+-+-+-+
Type: 53 for ECN Support
Length: 1
ECN Support: An 8-bit value representing the sender's support for
ECN, as defined in [RFC3168]. All CAPWAP Implementations MUST
support the Limited ECN Support mode. Full ECN Support is used if
both the WTP and AC advertise the capability for "Full and Limited
ECN" Support; otherwise, Limited ECN Support is used.
0 - Limited ECN Support
1 - Full and Limited ECN Support
Calhoun, et al. Standards Track [Page 78]
RFC 5415 CAPWAP Protocol Specification March 2009
4.6.26. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Type | Data ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 24 for Image Data
Length: >= 1
Data Type: An 8-bit value representing the image Data Type. The
following enumerated values are supported:
1 - Image data is included.
2 - Last Image Data Block is included (EOF).
5 - An error occurred. Transfer is aborted.
Data: The Image Data field contains up to 1024 characters, and its
length is inferred from this message element's length field. If
the block being sent is the last one, the Data Type field is set
to 2. The AC MAY opt to abort the data transfer by setting the
Data Type field to 5. When the Data Type field is 5, the Value
field has a zero length.
4.6.27. Image Identifier
The Image Identifier message element is sent by the AC to the WTP to
indicate the expected active software version that is to be run on
the WTP. The WTP sends the Image Identifier message element in order
to request a specific software version from the AC. The actual
download process is defined in Section 9.1. The value is a variable-
length UTF-8 encoded string [RFC3629], which is NOT zero terminated.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Calhoun, et al. Standards Track [Page 79]
RFC 5415 CAPWAP Protocol Specification March 2009
Type: 25 for Image Identifier
Length: >= 5
Vendor Identifier: A 32-bit value containing the IANA-assigned "SMI
Network Management Private Enterprise Codes".
Data: A variable-length UTF-8 encoded string [RFC3629] containing
the firmware identifier to be run on the WTP, whose length MUST
NOT exceed 1024 octets. The length of this field is inferred from
this message element's length field.
4.6.28. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 26 for Image Information
Length: 20
File Size: A 32-bit value containing the size of the file, in
bytes, that will be transferred by the AC to the WTP.
Hash: A 16-octet MD5 hash of the image using the procedures defined
in [RFC1321].
Calhoun, et al. Standards Track [Page 80]
RFC 5415 CAPWAP Protocol Specification March 2009
4.6.29. Initiate Download
The Initiate Download message element is used by the WTP to inform
the AC that the AC SHOULD initiate a firmware upgrade. The AC
subsequently transmits an Image Data Request message, which includes
the Image Data message element. This message element does not
contain any data.
Type: 27 for Initiate Download
Length: 0
4.6.30. Location Data
The Location Data message element is a variable-length byte UTF-8
encoded string [RFC3629] 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: >= 1
Location: A non-zero-terminated UTF-8 encoded string [RFC3629]
containing the WTP location, whose maximum size MUST NOT exceed
1024.
4.6.31. 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
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
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Calhoun, et al. Standards Track [Page 81]
RFC 5415 CAPWAP Protocol Specification March 2009
Type: 29 for Maximum Message Length
Length: 2
Maximum Message Length A 16-bit unsigned integer indicating the
maximum message length.
4.6.32. 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: 52 for MTU Discovery Padding
Length: Variable
Pad: A variable-length pad, filled with the value 0xFF.
4.6.33. 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
the AC has the WTP radio current administrative state settings. The
message element contains the following fields:
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
Calhoun, et al. Standards Track [Page 82]
RFC 5415 CAPWAP Protocol Specification March 2009
Radio ID: An 8-bit value representing the radio to configure, whose
value is between one (1) and 31. 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 enumerated values are
supported:
0 - Reserved
1 - Enabled
2 - Disabled
4.6.34. 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
Radio ID: The Radio Identifier refers to an interface index on the
WTP, whose value is between one (1) and 31. 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.
The following enumerated values are supported:
Calhoun, et al. Standards Track [Page 83]
RFC 5415 CAPWAP Protocol Specification March 2009
0 - Reserved
1 - Enabled
2 - Disabled
Cause: When a radio is inoperable, the cause field contains the
reason the radio is out of service. The following enumerated
values are supported:
0 - Normal
1 - Radio Failure
2 - Software Failure
3 - Administratively Set
4.6.35. 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 enumerated values are defined:
0 Success
1 Failure (AC List Message Element MUST Be Present)
2 Success (NAT Detected)
3 Join Failure (Unspecified)
4 Join Failure (Resource Depletion)
5 Join Failure (Unknown Source)
Calhoun, et al. Standards Track [Page 84]
RFC 5415 CAPWAP Protocol Specification March 2009
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
22 Data Transfer Error (No Information to Transfer)
4.6.36. 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, et al. Standards Track [Page 85]
RFC 5415 CAPWAP Protocol Specification March 2009
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason | Length | Message Element...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 34 for Returned Message Element
Length: >= 6
Reason: The reason the configuration in the offending message
element could not be applied by the WTP. The following enumerated
values are supported:
0 - Reserved
1 - Unknown Message Element
2 - Unsupported Message Element
3 - Unknown Message Element Value
4 - Unsupported Message Element Value
Length: The length of the Message Element field, which MUST NOT
exceed 255 octets.
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.37. Session ID
The Session ID message element value contains a randomly generated
unsigned 128-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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Calhoun, et al. Standards Track [Page 86]
RFC 5415 CAPWAP Protocol Specification March 2009
Type: 35 for Session ID
Length: 16
Session ID: A 128-bit unsigned integer used as a random session
identifier
4.6.38. 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.14.
4.6.39. Vendor Specific Payload
The Vendor Specific Payload message element is used to communicate
vendor-specific information between the WTP and the AC. The Vendor
Specific Payload message element MAY be present in any CAPWAP
message. The exchange of vendor-specific data between the MUST NOT
modify the behavior of the base CAPWAP protocol and state machine.
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 | Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 37 for Vendor Specific Payload
Length: >= 7
Calhoun, et al. Standards Track [Page 87]
RFC 5415 CAPWAP Protocol Specification March 2009
Vendor Identifier: A 32-bit value containing the IANA-assigned "SMI
Network Management Private Enterprise Codes" [RFC3232].
Element ID: A 16-bit Element Identifier that is managed by the
vendor.
Data: Variable-length vendor-specific information, whose contents
and format are proprietary and understood based on the Element ID
field. This field MUST NOT exceed 2048 octets.
4.6.40. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Board Data Sub-Element...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 38 for WTP Board Data
Length: >=14
Vendor Identifier: A 32-bit value containing the IANA-assigned "SMI
Network Management Private Enterprise Codes", identifying the WTP
hardware manufacturer. The Vendor Identifier field MUST NOT be
set to zero.
Board Data Sub-Element: The WTP Board Data message element contains
multiple Board Data sub-elements, some of which are mandatory and
some are optional, as described below. The Board Data Type values
are not extensible by vendors, and are therefore not coupled along
with the Vendor Identifier field. The Board Data sub-element 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Board Data Type | Board Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Board Data Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Calhoun, et al. Standards Track [Page 88]
RFC 5415 CAPWAP Protocol Specification March 2009
Board Data Type: The Board Data Type field identifies the data
being encoded. The CAPWAP protocol defines the following
values, and each of these types identify whether their presence
is mandatory or optional:
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 message element.
3 - Board Revision: A revision number of the board, which MAY be
included in the WTP Board Data message element.
4 - Base MAC Address: The WTP's Base MAC address, which MAY be
assigned to the primary Ethernet interface.
Board Data Length: The length of the data in the Board Data Value
field, whose length MUST NOT exceed 1024 octets.
Board Data Value: The data associated with the Board Data Type
field for this Board Data sub-element.
4.6.41. 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 | Num Encrypt |Encryp Sub-Elmt|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encryption Sub-Element | Descriptor Sub-Element...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 39 for WTP Descriptor
Length: >= 33
Calhoun, et al. Standards Track [Page 89]
RFC 5415 CAPWAP Protocol Specification March 2009
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.
Radios in use: An 8-bit value representing the number of radios in
use in the WTP.
Num Encrypt: The number of 3-byte Encryption sub-elements that
follow this field. The value of the Num Encrypt field MUST be
between one (1) and 255.
Encryption Sub-Element: The WTP Descriptor message element MUST
contain at least one Encryption sub-element. One sub-element is
present for each binding supported by the WTP. The Encryption
sub-element has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Resvd| WBID | Encryption Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Resvd: 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.
WBID: A 5-bit field that is the wireless binding identifier.
The identifier will indicate the type of wireless packet
associated with the radio. The WBIDs defined in this
specification can be found in Section 4.3.
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.
Descriptor Sub-Element: The WTP Descriptor message element contains
multiple Descriptor sub-elements, some of which are mandatory and
some are optional, as described below. The Descriptor sub-element
has the following format:
Calhoun, et al. Standards Track [Page 90]
RFC 5415 CAPWAP Protocol Specification March 2009
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Descriptor Vendor Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Descriptor Type | Descriptor Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Descriptor Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Descriptor Vendor Identifier: A 32-bit value containing the
IANA-assigned "SMI Network Management Private Enterprise
Codes".
Descriptor Type: The Descriptor Type field identifies the data
being encoded. The format of the data is vendor-specific
encoded in the UTF-8 format [RFC3629]. The CAPWAP protocol
defines the following values, and each of these types identify
whether their presence is mandatory or optional. The values
listed below are used in conjunction with the Descriptor Vendor
Identifier field, whose value MUST be set to zero (0). This
field, combined with the Descriptor Vendor Identifier set to a
non-zero (0) value, allows vendors to use a private namespace.
0 - Hardware Version: The WTP hardware version number MUST be
present.
1 - Active Software Version: The WTP running software version
number MUST be present.
2 - Boot Version: The WTP boot loader version number MUST be
present.
3 - Other Software Version: The WTP non-running software
(firmware) version number MAY be present. This type is
used to communicate alternate software versions that are
available on the WTP's non-volatile storage.
Descriptor Length: Length of the vendor-specific encoding of the
Descriptor Data field, whose length MUST NOT exceed 1024
octets.
Descriptor Data: Vendor-specific data of WTP information encoded
in the UTF-8 format [RFC3629].
Calhoun, et al. Standards Track [Page 91]
RFC 5415 CAPWAP Protocol Specification March 2009
4.6.42. 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 to which it is not currently connected.
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Mode |
+-+-+-+-+-+-+-+-+
Type: 40 for WTP Fallback
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.9. The following
enumerated values are supported:
0 - Reserved
1 - Enabled
2 - Disabled
4.6.43. WTP Frame Tunnel Mode
The WTP Frame Tunnel Mode message element allows the WTP to
communicate the tunneling modes of operation that 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
+-+-+-+-+-+-+-+-+
|Reservd|N|E|L|U|
+-+-+-+-+-+-+-+-+
Calhoun, et al. Standards Track [Page 92]
RFC 5415 CAPWAP Protocol Specification March 2009
Type: 41 for WTP Frame Tunnel Mode
Length: 1
Reservd: 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.
N: 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)
E: 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.
L: 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.
R: A reserved bit 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.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
Calhoun, et al. Standards Track [Page 93]
RFC 5415 CAPWAP Protocol Specification March 2009
Length: 1
MAC Type: The MAC mode of operation supported by the WTP. The
following enumerated values are supported:
0 - Local MAC: Local MAC is the default mode that MUST be
supported by all WTPs. When tunneling is enabled (see
Section 4.6.43), the encapsulated frames MUST be in the
802.3 format (see Section 4.4.2), unless a wireless
management or control frame which MAY be in its native
format. Any CAPWAP binding needs to specify the format of
management and control wireless frames.
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 [RFC3629]. The string is not zero terminated.
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-
| WTP Name ...
+-+-+-+-+-+-+-+-+-
Type: 45 for WTP Name
Length: >= 1
WTP Name: A non-zero-terminated UTF-8 encoded string [RFC3629]
containing the WTP name, whose maximum size MUST NOT exceed 512
bytes.
4.6.46. 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. These counters are never reset on the WTP, and
will therefore roll over to zero when the maximum size has been
reached.
Calhoun, et al. Standards Track [Page 94]
RFC 5415 CAPWAP Protocol Specification March 2009
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,
whose value is between one (1) and 31.
Last Failure Type: The last WTP failure. The following enumerated
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 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, et al. Standards Track [Page 95]
RFC 5415 CAPWAP Protocol Specification March 2009
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 that indicates the noise
floor of the radio receiver in units of dBm.
4.6.47. 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. These
counters are never reset on the WTP, and will therefore roll over to
zero when the maximum size has been reached.
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, et al. Standards Track [Page 96]
RFC 5415 CAPWAP Protocol Specification March 2009
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 enumerated 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.48. 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. IPv6 WTPs are expected to use dynamic addresses.
Calhoun, et al. Standards Track [Page 97]
RFC 5415 CAPWAP Protocol Specification March 2009
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.
Static: An 8-bit Boolean stating whether or not the WTP should use
a static IP address. 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 definition of 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.
Default: 25 seconds
4.7.2. DataChannelKeepAlive
The DataChannelKeepAlive timer is used by the WTP to determine the
next opportunity when it must transmit the Data Channel Keep-Alive,
in seconds.
Default: 30 seconds
Calhoun, et al. Standards Track [Page 98]
RFC 5415 CAPWAP Protocol Specification March 2009
4.7.3. 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
timer MUST be no less than 2*DataChannelKeepAlive seconds and no
greater that 240 seconds.
Default: 60
4.7.4. DataCheckTimer
The number of seconds the AC will wait for the Data Channel Keep
Alive, which is required by the CAPWAP state machine's Data Check
state. The AC resets the state machine if this timer expires prior
to transitioning to the next state.
Default: 30
4.7.5. 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.6. DTLSSessionDelete
The minimum time, in seconds, a WTP MUST wait for DTLS session
deletion.
Default: 5
4.7.7. EchoInterval
The minimum time, in seconds, between sending Echo Request messages
to the AC with which the WTP has joined.
Default: 30
4.7.8. IdleTimeout
The default Idle Timeout is 300 seconds.
Calhoun, et al. Standards Track [Page 99]
RFC 5415 CAPWAP Protocol Specification March 2009
4.7.9. ImageDataStartTimer
The number of seconds the WTP will wait for its peer to transmit the
Image Data Request.
Default: 30
4.7.10. 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.11. ReportInterval
The ReportInterval is used by the WTP to determine the interval the
WTP uses between sending the Decryption Error message elements to
inform the AC of decryption errors, in seconds.
The default Report Interval is 120 seconds.
4.7.12. RetransmitInterval
The minimum time, in seconds, in which a non-acknowledged CAPWAP
packet will be retransmitted.
Default: 3
4.7.13. 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
establish a 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 seconds
4.7.14. StatisticsTimer
The StatisticsTimer is used by the WTP to determine the interval the
WTP uses between the WTP Events Requests it transmits to the AC to
communicate its statistics, in seconds.
Default: 120 seconds
Calhoun, et al. Standards Track [Page 100]
RFC 5415 CAPWAP Protocol Specification March 2009
4.7.15. 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.16. WaitJoin
The maximum time, in seconds, an AC will wait after the DTLS session
has been established until it receives the Join Request from the WTP.
This timer MUST be greater than 20 seconds.
Default: 60
4.8. CAPWAP Protocol Variables
This section defines the CAPWAP protocol variables, which are used
for various protocol functions. Some of these variables are
configurable, while others are counters or have a fixed value. For
non-counter-related variables, default values are specified.
However, when a WTP's variable configuration is explicitly overridden
by an AC, the WTP MUST save the new value.
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.
Calhoun, et al. Standards Track [Page 101]
RFC 5415 CAPWAP Protocol Specification March 2009
4.8.5. MaxDiscoveries
The maximum number of Discovery Request messages that will be sent
after a WTP boots.
Default: 10
4.8.6. MaxFailedDTLSSessionRetry
The maximum number of failed DTLS session establishment attempts
before the CAPWAP device enters a silent period.
Default: 3
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. RetransmitCount
The number of retransmissions for a given CAPWAP packet. This is a
monotonically increasing counter.
4.8.9. 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.47.
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.43.
Calhoun, et al. Standards Track [Page 102]
RFC 5415 CAPWAP Protocol Specification March 2009
4.9.3. LastRebootReason
The reason why the WTP last rebooted, defined in Section 4.6.47.
4.9.4. MacType
For WTPs that support multiple MAC-Types, it is useful to save the
value configured by the AC. The MAC-Type 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.47.
4.9.7. 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.48).
4.9.8. WTPLinkFailureCount
The number of times the link to the AC has failed, see
Section 4.6.47.
4.9.9. WTPLocation
The WTP Location, defined in Section 4.6.30.
4.9.10. WTPName
The WTP Name, defined in Section 4.6.45.
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
Calhoun, et al. Standards Track [Page 103]
RFC 5415 CAPWAP Protocol Specification March 2009
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.
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. Once a Discovery
Response has been received, if the WTP decides to establish a session
with the responding AC, it SHOULD perform an MTU discovery, using the
process described in Section 3.5.
It is possible for the AC to receive a clear text 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,
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.21
Calhoun, et al. Standards Track [Page 104]
RFC 5415 CAPWAP Protocol Specification March 2009
o WTP Board Data, see Section 4.6.40
o WTP Descriptor, see Section 4.6.41
o WTP Frame Tunnel Mode, see Section 4.6.43
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).
The following message elements MAY be included in the Discovery
Request message:
o MTU Discovery Padding, see Section 4.6.32
o Vendor Specific Payload, see Section 4.6.39
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
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:
Calhoun, et al. Standards Track [Page 105]
RFC 5415 CAPWAP Protocol Specification March 2009
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.9
* CAPWAP Control IPv6 Address, see Section 4.6.10
The following message elements MAY be included in the Discovery
Response message:
o Vendor Specific Payload, see Section 4.6.39
5.3. Primary Discovery Request Message
The Primary Discovery Request message is sent by the WTP to:
o determine whether its preferred (or primary) AC is available, or
o perform a Path MTU Discovery (see Section 3.5).
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.
o Discovery Type, see Section 4.6.21
Calhoun, et al. Standards Track [Page 106]
RFC 5415 CAPWAP Protocol Specification March 2009
o WTP Board Data, see Section 4.6.40
o WTP Descriptor, see Section 4.6.41
o WTP Frame Tunnel Mode, see Section 4.6.43
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).
The following message elements MAY be included in the Primary
Discovery Request message:
o MTU Discovery Padding, see Section 4.6.32
o Vendor Specific Payload, see Section 4.6.39
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).
Calhoun, et al. Standards Track [Page 107]
RFC 5415 CAPWAP Protocol Specification March 2009
One of the following message elements MUST be included in the
Discovery Response Message:
o CAPWAP Control IPv4 Address, see Section 4.6.9
o CAPWAP Control IPv6 Address, see Section 4.6.10
The following message elements MAY be included in the Primary
Discovery Response message:
o Vendor Specific Payload, see Section 4.6.39
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 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. If the WTP is performing the optional AC Discovery process
(see Section 3.3), the join process occurs after the WTP has received
one or more Discovery Response messages. During the Discovery
process, an AC MAY return more than one CAPWAP Control IPv4 Address
or CAPWAP Control IPv6 Address message elements. When more than one
such message element is returned, the WTP SHOULD perform "load
balancing" by choosing the interface that is servicing the least
number of WTPs (known through the WTP Count field of the message
element). Note, however, that other load balancing algorithms are
also permitted. Once the WTP has determined its preferred AC, and
its associated interface, to which to connect, it establishes the
DTLS session, and transmits the Join Request over the secured control
channel. When an AC receives a Join Request message it responds with
a Join Response message.
Upon completion of the DTLS handshake and receipt of 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.
Calhoun, et al. Standards Track [Page 108]
RFC 5415 CAPWAP Protocol Specification March 2009
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.30
o WTP Board Data, see Section 4.6.40
o WTP Descriptor, see Section 4.6.41
o WTP Name, see Section 4.6.45
o Session ID, see Section 4.6.37
o WTP Frame Tunnel Mode, see Section 4.6.43
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).
o ECN Support, see Section 4.6.25
At least one of the following message element MUST be included in the
Join Request message.
o CAPWAP Local IPv4 Address, see Section 4.6.11
o CAPWAP Local IPv6 Address, see Section 4.6.12
The following message element MAY be included in the Join Request
message.
o CAPWAP Transport Protocol, see Section 4.6.14
o Maximum Message Length, see Section 4.6.31
Calhoun, et al. Standards Track [Page 109]
RFC 5415 CAPWAP Protocol Specification March 2009
o WTP Reboot Statistics, see Section 4.6.47
o Vendor Specific Payload, see Section 4.6.39
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) attempt to join a new AC.
If one of the WTP Radio Information message elements (see
Section 2.1) in the Join Request message requested support for a
CAPWAP binding that 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 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 MUST be included in the Join Response
message.
o Result Code, see Section 4.6.35
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).
Calhoun, et al. Standards Track [Page 110]
RFC 5415 CAPWAP Protocol Specification March 2009
o ECN Support, see Section 4.6.25
One of the following message elements MUST be included in the Join
Response Message:
o CAPWAP Control IPv4 Address, see Section 4.6.9
o CAPWAP Control IPv6 Address, see Section 4.6.10
One of the following message elements MUST be included in the Join
Response Message:
o CAPWAP Local IPv4 Address, see Section 4.6.11
o CAPWAP Local IPv6 Address, see Section 4.6.12
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 CAPWAP Transport Protocol, see Section 4.6.14
o Image Identifier, see Section 4.6.27
o Maximum Message Length, see Section 4.6.31
o Vendor Specific Payload, see Section 4.6.39
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.
Calhoun, et al. Standards Track [Page 111]
RFC 5415 CAPWAP Protocol Specification March 2009
Echo Request messages are sent periodically by a WTP in the Image
Data or 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 Echo Request message is sent by the WTP when in the Run state.
The AC does not transmit this message.
The following message elements MAY be included in the Echo Request
message:
o Vendor Specific Payload, see Section 4.6.39
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 Echo
Request message. After transmitting the Echo Response message, the
AC SHOULD reset its EchoInterval timer (see Section 4.7.7). 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 following message elements MAY be included in the Echo Response
message:
o Vendor Specific Payload, see Section 4.6.39
When a WTP receives an Echo Response message it initializes the
EchoInterval to the configured value.
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 can behave in one of two ways, which is
implementation specific:
Calhoun, et al. Standards Track [Page 112]
RFC 5415 CAPWAP Protocol Specification March 2009
1. The WTP retains no configuration and accepts the configuration
provided by the AC.
2. The WTP saves the configuration of parameters provided by the AC
that are non-default values into local non-volatile memory, and
are enforced during the WTP's power up initialization phase.
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 Request 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.
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
Calhoun, et al. Standards Track [Page 113]
RFC 5415 CAPWAP Protocol Specification March 2009
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 Request
The Configuration Status Request message is sent by a WTP to deliver
its current configuration to the AC.
The Configuration Status Request message carries binding-specific
message elements. Refer to the appropriate binding for the
definition of this structure.
When an AC receives a Configuration Status Request message, it acts
upon the content of the message and responds to the WTP with a
Configuration Status Response message.
The Configuration Status Request message includes multiple Radio
Administrative State message elements, one for the WTP, and one for
each radio in the WTP.
The Configuration Status Request 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 Request message.
o AC Name, see Section 4.6.4
o Radio Administrative State, see Section 4.6.33
o Statistics Timer, see Section 4.6.38
o WTP Reboot Statistics, see Section 4.6.47
The following message elements MAY be included in the Configuration
Status Request message.
o AC Name with Priority, see Section 4.6.5
o CAPWAP Transport Protocol, see Section 4.6.14
o WTP Static IP Address Information, see Section 4.6.48
o Vendor Specific Payload, see Section 4.6.39
Calhoun, et al. Standards Track [Page 114]
RFC 5415 CAPWAP Protocol Specification March 2009
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 Status 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 CAPWAP Timers, see Section 4.6.13
o Decryption Error Report Period, see Section 4.6.18
o Idle Timeout, see Section 4.6.24
o WTP Fallback, see Section 4.6.42
One or both of 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
The following message element MAY be included in the Configuration
Status Response message.
o WTP Static IP Address Information, see Section 4.6.48
o Vendor Specific Payload, see Section 4.6.39
Calhoun, et al. Standards Track [Page 115]
RFC 5415 CAPWAP Protocol Specification March 2009
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 message element (see
Section 4.6.27) 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 by transmitting an Image
Data Request (see Section 9.1.1) that includes the Initiate Download
message element (see Section 4.6.29).
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 Priority, see Section 4.6.5
o AC Timestamp, see Section 4.6.6
o Add MAC ACL Entry, see Section 4.6.7
o CAPWAP Timers, see Section 4.6.13
o Decryption Error Report Period, see Section 4.6.18
o Delete MAC ACL Entry, see Section 4.6.19
o Idle Timeout, see Section 4.6.24
o Location Data, see Section 4.6.30
o Radio Administrative State, see Section 4.6.33
o Statistics Timer, see Section 4.6.38
o WTP Fallback, see Section 4.6.42
o WTP Name, see Section 4.6.45
Calhoun, et al. Standards Track [Page 116]
RFC 5415 CAPWAP Protocol Specification March 2009
o WTP Static IP Address Information, see Section 4.6.48
o Image Identifier, see Section 4.6.27
o Vendor Specific Payload, see Section 4.6.39
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.35
The following message elements MAY be present in the Configuration
Update Response message.
o Radio Operational State, see Section 4.6.34
o Vendor Specific Payload, see Section 4.6.39
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
the WTP's radio operational state.
Calhoun, et al. Standards Track [Page 117]
RFC 5415 CAPWAP Protocol Specification March 2009
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 specific configuration
request, it indicates the failure by including one or more Returned
Message Element message elements (see Section 4.6.36).
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.34
o Result Code, see Section 4.6.35
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.36
o Vendor Specific Payload, see Section 4.6.39
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.
Calhoun, et al. Standards Track [Page 118]
RFC 5415 CAPWAP Protocol Specification March 2009
The following message element MAY be included in the Change State
Event Response message:
o Vendor Specific Payload, see Section 4.6.39
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 following message element MAY be included in the Clear
Configuration Request message:
o Vendor Specific Payload, see Section 4.6.39
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 Response message MUST include the following
message element:
o Result Code, see Section 4.6.35
The following message element MAY be included in the Clear
Configuration Request message:
o Vendor Specific Payload, see Section 4.6.39
Calhoun, et al. Standards Track [Page 119]
RFC 5415 CAPWAP Protocol Specification March 2009
9. Device Management Operations
This section defines CAPWAP operations responsible for debugging,
gathering statistics, logging, and firmware management. The
management operations defined in this section are used by the AC to
either push/pull information to/from the WTP, or request that the WTP
reboot. This section does not deal with the management of the AC per
se, and assumes that the AC is operational and configured.
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. The former allows the download to occur at boot time,
while the latter is used to trigger the download while an active
CAPWAP session exists. It is important to note that the CAPWAP
protocol does not provide the ability for the AC to identify whether
the firmware information provided by the WTP is correct or whether
the WTP is properly storing the firmware (see Section 12.10 for more
information).
Figure 6 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.
Calhoun, et al. Standards Track [Page 120]
RFC 5415 CAPWAP Protocol Specification March 2009
WTP AC
Join Request
-------------------------------------------------------->
Join Response (Image Identifier = x)
<------------------------------------------------------
Image Data Request (Image Identifier = x,
Initiate Download)
-------------------------------------------------------->
Image Data Response (Result Code = Success,
Image Information = {size,hash})
<------------------------------------------------------
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)
Figure 6: WTP Firmware Download Case 1
Figure 7 provides an example in which the WTP has the image specified
by the AC in its non-volatile storage, but is not its current running
image. In this case, the WTP opts to NOT download the firmware and
immediately reset to the requested image.
Calhoun, et al. Standards Track [Page 121]
RFC 5415 CAPWAP Protocol Specification March 2009
WTP AC
Join Request
-------------------------------------------------------->
Join Response (Image Identifier = x)
<------------------------------------------------------
(WTP enters the Reset State)
Figure 7: WTP Firmware Download Case 2
Figure 8 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, et al. Standards Track [Page 122]
RFC 5415 CAPWAP Protocol Specification March 2009
WTP AC
Configuration Update Request (Image Identifier = x)
<------------------------------------------------------
Configuration Update Response (Result Code = Success)
-------------------------------------------------------->
Image Data Request (Image Identifier = x,
Initiate Download)
-------------------------------------------------------->
Image Data Response (Result Code = Success,
Image Information = {size,hash})
<------------------------------------------------------
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 8: WTP Firmware Download Case 3
Figure 9 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-volatile storage. The WTP opts to NOT
download the firmware. The WTP resets upon receipt of a Reset
Request message from the AC.
Calhoun, et al. Standards Track [Page 123]
RFC 5415 CAPWAP Protocol Specification March 2009
WTP AC
Configuration Update Request (Image Identifier = x)
<------------------------------------------------------
Configuration Update Response (Result Code = Already Have Image)
-------------------------------------------------------->
.....
(administratively requested reboot request)
Reset Request (Image Identifier = x)
<------------------------------------------------------
Reset Response (Result Code = Success)
-------------------------------------------------------->
Figure 9: 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 in its
non-volatile flash, but is not its currently running image, it
simply resets to run the proper firmware.
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 Image Identifier
message elements. This will cause the WTP to transmit an Image
Calhoun, et al. Standards Track [Page 124]
RFC 5415 CAPWAP Protocol Specification March 2009
Data Request with the Image Identifier and the Initiate Download
message elements. 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 transferred.
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 CAPWAP Transport Protocol, see Section 4.6.14
o Image Data, see Section 4.6.26
o Vendor Specific Payload, see Section 4.6.39
The following message elements MAY be included in the Image Data
Request message when sent by the WTP:
o Image Identifier, see Section 4.6.27
o Initiate Download, see Section 4.6.29
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.
Calhoun, et al. Standards Track [Page 125]
RFC 5415 CAPWAP Protocol Specification March 2009
The following message element MUST be included in the Image Data
Response message:
o Result Code, see Section 4.6.35
The following message element MAY be included in the Image Data
Response message:
o Vendor Specific Payload, see Section 4.6.39
The following message element MAY be included in the Image Data
Response message when sent by the AC:
o Image Information, see Section 4.6.28
Upon receiving an Image Data Response message indicating an error,
the WTP MAY retransmit a previous Image Data Request 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. If the AC includes the Image Identifier
message element (see Section 4.6.27), it indicates to the WTP that it
SHOULD use that version of software upon reboot.
The Reset Request is sent by the AC when in the Run state. The WTP
does not transmit this message.
The following message element MUST be included in the Reset Request
message:
o Image Identifier, see Section 4.6.27
The following message element MAY be included in the Reset Request
message:
o Vendor Specific Payload, see Section 4.6.39
When a WTP receives a Reset Request message, it responds with a Reset
Response message indicating success and then reinitializes 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,
Calhoun, et al. Standards Track [Page 126]
RFC 5415 CAPWAP Protocol Specification March 2009
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 elements MAY be included in the Reset Response
message.
o Result Code, see Section 4.6.35
o Vendor Specific Payload, see Section 4.6.39
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.24), due 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.
Calhoun, et al. Standards Track [Page 127]
RFC 5415 CAPWAP Protocol Specification March 2009
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 message element
listed MAY be included in the WTP Event Request message.
o Decryption Error Report, see Section 4.6.17
o Duplicate IPv4 Address, see Section 4.6.22
o Duplicate IPv6 Address, see Section 4.6.23
o WTP Radio Statistics, see Section 4.6.46
o WTP Reboot Statistics, see Section 4.6.47
o Delete Station, see Section 4.6.20
o Vendor Specific Payload, see Section 4.6.39
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 following message element MAY be included in the WTP Event
Response message:
o Vendor Specific Payload, see Section 4.6.39
9.6. Data Transfer
This section describes the data transfer procedures used by the
CAPWAP protocol. The data transfer mechanism is used to upload
information available at the WTP to the AC, such as crash or debug
information. The data transfer messages can only be exchanged while
in the Run state.
Figure 10 provides an example of an AC that requests that the WTP
transfer its latest crash file. Once the WTP acknowledges that it
has information to send, via the Data Transfer Response, it transmits
its own Data Transfer Request. Upon receipt, the AC responds with a
Calhoun, et al. Standards Track [Page 128]
RFC 5415 CAPWAP Protocol Specification March 2009
Data Transfer Response, and the exchange continues until the WTP
transmits a Data Transfer Data message element that indicates an End
of File (EOF).
WTP AC
Data Transfer Request (Data Transfer Mode = Crash Data)
<------------------------------------------------------
Data Transfer Response (Result Code = Success)
-------------------------------------------------------->
Data Transfer Request (Data Transfer Data = Data)
-------------------------------------------------------->
Data Transfer Response (Result Code = Success)
<------------------------------------------------------
.....
Data Transfer Request (Data Transfer Data = EOF)
-------------------------------------------------------->
Data Transfer Response (Result Code = Success)
<------------------------------------------------------
Figure 10: WTP Data Transfer Case 1
Figure 11 provides an example of an AC that requests that the WTP
transfer its latest crash file. However, in this example, the WTP
does not have any crash information to send, and therefore sends a
Data Transfer Response with a Result Code indicating the error.
WTP AC
Data Transfer Request (Data Transfer Mode = Crash Data)
<------------------------------------------------------
Data Transfer Response (Result Code = Data Transfer
Error (No Information to Transfer))
-------------------------------------------------------->
Figure 11: WTP Data Transfer Case 2
Calhoun, et al. Standards Track [Page 129]
RFC 5415 CAPWAP Protocol Specification March 2009
9.6.1. Data Transfer Request
The Data Transfer Request message is used to deliver debug
information from the WTP to the AC.
The Data Transfer Request messages can be sent either by the AC or
the WTP. When sent by the AC, it is used to request that data be
transmitted from the WTP to the AC, and includes the Data Transfer
Mode message element, which specifies the information desired by the
AC. The Data Transfer Request is sent by the WTP in order to
transfer actual data to the AC, through the Data Transfer Data
message element.
Given that the CAPWAP protocol minimizes the need for WTPs to be
directly managed, the Data Transfer Request is an important
troubleshooting tool used by the AC to retrieve information that may
be available on the WTP. For instance, some WTP implementations may
store crash information to help manufacturers identify software
faults. The Data Transfer Request message can be used to send such
information from the WTP to the AC. Another possible use would be to
allow a remote debugger function in the WTP to use the Data Transfer
Request message to send console output to the AC for debugging
purposes.
When the WTP or 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 through the Data Transfer Data
message element.
The Data Transfer Request message is sent by the WTP or AC when in
the Run state.
When sent by the AC, the Data Transfer Request message MUST contain
the following message element:
o Data Transfer Mode, see Section 4.6.16
When sent by the WTP, the Data Transfer Request message MUST contain
the following message element:
o Data Transfer Data, see Section 4.6.15
Regardless of whether the Data Transfer Request is sent by the AC or
WTP, the following message element MAY be included in the Data
Transfer Request message:
o Vendor Specific Payload, see Section 4.6.39
Calhoun, et al. Standards Track [Page 130]
RFC 5415 CAPWAP Protocol Specification March 2009
9.6.2. 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. When sent by the WTP, the
Result Code message element is used to indicate whether the data
transfer requested by the AC can be completed. When sent by the AC,
the Result Code message element is used to indicate receipt of the
data transferred in the Data Transfer Request message.
The Data Transfer Response message is sent by the WTP or AC when in
the Run state.
The following message element MUST be included in the Data Transfer
Response message:
o Result Code, see Section 4.6.35
The following message element MAY be included in the Data Transfer
Response message:
o Vendor Specific Payload, see Section 4.6.39
Upon receipt of a Data Transfer Response message, the WTP transmits
more information, if more information is available.
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.
Calhoun, et al. Standards Track [Page 131]
RFC 5415 CAPWAP Protocol Specification March 2009
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.20
o Vendor Specific Payload, see Section 4.6.39
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.35
The following message element MAY be included in the Station
Configuration Response message:
o Vendor Specific Payload, see Section 4.6.39
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.
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 therefore cannot use the WTP's IP address
alone to bind the CAPWAP Control and Data channel. The CAPWAP Data
Check state, which establishes the data plane connection and
Calhoun, et al. Standards Track [Page 132]
RFC 5415 CAPWAP Protocol Specification March 2009
communicates the CAPWAP Data Channel Keep-Alive, 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). CAPWAP implementations MUST also use DTLS session
information on any encrypted CAPWAP channel to validate the source of
both the control and data plane, as described in Section 12.2.
In the third configuration, the AC is deployed behind a NAT. In this
case, the AC is not reachable by the WTP unless a specific rule has
been configured on the NAT to translate the address and redirect
CAPWAP messages to the AC. This deployment presents two issues.
First, an AC communicates its interfaces and corresponding WTP load
using the CAPWAP Control IPv4 Address and CAPWAP Control IPv6 Address
message elements. This message element is mandatory, but contains IP
addresses that are only valid in the private address space used by
the AC, which is not reachable by the WTP. The WTP MUST NOT utilize
the information in these message elements if it detects a NAT (as
described in the CAPWAP Transport Protocol message element in
Section 4.6.14). Second, since the addresses cannot be used by the
WTP, this effectively disables the load-balancing capabilities (see
Section 6.1) of the CAPWAP protocol. Alternatively, the AC could
have a configured NAT'ed address, which it would include in either of
the two control address message elements, and the NAT would need to
be configured accordingly.
In order for a CAPWAP WTP or AC to detect whether a middlebox is
present, both the Join Request (see Section 6.1) and the Join
Response (see Section 6.2) include either the CAPWAP Local IPv4
Address (see Section 4.6.11) or the CAPWAP Local IPv6 Address (see
Section 4.6.12) message element. Upon receiving one of these
messages, if the packet's source IP address differs from the address
found in either one of these message elements, it indicates that a
middlebox is present.
In order for CAPWAP to be compatible with potential middleboxes in
the network, CAPWAP implementations MUST send return traffic from the
same port on which it received traffic from a given peer. Further,
any unsolicited requests generated by a CAPWAP node MUST be sent on
the same port.
Note that this middlebox detection technique is not foolproof. If
the public IP address assigned to the NAT is identical to the private
IP address used by the AC, detection by the WTP would fail. This
failure can lead to various protocol errors, so it is therefore
necessary for deployments to ensure that the NAT's IP address is not
the same as the ACs.
Calhoun, et al. Standards Track [Page 133]
RFC 5415 CAPWAP Protocol Specification March 2009
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 ignored by the WTP when it detects the AC is
behind a middlebox.
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.
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 Authentication, Authorization, and
Accounting (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)
Figure 12: STA Session Setup
Calhoun, et al. Standards Track [Page 134]
RFC 5415 CAPWAP Protocol Specification March 2009
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
unprotected data and attempting to convert un-protected data into
protected data. These concerns are addressed below.
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 man in the middle (MITM) can
Calhoun, et al. Standards Track [Page 135]
RFC 5415 CAPWAP Protocol Specification March 2009
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.1.5. Use of MD5
The Image Information message element (Section 4.6.28) makes use of
MD5 to compute the hash field. The authenticity and integrity of the
image file is protected by DTLS, and in this context, MD5 is not used
as a cryptographically secure hash, but just as a basic checksum.
Therefore, the use of MD5 is not considered a security vulnerability,
and no mechanisms for algorithm agility are provided.
12.1.6. CAPWAP Fragmentation
RFC 4963 [RFC4963] describes a possible security vulnerability where
a malicious entity can "corrupt" a flow by injecting fragments. By
sending "high" fragments (those with offset greater than zero) with a
forged source address, the attacker can deliberately cause
corruption. The use of DTLS on the CAPWAP Data channel can be used
to avoid this possible vulnerability.
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
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 128-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.
Calhoun, et al. Standards Track [Page 136]
RFC 5415 CAPWAP Protocol Specification March 2009
12.3. Discovery or DTLS Setup Attacks
Since the Discovery Request messages are sent in the clear, it is
important that AC implementations NOT assume that receiving a
Discovery Request message from a WTP implies that the WTP 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.
Similarly, when the AC is entering the DTLS Setup phase, it SHOULD
NOT assume that the WTP has reset, and therefore should not discard
active state until the DTLS session has been successfully
established. While the HelloVerifyRequest provides some protection
against denial-of-service (DoS) attacks on the AC, an adversary
capable of receiving packets at a valid address (or a malfunctioning
or misconfigured WTP) may repeatedly attempt DTLS handshakes with the
AC, potentially creating a resource shortage. If either the
FailedDTLSSessionCount or the FailedDTLSAuthFailCount counter reaches
the value of MaxFailedDTLSSessionRetry variable (see Section 4.8),
implementations MAY choose to rate-limit new DTLS handshakes for some
period of time. It is RECOMMENDED that implementations choosing to
implement rate-limiting use a random discard technique, rather than
mimicking the WTP's sulking behavior. This will ensure that messages
from valid WTPs will have some probability of eliciting a response,
even in the face of a significant DoS attack.
Some CAPWAP implementations may wish to restrict the DTLS setup
process to only those peers that have been configured in the access
control list, authorizing only those clients to initiate a DTLS
handshake. Note that the impact of this on mitigating denial-of-
service attacks against the DTLS layer is minimal, because DTLS
already uses client-side cookies to minimize processor consumption
attacks.
12.4. Interference with a DTLS Session
If a WTP or AC repeatedly receives packets that 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.
Calhoun, et al. Standards Track [Page 137]
RFC 5415 CAPWAP Protocol Specification March 2009
In the state machine (section 2.3), transitions to the DTLS Tear Down
(TD) 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. CAPWAP Pre-Provisioning
In order for CAPWAP to establish a secure communication with a peer,
some level of pre-provisioning on both the WTP and AC is necessary.
This section will detail the minimal number of configuration
parameters.
When using pre-shared keys, it is necessary to configure the pre-
shared key for each possible peer with which a DTLS session may be
established. To support this mode of operation, one or more entries
of the following table may be configured on either the AC or WTP:
o Identity: The identity of the peering AC or WTP. This format MAY
be in the form of either an IP address or host name (the latter of
which needs to be resolved to an IP address using DNS).
o Key: The pre-shared key for use with the peer when establishing
the DTLS session (see Section 12.6 for more information).
o PSK Identity: Identity hint associated with the provisioned key
(see Section 2.4.4.4 for more information).
When using certificates, the following items need to be pre-
provisioned:
o Device Certificate: The local device's certificate (see
Section 12.7 for more information).
o Trust Anchor: Trusted root certificate chain used to validate any
certificate received from CAPWAP peers. Note that one or more
root certificates MAY be configured on a given device.
Regardless of the authentication method, the following item needs to
be pre-provisioned:
Calhoun, et al. Standards Track [Page 138]
RFC 5415 CAPWAP Protocol Specification March 2009
o Access Control List: The access control list table contains the
identities of one or more CAPWAP peers, along with a rule. The
rule is used to determine whether communication with the peer is
permitted (see Section 2.4.4.3 for more information).
12.6. Use of Pre-Shared Keys in CAPWAP
While use of pre-shared keys may provide deployment and provisioning
advantages not found in public-key-based deployments, it also
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 pre-shared 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 pre-shared 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
[RFC4086] into account.
o Pre-shared 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
unique PSK. This prevents the domino effect (see "Guidance for
Authentication, Authorization, and Accounting (AAA) Key Management"
[RFC4962]). 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.
Calhoun, et al. Standards Track [Page 139]
RFC 5415 CAPWAP Protocol Specification March 2009
12.7. 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.
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
peer certificate itself. 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 Online Certificate Status
Protocol (OCSP) server or otherwise obtain an up-to-date Certificate
Revocation List (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.8. Use of MAC Address in CN Field
The CAPWAP protocol is an evolution of an existing protocol [LWAPP],
which is implemented on a large number of already deployed ACs and
WTPs. Every one of these devices has an existing X.509 certificate,
which is provisioned at the time of manufacturing. These X.509
certificates use the device's MAC address in the Common Name (CN)
field. It is well understood that encoding the MAC address in the CN
field is less than optimal, and using the SubjectAltName field would
be preferable. However, at the time of publication, there is no URN
Calhoun, et al. Standards Track [Page 140]
RFC 5415 CAPWAP Protocol Specification March 2009
specification that allows for the MAC address to be used in the
SubjectAltName field. As such a specification is published by the
IETF, future versions of the CAPWAP protocol MAY require support for
the new URN scheme.
12.9. AAA Security
The AAA protocol is used to distribute Extensible Authentication
Protocol (EAP) keys to the ACs, and consequently its security is
important to the overall system security. When used with Transport
Layer Security (TLS) or IPsec, security guidelines specified in RFC
3539 [RFC3539] 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.
12.10. WTP Firmware
The CAPWAP protocol defines a mechanism by which the AC downloads new
firmware to the WTP. During the session establishment process, the
WTP provides information about its current firmware to the AC. The
AC then decides whether the WTP's firmware needs to be updated. It
is important to note that the CAPWAP specification makes the explicit
assumption that the WTP is providing the correct firmware version to
the AC, and is therefore not lying. Further, during the firmware
download process, the CAPWAP protocol does not provide any mechanisms
to recognize whether the WTP is actually storing the firmware for
future use.
13. Operational 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 command line interface (CLI) or Simple Network Management
Protocol (SNMP), could lead to the AC state being out of sync with
the WTP.
Calhoun, et al. Standards Track [Page 141]
RFC 5415 CAPWAP Protocol Specification March 2009
The CAPWAP protocol does not deal with the management of the ACs.
The AC is assumed to be configured through some separate management
interface, which could be via a proprietary CLI, SNMP, Network
Configuration Protocol (NETCONF), or some other management protocol.
The CAPWAP protocol's control channel is fairly lightweight from a
traffic perspective. Once the WTP has been configured, the WTP sends
periodic statistics. Further, the specification calls for a keep-
alive packet to be sent on the protocol's data channel to make sure
that any possible middleboxes (e.g., NAT) maintain their UDP state.
The overhead associated with the control and data channel is not
expected to impact network traffic. That said, the CAPWAP protocol
does allow for the frequency of these packets to be modified through
the DataChannelKeepAlive and StatisticsTimer (see Section 4.7.2 and
Section 4.7.14, respectively).
14. Transport Considerations
The CAPWAP WG carefully considered the congestion control
requirements of the CAPWAP protocol, both for the CAPWAP Control and
Data channels.
CAPWAP specifies a single-threaded command/response protocol to be
used on the control channel, and we have specified that an
exponential back-off algorithm should be used when commands are
retransmitted. When CAPWAP runs in its default mode (Local MAC), the
control channel is the only CAPWAP channel.
However, CAPWAP can also be run in Split MAC mode, in which case
there will be a DTLS-encrypted data channel between each WTP and the
AC. The WG discussed various options for providing congestion
control on this channel. However, due to performance problems with
TCP when it is run over another congestion control mechanism and the
fact that the vast majority of traffic run over the CAPWAP Data
channel is likely to be congestion-controlled IP traffic, the CAPWAP
WG felt that specifying a congestion control mechanism for the CAPWAP
Data channel would be more likely to cause problems than to resolve
any.
Because there is no congestion control mechanism specified for the
CAPWAP Data channel, it is RECOMMENDED that non-congestion-controlled
traffic not be tunneled over CAPWAP. When a significant amount of
non-congestion-controlled traffic is expected to be present on a
WLAN, the CAPWAP connection between the AC and the WTP for that LAN
should be configured to remain in Local MAC mode with Distribution
function at the WTP.
Calhoun, et al. Standards Track [Page 142]
RFC 5415 CAPWAP Protocol Specification March 2009
The lock step nature of the CAPWAP protocol's control channel can
cause the firmware download process to take some time, depending upon
the round-trip time (RTT). This is not expected to be a problem
since the CAPWAP protocol allows firmware to be downloaded while the
WTP provides service to wireless clients/devices.
It is necessary for the WTP and AC to configure their MTU based on
the capabilities of the path. See Section 3.5 for more information.
The CAPWAP protocol mandates support of the Explicit Congestion
Notification (ECN) through a mode of operation named "limited
functionality option", detailed in section 9.1.1 of [RFC3168].
Future versions of the CAPWAP protocol should consider mandating
support for the "full functionality option".
15. IANA Considerations
This section details the actions that IANA has taken in preparation
for publication of the specification. Numerous registries have been
created, and the contents, document action (see [RFC5226], and
registry format are all included below. Note that in cases where bit
fields are referred to, the bit numbering is left to right, where the
leftmost bit is labeled as bit zero (0).
For future registration requests where an Expert Review is required,
a Designated Expert should be consulted, which is appointed by the
responsible IESG Area Director. The intention is that any allocation
will be accompanied by a published RFC, but given that other SDOs may
want to create standards built on top of CAPWAP, a document the
Designated Expert can review is also acceptable. IANA should allow
for allocation of values prior to documents being approved for
publication, so the Designated Expert can approve allocations once it
seems clear that publication will occur. The Designated Expert will
post a request to the CAPWAP WG mailing list (or a successor
designated by the Area Director) for comment and review. Before a
period of 30 days has passed, the Designated Expert will either
approve or deny the registration request and publish a notice of the
decision to the CAPWAP WG mailing list or its successor, as well as
informing IANA. A denial notice must be justified by an explanation,
and in the cases where it is possible, concrete suggestions on how
the request can be modified so as to become acceptable should be
provided.
15.1. IPv4 Multicast Address
IANA has registered a new IPv4 multicast address called "capwap-ac"
from the Internetwork Control Block IPv4 multicast address registry;
see Section 3.3.
Calhoun, et al. Standards Track [Page 143]
RFC 5415 CAPWAP Protocol Specification March 2009
15.2. IPv6 Multicast Address
IANA has registered a new organization local multicast address called
the "All ACs multicast address" in the Variable Scope IPv6 multicast
address registry; see Section 3.3.
15.3. UDP Port
IANA registered two new UDP Ports, which are organization-local
multicast addresses, in the registered port numbers registry; see
Section 3.1. The following values have been registered:
Keyword Decimal Description References
------- ------- ----------- ----------
capwap-control 5246/udp CAPWAP Control Protocol This Document
capwap-data 5247/udp CAPWAP Data Protocol This Document
15.4. CAPWAP Message Types
The Message Type field in the CAPWAP Header (see Section 4.5.1.1) is
used to identify the operation performed by the message. There are
multiple namespaces, which are identified via the first three octets
of the field containing the IANA Enterprise Number [RFC5226].
IANA maintains the CAPWAP Message Types registry for all message
types whose Enterprise Number is set to zero (0). The namespace is 8
bits (0-255), where the value of zero (0) is reserved and must not be
assigned. The values one (1) through 26 are allocated in this
specification, and can be found in Section 4.5.1.1. Any new
assignments of a CAPWAP Message Type whose Enterprise Number is set
to zero (0) requires an Expert Review. The registry maintained by
IANA has the following format:
CAPWAP Control Message Message Type Reference
Value
15.5. CAPWAP Header Flags
The Flags field in the CAPWAP Header (see Section 4.3) is 9 bits in
length and is used to identify any special treatment related to the
message. This specification defines bits zero (0) through five (5),
while bits six (6) through eight (8) are reserved. There are
currently three unused, reserved bits that are managed by IANA and
whose assignment require an Expert Review. IANA created the CAPWAP
Header Flags registry, whose format is:
Flag Field Name Bit Position Reference
Calhoun, et al. Standards Track [Page 144]
RFC 5415 CAPWAP Protocol Specification March 2009
15.6. CAPWAP Control Message Flags
The Flags field in the CAPWAP Control Message header (see
Section 4.5.1.4) is used to identify any special treatment related to
the control message. There are currently eight (8) unused, reserved
bits. The assignment of these bits is managed by IANA and requires
an Expert Review. IANA created the CAPWAP Control Message Flags
registry, whose format is:
Flag Field Name Bit Position Reference
15.7. CAPWAP Message Element Type
The Type field in the CAPWAP Message Element header (see Section 4.6)
is used to identify the data being transported. The namespace is 16
bits (0-65535), where the value of zero (0) is reserved and must not
be assigned. The values one (1) through 53 are allocated in this
specification, and can be found in Section 4.5.1.1.
The 16-bit namespace is further divided into blocks of addresses that
are reserved for specific CAPWAP wireless bindings. The following
blocks are reserved:
CAPWAP Protocol Message Elements 1 - 1023
IEEE 802.11 Message Elements 1024 - 2047
EPCGlobal Message Elements 3072 - 4095
This namespace is managed by IANA and assignments require an Expert
Review. IANA created the CAPWAP Message Element Type registry, whose
format is:
CAPWAP Message Element Type Value Reference
15.8. CAPWAP Wireless Binding Identifiers
The Wireless Binding Identifier (WBID) field in the CAPWAP Header
(see Section 4.3) is used to identify the wireless technology
associated with the packet. This specification allocates the values
one (1) and three (3). Due to the limited address space available, a
new WBID request requires Expert Review. IANA created the CAPWAP
Wireless Binding Identifier registry, whose format is:
CAPWAP Wireless Binding Identifier Type Value Reference
Calhoun, et al. Standards Track [Page 145]
RFC 5415 CAPWAP Protocol Specification March 2009
15.9. AC Security Types
The Security field in the AC Descriptor message element (see
Section 4.6.1) is 8 bits in length and is used to identify the
authentication methods available on the AC. This specification
defines bits five (5) and six (6), while bits zero (0) through four
(4) as well as bit seven (7) are reserved and unused. These reserved
bits are managed by IANA and assignment requires Standards Action.
IANA created the AC Security Types registry, whose format is:
AC Security Type Bit Position Reference
15.10. AC DTLS Policy
The DTLS Policy field in the AC Descriptor message element (see
Section 4.6.1) is 8 bits in length and is used to identify whether
the CAPWAP Data Channel is to be secured. This specification defines
bits five (5) and six (6), while bits zero (0) through four (4) as
well as bit seven (7) are reserved and unused. These reserved bits
are managed by IANA and assignment requires Standards Action. IANA
created the AC DTLS Policy registry, whose format is:
AC DTLS Policy Bit Position Reference
15.11. AC Information Type
The Information Type field in the AC Descriptor message element (see
Section 4.6.1) is used to represent information about the AC. The
namespace is 16 bits (0-65535), where the value of zero (0) is
reserved and must not be assigned. This field, combined with the AC
Information Vendor ID, allows vendors to use a private namespace.
This specification defines the AC Information Type namespace when the
AC Information Vendor ID is set to zero (0), for which the values
four (4) and five (5) are allocated in this specification, and can be
found in Section 4.6.1. This namespace is managed by IANA and
assignments require an Expert Review. IANA created the AC
Information Type registry, whose format is:
AC Information Type Type Value Reference
15.12. CAPWAP Transport Protocol Types
The Transport field in the CAPWAP Transport Protocol message element
(see Section 4.6.14) is used to identify the transport to use for the
CAPWAP Data Channel. The namespace is 8 bits (0-255), where the
value of zero (0) is reserved and must not be assigned. The values
one (1) and two (2) are allocated in this specification, and can be
Calhoun, et al. Standards Track [Page 146]
RFC 5415 CAPWAP Protocol Specification March 2009
found in Section 4.6.14. This namespace is managed by IANA and
assignments require an Expert Review. IANA created the CAPWAP
Transport Protocol Types registry, whose format is:
CAPWAP Transport Protocol Type Type Value Reference
15.13. Data Transfer Type
The Data Type field in the Data Transfer Data message element (see
Section 4.6.15) and Image Data message element (see Section 4.6.26)
is used to provide information about the data being carried. The
namespace is 8 bits (0-255), where the value of zero (0) is reserved
and must not be assigned. The values one (1), two (2), and five (5)
are allocated in this specification, and can be found in
Section 4.6.15. This namespace is managed by IANA and assignments
require an Expert Review. IANA created the Data Transfer Type
registry, whose format is:
Data Transfer Type Type Value Reference
15.14. Data Transfer Mode
The Data Mode field in the Data Transfer Data message element (see
Section 4.6.15) and Data Transfer Mode message element (see
Section 15.14) is used to provide information about the data being
carried. The namespace is 8 bits (0-255), where the value of zero
(0) is reserved and must not be assigned. The values one (1) and two
(2) are allocated in this specification, and can be found in
Section 15.14. This namespace is managed by IANA and assignments
require an Expert Review. IANA created the Data Transfer Mode
registry, whose format is:
Data Transfer Mode Type Value Reference
15.15. Discovery Types
The Discovery Type field in the Discovery Type message element (see
Section 4.6.21) is used by the WTP to indicate to the AC how it was
discovered. The namespace is 8 bits (0-255). The values zero (0)
through four (4) are allocated in this specification and can be found
in Section 4.6.21. This namespace is managed by IANA and assignments
require an Expert Review. IANA created the Discovery Types registry,
whose format is:
Discovery Types Type Value Reference
Calhoun, et al. Standards Track [Page 147]
RFC 5415 CAPWAP Protocol Specification March 2009
15.16. ECN Support
The ECN Support field in the ECN Support message element (see
Section 4.6.25) is used by the WTP to represent its ECN Support. The
namespace is 8 bits (0-255). The values zero (0) and one (1) are
allocated in this specification, and can be found in Section 4.6.25.
This namespace is managed by IANA and assignments require an Expert
Review. IANA created the ECN Support registry, whose format is:
ECN Support Type Value Reference
15.17. Radio Admin State
The Radio Admin field in the Radio Administrative State message
element (see Section 4.6.33) is used by the WTP to represent the
state of its radios. The namespace is 8 bits (0-255), where the
value of zero (0) is reserved and must not be assigned. The values
one (1) and two (2) are allocated in this specification, and can be
found in Section 4.6.33. This namespace is managed by IANA and
assignments require an Expert Review. IANA created the Radio Admin
State registry, whose format is:
Radio Admin State Type Value Reference
15.18. Radio Operational State
The State field in the Radio Operational State message element (see
Section 4.6.34) is used by the WTP to represent the operational state
of its radios. The namespace is 8 bits (0-255), where the value of
zero (0) is reserved and must not be assigned. The values one (1)
and two (2) are allocated in this specification, and can be found in
Section 4.6.34. This namespace is managed by IANA and assignments
require an Expert Review. IANA created the Radio Operational State
registry, whose format is:
Radio Operational State Type Value Reference
15.19. Radio Failure Causes
The Cause field in the Radio Operational State message element (see
Section 4.6.34) is used by the WTP to represent the reason a radio
may have failed. The namespace is 8 bits (0-255), where the value of
zero (0) through three (3) are allocated in this specification, and
can be found in Section 4.6.34. This namespace is managed by IANA
and assignments require an Expert Review. IANA created the Radio
Failure Causes registry, whose format is:
Radio Failure Causes Type Value Reference
Calhoun, et al. Standards Track [Page 148]
RFC 5415 CAPWAP Protocol Specification March 2009
15.20. Result Code
The Result Code field in the Result Code message element (see
Section 4.6.35) is used to indicate the success or failure of a
CAPWAP Control message. The namespace is 32 bits (0-4294967295),
where the value of zero (0) through 22 are allocated in this
specification, and can be found in Section 4.6.35. This namespace is
managed by IANA and assignments require an Expert Review. IANA
created the Result Code registry, whose format is:
Result Code Type Value Reference
15.21. Returned Message Element Reason
The Reason field in the Returned Message Element message element (see
Section 4.6.36) is used to indicate the reason why a message element
was not processed successfully. The namespace is 8 bits (0-255),
where the value of zero (0) is reserved and must not be assigned.
The values one (1) through four (4) are allocated in this
specification, and can be found in Section 4.6.36. This namespace is
managed by IANA and assignments require an Expert Review. IANA
created the Returned Message Element Reason registry, whose format
is:
Returned Message Element Reason Type Value Reference
15.22. WTP Board Data Type
The Board Data Type field in the WTP Board Data message element (see
Section 4.6.40) is used to represent information about the WTP
hardware. The namespace is 16 bits (0-65535). The WTP Board Data
Type values zero (0) through four (4) are allocated in this
specification, and can be found in Section 4.6.40. This namespace is
managed by IANA and assignments require an Expert Review. IANA
created the WTP Board Data Type registry, whose format is:
WTP Board Data Type Type Value Reference
15.23. WTP Descriptor Type
The Descriptor Type field in the WTP Descriptor message element (see
Section 4.6.41) is used to represent information about the WTP
software. The namespace is 16 bits (0-65535). This field, combined
with the Descriptor Vendor ID, allows vendors to use a private
namespace. This specification defines the WTP Descriptor Type
namespace when the Descriptor Vendor ID is set to zero (0), for which
the values zero (0) through three (3) are allocated in this
Calhoun, et al. Standards Track [Page 149]
RFC 5415 CAPWAP Protocol Specification March 2009
specification, and can be found in Section 4.6.41. This namespace is
managed by IANA and assignments require an Expert Review. IANA
created the WTP Board Data Type registry, whose format is:
WTP Descriptor Type Type Value Reference
15.24. WTP Fallback Mode
The Mode field in the WTP Fallback message element (see
Section 4.6.42) is used to indicate the type of AC fallback mechanism
the WTP should employ. The namespace is 8 bits (0-255), where the
value of zero (0) is reserved and must not be assigned. The values
one (1) and two (2) are allocated in this specification, and can be
found in Section 4.6.42. This namespace is managed by IANA and
assignments require an Expert Review. IANA created the WTP Fallback
Mode registry, whose format is:
WTP Fallback Mode Type Value Reference
15.25. WTP Frame Tunnel Mode
The Tunnel Type field in the WTP Frame Tunnel Mode message element
(see Section 4.6.43) is 8 bits and is used to indicate the type of
tunneling to use between the WTP and the AC. This specification
defines bits four (4) through six (6), while bits zero (0) through
three (3) as well as bit seven (7) are reserved and unused. These
reserved bits are managed by IANA and assignment requires an Expert
Review. IANA created the WTP Frame Tunnel Mode registry, whose
format is:
WTP Frame Tunnel Mode Bit Position Reference
15.26. WTP MAC Type
The MAC Type field in the WTP MAC Type message element (see
Section 4.6.44) is used to indicate the type of MAC to use in
tunneled frames between the WTP and the AC. The namespace is 8 bits
(0-255), where the value of zero (0) through two (2) are allocated in
this specification, and can be found in Section 4.6.44. This
namespace is managed by IANA and assignments require an Expert
Review. IANA created the WTP MAC Type registry, whose format is:
WTP MAC Type Type Value Reference
Calhoun, et al. Standards Track [Page 150]
RFC 5415 CAPWAP Protocol Specification March 2009
15.27. WTP Radio Stats Failure Type
The Last Failure Type field in the WTP Radio Statistics message
element (see Section 4.6.46) is used to indicate the last WTP
failure. The namespace is 8 bits (0-255), where the value of zero
(0) through three (3) as well as the value 255 are allocated in this
specification, and can be found in Section 4.6.46. This namespace is
managed by IANA and assignments require an Expert Review. IANA
created the WTP Radio Stats Failure Type registry, whose format is:
WTP Radio Stats Failure Type Type Value Reference
15.28. WTP Reboot Stats Failure Type
The Last Failure Type field in the WTP Reboot Statistics message
element (see Section 4.6.47) is used to indicate the last reboot
reason. The namespace is 8 bits (0-255), where the value of zero (0)
through five (5) as well as the value 255 are allocated in this
specification, and can be found in Section 4.6.47. This namespace is
managed by IANA and assignments require an Expert Review. IANA
created the WTP Reboot Stats Failure Type registry, whose format is:
WTP Reboot Stats Failure Type Type Value Reference
16. Acknowledgments
The following individuals are acknowledged for their contributions to
this protocol specification: Puneet Agarwal, Abhijit Choudhury, Pasi
Eronen, Saravanan Govindan, Peter Nilsson, David Perkins, and Yong
Zhang.
Michael Vakulenko contributed text to describe how CAPWAP can be used
over Layer 3 (IP/UDP) networks.
17. References
17.1. Normative References
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery",
RFC 1191, November 1990.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm",
RFC 1321, April 1992.
[RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", RFC 1305,
March 1992.
Calhoun, et al. Standards Track [Page 151]
RFC 5415 CAPWAP Protocol Specification March 2009
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU
Discovery for IP version 6", RFC 1981,
August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol,
Version 6 (IPv6) Specification", RFC 2460,
December 1998.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field
(DS Field) in the IPv4 and IPv6 Headers",
RFC 2474, December 1998.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS
RR for specifying the location of services (DNS
SRV)", RFC 2782, February 2000.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The
Addition of Explicit Congestion Notification (ECN)
to IP", RFC 3168, September 2001.
[RFC3539] Aboba, B. and J. Wood, "Authentication,
Authorization and Accounting (AAA) Transport
Profile", RFC 3539, June 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of
ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson,
L-E., and G. Fairhurst, "The Lightweight User
Datagram Protocol (UDP-Lite)", RFC 3828,
July 2004.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106,
RFC 4086, June 2005.
[RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key
Ciphersuites for Transport Layer Security (TLS)",
RFC 4279, December 2005.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.2", RFC 5246,
August 2008.
Calhoun, et al. Standards Track [Page 152]
RFC 5415 CAPWAP Protocol Specification March 2009
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport
Layer Security", RFC 4347, April 2006.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer
Path MTU Discovery", RFC 4821, March 2007.
[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4
Reassembly Errors at High Data Rates", RFC 4963,
July 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in RFCs",
BCP 26, RFC 5226, May 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen,
S., Housley, R., and W. Polk, "Internet X.509
Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile",
RFC 5280, May 2008.
[ISO.9834-1.1993] International Organization for Standardization,
"Procedures for the operation of OSI registration
authorities - part 1: general procedures",
ISO Standard 9834-1, 1993.
[RFC5416] Calhoun, P., Ed., Montemurro, M., Ed., and D.
Stanley, Ed., "Control And Provisioning of
Wireless Access Points (CAPWAP) Protocol Binding
for IEEE 802.11", RFC 5416, March 2009.
[RFC5417] Calhoun, P., "Control And Provisioning of Wireless
Access Points (CAPWAP) Access Controller DHCP
Option", RFC 5417, March 2009.
[FRAME-EXT] IEEE, "IEEE Standard 802.3as-2006", 2005.
17.2. Informative References
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is
Replaced by an On-line Database", RFC 3232,
January 2002.
[RFC3753] Manner, J. and M. Kojo, "Mobility Related
Terminology", RFC 3753, June 2004.
Calhoun, et al. Standards Track [Page 153]
RFC 5415 CAPWAP Protocol Specification March 2009
[RFC4564] Govindan, S., Cheng, H., Yao, ZH., Zhou, WH., and
L. Yang, "Objectives for Control and Provisioning
of Wireless Access Points (CAPWAP)", RFC 4564,
July 2006.
[RFC4962] Housley, R. and B. Aboba, "Guidance for
Authentication, Authorization, and Accounting
(AAA) Key Management", BCP 132, RFC 4962,
July 2007.
[LWAPP] Calhoun, P., O'Hara, B., Suri, R., Cam Winget, N.,
Kelly, S., Williams, M., and S. Hares,
"Lightweight Access Point Protocol", Work in
Progress, March 2007.
[SLAPP] Narasimhan, P., Harkins, D., and S. Ponnuswamy,
"SLAPP: Secure Light Access Point Protocol", Work
in Progress, May 2005.
[DTLS-DESIGN] Modadugu, et al., N., "The Design and
Implementation of Datagram TLS", Feb 2004.
[EUI-48] IEEE, "Guidelines for use of a 48-bit Extended
Unique Identifier", Dec 2005.
[EUI-64] IEEE, "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER
(EUI-64) REGISTRATION AUTHORITY".
[EPCGlobal] "See http://www.epcglobalinc.org/home".
[PacketCable] "PacketCable Security Specification PKT-SP-SEC-
I12-050812", August 2005, <PacketCable>.
[CableLabs] "OpenCable System Security Specification OC-SP-
SEC-I07-061031", October 2006, <CableLabs>.
[WiMAX] "WiMAX Forum X.509 Device Certificate Profile
Approved Specification V1.0.1", April 2008,
<WiMAX>.
[RFC5418] Kelly, S. and C. Clancy, "Control And Provisioning
for Wireless Access Points (CAPWAP) Threat
Analysis for IEEE 802.11 Deployments", RFC 5418,
March 2009.
Calhoun, et al. Standards Track [Page 154]
RFC 5415 CAPWAP Protocol Specification March 2009
Editors' Addresses
Pat R. Calhoun (editor)
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
Phone: +1 408-902-3240
EMail: pcalhoun@cisco.com
Michael P. Montemurro (editor)
Research In Motion
5090 Commerce Blvd
Mississauga, ON L4W 5M4
Canada
Phone: +1 905-629-4746 x4999
EMail: mmontemurro@rim.com
Dorothy Stanley (editor)
Aruba Networks
1322 Crossman Ave
Sunnyvale, CA 94089
Phone: +1 630-363-1389
EMail: dstanley@arubanetworks.com
Calhoun, et al. Standards Track [Page 155]
Reference in New Issue View Git Blame Copy Permalink