draft-ietf-capwap-protocol-specification-08.txt   draft-ietf-capwap-protocol-specification-09.txt 
Network Working Group P. Calhoun, Editor Network Working Group P. Calhoun, Editor
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: May 19, 2008 M. Montemurro, Editor Expires: August 24, 2008 M. Montemurro, Editor
Research In Motion Research In Motion
D. Stanley, Editor D. Stanley, Editor
Aruba Networks Aruba Networks
November 16, 2007 February 21, 2008
CAPWAP Protocol Specification CAPWAP Protocol Specification
draft-ietf-capwap-protocol-specification-08 draft-ietf-capwap-protocol-specification-09
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 19, 2008. This Internet-Draft will expire on August 24, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This specification defines the Control And Provisioning of Wireless This specification defines the Control And Provisioning of Wireless
Access Points (CAPWAP) Protocol. The CAPWAP protocol meets the IETF Access Points (CAPWAP) Protocol. The CAPWAP protocol meets the IETF
CAPWAP working group protocol requirements. The CAPWAP protocol is CAPWAP working group protocol requirements. The CAPWAP protocol is
designed to be flexible, allowing it to be used for a variety of designed to be flexible, allowing it to be used for a variety of
wireless technologies. This document describes the base CAPWAP wireless technologies. This document describes the base CAPWAP
protocol. The CAPWAP protocol binding which defines extensions for protocol. The CAPWAP protocol binding which defines extensions for
use with the IEEE 802.11 wireless LAN protocol is available in [16]. use with the IEEE 802.11 wireless LAN protocol is available in [16].
Extensions are expected to be defined to enable use of the CAPWAP Extensions are expected to be defined to enable use of the CAPWAP
protocol with additional wireless technologies. protocol with additional wireless technologies.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2. Conventions used in this document . . . . . . . . . . . . 8
1.3. Contributing Authors . . . . . . . . . . . . . . . . . . 9
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 10
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12
2.1. Wireless Binding Definition . . . . . . . . . . . . . . . 13
2.2. CAPWAP Session Establishment Overview . . . . . . . . . . 14
2.3. CAPWAP State Machine Definition . . . . . . . . . . . . . 16
2.3.1. CAPWAP Protocol State Transitions . . . . . . . . . . 18
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 . . . . . . . . . . . . . 34
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 . . . . . . . . . . . . . . . . . . . 40
3.3. AC Discovery . . . . . . . . . . . . . . . . . . . . . . 41
3.4. Fragmentation/Reassembly . . . . . . . . . . . . . . . . 42
3.5. MTU Discovery . . . . . . . . . . . . . . . . . . . . . . 42
4. CAPWAP Packet Formats . . . . . . . . . . . . . . . . . . . . 43
4.1. CAPWAP Preamble . . . . . . . . . . . . . . . . . . . . . 45
4.2. CAPWAP DTLS Header . . . . . . . . . . . . . . . . . . . 45
4.3. CAPWAP Header . . . . . . . . . . . . . . . . . . . . . . 46
4.4. CAPWAP Data Messages . . . . . . . . . . . . . . . . . . 49
4.4.1. CAPWAP Data Keepalive . . . . . . . . . . . . . . . . 49
4.4.2. Data Payload . . . . . . . . . . . . . . . . . . . . 50
4.4.3. Establishment of a DTLS Data Channel . . . . . . . . 51
4.5. CAPWAP Control Messages . . . . . . . . . . . . . . . . . 51
4.5.1. Control Message Format . . . . . . . . . . . . . . . 52
4.5.2. Control Message Quality of Service . . . . . . . . . 55
4.5.3. Retransmissions . . . . . . . . . . . . . . . . . . . 55
4.6. CAPWAP Protocol Message Elements . . . . . . . . . . . . 56
4.6.1. AC Descriptor . . . . . . . . . . . . . . . . . . . . 58
4.6.2. AC IPv4 List . . . . . . . . . . . . . . . . . . . . 60
4.6.3. AC IPv6 List . . . . . . . . . . . . . . . . . . . . 61
4.6.4. AC Name . . . . . . . . . . . . . . . . . . . . . . . 61
4.6.5. AC Name with Index . . . . . . . . . . . . . . . . . 62
4.6.6. AC Timestamp . . . . . . . . . . . . . . . . . . . . 62
4.6.7. Add MAC ACL Entry . . . . . . . . . . . . . . . . . . 63
4.6.8. Add Station . . . . . . . . . . . . . . . . . . . . . 63
4.6.9. Add Static MAC ACL Entry . . . . . . . . . . . . . . 64
4.6.10. CAPWAP Control IPv4 Address . . . . . . . . . . . . . 64
4.6.11. CAPWAP Control IPv6 Address . . . . . . . . . . . . . 65
4.6.12. CAPWAP Local IPv4 Address . . . . . . . . . . . . . . 66
4.6.13. CAPWAP Local IPv6 Address . . . . . . . . . . . . . . 66
4.6.14. CAPWAP Timers . . . . . . . . . . . . . . . . . . . . 67
4.6.15. CAPWAP Transport Protocol . . . . . . . . . . . . . . 67
4.6.16. Data Transfer Data . . . . . . . . . . . . . . . . . 68
4.6.17. Data Transfer Mode . . . . . . . . . . . . . . . . . 69
4.6.18. Decryption Error Report . . . . . . . . . . . . . . . 69
4.6.19. Decryption Error Report Period . . . . . . . . . . . 70
4.6.20. Delete MAC ACL Entry . . . . . . . . . . . . . . . . 70
4.6.21. Delete Station . . . . . . . . . . . . . . . . . . . 71
4.6.22. Delete Static MAC ACL Entry . . . . . . . . . . . . . 71
4.6.23. Discovery Type . . . . . . . . . . . . . . . . . . . 72
4.6.24. Duplicate IPv4 Address . . . . . . . . . . . . . . . 73
4.6.25. Duplicate IPv6 Address . . . . . . . . . . . . . . . 73
4.6.26. Idle Timeout . . . . . . . . . . . . . . . . . . . . 74
4.6.27. Image Data . . . . . . . . . . . . . . . . . . . . . 75
4.6.28. Image Identifier . . . . . . . . . . . . . . . . . . 75
4.6.29. Image Information . . . . . . . . . . . . . . . . . . 76
4.6.30. Initiate Download . . . . . . . . . . . . . . . . . . 77
4.6.31. Location Data . . . . . . . . . . . . . . . . . . . . 77
4.6.32. Maximum Message Length . . . . . . . . . . . . . . . 77
4.6.33. Radio Administrative State . . . . . . . . . . . . . 78
4.6.34. Radio Operational State . . . . . . . . . . . . . . . 78
4.6.35. Result Code . . . . . . . . . . . . . . . . . . . . . 79
4.6.36. Returned Message Element . . . . . . . . . . . . . . 81
4.6.37. Session ID . . . . . . . . . . . . . . . . . . . . . 81
4.6.38. Statistics Timer . . . . . . . . . . . . . . . . . . 82
4.6.39. Vendor Specific Payload . . . . . . . . . . . . . . . 82
4.6.40. WTP Board Data . . . . . . . . . . . . . . . . . . . 83
4.6.41. WTP Descriptor . . . . . . . . . . . . . . . . . . . 84
4.6.42. WTP Fallback . . . . . . . . . . . . . . . . . . . . 85
4.6.43. WTP Frame Tunnel Mode . . . . . . . . . . . . . . . . 86
4.6.44. WTP IPv4 IP Address . . . . . . . . . . . . . . . . . 87
4.6.45. WTP IPv6 IP Address . . . . . . . . . . . . . . . . . 87
4.6.46. WTP MAC Type . . . . . . . . . . . . . . . . . . . . 88
4.6.47. WTP Name . . . . . . . . . . . . . . . . . . . . . . 89
4.6.48. WTP Operational Statistics . . . . . . . . . . . . . 89
4.6.49. WTP Radio Statistics . . . . . . . . . . . . . . . . 90
4.6.50. WTP Reboot Statistics . . . . . . . . . . . . . . . . 91
4.6.51. WTP Static IP Address Information . . . . . . . . . . 92
4.7. CAPWAP Protocol Timers . . . . . . . . . . . . . . . . . 93
4.7.1. ChangeStatePendingTimer . . . . . . . . . . . . . . . 93
4.7.2. DataChannelKeepAlive . . . . . . . . . . . . . . . . 93
4.7.3. DataChannelDeadInterval . . . . . . . . . . . . . . . 94
4.7.4. DataCheckTimer . . . . . . . . . . . . . . . . . . . 94
4.7.5. DiscoveryInterval . . . . . . . . . . . . . . . . . . 94
4.7.6. DTLSSessionDelete . . . . . . . . . . . . . . . . . . 94
4.7.7. EchoInterval . . . . . . . . . . . . . . . . . . . . 94
4.7.8. ImageDataStartTimer . . . . . . . . . . . . . . . . . 94
4.7.9. MaxDiscoveryInterval . . . . . . . . . . . . . . . . 95
4.7.10. MaxFailedDTLSSessionRetry . . . . . . . . . . . . . . 95
4.7.11. ResponseTimeout . . . . . . . . . . . . . . . . . . . 95
4.7.12. RetransmitInterval . . . . . . . . . . . . . . . . . 95
4.7.13. SilentInterval . . . . . . . . . . . . . . . . . . . 95
4.7.14. StatisticsTimer . . . . . . . . . . . . . . . . . . . 95
4.7.15. WaitDTLS . . . . . . . . . . . . . . . . . . . . . . 95
4.7.16. WaitJoin . . . . . . . . . . . . . . . . . . . . . . 96
4.8. CAPWAP Protocol Variables . . . . . . . . . . . . . . . . 96
4.8.1. AdminState . . . . . . . . . . . . . . . . . . . . . 96
4.8.2. DiscoveryCount . . . . . . . . . . . . . . . . . . . 96
4.8.3. FailedDTLSAuthFailCount . . . . . . . . . . . . . . . 96
4.8.4. FailedDTLSSessionCount . . . . . . . . . . . . . . . 96
4.8.5. IdleTimeout . . . . . . . . . . . . . . . . . . . . . 96
4.8.6. MaxDiscoveries . . . . . . . . . . . . . . . . . . . 96
4.8.7. MaxRetransmit . . . . . . . . . . . . . . . . . . . . 97
4.8.8. ReportInterval . . . . . . . . . . . . . . . . . . . 97
4.8.9. RetransmitCount . . . . . . . . . . . . . . . . . . . 97
4.8.10. WTPFallBack . . . . . . . . . . . . . . . . . . . . . 97
4.9. WTP Saved Variables . . . . . . . . . . . . . . . . . . . 97
4.9.1. AdminRebootCount . . . . . . . . . . . . . . . . . . 97
4.9.2. FrameEncapType . . . . . . . . . . . . . . . . . . . 97
4.9.3. LastRebootReason . . . . . . . . . . . . . . . . . . 97
4.9.4. MacType . . . . . . . . . . . . . . . . . . . . . . . 97
4.9.5. PreferredACs . . . . . . . . . . . . . . . . . . . . 98
4.9.6. RebootCount . . . . . . . . . . . . . . . . . . . . . 98
4.9.7. Static ACL Table . . . . . . . . . . . . . . . . . . 98
4.9.8. Static IP Address . . . . . . . . . . . . . . . . . . 98
4.9.9. WTPLinkFailureCount . . . . . . . . . . . . . . . . . 98
4.9.10. WTPLocation . . . . . . . . . . . . . . . . . . . . . 98
4.9.11. WTPName . . . . . . . . . . . . . . . . . . . . . . . 98
5. CAPWAP Discovery Operations . . . . . . . . . . . . . . . . . 99
5.1. Discovery Request Message . . . . . . . . . . . . . . . . 99
5.2. Discovery Response Message . . . . . . . . . . . . . . . 100
5.3. Primary Discovery Request Message . . . . . . . . . . . . 101
5.4. Primary Discovery Response . . . . . . . . . . . . . . . 102
6. CAPWAP Join Operations . . . . . . . . . . . . . . . . . . . 104
6.1. Join Request . . . . . . . . . . . . . . . . . . . . . . 104
6.2. Join Response . . . . . . . . . . . . . . . . . . . . . . 105
7. Control Channel Management . . . . . . . . . . . . . . . . . 108
7.1. Echo Request . . . . . . . . . . . . . . . . . . . . . . 108
7.2. Echo Response . . . . . . . . . . . . . . . . . . . . . . 108
8. WTP Configuration Management . . . . . . . . . . . . . . . . 110
8.1. Configuration Consistency . . . . . . . . . . . . . . . . 110
8.1.1. Configuration Flexibility . . . . . . . . . . . . . . 111
8.2. Configuration Status . . . . . . . . . . . . . . . . . . 111
8.3. Configuration Status Response . . . . . . . . . . . . . . 112
8.4. Configuration Update Request . . . . . . . . . . . . . . 113
8.5. Configuration Update Response . . . . . . . . . . . . . . 114
8.6. Change State Event Request . . . . . . . . . . . . . . . 114
8.7. Change State Event Response . . . . . . . . . . . . . . . 116
8.8. Clear Configuration Request . . . . . . . . . . . . . . . 116
8.9. Clear Configuration Response . . . . . . . . . . . . . . 116
9. Device Management Operations . . . . . . . . . . . . . . . . 118
9.1. Firmware Management . . . . . . . . . . . . . . . . . . . 118
9.1.1. Image Data Request . . . . . . . . . . . . . . . . . 121
9.1.2. Image Data Response . . . . . . . . . . . . . . . . . 122
9.2. Reset Request . . . . . . . . . . . . . . . . . . . . . . 123
9.3. Reset Response . . . . . . . . . . . . . . . . . . . . . 123
9.4. WTP Event Request . . . . . . . . . . . . . . . . . . . . 124
9.5. WTP Event Response . . . . . . . . . . . . . . . . . . . 125
9.6. Data Transfer Request . . . . . . . . . . . . . . . . . . 125
9.7. Data Transfer Response . . . . . . . . . . . . . . . . . 126
10. Station Session Management . . . . . . . . . . . . . . . . . 127
10.1. Station Configuration Request . . . . . . . . . . . . . . 127
10.2. Station Configuration Response . . . . . . . . . . . . . 127
11. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 129
12. Security Considerations . . . . . . . . . . . . . . . . . . . 131
12.1. CAPWAP Security . . . . . . . . . . . . . . . . . . . . . 131
12.1.1. Converting Protected Data into Unprotected Data . . . 132
12.1.2. Converting Unprotected Data into Protected Data
(Insertion) . . . . . . . . . . . . . . . . . . . . . 132
12.1.3. Deletion of Protected Records . . . . . . . . . . . . 132
12.1.4. Insertion of Unprotected Records . . . . . . . . . . 132
12.2. Session ID Security . . . . . . . . . . . . . . . . . . . 132
12.3. Discovery or DTLS Setup Attacks . . . . . . . . . . . . . 133
12.4. Interference with a DTLS Session . . . . . . . . . . . . 134
12.5. Use of Preshared Keys in CAPWAP . . . . . . . . . . . . . 134
12.6. Use of Certificates in CAPWAP . . . . . . . . . . . . . . 135
12.7. AAA Security . . . . . . . . . . . . . . . . . . . . . . 136
13. Management Considerations . . . . . . . . . . . . . . . . . . 137
14. Transport Considerations . . . . . . . . . . . . . . . . . . 138
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 139
15.1. CAPWAP Message Types . . . . . . . . . . . . . . . . . . 139
15.2. Wireless Binding Identifiers . . . . . . . . . . . . . . 139
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 140
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 141
17.1. Normative References . . . . . . . . . . . . . . . . . . 141
17.2. Informational References . . . . . . . . . . . . . . . . 142
Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 143
Intellectual Property and Copyright Statements . . . . . . . . . 144
1. Introduction 1. Introduction
This document describes the CAPWAP Protocol, a standard, This document describes the CAPWAP Protocol, a standard,
interoperable protocol which enables an Access Controller (AC) to interoperable protocol which enables an Access Controller (AC) to
manage a collection of Wireless Termination Points (WTPs). The manage a collection of Wireless Termination Points (WTPs). The
CAPWAP protocol is defined to be independent of layer 2 technology. CAPWAP protocol is defined to be independent of layer 2 technology.
The emergence of centralized IEEE 802.11 Wireless Local Area Network The emergence of centralized IEEE 802.11 Wireless Local Area Network
(WLAN) architectures, in which simple IEEE 802.11 WTPs are managed by (WLAN) architectures, in which simple IEEE 802.11 WTPs are managed by
an Access Controller (AC) suggested that a standards based, an Access Controller (AC) suggested that a standards based,
skipping to change at page 6, line 36 skipping to change at page 10, line 36
T. Charles Clancy, Laboratory for Telecommunications Sciences, T. Charles Clancy, Laboratory for Telecommunications Sciences,
8080 Greenmead Drive, College Park, MD 20740 8080 Greenmead Drive, College Park, MD 20740
Phone: +1 240-373-5069, Email: clancy@ltsnet.net Phone: +1 240-373-5069, Email: clancy@ltsnet.net
Scott Kelly, Aruba Networks Scott Kelly, Aruba Networks
1322 Crossman Ave, Sunnyvale, CA 94089 1322 Crossman Ave, Sunnyvale, CA 94089
Phone: +1 408-754-8408, Email: skelly@arubanetworks.com Phone: +1 408-754-8408, Email: skelly@arubanetworks.com
1.4. Terminology 1.4. Terminology
Access Controller (AC): The network entity that provides WTPs access Access Controller (AC): The network entity that provides WTP access
to the network infrastructure in the data plane, control plane, to the network infrastructure in the data plane, control plane,
management plane, or a combination therein. management plane, or a combination therein.
CAPWAP Control Channel: A bi-directional flow defined by the AC IP CAPWAP Control Channel: A bi-directional flow defined by the AC IP
Address, WTP IP Address, AC control port, WTP control port and the Address, WTP IP Address, AC control port, WTP control port and the
transport-layer protocol (UDP or UDP-Lite) over which CAPWAP control transport-layer protocol (UDP or UDP-Lite) over which CAPWAP control
packets are sent and received. packets are sent and received.
CAPWAP Data Channel: A bi-directional flow defined by the AC IP CAPWAP Data Channel: A bi-directional flow defined by the AC IP
Address, WTP IP Address, AC data port, WTP data port, and the Address, WTP IP Address, AC data port, WTP data port, and the
transport-layer protocol (UDP or UDP-Lite) over which CAPWAP data transport-layer protocol (UDP or UDP-Lite) over which CAPWAP data
packets are sent and received. packets are sent and received.
Station (STA): A device that contains an IEEE 802.11 conformant Station (STA): A device that contains an interface to a wireless
medium access control (MAC) and physical layer (PHY) interface to the medium (WM).
wireless medium (WM).
Wireless Termination Point (WTP): The physical or network entity that Wireless Termination Point (WTP): The physical or network entity that
contains an RF antenna and wireless PHY to transmit and receive contains an RF antenna and wireless PHY to transmit and receive
station traffic for wireless access networks. station traffic for wireless access networks.
This document uses additional terminology defined in [19]. This document uses additional terminology defined in [19].
2. Protocol Overview 2. Protocol Overview
The CAPWAP protocol is a generic protocol defining AC and WTP control The CAPWAP protocol is a generic protocol defining AC and WTP control
skipping to change at page 8, line 46 skipping to change at page 12, line 46
settings. The WTP is then enabled for operation. settings. The WTP is then enabled for operation.
When the WTP and AC have completed the version and provision exchange When the WTP and AC have completed the version and provision exchange
and the WTP is enabled, the CAPWAP protocol is used to encapsulate and the WTP is enabled, the CAPWAP protocol is used to encapsulate
the wireless data frames sent between the WTP and AC. The CAPWAP the wireless data frames sent between the WTP and AC. The CAPWAP
protocol will fragment the L2 frames if the size of the encapsulated protocol will fragment the L2 frames if the size of the encapsulated
wireless user data (Data) or protocol control (Management) frames wireless user data (Data) or protocol control (Management) frames
causes the resulting CAPWAP protocol packet to exceed the MTU causes the resulting CAPWAP protocol packet to exceed the MTU
supported between the WTP and AC. Fragmented CAPWAP packets are supported between the WTP and AC. Fragmented CAPWAP packets are
reassembled to reconstitute the original encapsulated payload. MTU reassembled to reconstitute the original encapsulated payload. MTU
Discovery and Fragmentation is described in Section 3. Discovery and Fragmentation are described in Section 3.
The CAPWAP protocol provides for the delivery of commands from the AC The CAPWAP protocol provides for the delivery of commands from the AC
to the WTP for the management of stations that are communicating with 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. This may include the creation of local data structures in
the WTP for the stations and the collection of statistical the WTP for the stations and the collection of statistical
information about the communication between the WTP and the stations. information about the communication between the WTP and the stations.
The CAPWAP protocol provides a mechanism for the AC to obtain The CAPWAP protocol provides a mechanism for the AC to obtain
statistical information collected by the WTP. statistical information collected by the WTP.
skipping to change at page 9, line 26 skipping to change at page 13, line 26
accommodate the specific needs of each wireless technology in a accommodate the specific needs of each wireless technology in a
standard way. Implementation of the CAPWAP protocol for a particular standard way. Implementation of the CAPWAP protocol for a particular
wireless technology MUST follow the binding requirements defined for wireless technology MUST follow the binding requirements defined for
that technology. that technology.
When defining a binding for wireless technologies, the authors MUST When defining a binding for wireless technologies, the authors MUST
include any necessary definitions for technology-specific messages include any necessary definitions for technology-specific messages
and all technology-specific message elements for those messages. At and all technology-specific message elements for those messages. At
a minimum, a binding MUST provide: a minimum, a binding MUST provide:
1 - The definition for a binding-specific Statistics message 1. The definition for a binding-specific Statistics message element,
element, carried in the WTP Event Request message carried in the WTP Event Request message
2 - A message element carried in the Station Configuration Request 2. A message element carried in the Station Configuration Request
message to configure station information on the WTP message to configure station information on the WTP
3 - A WTP Radio Information message element carried in the 3. A WTP Radio Information message element carried in the Discovery,
Discovery, Primary Discovery and Join Request and Response Primary Discovery and Join Request and Response messages,
messages, indicating the binding specific radio types supported at indicating the binding specific radio types supported at the WTP
the WTP and AC. and AC.
If technology specific message elements are required for any of the If technology specific message elements are required for any of the
existing CAPWAP messages defined in this specification, they MUST existing CAPWAP messages defined in this specification, they MUST
also be defined in the technology binding document. also be defined in the technology binding document.
The naming of binding-specific message elements MUST begin with the The naming of binding-specific message elements MUST begin with the
name of the technology type, e.g., the binding for IEEE 802.11, name of the technology type, e.g., the binding for IEEE 802.11,
provided in [16], begins with "IEEE 802.11". provided in [16], begins with "IEEE 802.11".
The CAPWAP binding concept is also used in any future specifications The CAPWAP binding concept MUST also be used in any future
that add functionality to either the base CAPWAP protocol specification that add functionality to either the base CAPWAP
specification, or any published CAPWAP binding specification. A protocol specification, or any published CAPWAP binding
separate WTP Radio Information message element MUST be created to specification. A separate WTP Radio Information message element MUST
properly advertise support for the specification. This mechanism be created to properly advertise support for the specification. This
allows for future protocol extensibility, while providing the mechanism allows for future protocol extensibility, while providing
necessary capabilities advertisement, through the WTP Radio the necessary capabilities advertisement, through the WTP Radio
Information message element, to ensure WTP/AC interoperability. Information message element, to ensure WTP/AC interoperability.
2.2. CAPWAP Session Establishment Overview 2.2. CAPWAP Session Establishment Overview
This section describes the session establishment process message This section describes the session establishment process message
exchanges in the ideal case. The annotated ladder diagram shows the exchanges in the ideal case. The annotated ladder diagram shows the
AC on the right, the WTP on the left, and assumes the use of AC on the right, the WTP on the left, and assumes the use of
certificates for DTLS authentication. The CAPWAP Protocol State certificates for DTLS authentication. The CAPWAP Protocol State
Machine is described in detail in Section 2.3. Note that DTLS allows Machine is described in detail in Section 2.3. Note that DTLS allows
certain messages to be aggregated into a single frame, which is certain messages to be aggregated into a single frame, which is
denoted via an asterix in the following figure. denoted via an asterisk in the following figure.
============ ============ ============ ============
WTP AC WTP AC
============ ============ ============ ============
[----------- begin optional discovery ------------] [----------- begin optional discovery ------------]
Discover Request Discover Request
------------------------------------> ------------------------------------>
Discover Response Discover Response
<------------------------------------ <------------------------------------
skipping to change at page 13, line 8 skipping to change at page 17, line 8
machines. The DTLS and CAPWAP state machines are coupled through an machines. The DTLS and CAPWAP state machines are coupled through an
API consisting of commands (see Section 2.3.2.1) and notifications 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 (see Section 2.3.2.2). Certain transitions in the DTLS state machine
are triggered by commands from the CAPWAP state machine, while are triggered by commands from the CAPWAP state machine, while
certain transitions in the CAPWAP state machine are triggered by certain transitions in the CAPWAP state machine are triggered by
notifications from the DTLS state machine. notifications from the DTLS state machine.
/-------------------------------------\ /-------------------------------------\
| /-------------------------\| | /-------------------------\|
| w| || | w| ||
| 5+----------+ x +------------+ || | x+----------+ y +------------+ ||
| | Run |-->| Reset |-\|| | | Run |-->| Reset |-\||
| +----------+ +------------+ ||| | +----------+ +------------+ |||
6| u ^ ^ ^ y||| u| V ^ ^ ^ z|||
+------------+--------/ | | ||| +------------+--------/ | | |||
| Data Check | /-------/ | ||| | Data Check | /-------/ | |||
+------------+<-------\ | | ||| +------------+<-------\ | | |||
| | | ||| | | | |||
/------------------+--------\ | ||| /------------------+--------\ | |||
r| t| s| 4 v o| ||| m| t| o| q v r| |||
+--------+ +-----------+ +--------------+||| +--------+ +-----------+ +--------------+|||
| Join |---->| Configure | | Image Data |||| | Join |---->| Configure | | Image Data ||||
+--------+ q +-----------+ +--------------+||| +--------+ n +-----------+ +--------------+|||
^ p| V| x| ||| ^ |l p| s| |||
| | \-------------------\ | ||| | | \-------------------\ | |||
| \--------------------------------------\| | ||| | \--------------------------------------\| | |||
\------------------------\ || | ||| \------------------------\ || | |||
/--------------<----------------+--------------\ || | ||| /--------------<----------------+---------------\ || | |||
| /------------<-------------\ | | || | ||| | /------------<----------------+-------------\ | || | |||
| | m| |n z| vv v vvv | | i |k 8| | vv v vvv
| | +----------------+ +--------------+ +-----------+ | | +----------------+<--+--------------+ +-----------+
| | | DTLS Setup | | DTLS Connect | | DTLS TD | /---|-|---| DTLS Setup | | DTLS Connect |-->| DTLS TD |
| | +----------------+ +--------------+ +-----------+ | /-|-|---+----------------+e +--------------+ 7 +-----------+
| | g| ^ ^ |h ^ ^ | | | | d |6 ^ ^ |f ^ j| ^ |~
v v | | | | | | v v v v | | | | | | | |
| | | | | \-------\ | /-----------/ | | | | | | | \-------\ | /----+------/ |
| | | | | | | | | | | | | | | | | | \---\ |
| | v |e f| 2 v |j |k | | | | v c| 1 |5 2 v |g |h v v
| \->+------+ +------+ +-----------+ | | | \->+------+-->+------+ +-----------+ +--------+
| | Idle |-->| Disc | | Authorize | | | | | Idle | | Disc | | Authorize | | Dead |
\--->+------+ a +------+ +-----------+ | | | +------+<--+------+ +-----------+ +--------+
b| ^ |c | | | ^ 0 |3 ^
| | /----/ | | | | | |b
v d| | | | |9 |4 | |
+---------+ | | | \->+---------+<------/ |
| Sulking |<-/ | \--->| Sulking | |
3 +---------+ | +---------+a |
\---------------------------------------------------/
Figure 3: CAPWAP Integrated State Machine Figure 3: CAPWAP Integrated State Machine
The CAPWAP protocol state machine, depicted above, is used by both 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 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 implemented in one or the other of the AC or WTP), this is explicitly
called out in the transition descriptions below. For every state called out in the transition descriptions below. For every state
defined, only certain messages are permitted to be sent and received. defined, only certain messages are permitted to be sent and received.
The CAPWAP control message definitions specify the state(s) in which
The CAPWAP control messages definitions specify the state(s) in which
each message is valid. each message is valid.
Since the WTP only communicates with a single AC, it only has a Since the WTP only communicates with a single AC, it only has a
single instance of the CAPWAP state machine. The AC has a separate single instance of the CAPWAP state machine. The state machine works
instance of the CAPWAP state machine per WTP it is communicating differently on the AC since it communicates with many WTPs. The AC
with. uses the concept of two 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 the shared
services, which includes receiving and responding to Discovery
Request messages. The Listener thread handles the common tasks,
up to the DTLS Setup state. The state machine transitions in
figure Figure 3are 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.
Service Thread - The AC's Service thread handles the per-WTP
states, and one such thread exists per-WTP connection. This
thread starts during the DTLS Setup state, which is when the
DTLSListen command is invoked. 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. The state machine transitions in the above
figure are represented by alphabetic characters (including
symbols).
2.3.1. CAPWAP Protocol State Transitions 2.3.1. CAPWAP Protocol State Transitions
This section describes the various state transitions, and the events This section describes the various state transitions, and the events
that cause them. This section does not discuss interactions between that cause them. This section does not discuss interactions between
DTLS- and CAPWAP-specific states. Those interactions, and DTLS- DTLS- and CAPWAP-specific states. Those interactions, and DTLS-
specific states and transitions, are discussed in Section 2.3.2. specific states and transitions, are discussed in Section 2.3.2.
Idle to Discovery (a): This transition occurs once device Idle to Discovery (1): This transition occurs once device
initialization is complete. initialization is complete.
WTP: The WTP enters the Discovery state prior to transmitting the WTP: The WTP enters the Discovery state prior to transmitting the
first Discovery Request message (see Section 5.1). Upon first Discovery Request message (see Section 5.1). Upon
entering this state, the WTP sets the DiscoveryInterval timer entering this state, the WTP sets the DiscoveryInterval timer
(see Section 4.7). The WTP resets the DiscoveryCount counter (see Section 4.7). The WTP resets the DiscoveryCount counter
to zero (0) (see Section 4.8). The WTP also clears all to zero (0) (see Section 4.8). The WTP also clears all
information from ACs it may have received during a previous information from ACs it may have received during a previous
Discovery phase. Discovery phase.
AC: The AC does not maintain state information for the WTP upon AC: This state transition is executed by the AC's Listener
reception of the Discovery Request message, but it SHOULD thread, and occurs when a Discovery Request message is
respond with a Discovery Response message (see Section 5.2). received. The AC SHOULD respond with a Discovery Response
This transition is a no-op for the AC. message (see Section 5.2). The AC SHOULD NOT maintain WTP
state at this point (see Section 12 for more information).
Idle to Sulking (b): This transition occurs to force the WTP and AC
to enter a quiet period to avoid repeatedly attempting to
establish a connection.
WTP: The WTP enters this state when the FailedDTLSSessionCount or
the FailedDTLSAuthFailCount counter reaches
MaxFailedDTLSSessionRetry variable (see Section 4.8). Upon
entering this state, the WTP MUST start the SilentInterval
timer. While in the Sulking state, all received CAPWAP and
DTLS protocol messages received MUST be ignored.
AC: The AC enters this state with the specific WTP when the
FailedDTLSSessionCount or the FailedDTLSAuthFailCount counter
reaches MaxFailedDTLSSessionRetry variable (see Section 4.8).
Upon entering this state, the AC MUST start the SilentInterval
timer. While in the Sulking state, all received CAPWAP and
DTLS protocol messages received from the WTP MUST be ignored.
Discovery to Discovery (2): In the Discovery state, the WTP Discovery to Discovery (2): In the Discovery state, the WTP
determines which AC to connect to. determines which AC to connect to.
WTP: This transition occurs when the DiscoveryInterval timer WTP: This transition occurs when the DiscoveryInterval timer
expires. If the WTP is configured with a list of ACs, it expires. If the WTP is configured with a list of ACs, it
transmits a Discovery Request message to every AC from which it transmits a Discovery Request message to every AC from which it
has not received a Discovery Response message. For every has not received a Discovery Response message. For every
transition to this event, the WTP increments the DiscoveryCount transition to this event, the WTP increments the DiscoveryCount
counter. See Section 5.1 for more information on how the WTP counter. See Section 5.1 for more information on how the WTP
knows the ACs to which it should transmit the Discovery Request knows the ACs to which it should transmit the Discovery Request
messages. The WTP restarts the DiscoveryInterval timer messages. The WTP restarts the DiscoveryInterval timer
whenever it transmits Discovery Request messages. whenever it transmits Discovery Request messages.
AC: This is a no-op. AC: This is an invalid state transition for the AC.
Discovery to Sulking (c): This transition occurs on a WTP when Discovery to Idle (0): This transition occurs on the AC's Listener
Discovery or connectivity to the AC fails. thread when the Discovery processing is complete.
WTP: This is an invalid state transition for the WTP.
AC: This state transition is executed by the AC's Listener thread
when it has transmitted the Discovery Response, in response to
a Discovery Request.
Discovery to Sulking (3): This transition occurs on a WTP when AC
Discovery fails.
WTP: The WTP enters this state when the DiscoveryInterval timer WTP: The WTP enters this state when the DiscoveryInterval timer
expires or the DiscoveryCount variable is equal to the expires and the DiscoveryCount variable is equal to the
MaxDiscoveries variable (see Section 4.8). Upon entering this MaxDiscoveries variable (see Section 4.8). Upon entering this
state, the WTP MUST start the SilentInterval timer. While in state, the WTP MUST start the SilentInterval timer. While in
the Sulking state, all received CAPWAP protocol messages the Sulking state, all received CAPWAP protocol messages MUST
received MUST be ignored. be ignored.
AC: This is a no-op. AC: This is an invalid state transition for the AC.
Sulking to Idle (d): This transition occurs on a WTP when it must Sulking to Idle (4): This transition occurs on a WTP when it must
restart the discovery phase. restart the discovery phase.
WTP: The WTP enters this state when the SilentInterval timer (see WTP: The WTP enters this state when the SilentInterval timer (see
Section 4.7) expires. The FailedDTLSSessionCount, Section 4.7) expires. The FailedDTLSSessionCount,
DiscoveryCount and FailedDTLSAuthFailCount counters are reset DiscoveryCount and FailedDTLSAuthFailCount counters are reset
to zero. to zero.
AC: The AC enters this state when the SilentInterval timer (see AC: This is an invalid state transition for the AC.
Section 4.7) expires. The FailedDTLSSessionCount,
DiscoveryCount and FailedDTLSAuthFailCount counters are reset
to zero.
Sulking to Sulking (3): The Sulking state provides the silent Sulking to Sulking (a): The Sulking state provides the silent
period, minimizing the possibility for Denial of Service (DoS) period, minimizing the possibility for Denial of Service (DoS)
attacks. attacks.
WTP: All packets received from the AC while in the sulking state WTP: All packets received from the AC while in the sulking state
are ignored. are ignored.
AC: All packets receive from the WTP while in the sulking state AC: This is an invalid state transition for the AC.
are ignored.
Idle to DTLS Setup (e): This transition occurs to establish a secure Idle to DTLS Setup (c): This transition occurs to establish a secure
DTLS session with the peer. DTLS session with the peer.
WTP: The WTP initiates this transition by invoking the DTLSStart WTP: The WTP initiates this transition by invoking the DTLSStart
command, which starts the DTLS session establishment with the command, which starts the DTLS session establishment with the
chosen AC. When the discovery phase is bypassed, it is assumed chosen AC. When the discovery phase is bypassed, it is assumed
the WTP has a locally configured AC. the WTP has locally configured ACs.
AC: The AC initiates this transition by invoking the DTLSListen AC: The AC initiates this transition by invoking the DTLSListen
command, which informs the DTLS stack that it is willing to command (see Section 2.3.2.1), which informs the DTLS stack
listen for an incoming session. The AC MAY provide optional that it is willing to listen for an incoming session. The AC's
qualifiers in the DTLSListen command to only accept session Listener thread forks an instance of the Service thread, along
requests from specific WTPs. with a copy of the state context. If the AC had maintained WTP
state information during the Discovery exchange, or through
some other means that may include static configuration of WTPs,
the AC MAY provide optional qualifiers in the DTLSListen
command to only accept session requests a specific WTP. Note
that the AC SHOULD NOT maintain state information based on an
unsecured Discovery Request message, as this can lead to a
Denial of Service attack (see Section 12). However, in the
event that the AC does maintain state, it MUST ensure that the
state information is freed after a period, which is
implementation specific.
Discovery to DTLS Setup (f): This transition occurs to establish a Discovery to DTLS Setup (5): This transition occurs to establish a
secure DTLS session with the peer. secure DTLS session with the peer.
WTP: The WTP initiates this transition by invoking the DTLSStart WTP: The WTP initiates this transition by invoking the DTLSStart
command (see Section 2.3.2.1), which starts the DTLS session command (see Section 2.3.2.1), which starts the DTLS session
establishment with the chosen AC. The decision of which AC to establishment with the chosen AC. The decision of which AC to
connect to is the result of the discovery phase, which is connect to is the result of the discovery phase, which is
described in Section 3.3. described in Section 3.3.
AC: The AC initiates this transition by invoking the DTLSListen AC: This is an invalid state transition for the AC.
command (see Section 2.3.2.1), which informs the DTLS stack
that it is willing to listen for an incoming session. The AC
MAY have maintained state information when it received the
Discovery Request message to provide optional qualifiers in the
DTLSListen command to only accept session requests from a
specific WTP. Note that maintaining state information based on
an unsecured Discovery Request message MAY lead to a Denial of
Service attack. Therefore the AC SHOULD ensure that the state
information is freed after a period, which is implementation
specific.
DTLS Setup to Idle (g): This transition occurs when the DTLS Session DTLS Setup to Idle (6): This transition occurs when the DTLS
failed to be established. connection setup fails.
WTP: The WTP initiates this state transition when it receives a WTP: The WTP initiates this state transition when it receives a
DTLSEstablishFail notification from DTLS (see Section 2.3.2.2). DTLSEstablishFail notification from DTLS (see Section 2.3.2.2),
This error notification aborts the secure DTLS session 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 establishment. When this notification is received, the
FailedDTLSSessionCount counter is incremented. FailedDTLSSessionCount counter is incremented.
AC: The WTP initiates this state transition when it receives a AC: This is an invalid state transition for the AC.
DTLS Setup to Sulking (d): 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 Setup to Dead (b): This transition occurs on the AC when the
DTLS connection setup fails.
WTP: This is an invalid state transition for the WTP.
AC: The AC initiates this state transition when it receives a
DTLSEstablishFail notification from DTLS (see Section 2.3.2.2). DTLSEstablishFail notification from DTLS (see Section 2.3.2.2).
This error notification aborts the secure DTLS session This error notification aborts the secure DTLS session
establishment. When this notification is received, the establishment. When this notification is received, the
FailedDTLSSessionCount counter is incremented. FailedDTLSSessionCount counter is incremented. The AC must
release all resources associated with the control plane DTLS
session. The data plane DTLS session is also shutdown, 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.
DTLS Setup to Authorize (h): This transition occurs when an incoming DTLS Setup to DTLS Setup (e): This transition occurs when the DTLS
Session failed to be established.
WTP: This is an invalid state transition for the WTP.
AC: The AC initiates this state transition by the Service thread
when it receives a DTLSEstablishFail notification from DTLS
(see Section 2.3.2.2). This error notification aborts the
secure DTLS session establishment. When this notification is
received, the FailedDTLSSessionCount counter is incremented.
DTLS Setup to Authorize (f): This transition occurs when an incoming
DTLS session is being established, and the DTLS stack needs DTLS session is being established, and the DTLS stack needs
authorization to proceed with the session establishment. authorization to proceed with the session establishment.
WTP: This state transition occurs when the WTP receives the WTP: This state transition occurs when the WTP receives the
DTLSPeerAuthorize notification (see Section 2.3.2.2). Upon DTLSPeerAuthorize notification (see Section 2.3.2.2). Upon
entering this state, the WTP performs an authorization check entering this state, the WTP performs an authorization check
against the AC credentials. See Section 2.4.4 for more against the AC credentials. See Section 2.4.4 for more
information on AC authorization. information on AC authorization.
AC: This state transition occurs when the AC receives the AC: This state transition occurs when the AC receives the
DTLSPeerAuthorize notification (see Section 2.3.2.2). Upon DTLSPeerAuthorize notification (see Section 2.3.2.2). Upon
entering this state, the AC performs an authorization check entering this state, the AC performs an authorization check
against the WTP credentials. See Section 2.4.4 for more against the WTP credentials. See Section 2.4.4 for more
information on WTP authorization. information on WTP authorization.
Authorize to DTLS Connect (j): This transition occurs to notify the Authorize to DTLS Connect (g): This transition occurs to notify the
DTLS stack that the session should be established. DTLS stack that the session should be established.
WTP: This state transition occurs when the WTP has either opted WTP: This state transition occurs when the WTP has successfully
to forgo the authorization check of the AC's credentials, or authorized the AC's credentials (see Section 2.4.4). This is
the credentials were successfully authorized. This is done by done by invoking the DTLSAccept DTLS command (see
invoking the DTLSAccept DTLS command (see Section 2.3.2.1). Section 2.3.2.1).
AC: This state transition occurs when the AC has either opted to AC: This state transition occurs when the AC has successfully
forgo the authorization check of the WTP's credentials, or the authorized the WTP's credentials (see Section 2.4.4). This is
credentials were successfully authorized. This is done by done by invoking the DTLSAccept DTLS command (see
invoking the DTLSAccept DTLS command (see Section 2.3.2.1). Section 2.3.2.1).
Authorize to DTLS Teardown (k): This transition occurs to notify the Authorize to DTLS Teardown (h): This transition occurs to notify the
DTLS stack that the session should be aborted. DTLS stack that the session should be aborted.
WTP: This state transition occurs when the WTP was unable to WTP: This state transition occurs when the WTP was unable to
authorize the AC, using the AC credentials. The WTP then authorize the AC, using the AC credentials. The WTP then
aborts the DTLS session by invoking the DTLSAbortSession aborts the DTLS session by invoking the DTLSAbortSession
command (see Section 2.3.2.1). command (see Section 2.3.2.1).
AC: This state transition occurs when the AC was unable to AC: This state transition occurs when the AC was unable to
authorize the WTP, using the WTP credentials. The AC then authorize the WTP, using the WTP credentials. The AC then
aborts the DTLS session by invoking the DTLSAbortSession aborts the DTLS session by invoking the DTLSAbortSession
command (see Section 2.3.2.1). command (see Section 2.3.2.1).
DTLS Connect to Idle (m): This transition occurs when the DTLS DTLS Connect to DTLS Teardown (7): This transition occurs when the
Session failed to be established. DTLS Session failed to be established.
WTP: This state transition occurs when the WTP receives either a WTP: This state transition occurs when the WTP receives either a
DTLSAborted or DTLSAuthenticateFail notification (see DTLSAborted or DTLSAuthenticateFail notification (see
Section 2.3.2.2), indicating that the DTLS session was not Section 2.3.2.2), indicating that the DTLS session was not
successfully established. When this transition occurs due to successfully established. When this transition occurs due to
the DTLSAuthenticateFail notification, the the DTLSAuthenticateFail notification, the
FailedDTLSAuthFailCount is incremented, otherwise the FailedDTLSAuthFailCount is incremented, otherwise the
FailedDTLSSessionCount counter is incremented. FailedDTLSSessionCount counter is incremented.
AC: This is an invalid state transition for the AC.
DTLS Connect to DTLS Setup (i): This transition occurs when the DTLS
Session failed to be established.
WTP: This is an invalid state transition for the WTP.
AC: This state transition occurs when the AC receives either a AC: This state transition occurs when the AC receives either a
DTLSAborted or DTLSAuthenticateFail notification (see DTLSAborted or DTLSAuthenticateFail notification (see
Section 2.3.2.2), indicating that the DTLS session was not Section 2.3.2.2), indicating that the DTLS session was not
successfully established. When this transition occurs due to successfully established, and both of the
the DTLSAuthenticateFail notification, the FailedDTLSAuthFailCount and FailedDTLSSessionCount counters
FailedDTLSAuthFailCount is incremented, otherwise the have not reached the value of the MaxFailedDTLSSessionRetry
FailedDTLSSessionCount counter is incremented. variable (see Section 4.8).
DTLS Connect to Join (n): This transition occurs when the DTLS DTLS Connect to Dead (j): This transition occurs when the DTLS
Session failed to be established.
WTP: This is an invalid state transition for the WTP.
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 either the
FailedDTLSAuthFailCount and FailedDTLSSessionCount counters
have reached the value of the MaxFailedDTLSSessionRetry
variable (see Section 4.8).
DTLS Connect to Join (k): This transition occurs when the DTLS
Session is successfully established. Session is successfully established.
WTP: This state transition occurs when the WTP receives the WTP: This state transition occurs when the WTP receives the
DTLSEstablished notification (see Section 2.3.2.2), indicating DTLSEstablished notification (see Section 2.3.2.2), indicating
that the DTLS session was successfully established. When this that the DTLS session was successfully established. When this
notification is received, the FailedDTLSSessionCount counter is notification is received, the FailedDTLSSessionCount counter is
set to zero. set to zero.
AC: This state transition occurs when the AC receives the AC: This state transition occurs when the AC receives the
DTLSEstablished notification (see Section 2.3.2.2), indicating DTLSEstablished notification (see Section 2.3.2.2), indicating
that the DTLS session was successfully established. When this that the DTLS session was successfully established. When this
notification is received, the FailedDTLSSessionCount counter is notification is received, the FailedDTLSSessionCount counter is
set to zero, and the WaitJoin timer is started (see set to zero, and the WaitJoin timer is started (see
Section 4.7). Section 4.7).
Join to DTLS Teardown (p): This transition occurs when the join Join to DTLS Teardown (l): This transition occurs when the join
process failed. process failed.
WTP: This state transition occurs when the WTP receives a Join WTP: This state transition occurs when the WTP receives a Join
Response message with a Result Code message element containing Response message with a Result Code message element containing
an error, if the Image Identifier provided by the AC in the an error, if the Image Identifier provided by the AC in the
Join Response message differs from the WTP's currently running Join Response message differs from the WTP's currently running
firmware version and the WTP has the requested image in its firmware version and the WTP has the requested image in its
non-volatile memory, or if the WaitDTLS timer expires. This non-volatile memory, or if the WaitDTLS timer expires. This
causes the WTP to initiate the DTLSShutdown command (see causes the WTP to initiate the DTLSShutdown command (see
Section 2.3.2.1). This transition also occurs if the WTP Section 2.3.2.1). This transition also occurs if the WTP
skipping to change at page 19, line 13 skipping to change at page 24, line 43
DTLSReassemblyFailure or DTLSPeerDisconnect. DTLSReassemblyFailure or DTLSPeerDisconnect.
AC: This state transition occurs either if the WaitJoin timer AC: This state transition occurs either if the WaitJoin timer
expires or if the AC transmits a Join Response message with a expires or if the AC transmits a Join Response message with a
Result Code message element containing an error. This causes Result Code message element containing an error. This causes
the AC to initiate the DTLSShutdown command (see the AC to initiate the DTLSShutdown command (see
Section 2.3.2.1). This transition also occurs if the AC Section 2.3.2.1). This transition also occurs if the AC
receives one of the following DTLS notifications: DTLSAborted, receives one of the following DTLS notifications: DTLSAborted,
DTLSReassemblyFailure or DTLSPeerDisconnect. DTLSReassemblyFailure or DTLSPeerDisconnect.
Join to Image Data (r): This state transition is used by the WTP and Join to Image Data (m): This state transition is used by the WTP and
the AC to download executable firmware. the AC to download executable firmware.
WTP: The WTP enters the Image Data state when it receives a WTP: The WTP enters the Image Data state when it receives a
successful Join Response message and determines and the successful Join Response message and determines and the
included Image Identifier message element is not the same as included Image Identifier message element is not the same as
its currently running image. The WTP also detects that the its currently running image. The WTP also detects that the
requested image version is not currently available in the WTP's requested image version is not currently available in the WTP's
non-volatile storage (see Section 9.1 for a full description of non-volatile storage (see Section 9.1 for a full description of
the firmware download process). The WTP initializes the the firmware download process). The WTP initializes the
EchoInterval timer (see Section 4.7), and transmits the Image EchoInterval timer (see Section 4.7), and transmits the Image
Data Request message (see Section 9.1.1) requesting the start Data Request message (see Section 9.1.1) requesting the start
of the firmware download. of the firmware download.
AC: This state transition occurs when the AC receives the Image AC: This state transition occurs when the AC receives the Image
Data Request message from the WTP. The AC MUST transmit an Data Request message from the WTP. The AC MUST transmit an
Image Data Response message (see Section 9.1.2) to the WTP, Image Data Response message (see Section 9.1.2) to the WTP,
which includes a portion of the firmware. The AC MUST start which includes a portion of the firmware. The AC MUST start
the ImageDataStartTimer timer (see Section 4.7). the ImageDataStartTimer timer (see Section 4.7).
Join to Configure (q): This state transition is used by the WTP and Join to Configure (n): This state transition is used by the WTP and
the AC to exchange configuration information. the AC to exchange configuration information.
WTP: The WTP enters the Configure state when it receives a WTP: The WTP enters the Configure state when it receives a
successful Join Response, and determines that the included successful Join Response message, and determines that the
Image Identifier message element is the same as its currently included Image Identifier message element is the same as its
running image. The WTP transmits the Configuration Status currently running image. The WTP transmits the Configuration
message (see Section 8.2) to the AC with message elements Status message (see Section 8.2) to the AC with message
describing its current configuration. The WTP also starts the elements describing its current configuration. The WTP also
ResponseTimeout timer (see Section 4.7). starts the ResponseTimeout timer (see Section 4.7).
AC: This state transition occurs immediately after the AC AC: This state transition occurs immediately after the AC
transmits the Join Response message to the WTP. If the AC transmits the Join Response message to the WTP. If the AC
receives the Configuration Status message from the WTP, the AC receives the Configuration Status message from the WTP, the AC
MUST transmit a Configuration Status Response message (see MUST transmit a Configuration Status Response message (see
Section 8.3) to the WTP, and MAY include specific message Section 8.3) to the WTP, and MAY include specific message
elements to override the WTP's configuration. The WTP also elements to override the WTP's configuration. The AC also
starts the ChangeStatePendingTimer timer (see Section 4.7). starts the ChangeStatePendingTimer timer (see Section 4.7).
Configure to Reset (s): This state transition is used to reset the Configure to Reset (o): This state transition is used to reset the
connection either due to an error during the configuration phase, connection either due to an error during the configuration phase,
or when the WTP determines it needs to reset in order for the new or when the WTP determines it needs to reset in order for the new
configuration to take effect. configuration to take effect.
WTP: The WTP enters the Reset state when it receives a WTP: The WTP enters the Reset state when it receives a
Configuration Status Response indicating an error or when it Configuration Status Response message indicating an error or
determines that a reset of the WTP is required, due to the when it determines that a reset of the WTP is required, due to
characteristics of a new configuration. the characteristics of a new configuration.
AC: The AC transitions to the Reset state when it receives a AC: The AC transitions to the Reset state when it receives a
Change State Event message from the WTP that contains an error Change State Event message from the WTP that contains an error
for which AC policy does not permit the WTP to provide service. for which AC policy does not permit the WTP to provide service.
This state transition also occurs when the AC This state transition also occurs when the AC
ChangeStatePendingTimer timer expires. ChangeStatePendingTimer timer expires.
Configure to DTLS Teardown (V): This transition occurs when the Configure to DTLS Teardown (p): This transition occurs when the
configuration process aborts due to a DTLS error. configuration process aborts due to a DTLS error.
WTP: The WTP enters this state when it receives one of the WTP: The WTP enters this state when it receives one of the
following DTLS notifications: DTLSAborted, following DTLS notifications: DTLSAborted,
DTLSReassemblyFailure or DTLSPeerDisconnect (see DTLSReassemblyFailure or DTLSPeerDisconnect (see
Section 2.3.2.2). The WTP MAY tear down the DTLS session if it Section 2.3.2.2). The WTP MAY tear down the DTLS session if it
receives frequent DTLSDecapFailure notifications. receives frequent DTLSDecapFailure notifications.
AC: The AC enters this state when it receives one of the AC: The AC enters this state when it receives one of the
following DTLS notifications: DTLSAborted, following DTLS notifications: DTLSAborted,
DTLSReassemblyFailure or DTLSPeerDisconnect (see DTLSReassemblyFailure or DTLSPeerDisconnect (see
Section 2.3.2.2). The WTP MAY tear down the DTLS session if it Section 2.3.2.2). The WTP MAY tear down the DTLS session if it
receives frequent DTLSDecapFailure notifications. receives frequent DTLSDecapFailure notifications.
Image Data to Image Data (4): The Image Data state is used by the Image Data to Image Data (q): The Image Data state is used by the
WTP and the AC during the firmware download phase. WTP and the AC during the firmware download phase.
WTP: The WTP enters the Image Data state when it receives an WTP: The WTP enters the Image Data state when it receives an
Image Data Response message indicating that the AC has more Image Data Response message indicating that the AC has more
data to send. data to send.
AC: This state transition occurs when the AC receives the Image AC: This state transition occurs when the AC receives the Image
Data Request message from the WTP while already in the Image Data Request message from the WTP while already in the Image
Data state. The AC resets the ImageDataStartTimer timer. Data state. The AC resets the ImageDataStartTimer timer.
Image Data to Reset (o): This state transition is used to reset the Image Data to Reset (r): This state transition is used to reset the
DTLS connection prior to restarting the WTP after an image DTLS connection prior to restarting the WTP after an image
download. download.
WTP: When an image download completes, the WTP enters the Reset WTP: When an image download completes, the WTP enters the Reset
state. The WTP MAY also transition to this state upon state. The WTP MAY also transition to this state upon
receiving an Image Data Response message from the AC (see receiving an Image Data Response message from the AC (see
Section 9.1.2) indicating a failure. Section 9.1.2) indicating a failure.
AC: The AC enters the Reset state when an error occurs during the AC: The AC enters the Reset state when an error occurs during the
image download process or if the ImageDataStartTimer timer image download process or if the ImageDataStartTimer timer
expires. expires.
Image Data to DTLS Teardown (x): This transition occurs when the Image Data to DTLS Teardown (s): This transition occurs when the
firmware download process aborts due to a DTLS error. firmware download process aborts due to a DTLS error.
WTP: The WTP enters this state when it receives one of the WTP: The WTP enters this state when it receives one of the
following DTLS notifications: DTLSAborted, following DTLS notifications: DTLSAborted,
DTLSReassemblyFailure or DTLSPeerDisconnect (see DTLSReassemblyFailure or DTLSPeerDisconnect (see
Section 2.3.2.2). The WTP MAY tear down the DTLS session if it Section 2.3.2.2). The WTP MAY tear down the DTLS session if it
receives frequent DTLSDecapFailure notifications. receives frequent DTLSDecapFailure notifications.
AC: The AC enters this state when it receives one of the AC: The AC enters this state when it receives one of the
following DTLS notifications: DTLSAborted, following DTLS notifications: DTLSAborted,
skipping to change at page 21, line 44 skipping to change at page 27, line 26
initializes the EchoInterval timer (see Section 4.7), and initializes the EchoInterval timer (see Section 4.7), and
transmits the Change State Event Request message (see transmits the Change State Event Request message (see
Section 8.6). Section 8.6).
AC: This state transition occurs when the AC receives the Change AC: This state transition occurs when the AC receives the Change
State Event Request message (see Section 8.6) from the WTP. State Event Request message (see Section 8.6) from the WTP.
The AC responds with a Change State Event Response message (see The AC responds with a Change State Event Response message (see
Section 8.7). The AC MUST start the DataCheckTimer timer (see Section 8.7). The AC MUST start the DataCheckTimer timer (see
Section 4.7). Section 4.7).
Data Check to DTLS Teardown (6): This transition occurs when the WTP Data Check to DTLS Teardown (u): This transition occurs when the WTP
does not complete the Data Check exchange. does not complete the Data Check exchange.
WTP: This state transition occurs if the WTP does not receive the WTP: This state transition occurs if the WTP does not receive the
Change State Event Response before a CAPWAP transmission Change State Event Response message before a CAPWAP
timeout occurs. transmission timeout occurs.
AC: The AC enters this state when the DataCheckTimer timer AC: The AC enters this state when the DataCheckTimer timer
expires (see Section 4.7). expires (see Section 4.7).
Data Check to Run (u): This state transition occurs when the linkage Data Check to Run (V): This state transition occurs when the linkage
between the control and data channels has occured, causing the WTP between the control and data channels is established, causing the
and AC to enter their normal state of operation. WTP and AC to enter their normal state of operation.
WTP: The WTP enters this state when it receives a successful WTP: The WTP enters this state when it receives a successful
Change State Event Response message from the AC. The WTP Change State Event Response message from the AC. The WTP
initiates the data channel, which MAY require the establishment initiates the data channel, which MAY require the establishment
of a DTLS session, starts the DataChannelKeepAlive timer (see of a DTLS session, starts the DataChannelKeepAlive timer (see
Section 4.7) and transmits a Data Channel Keep Alive packet Section 4.7) and transmits a Data Channel Keep Alive packet
(see Section 4.4.1). The WTP then starts the (see Section 4.4.1). The WTP then starts the
DataChannelDeadInterval timer (see Section 4.7). DataChannelDeadInterval timer (see Section 4.7).
AC: This state transition occurs when the AC receives the Data AC: This state transition occurs when the AC receives the Data
Channel Keep Alive packet (see Section 4.4.1), with a Session Channel Keep Alive packet (see Section 4.4.1), with a Session
ID message element matching that included by the WTP in the ID message element matching that included by the WTP in the
Join Request message. The AC disables the DataCheckTimer Join Request message. The AC disables the DataCheckTimer
timer. Note that if AC policy is to require the data channel timer. Note that if AC policy is to require the data channel
to be encrypted, this process would also require the to be encrypted, this process would also require the
establishment of a data channel DTLS session. Upon receiving establishment of a data channel DTLS session. Upon receiving
the Data Channel Keep Alive packet, the AC transmits its own the Data Channel Keep Alive packet, the AC transmits its own
Data Channel Keep Alive packet. Data Channel Keep Alive packet.
Run to DTLS Teardown (u): This state transition occurs when an error Run to DTLS Teardown (w): This state transition occurs when an error
has occured in the DTLS stack, causing the DTLS session to be has occurred in the DTLS stack, causing the DTLS session to be
torndown. torndown.
WTP: The WTP enters this state when it receives one of the WTP: The WTP enters this state when it receives one of the
following DTLS notifications: DTLSAborted, following DTLS notifications: DTLSAborted,
DTLSReassemblyFailure or DTLSPeerDisconnect (see DTLSReassemblyFailure or DTLSPeerDisconnect (see
Section 2.3.2.2). The WTP MAY tear down the DTLS session if it Section 2.3.2.2). The WTP MAY tear down the DTLS session if it
receives frequent DTLSDecapFailure notifications. The WTP also receives frequent DTLSDecapFailure notifications. The WTP also
transitions to this state if the underlying reliable transitions to this state if the underlying reliable
transport's RetransmitCount counter has reached the transport's RetransmitCount counter has reached the
MaxRetransmit variable (see Section 4.7). MaxRetransmit variable (see Section 4.7).
AC: The AC enters this state when it receives one of the AC: The AC enters this state when it receives one of the
following DTLS notifications: DTLSAborted, following DTLS notifications: DTLSAborted,
DTLSReassemblyFailure or DTLSPeerDisconnect (see DTLSReassemblyFailure or DTLSPeerDisconnect (see
Section 2.3.2.2). The WTP MAY tear down the DTLS session if it Section 2.3.2.2). The WTP MAY tear down the DTLS session if it
receives frequent DTLSDecapFailure notifications. The AC receives frequent DTLSDecapFailure notifications. The AC
transitions to this state if the underlying reliable transitions to this state if the underlying reliable
transport's RetransmitCount counter has reached the transport's RetransmitCount counter has reached the
MaxRetransmit variable (see Section 4.7). MaxRetransmit variable (see Section 4.7).
Run to Run (5): This is the normal state of operation. Run to Run (x): This is the normal state of operation.
WTP: This is the WTP's normal state of operation. There are many WTP: This is the WTP's normal state of operation. There are many
events that result this state transition: events that result this state transition:
Configuration Update: The WTP receives a Configuration Update Configuration Update: The WTP receives a Configuration Update
Request message(see Section 8.4). The WTP MUST respond with Request message(see Section 8.4). The WTP MUST respond with
a Configuration Update Response message (see Section 8.5). a Configuration Update Response message (see Section 8.5).
Change State Event: The WTP receives a Change State Event Change State Event: The WTP receives a Change State Event
Response message, or determines that it must initiate a Response message, or determines that it must initiate a
skipping to change at page 24, line 26 skipping to change at page 30, line 10
Data Transfer: The AC receives a Data Transfer Request message Data Transfer: The AC receives a Data Transfer Request message
from the WTP (see Section 9.6) and MUST generate a from the WTP (see Section 9.6) and MUST generate a
corresponding Data Transfer Response message (see corresponding Data Transfer Response message (see
Section 9.7). Section 9.7).
Station Configuration Request: The AC sends a Station Station Configuration Request: The AC sends a Station
Configuration Request message (see Section 10.1) or receives Configuration Request message (see Section 10.1) or receives
the corresponding Station Configuration Response message the corresponding Station Configuration Response message
(see Section 10.2) from the WTP. (see Section 10.2) from the WTP.
Run to Reset (x): This state transition is used when either the AC Run to Reset (y): This state transition is used when either the AC
or WTP tear down the connection. This may occur as part of normal or WTP tear down the connection. This may occur as part of normal
operation, or due to error conditions. operation, or due to error conditions.
WTP: The WTP enters the Reset state when it receives a Reset WTP: The WTP enters the Reset state when it receives a Reset
Request message from the AC. Request message from the AC.
AC: The AC enters the Reset state when it transmits a Reset AC: The AC enters the Reset state when it transmits a Reset
Request message to the WTP. Request message to the WTP.
Reset to DTLS Teardown (y): This transition occurs when the CAPWAP Reset to DTLS Teardown (z): This transition occurs when the CAPWAP
reset is complete, to terminate the DTLS session. reset is complete, to terminate the DTLS session.
WTP: This state transition occurs when the WTP receives a Reset WTP: This state transition occurs when the WTP receives a Reset
Response message. This causes the WTP to initiate the Response message. This causes the WTP to initiate the
DTLSShutdown command (see Section 2.3.2.1). DTLSShutdown command (see Section 2.3.2.1).
AC: This state transition occurs when the AC transmits a Reset AC: This state transition occurs when the AC transmits a Reset
Response message. The AC does not invoke the DTLSShutdown Response message. The AC does not invoke the DTLSShutdown
command (see Section 2.3.2.1). command (see Section 2.3.2.1).
DTLS Teardown to Idle (z): This transition occurs when the DTLS DTLS Teardown to Idle (8): This transition occurs when the DTLS
session has been shutdown. session has been shutdown.
WTP: This state transition occurs when the WTP has successfully WTP: This state transition occurs when the WTP has successfully
cleaned up all resources associated with the control plane DTLS cleaned up all resources associated with the control plane DTLS
session. The data plane DTLS session is also shutdown, and all session. The data plane DTLS session is also shutdown, and all
resources freed, if a DTLS session was established for the data resources released, if a DTLS session was established for the
plane. Any timers set for the current instance of the state data plane. Any timers set for the current instance of the
machine are also cleared. state machine are also cleared.
AC: This is an invalid state transition for the AC.
DTLS Teardown to Sulking (9): 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 (~): This transition occurs when the DTLS
session has been shutdown.
WTP: This is an invalid state transition for the WTP.
AC: This state transition occurs when the AC has successfully AC: This state transition occurs when the AC has successfully
cleaned up all resources associated with the control plane DTLS cleaned up all resources associated with the control plane DTLS
session. The data plane DTLS session is also shutdown, and all session. The data plane DTLS session is also shutdown, and all
resources freed, if a DTLS session was established for the data resources released, if a DTLS session was established for the
plane. Any timers set for the current instance of the state data plane. Any timers set for the current instance of the
machine are also cleared. state machine are also cleared. The AC's Service thread is
terminated.
2.3.2. CAPWAP/DTLS Interface 2.3.2. CAPWAP/DTLS Interface
This section describes the DTLS Commands used by CAPWAP, and the This section describes the DTLS Commands used by CAPWAP, and the
notifications received from DTLS to the CAPWAP protocol stack. notifications received from DTLS to the CAPWAP protocol stack.
2.3.2.1. CAPWAP to DTLS Commands 2.3.2.1. CAPWAP to DTLS Commands
Six commands are defined for the CAPWAP to DTLS API. These Six commands are defined for the CAPWAP to DTLS API. These
"commands" are conceptual, and may be implemented as one or more "commands" are conceptual, and may be implemented as one or more
skipping to change at page 27, line 20 skipping to change at page 33, line 23
Section 12.4). Section 12.4).
o DTLSPeerDisconnect is sent to the CAPWAP component to indicate the o DTLSPeerDisconnect is sent to the CAPWAP component to indicate the
DTLS session has been torn down. Note that this notification is DTLS session has been torn down. Note that this notification is
only received if the DTLS session has been established. only received if the DTLS session has been established.
2.4. Use of DTLS in the CAPWAP Protocol 2.4. Use of DTLS in the CAPWAP Protocol
DTLS is used as a tightly-integrated, secure wrapper for the CAPWAP DTLS is used as a tightly-integrated, secure wrapper for the CAPWAP
protocol. In this document DTLS and CAPWAP are discussed as protocol. In this document DTLS and CAPWAP are discussed as
nominally distinct entitites; however they are very closely coupled, nominally distinct entities; however they are very closely coupled,
and may even be implemented inseparably. Since there are DTLS and may even be implemented inseparably. Since there are DTLS
library implementations currently available, and since security library implementations currently available, and since security
protocols (e.g. IPsec, TLS) are often implemented in widely protocols (e.g. IPsec, TLS) are often implemented in widely
available acceleration hardware, it is both convenient and forward- available acceleration hardware, it is both convenient and forward-
looking to maintain a modular distinction in this document. looking to maintain a modular distinction in this document.
This section describes a detailed walk-through of the interactions This section describes a detailed walk-through of the interactions
between the DTLS module and the CAPWAP module, via 'commands' (CAPWAP between the DTLS module and the CAPWAP module, via 'commands' (CAPWAP
to DTLS) and 'notifications' (DTLS to CAPWAP) as they would be to DTLS) and 'notifications' (DTLS to CAPWAP) as they would be
encountered during the normal course of operation. encountered during the normal course of operation.
skipping to change at page 28, line 37 skipping to change at page 34, line 37
(AC callout for WTP authorization (AC callout for WTP authorization
occurs in CAPWAP Auth state) occurs in CAPWAP Auth state)
[ChangeCipherSpec] [ChangeCipherSpec]
<------ Finished <------ Finished
DTLS, as specified, provides its own retransmit timers with an DTLS, as specified, provides its own retransmit timers with an
exponential back-off. However, DTLS will never terminate the exponential back-off. However, DTLS will never terminate the
handshake due to non-responsiveness; instead, DTLS will continue to handshake due to non-responsiveness; instead, DTLS will continue to
increase its back-off timer period. Hence, timing out incomplete increase its back-off timer period. Hence, timing out incomplete
DTLS handshakes is entirely the responsiblity of the CAPWAP module. DTLS handshakes is entirely the responsibility of the CAPWAP module.
The DTLS implementation used by CAPWAP MUST support TLS Session The DTLS implementation used by CAPWAP MUST support TLS Session
Resumption. Session resumption is used to establish the DTLS session Resumption. Session resumption is used to establish the DTLS session
used for the data channel. The DTLS implementation on the WTP MUST used for the data channel. The DTLS implementation on the WTP MUST
return some unique identifier to the CAPWAP module to enable return some unique identifier to the CAPWAP module to enable
subsequent establishment of a DTLS-encrypted data channel, if subsequent establishment of a DTLS-encrypted data channel, if
necessary. necessary.
2.4.2. DTLS Session Establishment 2.4.2. DTLS Session Establishment
skipping to change at page 29, line 22 skipping to change at page 35, line 22
2.4.3. DTLS Error Handling 2.4.3. DTLS Error Handling
If the AC does not respond to any DTLS messages sent by the WTP, the If the AC does not respond to any DTLS messages sent by the WTP, the
DTLS specification calls for the WTP to retransmit these messages. DTLS specification calls for the WTP to retransmit these messages.
If the WaitDTLS timer expires, CAPWAP will issue the DTLSAbortSession If the WaitDTLS timer expires, CAPWAP will issue the DTLSAbortSession
command, causing DTLS to terminate the handshake and remove any command, causing DTLS to terminate the handshake and remove any
allocated session context. Note that DTLS MAY send a single TLS allocated session context. Note that DTLS MAY send a single TLS
Alert message to the AC to indicate session termination. Alert message to the AC to indicate session termination.
If the WTP does not respond to any DTLS messages sent by the AC, the If the WTP does not respond to any DTLS messages sent by the AC, the
CAPWAP protocol allows for three possiblities, listed below. Note CAPWAP protocol allows for three possibilities, listed below. Note
that DTLS MAY send a single TLS Alert message to the AC to indicate that DTLS MAY send a single TLS Alert message to the AC to indicate
session termination. session termination.
o The message was lost in transit; in this case, the WTP will re- o The message was lost in transit; in this case, the WTP will re-
transmit its last outstanding message, since it did not receive a transmit its last outstanding message, since it did not receive a
reply. reply.
o The WTP sent a DTLS Alert, which was lost in transit; in this o The WTP sent a DTLS Alert, which was lost in transit; in this
case, the AC's WaitDTLS timer will expire, and the session will be case, the AC's WaitDTLS timer will expire, and the session will be
terminated. terminated.
skipping to change at page 31, line 29 skipping to change at page 37, line 29
o PSK key exchange algorithm - simplest method, ciphersuites use o PSK key exchange algorithm - simplest method, ciphersuites use
only symmetric key algorithms only symmetric key algorithms
o DHE_PSK key exchange algorithm - use a PSK to authenticate a o DHE_PSK key exchange algorithm - use a PSK to authenticate a
Diffie-Hellman exchange. These ciphersuites give some additional Diffie-Hellman exchange. These ciphersuites give some additional
protection against dictionary attacks and also provide Perfect protection against dictionary attacks and also provide Perfect
Forward Secrecy (PFS). Forward Secrecy (PFS).
The first approach (plain PSK) is susceptible to passive dictionary The first approach (plain PSK) is susceptible to passive dictionary
attacks; hence, while this alorithm MUST be supported, special care attacks; hence, while this algorithm MUST be supported, special care
should be taken when choosing that method. In particular, user- should be taken when choosing that method. In particular, user-
readable passphrases SHOULD NOT be used, and use of short PSKs SHOULD readable passphrases SHOULD NOT be used, and use of short PSKs SHOULD
be strongly discouraged. be strongly discouraged.
The following cryptographic algorithms MUST be supported when using The following cryptographic algorithms MUST be supported when using
preshared keys: preshared keys:
o TLS_PSK_WITH_AES_128_CBC_SHA o TLS_PSK_WITH_AES_128_CBC_SHA
o TLS_DHE_PSK_WITH_AES_128_CBC_SHA o TLS_DHE_PSK_WITH_AES_128_CBC_SHA
skipping to change at page 32, line 31 skipping to change at page 38, line 31
id-kp OBJECT IDENTIFIER ::= id-kp OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) 3 } security(5) mechanisms(5) pkix(7) 3 }
id-kp-capwapAC OBJECT IDENTIFIER ::= { id-kp 18 } id-kp-capwapAC OBJECT IDENTIFIER ::= { id-kp 18 }
id-kp-capwapWTP OBJECT IDENTIFIER ::= { id-kp 19 } id-kp-capwapWTP OBJECT IDENTIFIER ::= { id-kp 19 }
For an AC, the id-kp-capwapAC EKU MUST be present in the certificate. For an AC, the id-kp-capwapAC EKU MUST be present in the certificate.
For a WTP, the id-kp-capwapWTP EKU MUST be present in the For a WTP, the id-kp-capwapWTP EKU MUST be present in the
certificate. certificate. The id-kp-anyExtendedKeyUsage, if present, SHOULD be
ignored.
Part of the CAPWAP certificate validation process includes ensuring Part of the CAPWAP certificate validation process includes ensuring
that the proper EKU is included and allowing the CAPWAP session to be that the proper EKU is included and allowing the CAPWAP session to be
established only if the extension properly represents the device. 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.
The certificate common name (CN) for both the WTP and AC MUST be the CAPWAP implementations MUST support certificates where the common
MAC address of that device. The MAC address MUST be formatted as name (CN) for both the WTP and AC is the MAC address of that device.
ASCII HEX, e.g. 01:23:45:67:89:ab. The MAC address MUST be formatted as ASCII HEX, e.g.
01:23:45:67:89:ab. Note that the CN field MAY contain either of the
EUI-48 [22] or EUI-64 [23] MAC Address formats.
ACs and WTPs SHOULD authorize (e.g. through access control lists) ACs and WTPs MUST authorize (e.g. through access control lists)
certificates of devices to which they are connecting, based on the certificates of devices to which they are connecting, e.g., based on
MAC address and organizational information specified in the O and OU the issuer, MAC address, or organizational information specified in
fields. The identities specified in the certificates bind a the certificate. The identities specified in the certificates bind a
particular DTLS session to a specific pair of mutually-authenticated particular DTLS session to a specific pair of mutually-authenticated
and authorized MAC addresses. 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 vs. WTP), and that the
issuer of the certificate is appropriate for the domain in question.
2.4.4.4. PSK Usage 2.4.4.4. PSK Usage
When DTLS uses PSK Ciphersuites, the ServerKeyExchange message MUST When DTLS uses PSK Ciphersuites, the ServerKeyExchange message MUST
contain the "PSK identity hint" field and the ClientKeyExchange contain the "PSK identity hint" field and the ClientKeyExchange
message MUST contain the "PSK identity" field. These fields are used 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 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 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 provisioned to WTPs and ACs, both the PSK Hint and PSK Identity for
the key MUST be specified. the key MUST be specified.
skipping to change at page 34, line 20 skipping to change at page 40, line 20
is used for the CAPWAP control and data channels. is used for the CAPWAP control and data channels.
When run over IPv6, the CAPWAP control channel always uses UDP, while 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 CAPWAP data channel may use either UDP or UDP-Lite. UDP-Lite is
the default transport protocol for the CAPWAP data channel. However, the default transport protocol for the CAPWAP data channel. However,
if a middlebox or IPv4 to IPv6 gateway has been discovered, UDP is if a middlebox or IPv4 to IPv6 gateway has been discovered, UDP is
used for the CAPWAP data channel. used for the CAPWAP data channel.
This section describes how the CAPWAP protocol is carried over IP and This section describes how the CAPWAP protocol is carried over IP and
UDP/UDP-Lite transport protocols. The CAPWAP Transport Protocol UDP/UDP-Lite transport protocols. The CAPWAP Transport Protocol
message element Section 4.6.12 describes the rules to use in message element Section 4.6.15 describes the rules to use in
determing which transport protocol is to be used. determining which transport protocol is to be used.
3.1. UDP Transport 3.1. UDP Transport
One of the CAPWAP protocol requirements is to allow a WTP to reside One of the CAPWAP protocol requirements is to allow a WTP to reside
behind a middlebox, firewall and/or Network Address Translation (NAT) behind a middlebox, firewall and/or Network Address Translation (NAT)
device. Since a CAPWAP session is initiated by the WTP (client) to 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 the well-known UDP port of the AC (server), the use of UDP is a
logical choice. The UDP checksum field in CAPWAP packets MUST be set logical choice. The UDP checksum field in CAPWAP packets MUST be set
to zero. to zero.
skipping to change at page 36, line 38 skipping to change at page 42, line 38
intermediate devices. Consequently, the CAPWAP protocol can be used intermediate devices. Consequently, the CAPWAP protocol can be used
in any network configuration. in any network configuration.
3.5. MTU Discovery 3.5. MTU Discovery
Once a WTP has discovered the AC it wishes to establish a CAPWAP Once a WTP has discovered the AC it wishes to establish a CAPWAP
session with, it SHOULD perform a Path MTU (PMTU) discovery. The MTU session with, it SHOULD perform a Path MTU (PMTU) discovery. The MTU
discovered is used to configure the DTLS component (see discovered is used to configure the DTLS component (see
Section 2.3.2.1), while non-DTLS frames need to be fragmented to fit Section 2.3.2.1), while non-DTLS frames need to be fragmented to fit
the MTU, defined in Section 3.4. The procedures described in [14], the MTU, defined in Section 3.4. The procedures described in [14],
for IPv4, or [15], for IPv6 SHOULD be used. The WTP SHOULD also for IPv4, or [15], for IPv6 SHOULD be used. Alternatively,
periodically re-evaluate the MTU using the guidelines provided in implementers MAY use the procedures defined in [12]. The WTP SHOULD
these two RFCs. also periodically re-evaluate the MTU using the guidelines provided
in these two RFCs.
4. CAPWAP Packet Formats 4. CAPWAP Packet Formats
This section contains the CAPWAP protocol packet formats. A CAPWAP This section contains the CAPWAP protocol packet formats. A CAPWAP
protocol packet consists of one or more CAPWAP Transport Layer packet protocol packet consists of one or more CAPWAP Transport Layer packet
headers followed by a CAPWAP message. The CAPWAP message can be headers followed by a CAPWAP message. The CAPWAP message can be
either of type Control or Data, where Control packets carry either of type Control or Data, where Control packets carry
signaling, and Data packets carry user payloads. The CAPWAP frame signaling, and Data packets carry user payloads. The CAPWAP frame
formats for CAPWAP Data packets, and for DTLS encapsulated CAPWAP formats for CAPWAP Data packets, and for DTLS encapsulated CAPWAP
Data and Control packets are defined below. Data and Control packets are defined below.
skipping to change at page 38, line 40 skipping to change at page 44, line 40
CAPWAP Header: All CAPWAP protocol packets use a common header that CAPWAP Header: All CAPWAP protocol packets use a common header that
immediately follows the CAPWAP preamble or DTLS header. The immediately follows the CAPWAP preamble or DTLS header. The
CAPWAP Header is defined in Section 4.3. CAPWAP Header is defined in Section 4.3.
Wireless Payload: A CAPWAP protocol packet that contains a wireless Wireless Payload: A CAPWAP protocol packet that contains a wireless
payload is a CAPWAP data packet. The CAPWAP protocol does not payload is a CAPWAP data packet. The CAPWAP protocol does not
specify the format of the wireless payload, which is defined by specify the format of the wireless payload, which is defined by
the appropriate wireless standard. Additional information is in the appropriate wireless standard. Additional information is in
Section 4.4. Section 4.4.
Control Header: The CAPWAP protocol includes a signalling component, Control Header: The CAPWAP protocol includes a signaling component,
known as the CAPWAP control protocol. All CAPWAP control packets known as the CAPWAP control protocol. All CAPWAP control packets
include a Control Header, which is defined in Section 4.5.1. include a Control Header, which is defined in Section 4.5.1.
CAPWAP data packets do not contain a Control Header field. CAPWAP data packets do not contain a Control Header field.
Message Elements: A CAPWAP Control packet includes one or more Message Elements: A CAPWAP Control packet includes one or more
message elements, which are found immediately following the message elements, which are found immediately following the
Control Header. These message elements are in a Type/Length/value Control Header. These message elements are in a Type/Length/value
style header, defined in Section 4.6. style header, defined in Section 4.6.
A CAPWAP implementation MUST be capable of receiving a reassembled A CAPWAP implementation MUST be capable of receiving a reassembled
skipping to change at page 41, line 12 skipping to change at page 47, line 12
is to avoid any possible tampering of the version field in the is to avoid any possible tampering of the version field in the
preamble which is not encrypted or authenticated. preamble which is not encrypted or authenticated.
HLEN: A 5 bit field containing the length of the CAPWAP transport HLEN: A 5 bit field containing the length of the CAPWAP transport
header in 4 byte words (Similar to IP header length). This length header in 4 byte words (Similar to IP header length). This length
includes the optional headers. includes the optional headers.
RID: A 5 bit field which contains the Radio ID number for this RID: A 5 bit field which contains the Radio ID number for this
packet. Given that MAC Addresses are not necessarily unique packet. Given that MAC Addresses are not necessarily unique
across physical radios in a WTP, the Radio Identifier (RID) field across physical radios in a WTP, the Radio Identifier (RID) field
is used to indiciate which physical radio the message is is used to indicate which physical radio the message is associated
associated with. with.
WBID: A 5 bit field which is the wireless binding identifier. The WBID: A 5 bit field which is the wireless binding identifier. The
identifier will indicate the type of wireless packet type identifier will indicate the type of wireless packet associated
associated with the radio. The following values are defined: with the radio. The following values are defined:
1 - IEEE 802.11 1 - IEEE 802.11
2 - IEEE 802.16 2 - IEEE 802.16
3 - EPCGlobal 3 - EPCGlobal
T: The Type 'T' bit indicates the format of the frame being 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 transported in the payload. When this bit is set to one (1), the
payload has the native frame format indicated by the WBID field. payload has the native frame format indicated by the WBID field.
skipping to change at page 43, line 11 skipping to change at page 49, line 11
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | MAC Address | Length | MAC Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: The length of the MAC Address field [22] [23]. Length: The length of the MAC Address field [22] [23].
MAC Address: The MAC Address of the receiving radio. MAC Address: The MAC Address of the receiving radio.
Wireless Specific Information: This optional field contains Wireless Specific Information: This optional field contains
technology specific information that may be used to carry per technology specific information that may be used to carry per
packet wireless information. This field is only present if the packet wireless information. This field is only present if the
'W' bit is set. The HLEN field assumes 4 byte alignment, and this 'W' bit is set. The WBID field in the CAPWAP header is used to
field MUST be padded with zeroes (0x00) if it is not 4 byte identify the format of the wireless specific information optional
aligned. 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: The Wireless Specific Information field uses the following format:
0 1 2 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wireless ID | Length | Data | Length | Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Wireless ID: The wireless binding identifier. The following
values are defined:
1 - IEEE 802.11
2 - IEEE 802.16
3 - EPCGlobal
Length: The length of the data field Length: The length of the data field
Data: Wireless specific information, defined by the wireless Data: Wireless specific information, defined by the wireless
specific binding. specific binding specified in the CAPWAP Header's WBID field.
Payload: This field contains the header for a CAPWAP Data Message or Payload: This field contains the header for a CAPWAP Data Message or
CAPWAP Control Message, followed by the data contained in the CAPWAP Control Message, followed by the data contained in the
message. message.
4.4. CAPWAP Data Messages 4.4. CAPWAP Data Messages
There are two different types of CAPWAP data packets, CAPWAP Data There are two different types of CAPWAP data packets, CAPWAP Data
Channel Keep Alive packets and Data Payload packets. The first is Channel Keep Alive packets and Data Payload packets. The first is
used by the WTP to synchronize the control and data channels, and to used by the WTP to synchronize the control and data channels, and to
skipping to change at page 45, line 4 skipping to change at page 50, line 44
pertinent to each of the CAPWAP Data Keepalive message. The pertinent to each of the CAPWAP Data Keepalive message. The
following message elements MUST be present in this CAPWAP message: following message elements MUST be present in this CAPWAP message:
Session ID, see Section 4.6.37 Session ID, see Section 4.6.37
4.4.2. Data Payload 4.4.2. Data Payload
A CAPWAP protocol Data Payload packet encapsulates a forwarded A CAPWAP protocol Data Payload packet encapsulates a forwarded
wireless frame. The CAPWAP protocol defines two different modes of wireless frame. The CAPWAP protocol defines two different modes of
encapsulation; IEEE 802.3 and native wireless. IEEE 802.3 encapsulation; IEEE 802.3 and native wireless. IEEE 802.3
encapsulation requires that the bridging function be performed in the encapsulation requires that for 802.11 frames, the 802.11
WTP. An IEEE 802.3 encapsulated user payload frame has the following *Integration* function be performed in the WTP. An IEEE 802.3
format: encapsulated user payload frame has the following format:
+------------------------------------------------------+ +------------------------------------------------------+
| IP Header | UDP Header | CAPWAP Header | 802.3 Frame | | IP Header | UDP Header | CAPWAP Header | 802.3 Frame |
+------------------------------------------------------+ +------------------------------------------------------+
The CAPWAP protocol also defines the native wireless encapsulation The CAPWAP protocol also defines the native wireless encapsulation
mode. The format of the encapsulated CAPWAP data frame is subject to mode. The format of the encapsulated CAPWAP data frame is subject to
the rules defined by the specific wireless technology binding. Each the rules defined by the specific wireless technology binding. Each
wireless technology binding MUST contain a section entitled "Payload wireless technology binding MUST contain a section entitled "Payload
Encapsulation", which defines the format of the wireless payload that Encapsulation", which defines the format of the wireless payload that
is encapsulated within CAPWAP Data packets. is encapsulated within CAPWAP Data packets.
If the encapsulated frame would exceed the transport layer's MTU, the For 802.3 payload frames, the 802.3 frame is encapsulated (excluding
sender is responsible for fragmentation of the frame, as specified in the IEEE 802.3 FCS checksum). If the encapsulated frame would exceed
Section 3.4. the transport layer's MTU, the sender is responsible for
fragmentation of the frame, as specified in Section 3.4.
4.4.3. Establishment of a DTLS Data Channel 4.4.3. Establishment of a DTLS Data Channel
If the AC and WTP are configured to tunnel the data channel over 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 DTLS, the proper DTLS session must be initiated. To avoid having to
reauthenticate and reauthorize an AC and WTP, the DTLS data channel reauthenticate and reauthorize an AC and WTP, the DTLS data channel
MUST be initiated using the TLS session resumption feature [7]. MUST be initiated using the TLS session resumption feature [7].
When establishing the DTLS-encrypted data channel, the WTP MUST When establishing the DTLS-encrypted data channel, the WTP MUST
provide the identifier returned during the initialization of the provide the identifier returned during the initialization of the
skipping to change at page 51, line 49 skipping to change at page 57, line 49
AC IPv4 List 2 AC IPv4 List 2
AC IPv6 List 3 AC IPv6 List 3
AC Name 4 AC Name 4
AC Name with Index 5 AC Name with Index 5
AC Timestamp 6 AC Timestamp 6
Add MAC ACL Entry 7 Add MAC ACL Entry 7
Add Station 8 Add Station 8
Add Static MAC ACL Entry 9 Add Static MAC ACL Entry 9
CAPWAP Control IPV4 Address 10 CAPWAP Control IPV4 Address 10
CAPWAP Control IPV6 Address 11 CAPWAP Control IPV6 Address 11
CAPWAP Transport Protocol TBD
CAPWAP Local IPV4 Address TBD CAPWAP Local IPV4 Address TBD
CAPWAP Local IPV6 Address TBD CAPWAP Local IPV6 Address TBD
CAPWAP Timers 12 CAPWAP Timers 12
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
Delete Static MAC ACL Entry 19
Discovery Type 20
Duplicate IPv4 Address 21
Duplicate IPv6 Address 22
Idle Timeout 23
Image Data 24
Image Identifier 25
Image Info 26
Initiate Download 27
Location Data 28
Maximum Message Length 29
CAPWAP Message Element Type Value
AC Descriptor 1
AC IPv4 List 2
AC IPv6 List 3
AC Name 4
AC Name with Index 5
AC Timestamp 6
Add MAC ACL Entry 7
Add Station 8
Add Static MAC ACL Entry 9
CAPWAP Control IPV4 Address 10
CAPWAP Control IPV6 Address 11
CAPWAP Transport Protocol TBD CAPWAP Transport Protocol TBD
CAPWAP Local IPV4 Address TBD
CAPWAP Local IPV6 Address TBD
CAPWAP Timers 12
Data Transfer Data 13 Data Transfer Data 13
Data Transfer Mode 14 Data Transfer Mode 14
Decryption Error Report 15 Decryption Error Report 15
Decryption Error Report Period 16 Decryption Error Report Period 16
Delete MAC ACL Entry 17 Delete MAC ACL Entry 17
Delete Station 18 Delete Station 18
Delete Static MAC ACL Entry 19 Delete Static MAC ACL Entry 19
Discovery Type 20 Discovery Type 20
Duplicate IPv4 Address 21 Duplicate IPv4 Address 21
Duplicate IPv6 Address 22 Duplicate IPv6 Address 22
skipping to change at page 53, line 4 skipping to change at page 58, line 16
Data Transfer Mode 14 Data Transfer Mode 14
Decryption Error Report 15 Decryption Error Report 15
Decryption Error Report Period 16 Decryption Error Report Period 16
Delete MAC ACL Entry 17 Delete MAC ACL Entry 17
Delete Station 18 Delete Station 18
Delete Static MAC ACL Entry 19 Delete Static MAC ACL Entry 19
Discovery Type 20 Discovery Type 20
Duplicate IPv4 Address 21 Duplicate IPv4 Address 21
Duplicate IPv6 Address 22 Duplicate IPv6 Address 22
Idle Timeout 23 Idle Timeout 23
Image Data 24 Image Data 24
Image Identifier 25 Image Identifier 25
Image Info 26 Image Info 26
Initiate Download 27 Initiate Download 27
Location Data 28 Location Data 28
Maximum Message Length 29 Maximum Message Length 29
Radio Administrative State 31
Radio Operational State 32
Result Code 33
Returned Message Element 34
Session ID 35
Statistics Timer 36
Vendor Specific Payload 37
WTP Board Data 38
WTP Descriptor 39
WTP Fallback 40
WTP Frame Tunnel Mode 41
WTP IPv4 IP Address 42
WTP IPv6 IP Address 43
WTP MAC Type 44
WTP Name 45
WTP Operational Statistics 46
WTP Radio Statistics 47
WTP Reboot Statistics 48
WTP Static IP Address Information 49
4.6.1. AC Descriptor 4.6.1. AC Descriptor
The AC Descriptor message element is used by the AC to communicate The AC Descriptor message element is used by the AC to communicate
its current state. The value contains the following fields. its current state. The value contains the following fields.
0 1 2 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 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 | | Stations | Limit |
skipping to change at page 54, line 4 skipping to change at page 59, line 36
Type: 1 for AC Descriptor Type: 1 for AC Descriptor
Length: >= 12 Length: >= 12
Stations: The number of stations currently served by the AC Stations: The number of stations currently served by the AC
Limit: The maximum number of stations supported by the AC Limit: The maximum number of stations supported by the AC
Active WTPs: The number of WTPs currently attached to the AC Active WTPs: The number of WTPs currently attached to the AC
Max WTPs: The maximum number of WTPs supported by the AC Max WTPs: The maximum number of WTPs supported by the AC
Security: A 8 bit bit mask specifying the authentication credential Security: A 8 bit mask specifying the authentication credential
type supported by the AC. The following values are supported (see type supported by the AC. The following values are supported (see
Section 2.4.4): Section 2.4.4):
1 - X.509 Certificate Based 1 - X.509 Certificate Based
2 - Pre-Shared Secret 2 - Pre-Shared Secret
R-MAC Field: The AC supports the optional Radio MAC Address field R-MAC Field: The AC supports the optional Radio MAC Address field
in the CAPWAP transport Header (see Section 4.3). in the CAPWAP transport Header (see Section 4.3).
skipping to change at page 58, line 40 skipping to change at page 64, line 25
containing the VLAN Name on which the WTP is to locally bridge containing the VLAN Name on which the WTP is to locally bridge
user data. Note this field is only valid with WTPs configured in user data. Note this field is only valid with WTPs configured in
Local MAC mode. Local MAC mode.
4.6.9. Add Static MAC ACL Entry 4.6.9. Add Static MAC ACL Entry
The Add Static MAC ACL Entry message element is used by an AC to add The Add Static MAC ACL Entry message element is used by an AC to add
a permanent ACL entry on a WTP, ensuring that the WTP no longer a permanent ACL entry on a WTP, ensuring that the WTP no longer
provides any service to the MAC addresses provided in the message. provides any service to the MAC addresses provided in the message.
The MAC Addresses provided in this message element are expected to be The MAC Addresses provided in this message element are expected to be
saved in non-volative memory on the WTP. saved in non-volatile memory on the WTP.
0 1 2 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 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 ... | Num of Entries| Length | MAC Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 9 for Add Static MAC ACL Entry Type: 9 for Add Static MAC ACL Entry
Length: >= 8 Length: >= 8
Num of Entries: The number of instances of the Type/MAC Addresses Num of Entries: The number of instances of the Type/MAC Addresses
fields in the array. fields in the array.
Length: The length of the MAC Address field. Length: The length of the MAC Address field.
MAC Address: MAC Addresses to add to the permanent ACL. MAC Address: MAC Addresses to add to the permanent ACL.
4.6.10. CAPWAP Control IPv4 Address 4.6.10. CAPWAP Control IPv4 Address
skipping to change at page 60, line 27 skipping to change at page 66, line 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 11 for CAPWAP Control IPv6 Address Type: 11 for CAPWAP Control IPv6 Address
Length: 18 Length: 18
IP Address: The IP Address of an interface. IP Address: The IP Address of an interface.
WTP Count: The number of WTPs currently connected to the interface. WTP Count: The number of WTPs currently connected to the interface.
4.6.12. CAPWAP Transport Protocol 4.6.12. CAPWAP Local IPv4 Address
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 Configuration Status Request or Image
Data Request message if the CAPWAP message was received over IPv6,
and the CAPWAP Local IPv6 Address message element (see
Section 4.6.14) is present and the address matches the packet's
source IP address.
Upon receiving the Configuration Status Request or Image Data Request
message, the WTP MAY set the CAPWAP Transport Protocol to UDP-Lite in
the Configuration Status Response or Image Data Response message if
the message was received over IPv6, and the CAPWAP Local IPv6 Address
message element (see Section 4.6.14) is present and the address
matches the packet's source IP address.
For any other condition, the CAPWAP Transport Protocol MUST be set to
UDP.
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Transport |
+-+-+-+-+-+-+-+-+
Type: TBD for CAPWAP Transport Protocol
Length: 1
Transport: The transport to use for the CAPWAP data channel.
1 - UDP-Lite The UDP-Lite transport protocol is to be used for
the CAPWAP data channel. Note that this option is illegal is
either the WTP or the AC uses IPv4.
2 - UDP The UDP transport protocol is to be used for the CAPWAP
data channel.
4.6.13. CAPWAP Local IPv4 Address
The CAPWAP Local IPv4 Address message element is sent by either the The CAPWAP Local IPv4 Address message element is sent by either the
WTP or the AC in the Join Request, Configuration Status Request or WTP or the AC in the Join Request, Configuration Status Request or
Image Data Request message in order to communicate the IP Address of Image Data Request message in order to communicate the IP Address of
the transmitter. The receiver uses this to determine whether a the transmitter. The receiver uses this to determine whether a
middlebox exists between the two peers, by comparing the source IP middlebox exists between the two peers, by comparing the source IP
address of the packet against the value of the message element. address of the packet against the value of the message element.
0 1 2 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 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD for CAPWAP Local IPv4 Address Type: TBD for CAPWAP Local IPv4 Address
Length: 4 Length: 4
IP Address: The IP Address of the sender. IP Address: The IP Address of the sender.
4.6.14. CAPWAP Local IPv6 Address 4.6.13. CAPWAP Local IPv6 Address
The CAPWAP Local IPv6 Address message element is sent by either the The CAPWAP Local IPv6 Address message element is sent by either the
WTP or the AC in the Discovery Response or Join Request in order to WTP or the AC in the Discovery Response or Join Request in order to
communicate the IP Address of the transmitter. The receiver uses communicate the IP Address of the transmitter. The receiver uses
this to determine whether a middlebox exists between the two peers, this to determine whether a middlebox exists between the two peers,
by comparing the source IP address of the packet against the value of by comparing the source IP address of the packet against the value of
the message element. the message element.
0 1 2 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 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
skipping to change at page 62, line 20 skipping to change at page 67, line 4
| IP Address | | IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address | | IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address | | IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD for CAPWAP Local IPv6 Address Type: TBD for CAPWAP Local IPv6 Address
Length: 16 Length: 16
IP Address: The IP Address of the sender. IP Address: The IP Address of the sender.
4.6.15. CAPWAP Timers 4.6.14. CAPWAP Timers
The CAPWAP Timers message element is used by an AC to configure The CAPWAP Timers message element is used by an AC to configure
CAPWAP timers on a WTP. CAPWAP timers on a WTP.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discovery | Echo Request | | Discovery | Echo Request |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 62, line 45 skipping to change at page 67, line 28
Length: 2 Length: 2
Discovery: The number of seconds between CAPWAP Discovery messages, Discovery: The number of seconds between CAPWAP Discovery messages,
when the WTP is in the discovery phase. when the WTP is in the discovery phase.
Echo Request: The number of seconds between WTP Echo Request CAPWAP Echo Request: The number of seconds between WTP Echo Request CAPWAP
messages. The default value for this message element is specified messages. The default value for this message element is specified
in Section 4.7.7. in Section 4.7.7.
4.6.15. 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 Configuration Status Request or Image
Data Request message if the CAPWAP message was received over IPv6,
and the CAPWAP Local IPv6 Address message element (see
Section 4.6.13) is present and the address matches the packet's
source IP address.
Upon receiving the Configuration Status Request or Image Data Request
message, the WTP MAY set the CAPWAP Transport Protocol to UDP-Lite in
the Configuration Status Response or Image Data Response message if
the message was received over IPv6, and the CAPWAP Local IPv6 Address
message element (see Section 4.6.13) is present and the address
matches the packet's source IP address.
For any other condition, the CAPWAP Transport Protocol MUST be set to
UDP.
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Transport |
+-+-+-+-+-+-+-+-+
Type: TBD for CAPWAP Transport Protocol
Length: 1
Transport: The transport to use for the CAPWAP data channel.
1 - UDP-Lite The UDP-Lite transport protocol is to be used for
the CAPWAP data channel. Note that this option is illegal is
either the WTP or the AC uses IPv4.
2 - UDP The UDP transport protocol is to be used for the CAPWAP
data channel.
4.6.16. Data Transfer Data 4.6.16. Data Transfer Data
The Data Transfer Data message element is used by the WTP to provide The Data Transfer Data message element is used by the WTP to provide
information to the AC for debugging purposes. information to the AC for debugging purposes.
0 1 2 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Type | Data Length | Data .... | Data Type | Data Length | Data ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 71, line 4 skipping to change at page 76, line 30
| File Size | | File Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hash | | Hash |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hash | | Hash |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hash | | Hash |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hash | | Hash |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 26 for Image Information Type: 26 for Image Information
Length: 18 Length: 18
File Size: A 32-bit value containing the size of the file, in File Size: A 32-bit value containing the size of the file, in
bytes, that will be transfered by the AC to the WTP. bytes, that will be transferred by the AC to the WTP.
Hash: A 16 octet hash of the image. The hash is computed using Hash: A 16 octet hash of the image. The hash is computed using
MD5, using the following pseudo-code: MD5, using the following pseudo-code:
#include <md5.h> #include <md5.h>
CapwapCreateHash(char *hash, char *image, int image_len) CapwapCreateHash(char *hash, char *image, int image_len)
{ {
MD_CTX context; MD_CTX context;
MDInit (&context); MDInit (&context);
skipping to change at page 72, line 25 skipping to change at page 78, line 4
length that it supports to the AC. The Maximum Message Length length that it supports to the AC. The Maximum Message Length
message element is optionally included in Join Response message by message element is optionally included in Join Response message by
the AC to indicate the maximum CAPWAP message length that it supports the AC to indicate the maximum CAPWAP message length that it supports
to the WTP. to the WTP.
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Maximum Message Length | | Maximum Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type: 29 for Maximum Message Length
Type: 29 for Maximim Message Length
Length: 2 Length: 2
Maximum Message Length An 16-bit unsigned integer indicating the Maximum Message Length An 16-bit unsigned integer indicating the
maximum message length. maximum message length.
4.6.33. Radio Administrative State 4.6.33. Radio Administrative State
The Radio Administrative State message element is used to communicate The Radio Administrative State message element is used to communicate
the state of a particular radio. The Radio Administrative State the state of a particular radio. The Radio Administrative State
skipping to change at page 77, line 17 skipping to change at page 82, line 41
Length: 2 Length: 2
Statistics Timer: A 16-bit unsigned integer indicating the time, in Statistics Timer: A 16-bit unsigned integer indicating the time, in
seconds. The default value for this timer is specified in seconds. The default value for this timer is specified in
Section 4.7.14. Section 4.7.14.
4.6.39. Vendor Specific Payload 4.6.39. Vendor Specific Payload
The Vendor Specific Payload message element is used to communicate The Vendor Specific Payload message element is used to communicate
vendor specific information between the WTP and the AC. The message vendor specific information between the WTP and the AC. The Vendor
element uses the following format: Specific Payload message element MAY be present in any CAPWAP
message. The message element uses the following format:
0 1 2 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 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 | | Vendor Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Element ID | Value... | | Element ID | Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 37 for Vendor Specific Type: 37 for Vendor Specific
Length: >= 7 Length: >= 7
Vendor Identifier: A 32-bit value containing the IANA assigned "SMI Vendor Identifier: A 32-bit value containing the IANA assigned "SMI
Network Management Private Enterprise Codes" [18] Network Management Private Enterprise Codes" [18]
Element ID: A 16-bit Element Identifier which is managed by the Element ID: A 16-bit Element Identifier which is managed by the
vendor. vendor.
skipping to change at page 78, line 37 skipping to change at page 84, line 9
Type: The following values are supported: Type: The following values are supported:
0 - WTP Model Number: The WTP Model Number MUST be included in 0 - WTP Model Number: The WTP Model Number MUST be included in
the WTP Board Data message element. the WTP Board Data message element.
1 - WTP Serial Number: The WTP Serial Number MUST be included in 1 - WTP Serial Number: The WTP Serial Number MUST be included in
the WTP Board Data message element. the WTP Board Data message element.
2 - Board ID: A hardware identifier, which MAY be included in 2 - Board ID: A hardware identifier, which MAY be included in
the WTP Board Data mesage element. the WTP Board Data message element.
3 - Board Revision A revision number of the board, which MAY be 3 - Board Revision A revision number of the board, which MAY be
included in the WTP Board Data message element. included in the WTP Board Data message element.
4 - Base MAC Addres The WTP's Base MAC Address, which MAY be 4 - Base MAC Address The WTP's Base MAC Address, which MAY be
assigned to the primary Ethernet interface. assigned to the primary Ethernet interface.
4.6.41. WTP Descriptor 4.6.41. WTP Descriptor
The WTP Descriptor message element is used by a WTP to communicate The WTP Descriptor message element is used by a WTP to communicate
its current hardware and software (firmware) configuration. The its current hardware and software (firmware) configuration. The
value contains the following fields. value contains the following fields.
0 1 2 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 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
skipping to change at page 91, line 6 skipping to change at page 96, line 21
message. This timer MUST be greater than 30 seconds. message. This timer MUST be greater than 30 seconds.
Default: 60 Default: 60
4.8. CAPWAP Protocol Variables 4.8. CAPWAP Protocol Variables
A WTP or AC that implements the CAPWAP Discovery phase MUST allow for A WTP or AC that implements the CAPWAP Discovery phase MUST allow for
the following variables to be configured by system management; the following variables to be configured by system management;
default values are specified, making explicit configuration default values are specified, making explicit configuration
unnecessary in many cases. If the default values are explicitly unnecessary in many cases. If the default values are explicitly
overriden by the AC, the WTP MUST save the values sent by the AC. overridden by the AC, the WTP MUST save the values sent by the AC.
4.8.1. AdminState 4.8.1. AdminState
The default Administrative State value is enabled (1). The default Administrative State value is enabled (1).
4.8.2. DiscoveryCount 4.8.2. DiscoveryCount
The number of Discovery Request messages transmitted by a WTP to a The number of Discovery Request messages transmitted by a WTP to a
single AC. This is a monotonically increasing counter. single AC. This is a monotonically increasing counter.
skipping to change at page 95, line 27 skipping to change at page 100, line 27
o WTP Descriptor, see Section 4.6.41 o WTP Descriptor, see Section 4.6.41
o WTP Frame Tunnel Mode, see Section 4.6.43 o WTP Frame Tunnel Mode, see Section 4.6.43
o WTP MAC Type, see Section 4.6.46 o WTP MAC Type, see Section 4.6.46
o WTP Radio Information message element(s)that the WTP supports; o WTP Radio Information message element(s)that the WTP supports;
These are defined by the individual link layer CAPWAP Binding These are defined by the individual link layer CAPWAP Binding
Protocols (see Section 2.1). Protocols (see Section 2.1).
The following message elements MAY be included in the Discovery
Request message:
o Vendor Specific Payload, see Section 4.6.39
5.2. Discovery Response Message 5.2. Discovery Response Message
The Discovery Response message provides a mechanism for an AC to The Discovery Response message provides a mechanism for an AC to
advertise its services to requesting WTPs. advertise its services to requesting WTPs.
When a WTP receives a Discovery Response message, it MUST wait for an When a WTP receives a Discovery Response message, it MUST wait for an
interval not less than DiscoveryInterval for receipt of additional interval not less than DiscoveryInterval for receipt of additional
Discovery Response messages. After the DiscoveryInterval elapses, Discovery Response messages. After the DiscoveryInterval elapses,
the WTP enters the DTLS-Init state and selects one of the ACs that 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 sent a Discovery Response message and send a DTLS Handshake to that
skipping to change at page 96, line 23 skipping to change at page 101, line 28
These are defined by the individual link layer CAPWAP Binding These are defined by the individual link layer CAPWAP Binding
Protocols (see Section 2.1 for more information). Protocols (see Section 2.1 for more information).
o One of the following message elements MUST be included in the o One of the following message elements MUST be included in the
Discovery Response Message: Discovery Response Message:
* CAPWAP Control IPv4 Address, see Section 4.6.10 * CAPWAP Control IPv4 Address, see Section 4.6.10
* CAPWAP Control IPv6 Address, see Section 4.6.11 * CAPWAP Control IPv6 Address, see Section 4.6.11
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 5.3. Primary Discovery Request Message
The Primary Discovery Request message is sent by the WTP to determine The Primary Discovery Request message is sent by the WTP to determine
whether its preferred (or primary) AC is available. whether its preferred (or primary) AC is available.
A Primary Discovery Request message is sent by a WTP when it has a A Primary Discovery Request message is sent by a WTP when it has a
primary AC configured, and is connected to another AC. This 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 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 a means to discover when its primary AC becomes available. Since the
WTP only has a single instance of the CAPWAP state machine, the WTP only has a single instance of the CAPWAP state machine, the
skipping to change at page 97, line 4 skipping to change at page 102, line 13
source address of the received Primary Discovery Request message. source address of the received Primary Discovery Request message.
The following message elements MUST be included in the Primary The following message elements MUST be included in the Primary
Discovery Request message. Discovery Request message.
o Discovery Type, see Section 4.6.23 o Discovery Type, see Section 4.6.23
o WTP Board Data, see Section 4.6.40 o WTP Board Data, see Section 4.6.40
o WTP Descriptor, see Section 4.6.41 o WTP Descriptor, see Section 4.6.41
o WTP Frame Tunnel Mode, see Section 4.6.43 o WTP Frame Tunnel Mode, see Section 4.6.43
o WTP MAC Type, see Section 4.6.46 o WTP MAC Type, see Section 4.6.46
o WTP Radio Information message element(s)that the WTP supports; o WTP Radio Information message element(s)that the WTP supports;
These are defined by the individual link layer CAPWAP Binding These are defined by the individual link layer CAPWAP Binding
Protocols (see Section 2.1 for more information). Protocols (see Section 2.1 for more information).
The following message elements MAY be included in the Primary
Discovery Request message:
o Vendor Specific Payload, see Section 4.6.39
5.4. Primary Discovery Response 5.4. Primary Discovery Response
The Primary Discovery Response message enables an AC to advertise its The Primary Discovery Response message enables an AC to advertise its
availability and services to requesting WTPs that are configured to availability and services to requesting WTPs that are configured to
have the AC as its primary AC. have the AC as its primary AC.
The Primary Discovery Response message is sent by an AC after The Primary Discovery Response message is sent by an AC after
receiving a Primary Discovery Request message. receiving a Primary Discovery Request message.
When a WTP receives a Primary Discovery Response message, it may When a WTP receives a Primary Discovery Response message, it may
skipping to change at page 98, line 5 skipping to change at page 103, line 13
These are defined by the individual link layer CAPWAP Binding These are defined by the individual link layer CAPWAP Binding
Protocols (see Section 2.1 for more information). Protocols (see Section 2.1 for more information).
One of the following message elements MUST be included in the One of the following message elements MUST be included in the
Discovery Response Message: Discovery Response Message:
o CAPWAP Control IPv4 Address, see Section 4.6.10 o CAPWAP Control IPv4 Address, see Section 4.6.10
o CAPWAP Control IPv6 Address, see Section 4.6.11 o CAPWAP Control IPv6 Address, see Section 4.6.11
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 6. CAPWAP Join Operations
The Join Request message is used by a WTP to request service from an 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 AC after a DTLS connection is established to that AC. The Join
Response message is used by the the AC to indicate that it will or Response message is used by the AC to indicate that it will or will
will not provide service. not provide service.
6.1. Join Request 6.1. Join Request
The Join Request message is used by a WTP to request service through The Join Request message is used by a WTP to request service through
the AC. A Join Request message is sent by a WTP after (optionally) the AC. A Join Request message is sent by a WTP after (optionally)
receiving one or more Discovery Response messages, and completion of receiving one or more Discovery Response messages, and completion of
DTLS session establishment. When an AC receives a Join Request DTLS session establishment. When an AC receives a Join Request
message it responds with a Join Response message. message it responds with a Join Response message.
Upon completion of the DTLS handshake, and receiving the Upon completion of the DTLS handshake, and receiving the
skipping to change at page 99, line 34 skipping to change at page 105, line 34
message. message.
o Maximum Message Length, see Section 4.6.32 o Maximum Message Length, see Section 4.6.32
o WTP Reboot Statistics, see Section 4.6.50 o WTP Reboot Statistics, see Section 4.6.50
o WTP IPv4 IP Address, see Section 4.6.44 o WTP IPv4 IP Address, see Section 4.6.44
o WTP IPv6 IP Address, see Section 4.6.45 o WTP IPv6 IP Address, see Section 4.6.45
o Vendor Specific Payload, see Section 4.6.39
6.2. Join Response 6.2. Join Response
The Join Response message is sent by the AC to indicate to a WTP that 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. it is capable and willing to provide service to the WTP.
The WTP, receiving a Join Response message, checks for success or The WTP, receiving a Join Response message, checks for success or
failure. If the message indicates success, the WTP clears the failure. If the message indicates success, the WTP clears the
WaitDTLS timer for the session and proceeds to the Configure state. WaitDTLS timer for the session and proceeds to the Configure state.
If the WaitDTLS Timer expires prior to reception of the Join Response If the WaitDTLS Timer expires prior to reception of the Join Response
skipping to change at page 100, line 29 skipping to change at page 106, line 31
message. message.
o AC IPv4 List, see Section 4.6.2 o AC IPv4 List, see Section 4.6.2
o AC IPv6 List, see Section 4.6.3 o AC IPv6 List, see Section 4.6.3
o Image Identifier, see Section 4.6.28 o Image Identifier, see Section 4.6.28
o Maximum Message Length, see Section 4.6.32 o Maximum Message Length, see Section 4.6.32
o Vendor Specific Payload, see Section 4.6.39
The following message elements MUST be included in the Join Response The following message elements MUST be included in the Join Response
message. message.
o Result Code, see Section 4.6.35 o Result Code, see Section 4.6.35
o AC Descriptor, see Section 4.6.1 o AC Descriptor, see Section 4.6.1
o AC Name, see Section 4.6.4 o AC Name, see Section 4.6.4
o WTP Radio Information message element(s)that the AC supports; o WTP Radio Information message element(s)that the AC supports;
skipping to change at page 101, line 27 skipping to change at page 108, line 27
messages. messages.
Echo Request messages are sent periodically by a WTP in the Run state Echo Request messages are sent periodically by a WTP in the Run state
(see Section 2.3) to determine the state of the control connection (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 between the WTP and the AC. The Echo Request message is sent by the
WTP when the EchoInterval timer expires. WTP when the EchoInterval timer expires.
The Echo Request message is sent by the WTP when in the Run State. The Echo Request message is sent by the WTP when in the Run State.
The AC does not transmit this message. The AC does not transmit this message.
The Echo Request message carries no message elements. 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 When an AC receives an Echo Request message it responds with an Echo
Response message. Response message.
7.2. Echo Response 7.2. Echo Response
The Echo Response message acknowledges the Echo Request message. The Echo Response message acknowledges the Echo Request message.
An Echo Response message is sent by an AC after receiving an Echo An Echo Response message is sent by an AC after receiving an Echo
Request message. After transmitting the Echo Response message, the Request message. After transmitting the Echo Response message, the
AC SHOULD reset its EchoInterval timer. If another Echo Request AC SHOULD reset its EchoInterval timer. If another Echo Request
message or other control message is not received by the AC when the 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 timer expires, the AC SHOULD consider the WTP to be no longer
reachable. reachable.
The Echo Response message is sent by the AC when in the Run State. The Echo Response message is sent by the AC when in the Run State.
The WTP does not transmit this message. The WTP does not transmit this message.
The Echo Response message carries no message elements. 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 When a WTP receives an Echo Response message it initializes the
EchoInterval to the configured value. EchoInterval to the configured value.
8. WTP Configuration Management 8. WTP Configuration Management
WTP Configuration messages are used to exchange configuration WTP Configuration messages are used to exchange configuration
information between the AC and the WTP. information between the AC and the WTP.
8.1. Configuration Consistency 8.1. Configuration Consistency
skipping to change at page 104, line 7 skipping to change at page 112, line 7
o Statistics Timer, see Section 4.6.38 o Statistics Timer, see Section 4.6.38
o WTP Reboot Statistics, see Section 4.6.50 o WTP Reboot Statistics, see Section 4.6.50
The following message elements MAY be included in the Configuration The following message elements MAY be included in the Configuration
Status message. Status message.
o WTP Static IP Address Information, see Section 4.6.51 o WTP Static IP Address Information, see Section 4.6.51
o Vendor Specific Payload, see Section 4.6.39
8.3. Configuration Status Response 8.3. Configuration Status Response
The Configuration Status Response message is sent by an AC and The Configuration Status Response message is sent by an AC and
provides a mechanism for the AC to override a WTP's requested provides a mechanism for the AC to override a WTP's requested
configuration. configuration.
A Configuration Status Response message is sent by an AC after A Configuration Status Response message is sent by an AC after
receiving a Configuration Request message. receiving a Configuration Request message.
The Configuration Status Response message carries binding specific The Configuration Status Response message carries binding specific
skipping to change at page 104, line 37 skipping to change at page 112, line 39
The Configuration Status Response message is sent by the AC when in The Configuration Status Response message is sent by the AC when in
the Configure State. The WTP does not transmit this message. the Configure State. The WTP does not transmit this message.
The following message elements MUST be included in the Configuration The following message elements MUST be included in the Configuration
Status Response message. Status Response message.
o AC IPv4 List, see Section 4.6.2 o AC IPv4 List, see Section 4.6.2
o AC IPv6 List, see Section 4.6.3 o AC IPv6 List, see Section 4.6.3
o CAPWAP Timers, see Section 4.6.15 o CAPWAP Timers, see Section 4.6.14
o Decryption Error Report Period, see Section 4.6.19 o Decryption Error Report Period, see Section 4.6.19
o Idle Timeout, see Section 4.6.26 o Idle Timeout, see Section 4.6.26
o WTP Fallback, see Section 4.6.42 o WTP Fallback, see Section 4.6.42
The following message element MAY be included in the Configuration The following message element MAY be included in the Configuration
Status Response message. Status Response message.
o WTP Static IP Address Information, see Section 4.6.51 o WTP Static IP Address Information, see Section 4.6.51
o Vendor Specific Payload, see Section 4.6.39
8.4. Configuration Update Request 8.4. Configuration Update Request
Configuration Update Request messages are sent by the AC to provision Configuration Update Request messages are sent by the AC to provision
the WTP while in the Run state. This is used to modify the the WTP while in the Run state. This is used to modify the
configuration of the WTP while it is operational. configuration of the WTP while it is operational.
When a WTP receives a Configuration Update Request message, it When a WTP receives a Configuration Update Request message, it
responds with a Configuration Update Response message, with a Result responds with a Configuration Update Response message, with a Result
Code message element indicating the result of the configuration Code message element indicating the result of the configuration
skipping to change at page 105, line 36 skipping to change at page 113, line 37
Configuration Update message. Configuration Update message.
o AC Name with Index, see Section 4.6.5 o AC Name with Index, see Section 4.6.5
o AC Timestamp, see Section 4.6.6 o AC Timestamp, see Section 4.6.6
o Add MAC ACL Entry, see Section 4.6.7 o Add MAC ACL Entry, see Section 4.6.7
o Add Static MAC ACL Entry, see Section 4.6.9 o Add Static MAC ACL Entry, see Section 4.6.9
o CAPWAP Timers, see Section 4.6.15 o CAPWAP Timers, see Section 4.6.14
o Decryption Error Report Period, see Section 4.6.19 o Decryption Error Report Period, see Section 4.6.19
o Delete MAC ACL Entry, see Section 4.6.20 o Delete MAC ACL Entry, see Section 4.6.20
o Delete Static MAC ACL Entry, see Section 4.6.22 o Delete Static MAC ACL Entry, see Section 4.6.22
o Idle Timeout, see Section 4.6.26 o Idle Timeout, see Section 4.6.26
o Location Data, see Section 4.6.31 o Location Data, see Section 4.6.31
skipping to change at page 106, line 14 skipping to change at page 114, line 16
o WTP Fallback, see Section 4.6.42 o WTP Fallback, see Section 4.6.42
o WTP Name, see Section 4.6.47 o WTP Name, see Section 4.6.47
o WTP Static IP Address Information, see Section 4.6.51 o WTP Static IP Address Information, see Section 4.6.51
o Image Identifier, see Section 4.6.28 o Image Identifier, see Section 4.6.28
o Initiate Download, see Section 4.6.30 o Initiate Download, see Section 4.6.30
o Vendor Specific Payload, see Section 4.6.39
8.5. Configuration Update Response 8.5. Configuration Update Response
The Configuration Update Response message is the acknowledgement The Configuration Update Response message is the acknowledgement
message for the Configuration Update Request message. message for the Configuration Update Request message.
The Configuration Update Response message is sent by a WTP after The Configuration Update Response message is sent by a WTP after
receiving a Configuration Update Request message. receiving a Configuration Update Request message.
When an AC receives a Configuration Update Response message the When an AC receives a Configuration Update Response message the
result code indicates if the WTP successfully accepted the result code indicates if the WTP successfully accepted the
skipping to change at page 106, line 39 skipping to change at page 114, line 43
The following message element MUST be present in the Configuration The following message element MUST be present in the Configuration
Update message. Update message.
Result Code, see Section 4.6.35 Result Code, see Section 4.6.35
The following message elements MAY be present in the Configuration The following message elements MAY be present in the Configuration
Update Response message. Update Response message.
o Radio Operational State, see Section 4.6.34 o Radio Operational State, see Section 4.6.34
o Vendor Specific Payload, see Section 4.6.39
8.6. Change State Event Request 8.6. Change State Event Request
The Change State Event Request message is used by the WTP for two The Change State Event Request message is used by the WTP for two
main purposes: main purposes:
o When sent by the WTP following the reception of a Configuration o When sent by the WTP following the reception of a Configuration
Status Response message from the AC, the WTP uses the Change State Status Response message from the AC, the WTP uses the Change State
Event Request message to provide an update on the WTP radio's Event Request message to provide an update on the WTP radio's
operational state and to confirm that the configuration provided operational state and to confirm that the configuration provided
by the AC was successfully applied. by the AC was successfully applied.
skipping to change at page 107, line 17 skipping to change at page 115, line 23
with a Change State Event Response message and modifies its data with a Change State Event Response message and modifies its data
structures for the WTP as needed. The AC MAY decide not to provide 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, service to the WTP if it receives an error, based on local policy,
and to transition to the Reset state. and to transition to the Reset state.
The Change State Event Request message is sent by a WTP to The Change State Event Request message is sent by a WTP to
acknowledge or report an error condition to the AC for a requested acknowledge or report an error condition to the AC for a requested
configuration in the Configuration Status Response message. The configuration in the Configuration Status Response message. The
Change State Event Request message includes the Result Code message Change State Event Request message includes the Result Code message
element, which indicates whether the configuration was successfully element, which indicates whether the configuration was successfully
applied. If the WTP is unable to apply a specfic configuration applied. If the WTP is unable to apply a specific configuration
request, it indicates the failure by including one or more Returned request, it indicates the failure by including one or more Returned
Message Element message elements (see Section 4.6.36). Message Element message elements (see Section 4.6.36).
The Change State Event Request message is sent by the WTP in the The Change State Event Request message is sent by the WTP in the
Configure or Run State. The AC does not transmit this message. Configure or Run State. The AC does not transmit this message.
The WTP MAY save its configuration to persistent storage prior to The WTP MAY save its configuration to persistent storage prior to
transmitting the response. However, this is implementation specific transmitting the response. However, this is implementation specific
and is not required. and is not required.
skipping to change at page 107, line 40 skipping to change at page 115, line 46
o Radio Operational State, see Section 4.6.34 o Radio Operational State, see Section 4.6.34
o Result Code, see Section 4.6.35 o Result Code, see Section 4.6.35
One or more of the following message elements MAY be present in the One or more of the following message elements MAY be present in the
Change State Event Request message. Change State Event Request message.
o Returned Message Element(s), see Section 4.6.36 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 8.7. Change State Event Response
The Change State Event Response message acknowledges the Change State The Change State Event Response message acknowledges the Change State
Event Request message. Event Request message.
A Change State Event Response message is sent by an AC in response to A Change State Event Response message is sent by an AC in response to
a Change State Event Request message. a Change State Event Request message.
The Change State Event Response message is sent by the AC when in the 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. Configure or Run state. The WTP does not transmit this message.
The Change State Event Response message carries no message elements. The following message elements 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 The WTP does not take any action upon receipt of the Change State
Event Response message. Event Response message.
8.8. Clear Configuration Request 8.8. Clear Configuration Request
The Clear Configuration Request message is used to reset the WTP The Clear Configuration Request message is used to reset the WTP
configuration. configuration.
The Clear Configuration Request message is sent by an AC to request The Clear Configuration Request message is sent by an AC to request
that a WTP reset its configuration to the manufacturing default that a WTP reset its configuration to the manufacturing default
configuration. The Clear Config Request message is sent while in the configuration. The Clear Config Request message is sent while in the
Run state. Run state.
The Clear Configuration Request is sent by the AC when in the Run The Clear Configuration Request is sent by the AC when in the Run
State. The WTP does not transmit this message. State. The WTP does not transmit this message.
The Clear Configuration Request message carries no message elements. The following message elements 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 When a WTP receives a Clear Configuration Request message it resets
its configuration to the manufacturing default configuration. its configuration to the manufacturing default configuration.
8.9. Clear Configuration Response 8.9. Clear Configuration Response
The Clear Configuration Response message is sent by the WTP after The Clear Configuration Response message is sent by the WTP after
receiving a Clear Configuration Request message and resetting its receiving a Clear Configuration Request message and resetting its
configuration parameters to the manufacturing default values. configuration parameters to the manufacturing default values.
The Clear Configuration Response is sent by the WTP when in the Run The Clear Configuration Response is sent by the WTP when in the Run
State. The AC does not transmit this message. State. The AC does not transmit this message.
The Clear Configuration Request message MUST include the following The Clear Configuration Request message MUST include the following
message element. message element.
o Result Code, see Section 4.6.35 o Result Code, see Section 4.6.35
The following message elements MAY be included in the Clear
Configuration Request message:
o Vendor Specific Payload, see Section 4.6.39
9. Device Management Operations 9. Device Management Operations
This section defines CAPWAP operations responsible for debugging, This section defines CAPWAP operations responsible for debugging,
gathering statistics, logging, and firmware management. gathering statistics, logging, and firmware management.
9.1. Firmware Management 9.1. Firmware Management
This section describes the firmware download procedures used by the This section describes the firmware download procedures used by the
CAPWAP protocol. Firmware download can occur during the Image Data CAPWAP protocol. Firmware download can occur during the Image Data
or Run state. or Run state.
skipping to change at page 112, line 52 skipping to change at page 121, line 52
When the WTP joins the AC, the Join Response message includes the When the WTP joins the AC, the Join Response message includes the
Image Identifier message element, which informs the WTP of the Image Identifier message element, which informs the WTP of the
firmware it is expected to run. if the WTP does not currently have firmware it is expected to run. if the WTP does not currently have
the requested firmware version, it transmits an Image Data Request the requested firmware version, it transmits an Image Data Request
message, with the appropriate Image Identifier message element. message, with the appropriate Image Identifier message element.
If the WTP already has the requested firmware, it simply resets. If the WTP already has the requested firmware, it simply resets.
Once the WTP is in the Run state, it is possible for the AC to 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 cause the WTP to initiate a firmware download by sending a
Configuration Update Request message with the Initiate Download Configuration Update Request message with the Initiate Download
and and Image Identifier message elements. The WTP then transmits and Image Identifier message elements. The WTP then transmits the
the Image Data Request message, which includes the Image Image Data Request message, which includes the Image Identifier
Identifier message element to start the download process. Note message element to start the download process. Note that when the
that when the firmware is downloaded in this way, the WTP does not firmware is downloaded in this way, the WTP does not automatically
automatically reset after the download is complete. The WTP will reset after the download is complete. The WTP will only reset
only reset when it receives a Reset Request message from the AC. when it receives a Reset Request message from the AC. If the WTP
If the WTP already had the requested firmware version in its non- already had the requested firmware version in its non-volatile
volatile storage, the WTP does not transmit the Image Data Request storage, the WTP does not transmit the Image Data Request message
message and responds with a Configuration Update Response message and responds with a Configuration Update Response message with the
with the Result Code set to Image Already Present. Result Code set to Image Already Present.
Regardless of how the download was initiated, once the AC receives an Regardless of how the download was initiated, once the AC receives an
Image Data Request message with the Image Identifier message element, Image Data Request message with the Image Identifier message element,
it begins the transfer process by transmitting an Image Data Request it begins the transfer process by transmitting an Image Data Request
message that includes the Image Data message element. This continues message that includes the Image Data message element. This continues
until the firmware image has been transfered. 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 Request message is sent by the WTP or the AC when in
the Image Data or Run State. the Image Data or Run State.
The following message elements MAY be included in the Image Data The following message elements MAY be included in the Image Data
Request message. Request message.
o Image Data, see Section 4.6.27 o Image Data, see Section 4.6.27
o Image Identifier, see Section 4.6.28 o Image Identifier, see Section 4.6.28
o Vendor Specific Payload, see Section 4.6.39
9.1.2. Image Data Response 9.1.2. Image Data Response
The Image Data Response message acknowledges the Image Data Request The Image Data Response message acknowledges the Image Data Request
message. message.
An Image Data Response message is sent in response to a received An Image Data Response message is sent in response to a received
Image Data Request message. Its purpose is to acknowledge the Image Data Request message. Its purpose is to acknowledge the
receipt of the Image Data Request message. The Result Code is receipt of the Image Data Request message. The Result Code is
included to indicate whether a previously sent Image Data Request included to indicate whether a previously sent Image Data Request
message was invalid. message was invalid.
skipping to change at page 114, line 9 skipping to change at page 123, line 10
o Result Code, see Section 4.6.35 o Result Code, see Section 4.6.35
The following message elements MAY be included in the Image Data The following message elements MAY be included in the Image Data
Response message. Response message.
o Image Information, see Section 4.6.29 o Image Information, see Section 4.6.29
o Initiate Download, see Section 4.6.30 o Initiate Download, see Section 4.6.30
o Vendor Specific Payload, see Section 4.6.39
Upon receiving an Image Data Response message indicating an error, Upon receiving an Image Data Response message indicating an error,
the WTP MAY retransmit a previous Image Data Reqest message, or the WTP MAY retransmit a previous Image Data Request message, or
abandon the firmware download to the WTP by transitioning to the abandon the firmware download to the WTP by transitioning to the
Reset state. Reset state.
9.2. Reset Request 9.2. Reset Request
The Reset Request message is used to cause a WTP to reboot. 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 A Reset Request message is sent by an AC to cause a WTP to
reinitialize its operation. reinitialize its operation.
The Reset Request is sent by the AC when in the Run State. The WTP The Reset Request is sent by the AC when in the Run State. The WTP
does not transmit this message. does not transmit this message.
The following message elements MUST be included in the Reset Request The following message elements MUST be included in the Reset Request
message. message.
o Image Identifier, see Section 4.6.28 o Image Identifier, see Section 4.6.28
The following message elements 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 When a WTP receives a Reset Request message, it responds with a Reset
Response message indicating success and then reinitialize itself. If Response message indicating success and then reinitialize itself. If
the WTP is unable to write to its non-volatile storage, to ensure the WTP is unable to write to its non-volatile storage, to ensure
that it runs the requested software version indicated in the Image that it runs the requested software version indicated in the Image
Identifier message element, it MAY send the appropriate Result Code Identifier message element, it MAY send the appropriate Result Code
message element, but MUST reboot. If the WTP is unable to reset, message element, but MUST reboot. If the WTP is unable to reset,
including a hardware reset, it sends a Reset Response message to the including a hardware reset, it sends a Reset Response message to the
AC with a Result Code message element indicating failure. The AC no AC with a Result Code message element indicating failure. The AC no
longer provides service to the WTP. longer provides service to the WTP.
9.3. Reset Response 9.3. Reset Response
The Reset Response message acknowledges the Reset Request message. The Reset Response message acknowledges the Reset Request message.
A Reset Response message is sent by the WTP after receiving a Reset A Reset Response message is sent by the WTP after receiving a Reset
Request message. Request message.
The Reset Response is sent by the WTP when in the Run State. The AC The Reset Response is sent by the WTP when in the Run State. The AC
does not transmit this message. does not transmit this message.
The following message element MAY be included in the Image Data The following message element MAY be included in the Reset Response
Request message. message.
o Result Code, see Section 4.6.35 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 When an AC receives a successful Reset Response message, it is
notified that the WTP will reinitialize its operation. An AC that notified that the WTP will reinitialize its operation. An AC that
receives a Reset Response message indicating failure may opt to no receives a Reset Response message indicating failure may opt to no
longer provide service to the WTP. longer provide service to the WTP.
9.4. WTP Event Request 9.4. WTP Event Request
The WTP Event Request message is used by a WTP to send information to 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 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 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 WTP MAY collect statistics and use the WTP Event Request message to
transmit the statistics to the AC. transmit the statistics to the AC.
When an AC receives a WTP Event Request message it will respond with When an AC receives a WTP Event Request message it will respond with
a WTP Event Response message. a WTP Event Response message.
The presence of the Delete Station message element is used by the WTP 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 to inform the AC that it is no longer providing service to the
station. This could be the result of an Idle Timeout (see station. This could be the result of an Idle Timeout (see
Section 4.6.26), due to to resource shortages, or some other reason. Section 4.6.26), due to resource shortages, or some other reason.
The WTP Event Request message is sent by the WTP when in the Run The WTP Event Request message is sent by the WTP when in the Run
State. The AC does not transmit this message. State. The AC does not transmit this message.
The WTP Event Request message MUST contain one of the message The WTP Event Request message MUST contain one of the message
elements listed below, or a message element that is defined for a elements listed below, or a message element that is defined for a
specific wireless technology. More than one of each messsage element specific wireless technology. More than one of each message element
listed MAY be included in the WTP Event Request message. listed MAY be included in the WTP Event Request message.
o Decryption Error Report, see Section 4.6.18 o Decryption Error Report, see Section 4.6.18
o Duplicate IPv4 Address, see Section 4.6.24 o Duplicate IPv4 Address, see Section 4.6.24
o Duplicate IPv6 Address, see Section 4.6.25 o Duplicate IPv6 Address, see Section 4.6.25
o WTP Operational Statistics, see Section 4.6.48 o WTP Operational Statistics, see Section 4.6.48
o WTP Radio Statistics, see Section 4.6.49 o WTP Radio Statistics, see Section 4.6.49
o WTP Reboot Statistics, see Section 4.6.50 o WTP Reboot Statistics, see Section 4.6.50
o Delete Station, see Section 4.6.21 o Delete Station, see Section 4.6.21
o Vendor Specific Payload, see Section 4.6.39
9.5. WTP Event Response 9.5. WTP Event Response
The WTP Event Response message acknowledges receipt of the WTP Event The WTP Event Response message acknowledges receipt of the WTP Event
Request message. Request message.
A WTP Event Response message is sent by an AC after receiving a WTP A WTP Event Response message is sent by an AC after receiving a WTP
Event Request message. Event Request message.
The WTP Event Response message is sent by the AC when in the Run The WTP Event Response message is sent by the AC when in the Run
State. The WTP does not transmit this message. State. The WTP does not transmit this message.
The WTP Event Response message carries no message elements. The following message elements MAY be included in the WTP Event
Response message:
o Vendor Specific Payload, see Section 4.6.39
9.6. Data Transfer Request 9.6. Data Transfer Request
The Data Transfer Request message is used to deliver debug The Data Transfer Request message is used to deliver debug
information from the WTP to the AC. information from the WTP to the AC.
Data Transfer Request messages are sent by the WTP to the AC when the Data Transfer Request messages are sent by the WTP to the AC when the
WTP determines that it has important information to send to the AC. WTP determines that it has important information to send to the AC.
For instance, if the WTP detects that its previous reboot was caused For instance, if the WTP detects that its previous reboot was caused
by a system crash, it can send the crash file to the AC. The remote by a system crash, it can send the crash file to the AC. The remote
skipping to change at page 116, line 44 skipping to change at page 126, line 9
The Data Transfer Request message is sent by the WTP when in the Run The Data Transfer Request message is sent by the WTP when in the Run
State. The AC does not transmit this message. State. The AC does not transmit this message.
The Data Transfer Request message MUST contain one of the message The Data Transfer Request message MUST contain one of the message
elements listed below. elements listed below.
o Data Transfer Data, see Section 4.6.16 o Data Transfer Data, see Section 4.6.16
o Data Transfer Mode, see Section 4.6.17 o Data Transfer Mode, see Section 4.6.17
The following message elements MAY be included in the Data Transfer
Request message:
o Vendor Specific Payload, see Section 4.6.39
9.7. Data Transfer Response 9.7. Data Transfer Response
The Data Transfer Response message acknowledges the Data Transfer The Data Transfer Response message acknowledges the Data Transfer
Request message. Request message.
A Data Transfer Response message is sent in response to a received A Data Transfer Response message is sent in response to a received
Data Transfer Request message. Its purpose is to acknowledge receipt Data Transfer Request message. Its purpose is to acknowledge receipt
of the Data Transfer Request message. of the Data Transfer Request message.
The Data Transfer Response message is sent by the AC when in the Run The Data Transfer Response message is sent by the AC when in the Run
State. The WTP does not transmit this message. State. The WTP does not transmit this message.
The Data Transfer Response message carries no message elements. The following message elements 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 Upon receipt of a Data Transfer Response message, the WTP transmits
more information, if more information is available. more information, if more information is available.
10. Station Session Management 10. Station Session Management
Messages in this section are used by the AC to create, modify or Messages in this section are used by the AC to create, modify or
delete station session state on the WTPs. delete station session state on the WTPs.
10.1. Station Configuration Request 10.1. Station Configuration Request
skipping to change at page 118, line 32 skipping to change at page 127, line 32
The following CAPWAP Control message elements MAY be included in the The following CAPWAP Control message elements MAY be included in the
Station Configuration Request message. More than one of each message Station Configuration Request message. More than one of each message
element listed MAY be included in the Station Configuration Request element listed MAY be included in the Station Configuration Request
message. message.
o Add Station, see Section 4.6.8 o Add Station, see Section 4.6.8
o Delete Station, see Section 4.6.21 o Delete Station, see Section 4.6.21
o Vendor Specific Payload, see Section 4.6.39
10.2. Station Configuration Response 10.2. Station Configuration Response
The Station Configuration Response message is used to acknowledge a The Station Configuration Response message is used to acknowledge a
previously received Station Configuration Request message. previously received Station Configuration Request message.
The Station Configuration Response message is sent by the WTP when in The Station Configuration Response message is sent by the WTP when in
the Run State. The AC does not transmit this message. the Run State. The AC does not transmit this message.
The following message element MUST be present in the Station The following message element MUST be present in the Station
Configuration Response message. Configuration Response message.
o Result Code, see Section 4.6.35 o Result Code, see Section 4.6.35
The following message elements 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 The Result Code message element indicates that the requested
configuration was successfully applied, or that an error related to configuration was successfully applied, or that an error related to
processing of the Station Configuration Request message occurred on processing of the Station Configuration Request message occurred on
the WTP. the WTP.
11. NAT Considerations 11. NAT Considerations
There are three specific situations in which a NAT deployment may be There are three specific situations in which a NAT deployment may be
used in conjunction with a CAPWAP-enabled deployment. The first used in conjunction with a CAPWAP-enabled deployment. The first
consists of a configuration in which a single WTP is behind a NAT consists of a configuration in which a single WTP is behind a NAT
skipping to change at page 123, line 17 skipping to change at page 133, line 17
Session ID is not exposed, and therefore can safely be used to Session ID is not exposed, and therefore can safely be used to
associate a data and control channel. The 64-bit length of the associate a data and control channel. The 64-bit length of the
Session ID mitigates online guessing attacks where an adversarial, Session ID mitigates online guessing attacks where an adversarial,
authenticated WTP tries to correlate his own data channel with authenticated WTP tries to correlate his own data channel with
another WTP's control channel. Note that for encrypted data another WTP's control channel. Note that for encrypted data
channels, the Session ID should only be used for correlation for the channels, the Session ID should only be used for correlation for the
first packet immediately after the initial DTLS handshake. Future first packet immediately after the initial DTLS handshake. Future
correlation should instead be done via identification of a packet's correlation should instead be done via identification of a packet's
DTLS session. DTLS session.
12.3. Discovery Attacks 12.3. Discovery or DTLS Setup Attacks
Since the Discovery Request messages are sent in the clear, it is Since the Discovery Request messages are sent in the clear, it is
important that AC implementations NOT assume that receiving such a important that AC implementations NOT assume that receiving a
request from a WTP implies that it has rebooted, and consequently Discovery Request message from a WTP implies that the WTP has
tear down any active DTLS sessions. Discovery Request messages can rebooted, and consequently tear down any active DTLS sessions.
easily be spoofed by malicious devices, so it is important that the Discovery Request messages can easily be spoofed by malicious
AC maintain two separate sets of states for the WTP until the devices, so it is important that the AC maintain two separate sets of
DTLSSessionEstablished notification is received, indicating that the states for the WTP until the DTLSSessionEstablished notification is
WTP was authenticated. Once a new DTLS session is successfully received, indicating that the WTP was authenticated. Once a new DTLS
established, any state referring to the old session can be cleared. session is successfully established, any state referring to the old
session can be cleared.
Similarly, entering the DTLS Setup phase 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 implementations may wish to pass information about clients who
have passed the discovery phase to the DTLS layer, 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. As a result, implementations SHOULD
NOT maintain state between the discovery and DTLS handshake phases of
the CAPWAP protocol initialization.
12.4. Interference with a DTLS Session 12.4. Interference with a DTLS Session
If a WTP or AC repeatedly receives packets which fail DTLS If a WTP or AC repeatedly receives packets which fail DTLS
authentication or decryption, this could indicate a DTLS authentication or decryption, this could indicate a DTLS
desynchronization between the AC and WTP, a link prone to desynchronization between the AC and WTP, a link prone to
undetectable bit errors, or an attacker trying to disrupt a DTLS undetectable bit errors, or an attacker trying to disrupt a DTLS
session. session.
In the state machine (section 2.3), transitions to the DTLS tear down In the state machine (section 2.3), transitions to the DTLS tear down
skipping to change at page 124, line 33 skipping to change at page 135, line 12
administrator to manually configure the PSK also provide a administrator to manually configure the PSK also provide a
capability for generation of new random PSKs, taking RFC 4086 [2] capability for generation of new random PSKs, taking RFC 4086 [2]
into account. into account.
o Preshared keys SHOULD be periodically updated. Implementations o Preshared keys SHOULD be periodically updated. Implementations
MAY facilitate this by providing an administrative interface for MAY facilitate this by providing an administrative interface for
automatic key generation and periodic update, or it MAY be automatic key generation and periodic update, or it MAY be
accomplished manually instead. accomplished manually instead.
Every pairwise combination of WTP and AC on the network SHOULD have a Every pairwise combination of WTP and AC on the network SHOULD have a
unqiue PSK. This prevents the domino effect (see Guidance for AAA unique PSK. This prevents the domino effect (see Guidance for AAA
Key Management [20]). If PSKs are tied to specific WTPs, then Key Management [20]). If PSKs are tied to specific WTPs, then
knowledge of the PSK implies a binding to a specified identity that knowledge of the PSK implies a binding to a specified identity that
can be authorized. can be authorized.
If PSKs are shared, this binding between device and identity is no If PSKs are shared, this binding between device and identity is no
longer possible. Compromise of one WTP can yield compromise of longer possible. Compromise of one WTP can yield compromise of
another WTP, violating the CAPWAP security hierarchy. Consequently, another WTP, violating the CAPWAP security hierarchy. Consequently,
sharing keys between WTPs is NOT RECOMMENDED. sharing keys between WTPs is NOT RECOMMENDED.
12.6. Use of Certificates in CAPWAP 12.6. Use of Certificates in CAPWAP
skipping to change at page 125, line 4 skipping to change at page 135, line 31
12.6. Use of Certificates in CAPWAP 12.6. Use of Certificates in CAPWAP
For public-key-based DTLS deployments, each device SHOULD have unique For public-key-based DTLS deployments, each device SHOULD have unique
credentials, with an extended key usage authorizing the device to act 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 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 is possible that by compromising one device, any other device using
the same credential may also be considered to be compromised. the same credential may also be considered to be compromised.
Certificate validation involves checking a large variety of things. Certificate validation involves checking a large variety of things.
Since the necessary things to validate are often environment- Since the necessary things to validate are often environment-
specific, many are beyond the scope of this document. In this specific, many are beyond the scope of this document. In this
section, we provide some basic guidance on certificate validation. section, we provide some basic guidance on certificate validation.
Each device is responsible for authenticating and authorizing devices Each device is responsible for authenticating and authorizing devices
with which they communicate. Authentication entails validation of with which they communicate. Authentication entails validation of
the chain of trust leading to the peer certificate, followed by the the chain of trust leading to the peer certificate, followed by the
the peer certificate itself. At a minimum, devices SHOULD use SSH- peer certificate itself. Implementations SHOULD also provide a
style certificate caching to guarantee consistency. If devices have secure method for verifying that the credential in question has not
access to a certificate authority, they SHOULD properly validate the been revoked.
trust chain. Implementations SHOULD also provide a secure method for
verifying that the credential in question has not been revoked.
Note that if the WTP relies on the AC for network connectivity (e.g. 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 AC is a layer 2 switch to which the WTP is directly connected),
the WTP may not be able to contact an OCSP server or otherwise obtain the WTP may not be able to contact an OCSP server or otherwise obtain
an up to date CRL if a compromised AC doesn't explicitly permit this. an up to date CRL if a compromised AC doesn't explicitly permit this.
This cannot be avoided, except through effective physical security This cannot be avoided, except through effective physical security
and monitoring measures at the AC. and monitoring measures at the AC.
Proper validation of certificates typically requires checking to Proper validation of certificates typically requires checking to
ensure the certificate has not yet expired. If devices have a real- ensure the certificate has not yet expired. If devices have a real-
skipping to change at page 129, line 8 skipping to change at page 140, line 8
15.2. Wireless Binding Identifiers 15.2. Wireless Binding Identifiers
The Wireless Binding Identifier (WBID) field in the CAPWAP header The Wireless Binding Identifier (WBID) field in the CAPWAP header
(Section 4.3) is used to identify the wireless technology associated (Section 4.3) is used to identify the wireless technology associated
with the packet. Due to the limited address space available, a new with the packet. Due to the limited address space available, a new
WBID request requires Standards Action. WBID request requires Standards Action.
16. Acknowledgements 16. Acknowledgements
The following individuals are acknowledged for their contributions to The following individuals are acknowledged for their contributions to
this protocol specification: Puneet Agarwal, Saravanan Govindan, this protocol specification: Puneet Agarwal, Abhijit Choudhury,
Peter Nilsson, and David Perkins. Saravanan Govindan, Peter Nilsson, and David Perkins.
Michael Vakulenko contributed text to describe how CAPWAP can be used Michael Vakulenko contributed text to describe how CAPWAP can be used
over layer 3 (IP/UDP) networks. over layer 3 (IP/UDP) networks.
17. References 17. References
17.1. Normative References 17.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 131, line 9 skipping to change at page 142, line 9
[13] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) [13] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 1883, December 1995. Specification", RFC 1883, December 1995.
[14] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [14] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990. November 1990.
[15] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for [15] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for
IP version 6", RFC 1981, August 1996. IP version 6", RFC 1981, August 1996.
[16] Calhoun, P., "CAPWAP Protocol Binding for IEEE 802.11", [16] Calhoun, P., "CAPWAP Protocol Binding for IEEE 802.11",
draft-ietf-capwap-protocol-binding-ieee80211-04 (work in draft-ietf-capwap-protocol-binding-ieee80211-06 (work in
progress), June 2007. progress), February 2008.
[17] Calhoun, P., "CAPWAP Access Controller DHCP Option", [17] Calhoun, P., "CAPWAP Access Controller DHCP Option",
draft-calhoun-dhc-capwap-ac-option-00 (work in progress), draft-calhoun-dhc-capwap-ac-option-00 (work in progress),
April 2007. April 2007.
17.2. Informational References 17.2. Informational References
[18] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On- [18] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-
line Database", RFC 3232, January 2002. line Database", RFC 3232, January 2002.
skipping to change at page 133, line 7 skipping to change at page 144, line 7
Dorothy Stanley Dorothy Stanley
Aruba Networks Aruba Networks
1322 Crossman Ave 1322 Crossman Ave
Sunnyvale, CA 94089 Sunnyvale, CA 94089
Phone: +1 630-363-1389 Phone: +1 630-363-1389
Email: dstanley@arubanetworks.com Email: dstanley@arubanetworks.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 161 change blocks. 
359 lines changed or deleted 726 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/