draft-ietf-capwap-protocol-specification-15.txt   rfc5415.txt 
Network Working Group P. Calhoun, Editor Network Working Group P. Calhoun, Ed.
Internet-Draft Cisco Systems, Inc. Request for Comments: 5415 Cisco Systems, Inc.
Intended status: Standards Track M. Montemurro, Editor Category: Standards Track M. Montemurro, Ed.
Expires: May 4, 2009 Research In Motion Research In Motion
D. Stanley, Editor D. Stanley, Ed.
Aruba Networks Aruba Networks
October 31, 2008 Control And Provisioning of Wireless Access Points (CAPWAP)
Protocol Specification
CAPWAP Protocol Specification
draft-ietf-capwap-protocol-specification-15
Status of this Memo
By submitting this Internet-Draft, each author represents that any Status of This Memo
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document specifies an Internet standards track protocol for the
Task Force (IETF), its areas, and its working groups. Note that Internet community, and requests discussion and suggestions for
other groups may also distribute working documents as Internet- improvements. Please refer to the current edition of the "Internet
Drafts. Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Internet-Drafts are draft documents valid for a maximum of six months Copyright Notice
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Copyright (c) 2009 IETF Trust and the persons identified as the
http://www.ietf.org/ietf/1id-abstracts.txt. document authors. All rights reserved.
The list of Internet-Draft Shadow Directories can be accessed at This document is subject to BCP 78 and the IETF Trust's Legal
http://www.ietf.org/shadow.html. Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
This Internet-Draft will expire on May 4, 2009. This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Abstract Abstract
This specification defines the Control And Provisioning of Wireless This specification defines the Control And Provisioning of Wireless
Access Points (CAPWAP) Protocol, meeting the objectives defined by Access Points (CAPWAP) Protocol, meeting the objectives defined by
the CAPWAP working group in RFC 4564. The CAPWAP protocol is the CAPWAP Working Group in RFC 4564. 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, while separate binding extensions will enable its use with protocol, while separate binding extensions will enable its use with
additional wireless technologies. additional wireless technologies.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction ....................................................7
1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.1. Goals ......................................................8
1.2. Conventions used in this document . . . . . . . . . . . 9 1.2. Conventions Used in This Document ..........................9
1.3. Contributing Authors . . . . . . . . . . . . . . . . . . 9 1.3. Contributing Authors .......................................9
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . 10 1.4. Terminology ...............................................10
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12 2. Protocol Overview ..............................................11
2.1. Wireless Binding Definition . . . . . . . . . . . . . . 13 2.1. Wireless Binding Definition ...............................12
2.2. CAPWAP Session Establishment Overview . . . . . . . . . 14 2.2. CAPWAP Session Establishment Overview .....................13
2.3. CAPWAP State Machine Definition . . . . . . . . . . . . 16 2.3. CAPWAP State Machine Definition ...........................15
2.3.1. CAPWAP Protocol State Transitions . . . . . . . . . . 18 2.3.1. CAPWAP Protocol State Transitions ..................17
2.3.2. CAPWAP/DTLS Interface . . . . . . . . . . . . . . . . 32 2.3.2. CAPWAP/DTLS Interface ..............................31
2.4. Use of DTLS in the CAPWAP Protocol . . . . . . . . . . . 34 2.4. Use of DTLS in the CAPWAP Protocol ........................33
2.4.1. DTLS Handshake Processing . . . . . . . . . . . . . . 34 2.4.1. DTLS Handshake Processing ..........................33
2.4.2. DTLS Session Establishment . . . . . . . . . . . . . 36 2.4.2. DTLS Session Establishment .........................35
2.4.3. DTLS Error Handling . . . . . . . . . . . . . . . . . 36 2.4.3. DTLS Error Handling ................................35
2.4.4. DTLS EndPoint Authentication and Authorization . . . 37 2.4.4. DTLS Endpoint Authentication and Authorization .....36
3. CAPWAP Transport . . . . . . . . . . . . . . . . . . . . . . 41 3. CAPWAP Transport ...............................................40
3.1. UDP Transport . . . . . . . . . . . . . . . . . . . . . 41 3.1. UDP Transport .............................................40
3.2. UDP-Lite Transport . . . . . . . . . . . . . . . . . . . 42 3.2. UDP-Lite Transport ........................................41
3.3. AC Discovery . . . . . . . . . . . . . . . . . . . . . . 42 3.3. AC Discovery ..............................................41
3.4. Fragmentation/Reassembly . . . . . . . . . . . . . . . . 43 3.4. Fragmentation/Reassembly ..................................42
3.5. MTU Discovery . . . . . . . . . . . . . . . . . . . . . 44 3.5. MTU Discovery .............................................43
4. CAPWAP Packet Formats . . . . . . . . . . . . . . . . . . . . 45 4. CAPWAP Packet Formats ..........................................43
4.1. CAPWAP Preamble . . . . . . . . . . . . . . . . . . . . 47 4.1. CAPWAP Preamble ...........................................46
4.2. CAPWAP DTLS Header . . . . . . . . . . . . . . . . . . . 47 4.2. CAPWAP DTLS Header ........................................46
4.3. CAPWAP Header . . . . . . . . . . . . . . . . . . . . . 48 4.3. CAPWAP Header .............................................47
4.4. CAPWAP Data Messages . . . . . . . . . . . . . . . . . . 51 4.4. CAPWAP Data Messages ......................................50
4.4.1. CAPWAP Data Channel Keepalive . . . . . . . . . . . . 51 4.4.1. CAPWAP Data Channel Keep-Alive .....................51
4.4.2. Data Payload . . . . . . . . . . . . . . . . . . . . 52 4.4.2. Data Payload .......................................52
4.4.3. Establishment of a DTLS Data Channel . . . . . . . . 53 4.4.3. Establishment of a DTLS Data Channel ...............52
4.5. CAPWAP Control Messages . . . . . . . . . . . . . . . . 53 4.5. CAPWAP Control Messages ...................................52
4.5.1. Control Message Format . . . . . . . . . . . . . . . 54 4.5.1. Control Message Format .............................53
4.5.2. Quality of Service . . . . . . . . . . . . . . . . . 57 4.5.2. Quality of Service .................................56
4.5.3. Retransmissions . . . . . . . . . . . . . . . . . . . 58 4.5.3. Retransmissions ....................................57
4.6. CAPWAP Protocol Message Elements . . . . . . . . . . . . 59 4.6. CAPWAP Protocol Message Elements ..........................58
4.6.1. AC Descriptor . . . . . . . . . . . . . . . . . . . . 61 4.6.1. AC Descriptor ......................................61
4.6.2. AC IPv4 List . . . . . . . . . . . . . . . . . . . . 64 4.6.2. AC IPv4 List .......................................64
4.6.3. AC IPv6 List . . . . . . . . . . . . . . . . . . . . 65 4.6.3. AC IPv6 List .......................................64
4.6.4. AC Name . . . . . . . . . . . . . . . . . . . . . . . 65 4.6.4. AC Name ............................................65
4.6.5. AC Name with Priority . . . . . . . . . . . . . . . . 66 4.6.5. AC Name with Priority ..............................65
4.6.6. AC Timestamp . . . . . . . . . . . . . . . . . . . . 66 4.6.6. AC Timestamp .......................................66
4.6.7. Add MAC ACL Entry . . . . . . . . . . . . . . . . . . 67 4.6.7. Add MAC ACL Entry ..................................66
4.6.8. Add Station . . . . . . . . . . . . . . . . . . . . . 67 4.6.8. Add Station ........................................67
4.6.9. CAPWAP Control IPv4 Address . . . . . . . . . . . . . 68 4.6.9. CAPWAP Control IPv4 Address ........................68
4.6.10. CAPWAP Control IPv6 Address . . . . . . . . . . . . . 69 4.6.10. CAPWAP Control IPv6 Address .......................68
4.6.11. CAPWAP Local IPv4 Address . . . . . . . . . . . . . . 69 4.6.11. CAPWAP Local IPv4 Address .........................69
4.6.12. CAPWAP Local IPv6 Address . . . . . . . . . . . . . . 70 4.6.12. CAPWAP Local IPv6 Address .........................69
4.6.13. CAPWAP Timers . . . . . . . . . . . . . . . . . . . . 70 4.6.13. CAPWAP Timers .....................................70
4.6.14. CAPWAP Transport Protocol . . . . . . . . . . . . . . 71 4.6.14. CAPWAP Transport Protocol .........................71
4.6.15. Data Transfer Data . . . . . . . . . . . . . . . . . 72 4.6.15. Data Transfer Data ................................72
4.6.16. Data Transfer Mode . . . . . . . . . . . . . . . . . 73 4.6.16. Data Transfer Mode ................................73
4.6.17. Decryption Error Report . . . . . . . . . . . . . . . 73 4.6.17. Decryption Error Report ...........................73
4.6.18. Decryption Error Report Period . . . . . . . . . . . 74 4.6.18. Decryption Error Report Period ....................74
4.6.19. Delete MAC ACL Entry . . . . . . . . . . . . . . . . 75 4.6.19. Delete MAC ACL Entry ..............................74
4.6.20. Delete Station . . . . . . . . . . . . . . . . . . . 75 4.6.20. Delete Station ....................................75
4.6.21. Discovery Type . . . . . . . . . . . . . . . . . . . 76 4.6.21. Discovery Type ....................................75
4.6.22. Duplicate IPv4 Address . . . . . . . . . . . . . . . 76 4.6.22. Duplicate IPv4 Address ............................76
4.6.23. Duplicate IPv6 Address . . . . . . . . . . . . . . . 77 4.6.23. Duplicate IPv6 Address ............................77
4.6.24. Idle Timeout . . . . . . . . . . . . . . . . . . . . 78 4.6.24. Idle Timeout ......................................78
4.6.25. ECN Support . . . . . . . . . . . . . . . . . . . . . 79 4.6.25. ECN Support .......................................78
4.6.26. Image Data . . . . . . . . . . . . . . . . . . . . . 79 4.6.26. Image Data ........................................79
4.6.27. Image Identifier . . . . . . . . . . . . . . . . . . 80 4.6.27. Image Identifier ..................................79
4.6.28. Image Information . . . . . . . . . . . . . . . . . . 80 4.6.28. Image Information .................................80
4.6.29. Initiate Download . . . . . . . . . . . . . . . . . . 81 4.6.29. Initiate Download .................................81
4.6.30. Location Data . . . . . . . . . . . . . . . . . . . . 81 4.6.30. Location Data .....................................81
4.6.31. Maximum Message Length . . . . . . . . . . . . . . . 82 4.6.31. Maximum Message Length ............................81
4.6.32. MTU Discovery Padding . . . . . . . . . . . . . . . . 82 4.6.32. MTU Discovery Padding .............................82
4.6.33. Radio Administrative State . . . . . . . . . . . . . 83 4.6.33. Radio Administrative State ........................82
4.6.34. Radio Operational State . . . . . . . . . . . . . . . 84 4.6.34. Radio Operational State ...........................83
4.6.35. Result Code . . . . . . . . . . . . . . . . . . . . . 85 4.6.35. Result Code .......................................84
4.6.36. Returned Message Element . . . . . . . . . . . . . . 86 4.6.36. Returned Message Element ..........................85
4.6.37. Session ID . . . . . . . . . . . . . . . . . . . . . 87 4.6.37. Session ID ........................................86
4.6.38. Statistics Timer . . . . . . . . . . . . . . . . . . 87 4.6.38. Statistics Timer ..................................87
4.6.39. Vendor Specific Payload . . . . . . . . . . . . . . . 88 4.6.39. Vendor Specific Payload ...........................87
4.6.40. WTP Board Data . . . . . . . . . . . . . . . . . . . 89 4.6.40. WTP Board Data ....................................88
4.6.41. WTP Descriptor . . . . . . . . . . . . . . . . . . . 90 4.6.41. WTP Descriptor ....................................89
4.6.42. WTP Fallback . . . . . . . . . . . . . . . . . . . . 92 4.6.42. WTP Fallback ......................................92
4.6.43. WTP Frame Tunnel Mode . . . . . . . . . . . . . . . . 93 4.6.43. WTP Frame Tunnel Mode .............................92
4.6.44. WTP MAC Type . . . . . . . . . . . . . . . . . . . . 94 4.6.44. WTP MAC Type ......................................93
4.6.45. WTP Name . . . . . . . . . . . . . . . . . . . . . . 95 4.6.45. WTP Name ..........................................94
4.6.46. WTP Radio Statistics . . . . . . . . . . . . . . . . 95 4.6.46. WTP Radio Statistics ..............................94
4.6.47. WTP Reboot Statistics . . . . . . . . . . . . . . . . 97 4.6.47. WTP Reboot Statistics .............................96
4.6.48. WTP Static IP Address Information . . . . . . . . . . 98 4.6.48. WTP Static IP Address Information .................97
4.7. CAPWAP Protocol Timers . . . . . . . . . . . . . . . . . 99 4.7. CAPWAP Protocol Timers ....................................98
4.7.1. ChangeStatePendingTimer . . . . . . . . . . . . . . . 99 4.7.1. ChangeStatePendingTimer ............................98
4.7.2. DataChannelKeepAlive . . . . . . . . . . . . . . . . 99 4.7.2. DataChannelKeepAlive ...............................98
4.7.3. DataChannelDeadInterval . . . . . . . . . . . . . . . 99 4.7.3. DataChannelDeadInterval ............................99
4.7.4. DataCheckTimer . . . . . . . . . . . . . . . . . . . 99 4.7.4. DataCheckTimer .....................................99
4.7.5. DiscoveryInterval . . . . . . . . . . . . . . . . . . 100 4.7.5. DiscoveryInterval ..................................99
4.7.6. DTLSSessionDelete . . . . . . . . . . . . . . . . . . 100 4.7.6. DTLSSessionDelete ..................................99
4.7.7. EchoInterval . . . . . . . . . . . . . . . . . . . . 100 4.7.7. EchoInterval .......................................99
4.7.8. IdleTimeout . . . . . . . . . . . . . . . . . . . . . 100 4.7.8. IdleTimeout ........................................99
4.7.9. ImageDataStartTimer . . . . . . . . . . . . . . . . . 100 4.7.9. ImageDataStartTimer ...............................100
4.7.10. MaxDiscoveryInterval . . . . . . . . . . . . . . . . 100 4.7.10. MaxDiscoveryInterval .............................100
4.7.11. ReportInterval . . . . . . . . . . . . . . . . . . . 100 4.7.11. ReportInterval ...................................100
4.7.12. RetransmitInterval . . . . . . . . . . . . . . . . . 101 4.7.12. RetransmitInterval ...............................100
4.7.13. SilentInterval . . . . . . . . . . . . . . . . . . . 101 4.7.13. SilentInterval ...................................100
4.7.14. StatisticsTimer . . . . . . . . . . . . . . . . . . . 101 4.7.14. StatisticsTimer ..................................100
4.7.15. WaitDTLS . . . . . . . . . . . . . . . . . . . . . . 101 4.7.15. WaitDTLS .........................................101
4.7.16. WaitJoin . . . . . . . . . . . . . . . . . . . . . . 101 4.7.16. WaitJoin .........................................101
4.8. CAPWAP Protocol Variables . . . . . . . . . . . . . . . 101 4.8. CAPWAP Protocol Variables ................................101
4.8.1. AdminState . . . . . . . . . . . . . . . . . . . . . 102 4.8.1. AdminState ........................................101
4.8.2. DiscoveryCount . . . . . . . . . . . . . . . . . . . 102 4.8.2. DiscoveryCount ....................................101
4.8.3. FailedDTLSAuthFailCount . . . . . . . . . . . . . . . 102 4.8.3. FailedDTLSAuthFailCount ...........................101
4.8.4. FailedDTLSSessionCount . . . . . . . . . . . . . . . 102 4.8.4. FailedDTLSSessionCount ............................101
4.8.5. MaxDiscoveries . . . . . . . . . . . . . . . . . . . 102 4.8.5. MaxDiscoveries ....................................102
4.8.6. MaxFailedDTLSSessionRetry . . . . . . . . . . . . . . 102 4.8.6. MaxFailedDTLSSessionRetry .........................102
4.8.7. MaxRetransmit . . . . . . . . . . . . . . . . . . . . 102 4.8.7. MaxRetransmit .....................................102
4.8.8. RetransmitCount . . . . . . . . . . . . . . . . . . . 102 4.8.8. RetransmitCount ...................................102
4.8.9. WTPFallBack . . . . . . . . . . . . . . . . . . . . . 103 4.8.9. WTPFallBack .......................................102
4.9. WTP Saved Variables . . . . . . . . . . . . . . . . . . 103 4.9. WTP Saved Variables ......................................102
4.9.1. AdminRebootCount . . . . . . . . . . . . . . . . . . 103 4.9.1. AdminRebootCount ..................................102
4.9.2. FrameEncapType . . . . . . . . . . . . . . . . . . . 103 4.9.2. FrameEncapType ....................................102
4.9.3. LastRebootReason . . . . . . . . . . . . . . . . . . 103 4.9.3. LastRebootReason ..................................103
4.9.4. MacType . . . . . . . . . . . . . . . . . . . . . . . 103 4.9.4. MacType ...........................................103
4.9.5. PreferredACs . . . . . . . . . . . . . . . . . . . . 103 4.9.5. PreferredACs ......................................103
4.9.6. RebootCount . . . . . . . . . . . . . . . . . . . . . 103 4.9.6. RebootCount .......................................103
4.9.7. Static IP Address . . . . . . . . . . . . . . . . . . 103 4.9.7. Static IP Address .................................103
4.9.8. WTPLinkFailureCount . . . . . . . . . . . . . . . . . 104 4.9.8. WTPLinkFailureCount ...............................103
4.9.9. WTPLocation . . . . . . . . . . . . . . . . . . . . . 104 4.9.9. WTPLocation .......................................103
4.9.10. WTPName . . . . . . . . . . . . . . . . . . . . . . . 104 4.9.10. WTPName ..........................................103
5. CAPWAP Discovery Operations . . . . . . . . . . . . . . . . . 105 5. CAPWAP Discovery Operations ...................................103
5.1. Discovery Request Message . . . . . . . . . . . . . . . 105 5.1. Discovery Request Message ................................103
5.2. Discovery Response Message . . . . . . . . . . . . . . . 106 5.2. Discovery Response Message ...............................105
5.3. Primary Discovery Request Message . . . . . . . . . . . 107 5.3. Primary Discovery Request Message ........................106
5.4. Primary Discovery Response . . . . . . . . . . . . . . . 108 5.4. Primary Discovery Response ...............................107
6. CAPWAP Join Operations . . . . . . . . . . . . . . . . . . . 110 6. CAPWAP Join Operations ........................................108
6.1. Join Request . . . . . . . . . . . . . . . . . . . . . . 110 6.1. Join Request .............................................108
6.2. Join Response . . . . . . . . . . . . . . . . . . . . . 111 6.2. Join Response ............................................110
7. Control Channel Management . . . . . . . . . . . . . . . . . 114 7. Control Channel Management ....................................111
7.1. Echo Request . . . . . . . . . . . . . . . . . . . . . . 114 7.1. Echo Request .............................................111
7.2. Echo Response . . . . . . . . . . . . . . . . . . . . . 114 7.2. Echo Response ............................................112
8. WTP Configuration Management . . . . . . . . . . . . . . . . 116 8. WTP Configuration Management ..................................112
8.1. Configuration Consistency . . . . . . . . . . . . . . . 116 8.1. Configuration Consistency ................................112
8.1.1. Configuration Flexibility . . . . . . . . . . . . . . 117 8.1.1. Configuration Flexibility .........................113
8.2. Configuration Status Request . . . . . . . . . . . . . . 117 8.2. Configuration Status Request .............................114
8.3. Configuration Status Response . . . . . . . . . . . . . 118 8.3. Configuration Status Response ............................115
8.4. Configuration Update Request . . . . . . . . . . . . . . 119 8.4. Configuration Update Request .............................116
8.5. Configuration Update Response . . . . . . . . . . . . . 120 8.5. Configuration Update Response ............................117
8.6. Change State Event Request . . . . . . . . . . . . . . . 120 8.6. Change State Event Request ...............................117
8.7. Change State Event Response . . . . . . . . . . . . . . 122 8.7. Change State Event Response ..............................118
8.8. Clear Configuration Request . . . . . . . . . . . . . . 122 8.8. Clear Configuration Request ..............................119
8.9. Clear Configuration Response . . . . . . . . . . . . . . 122 8.9. Clear Configuration Response .............................119
9. Device Management Operations . . . . . . . . . . . . . . . . 124 9. Device Management Operations ..................................120
9.1. Firmware Management . . . . . . . . . . . . . . . . . . 124 9.1. Firmware Management ......................................120
9.1.1. Image Data Request . . . . . . . . . . . . . . . . . 128 9.1.1. Image Data Request ................................124
9.1.2. Image Data Response . . . . . . . . . . . . . . . . . 129 9.1.2. Image Data Response ...............................125
9.2. Reset Request . . . . . . . . . . . . . . . . . . . . . 130 9.2. Reset Request ............................................126
9.3. Reset Response . . . . . . . . . . . . . . . . . . . . . 131 9.3. Reset Response ...........................................127
9.4. WTP Event Request . . . . . . . . . . . . . . . . . . . 131 9.4. WTP Event Request ........................................127
9.5. WTP Event Response . . . . . . . . . . . . . . . . . . . 132 9.5. WTP Event Response .......................................128
9.6. Data Transfer . . . . . . . . . . . . . . . . . . . . . 132 9.6. Data Transfer ............................................128
9.6.1. Data Transfer Request . . . . . . . . . . . . . . . . 133 9.6.1. Data Transfer Request .............................130
9.6.2. Data Transfer Response . . . . . . . . . . . . . . . 134 9.6.2. Data Transfer Response ............................131
10. Station Session Management . . . . . . . . . . . . . . . . . 136 10. Station Session Management ...................................131
10.1. Station Configuration Request . . . . . . . . . . . . . 136 10.1. Station Configuration Request ...........................131
10.2. Station Configuration Response . . . . . . . . . . . . . 136 10.2. Station Configuration Response ..........................132
11. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 138 11. NAT Considerations ...........................................132
12. Security Considerations . . . . . . . . . . . . . . . . . . . 140 12. Security Considerations ......................................134
12.1. CAPWAP Security . . . . . . . . . . . . . . . . . . . . 140 12.1. CAPWAP Security .........................................134
12.1.1. Converting Protected Data into Unprotected Data . . . 141 12.1.1. Converting Protected Data into Unprotected Data ..135
12.1.2. Converting Unprotected Data into Protected Data 12.1.2. Converting Unprotected Data into
(Insertion) . . . . . . . . . . . . . . . . . . . . . 141 Protected Data (Insertion) .......................135
12.1.3. Deletion of Protected Records . . . . . . . . . . . . 141 12.1.3. Deletion of Protected Records ....................135
12.1.4. Insertion of Unprotected Records . . . . . . . . . . 141 12.1.4. Insertion of Unprotected Records .................135
12.1.5. Use of MD5 . . . . . . . . . . . . . . . . . . . . . 141 12.1.5. Use of MD5 .......................................136
12.1.6. CAPWAP Fragmentation . . . . . . . . . . . . . . . . 141 12.1.6. CAPWAP Fragmentation .............................136
12.2. Session ID Security . . . . . . . . . . . . . . . . . . 142 12.2. Session ID Security .....................................136
12.3. Discovery or DTLS Setup Attacks . . . . . . . . . . . . 142 12.3. Discovery or DTLS Setup Attacks .........................137
12.4. Interference with a DTLS Session . . . . . . . . . . . . 143 12.4. Interference with a DTLS Session ........................137
12.5. CAPWAP Pre-Provisioning . . . . . . . . . . . . . . . . 143 12.5. CAPWAP Pre-Provisioning .................................138
12.6. Use of Preshared Keys in CAPWAP . . . . . . . . . . . . 144 12.6. Use of Pre-Shared Keys in CAPWAP ........................139
12.7. Use of Certificates in CAPWAP . . . . . . . . . . . . . 145 12.7. Use of Certificates in CAPWAP ...........................140
12.8. Use of MAC Address in CN Field . . . . . . . . . . . . . 146 12.8. Use of MAC Address in CN Field ..........................140
12.9. AAA Security . . . . . . . . . . . . . . . . . . . . . . 146 12.9. AAA Security ............................................141
12.10. WTP Firmware . . . . . . . . . . . . . . . . . . . . . . 147 12.10. WTP Firmware ...........................................141
13. Operational Considerations . . . . . . . . . . . . . . . . . 148 13. Operational Considerations ...................................141
14. Transport Considerations . . . . . . . . . . . . . . . . . . 149 14. Transport Considerations .....................................142
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 150 15. IANA Considerations ..........................................143
15.1. IPv4 Multicast Address . . . . . . . . . . . . . . . . . 150 15.1. IPv4 Multicast Address ..................................143
15.2. IPv6 Multicast Address . . . . . . . . . . . . . . . . . 150 15.2. IPv6 Multicast Address ..................................144
15.3. UDP Port . . . . . . . . . . . . . . . . . . . . . . . . 150 15.3. UDP Port ................................................144
15.4. CAPWAP Message Types . . . . . . . . . . . . . . . . . . 151 15.4. CAPWAP Message Types ....................................144
15.5. CAPWAP Header Flags . . . . . . . . . . . . . . . . . . 151 15.5. CAPWAP Header Flags .....................................144
15.6. CAPWAP Control Message Flags . . . . . . . . . . . . . . 151 15.6. CAPWAP Control Message Flags ............................145
15.7. CAPWAP Message Element Type . . . . . . . . . . . . . . 152 15.7. CAPWAP Message Element Type .............................145
15.8. Wireless Binding Identifiers . . . . . . . . . . . . . . 152 15.8. CAPWAP Wireless Binding Identifiers .....................145
15.9. AC Security Types . . . . . . . . . . . . . . . . . . . 152 15.9. AC Security Types .......................................146
15.10. AC DTLS Policy . . . . . . . . . . . . . . . . . . . . . 153 15.10. AC DTLS Policy .........................................146
15.11. AC Information Type . . . . . . . . . . . . . . . . . . 153 15.11. AC Information Type ....................................146
15.12. CAPWAP Transport Protocol Types . . . . . . . . . . . . 153 15.12. CAPWAP Transport Protocol Types ........................146
15.13. Data Transfer Type . . . . . . . . . . . . . . . . . . . 153 15.13. Data Transfer Type .....................................147
15.14. Data Transfer Mode . . . . . . . . . . . . . . . . . . . 154 15.14. Data Transfer Mode .....................................147
15.15. Discovery Types . . . . . . . . . . . . . . . . . . . . 154 15.15. Discovery Types ........................................147
15.16. ECN Support . . . . . . . . . . . . . . . . . . . . . . 154 15.16. ECN Support ............................................148
15.17. Radio Admin State . . . . . . . . . . . . . . . . . . . 155 15.17. Radio Admin State ......................................148
15.18. Radio Operational State . . . . . . . . . . . . . . . . 155 15.18. Radio Operational State ................................148
15.19. Radio Failure Causes . . . . . . . . . . . . . . . . . . 155 15.19. Radio Failure Causes ...................................148
15.20. Result Code . . . . . . . . . . . . . . . . . . . . . . 155 15.20. Result Code ............................................149
15.21. Returned Message Element Reason . . . . . . . . . . . . 156 15.21. Returned Message Element Reason ........................149
15.22. WTP Board Data Type . . . . . . . . . . . . . . . . . . 156 15.22. WTP Board Data Type ....................................149
15.23. WTP Descriptor Type . . . . . . . . . . . . . . . . . . 156 15.23. WTP Descriptor Type ....................................149
15.24. WTP Fallback Mode . . . . . . . . . . . . . . . . . . . 156 15.24. WTP Fallback Mode ......................................150
15.25. WTP Frame Tunnel Mode . . . . . . . . . . . . . . . . . 157 15.25. WTP Frame Tunnel Mode ..................................150
15.26. WTP MAC Type . . . . . . . . . . . . . . . . . . . . . . 157 15.26. WTP MAC Type ...........................................150
15.27. WTP Radio Stats Failure Type . . . . . . . . . . . . . . 157 15.27. WTP Radio Stats Failure Type ...........................151
15.28. WTP Reboot Stats Failure Type . . . . . . . . . . . . . 158 15.28. WTP Reboot Stats Failure Type ..........................151
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 159 16. Acknowledgments ..............................................151
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 160 17. References ...................................................151
17.1. Normative References . . . . . . . . . . . . . . . . . . 160 17.1. Normative References ....................................151
17.2. Informational References . . . . . . . . . . . . . . . . 162 17.2. Informative References ..................................153
Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 164
Intellectual Property and Copyright Statements . . . . . . . . . 165
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 that 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 (L2)
and meets the Objectives for Control and Provisioning of Wireless technology, and meets the objectives in "Objectives for Control and
Access Points (CAPWAP) [RFC4564]. Provisioning of Wireless Access Points (CAPWAP)" [RFC4564].
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,
interoperable protocol could radically simplify the deployment and interoperable protocol could radically simplify the deployment and
management of wireless networks. WTPs require a set of dynamic management of wireless networks. WTPs require a set of dynamic
management and control functions related to their primary task of management and control functions related to their primary task of
connecting the wireless and wired mediums. Traditional protocols for connecting the wireless and wired mediums. Traditional protocols for
managing WTPs are either manual static configuration via HTTP, managing WTPs are either manual static configuration via HTTP,
proprietary Layer 2 specific or non-existent (if the WTPs are self- proprietary Layer 2-specific or non-existent (if the WTPs are self-
contained). An IEEE 802.11 binding is defined in contained). An IEEE 802.11 binding is defined in [RFC5416] to
[I-D.ietf-capwap-protocol-binding-ieee80211] to support use of the support use of the CAPWAP protocol with IEEE 802.11 WLAN networks.
CAPWAP protocol with IEEE 802.11 WLAN networks.
CAPWAP assumes a network configuration consisting of multiple WTPs CAPWAP assumes a network configuration consisting of multiple WTPs
communicating via the Internet Protocol (IP) to an AC. WTPs are communicating via the Internet Protocol (IP) to an AC. WTPs are
viewed as remote RF interfaces controlled by the AC. The CAPWAP viewed as remote radio frequency (RF) interfaces controlled by the
protocol supports two modes of operation: Split and Local MAC. In AC. The CAPWAP protocol supports two modes of operation: Split and
Split MAC mode all L2 wireless data and management frames are Local MAC (medium access control). In Split MAC mode, all L2
encapsulated via the CAPWAP protocol and exchanged between the AC and wireless data and management frames are encapsulated via the CAPWAP
the WTP. As shown in Figure 1, the wireless frames received from a protocol and exchanged between the AC and the WTP. As shown in
mobile device, which is referred to in this specification as a Figure 1, the wireless frames received from a mobile device, which is
Station (STA), are directly encapsulated by the WTP and forwarded to referred to in this specification as a Station (STA), are directly
the AC. encapsulated by the WTP and forwarded to the AC.
+-+ wireless frames +-+ +-+ wireless frames +-+
| |--------------------------------| | | |--------------------------------| |
| | +-+ | | | | +-+ | |
| |--------------| |---------------| | | |--------------| |---------------| |
| |wireless PHY/ | | CAPWAP | | | |wireless PHY/ | | CAPWAP | |
| | MAC sublayer | | | | | | MAC sublayer | | | |
+-+ +-+ +-+ +-+ +-+ +-+
STA WTP AC STA WTP AC
Figure 1: Representative CAPWAP Architecture for Split MAC Figure 1: Representative CAPWAP Architecture for Split MAC
The Local MAC mode of operation allows for the data frames to be The Local MAC mode of operation allows for the data frames to be
either locally bridged, or tunneled as 802.3 frames. The latter either locally bridged or tunneled as 802.3 frames. The latter
implies that the WTP performs the 802.11 Integration function. In implies that the WTP performs the 802.11 Integration function. In
either case the L2 wireless management frames are processed locally either case, the L2 wireless management frames are processed locally
by the WTP, and then forwarded to the AC. Figure 2 shows the Local by the WTP and then forwarded to the AC. Figure 2 shows the Local
MAC mode, in which a station transmits a wireless frame which is MAC mode, in which a station transmits a wireless frame that is
encapsulated in an 802.3 frame and forwarded to the AC. encapsulated in an 802.3 frame and forwarded to the AC.
+-+wireless frames +-+ 802.3 frames +-+ +-+wireless frames +-+ 802.3 frames +-+
| |----------------| |--------------| | | |----------------| |--------------| |
| | | | | | | | | | | |
| |----------------| |--------------| | | |----------------| |--------------| |
| |wireless PHY/ | | CAPWAP | | | |wireless PHY/ | | CAPWAP | |
| | MAC sublayer | | | | | | MAC sublayer | | | |
+-+ +-+ +-+ +-+ +-+ +-+
STA WTP AC STA WTP AC
Figure 2: Representative CAPWAP Architecture for Local MAC Figure 2: Representative CAPWAP Architecture for Local MAC
Provisioning WTPs with security credentials, and managing which WTPs Provisioning WTPs with security credentials and managing which WTPs
are authorized to provide service are traditionally handled by are authorized to provide service are traditionally handled by
proprietary solutions. Allowing these functions to be performed from proprietary solutions. Allowing these functions to be performed from
a centralized AC in an interoperable fashion increases manageability a centralized AC in an interoperable fashion increases manageability
and allows network operators to more tightly control their wireless and allows network operators to more tightly control their wireless
network infrastructure. network infrastructure.
1.1. Goals 1.1. Goals
The goals for the CAPWAP protocol are listed below: The goals for the CAPWAP protocol are listed below:
1. To centralize the authentication and policy enforcement functions 1. To centralize the authentication and policy enforcement functions
for a wireless network. The AC may also provide centralized for a wireless network. The AC may also provide centralized
bridging, forwarding, and encryption of user traffic. bridging, forwarding, and encryption of user traffic.
Centralization of these functions will enable reduced cost and Centralization of these functions will enable reduced cost and
higher efficiency by applying the capabilities of network higher efficiency by applying the capabilities of network
processing silicon to the wireless network, as in wired LANs. processing silicon to the wireless network, as in wired LANs.
2. To enable shifting of the higher level protocol processing from 2. To enable shifting of the higher-level protocol processing from
the WTP. This leaves the time critical applications of wireless the WTP. This leaves the time-critical applications of wireless
control and access in the WTP, making efficient use of the control and access in the WTP, making efficient use of the
computing power available in WTPs which are the subject to severe computing power available in WTPs, which are subject to severe
cost pressure. cost pressure.
3. To provide an extensible protocol that is not bound to a specific 3. To provide an extensible protocol that is not bound to a specific
wireless technology. Extensibility is provided via a generic wireless technology. Extensibility is provided via a generic
encapsulation and transport mechanism, enabling the CAPWAP encapsulation and transport mechanism, enabling the CAPWAP
protocol to be applied to many access point types in the future, protocol to be applied to many access point types in the future,
via a specific wireless binding. via a specific wireless binding.
The CAPWAP protocol concerns itself solely with the interface between The CAPWAP protocol concerns itself solely with the interface between
the WTP and the AC. Inter-AC and station-to AC-communication are the WTP and the AC. Inter-AC and station-to-AC communication are
strictly outside the scope of this document. strictly outside the scope of this document.
1.2. Conventions used in this document 1.2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1.3. Contributing Authors 1.3. Contributing Authors
This section lists and acknowledges the authors of significant text This section lists and acknowledges the authors of significant text
and concepts included in this specification. and concepts included in this specification.
The CAPWAP Working Group selected the Lightweight Access Point The CAPWAP Working Group selected the Lightweight Access Point
Protocol (LWAPP) [I-D.ohara-capwap-lwapp] to be used as the basis of Protocol (LWAPP) [LWAPP] to be used as the basis of the CAPWAP
the CAPWAP protocol specification. The following people are authors protocol specification. The following people are authors of the
of the LWAPP document: LWAPP document:
Bob O'Hara Bob O'Hara
Email: bob.ohara@computer.org Email: bob.ohara@computer.org
Pat Calhoun, Cisco Systems, Inc. Pat Calhoun, Cisco Systems, Inc.
170 West Tasman Drive, San Jose, CA 95134 170 West Tasman Drive, San Jose, CA 95134
Phone: +1 408-902-3240, Email: pcalhoun@cisco.com Phone: +1 408-902-3240, Email: pcalhoun@cisco.com
Rohit Suri, Cisco Systems, Inc. Rohit Suri, Cisco Systems, Inc.
170 West Tasman Drive, San Jose, CA 95134 170 West Tasman Drive, San Jose, CA 95134
skipping to change at page 10, line 7 skipping to change at page 10, line 7
Sue Hares, Green Hills Software Sue Hares, Green Hills Software
825 Victors Way, Suite 100, Ann Arbor, MI 48108 825 Victors Way, Suite 100, Ann Arbor, MI 48108
Phone: +1 734 222 1610, Email: shares@ndzh.com Phone: +1 734 222 1610, Email: shares@ndzh.com
Datagram Transport Layer Security (DTLS) [RFC4347] is used as the Datagram Transport Layer Security (DTLS) [RFC4347] is used as the
security solution for the CAPWAP protocol. The following people are security solution for the CAPWAP protocol. The following people are
authors of significant DTLS-related text included in this document: authors of significant DTLS-related text included in this document:
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
Eric Rescorla, Network Resonance Eric Rescorla, Network Resonance
2483 El Camino Real, #212,Palo Alto CA, 94303 2483 El Camino Real, #212,Palo Alto CA, 94303
Email: ekr@networkresonance.com Email: ekr@networkresonance.com
The concept of using DTLS to secure the CAPWAP protocol was part of The concept of using DTLS to secure the CAPWAP protocol was part of
the Secure Light Access Point Protocol (SLAPP) proposal the Secure Light Access Point Protocol (SLAPP) proposal [SLAPP]. The
[I-D.narasimhan-ietf-slapp]. The following people are authors of the following people are authors of the SLAPP proposal:
SLAPP proposal:
Partha Narasimhan, Aruba Networks Partha Narasimhan, Aruba Networks
1322 Crossman Ave, Sunnyvale, CA 94089 1322 Crossman Ave, Sunnyvale, CA 94089
Phone: +1 408-480-4716, Email: partha@arubanetworks.com Phone: +1 408-480-4716
Email: partha@arubanetworks.com
Dan Harkins, Tropos Networks Dan Harkins
555 Del Rey Avenue, Sunnyvale, CA, 95085 Trapeze Networks
Phone: +1 408 470 7372, Email: dharkins@tropos.com 5753 W. Las Positas Blvd, Pleasanton, CA 94588
Phone: +1-925-474-2212
EMail: dharkins@trpz.com
Subbu Ponnuswamy, Aruba Networks Subbu Ponnuswamy, Aruba Networks
1322 Crossman Ave, Sunnyvale, CA 94089 1322 Crossman Ave, Sunnyvale, CA 94089
Phone: +1 408-754-1213, Email: subbu@arubanetworks.com Phone: +1 408-754-1213
Email: subbu@arubanetworks.com
The following individuals contributed significant security related The following individuals contributed significant security-related
text to the draft: text to the document [RFC5418]:
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: scott@hyperthought.com
1.4. Terminology 1.4. Terminology
Access Controller (AC): The network entity that provides WTP 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 interface to a wireless Station (STA): A device that contains an interface to a wireless
medium (WM). 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 Physical Layer (PHY) to transmit
station traffic for wireless access networks. and receive station traffic for wireless access networks.
This document uses additional terminology defined in [RFC3753]. This document uses additional terminology defined in [RFC3753].
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
and data plane communication via a CAPWAP protocol transport and data plane communication via a CAPWAP protocol transport
mechanism. CAPWAP control messages, and optionally CAPWAP data mechanism. CAPWAP Control messages, and optionally CAPWAP Data
messages, are secured using Datagram Transport Layer Security (DTLS) messages, are secured using Datagram Transport Layer Security (DTLS)
[RFC4347]. DTLS is a standards-track IETF protocol based upon TLS. [RFC4347]. DTLS is a standards-track IETF protocol based upon TLS.
The underlying security-related protocol mechanisms of TLS have been The underlying security-related protocol mechanisms of TLS have been
successfully deployed for many years. successfully deployed for many years.
The CAPWAP protocol Transport layer carries two types of payload, The CAPWAP protocol transport layer carries two types of payload,
CAPWAP Data messages and CAPWAP Control messages. CAPWAP Data CAPWAP Data messages and CAPWAP Control messages. CAPWAP Data
messages encapsulate forwarded wireless frames. CAPWAP protocol messages encapsulate forwarded wireless frames. CAPWAP protocol
Control messages are management messages exchanged between a WTP and Control messages are management messages exchanged between a WTP and
an AC. The CAPWAP Data and Control packets are sent over separate an AC. The CAPWAP Data and Control packets are sent over separate
UDP ports. Since both data and control packets can exceed the UDP ports. Since both data and control packets can exceed the
Maximum Transmission Unit (MTU) length, the payload of a CAPWAP data Maximum Transmission Unit (MTU) length, the payload of a CAPWAP Data
or control message can be fragmented. The fragmentation behavior is or Control message can be fragmented. The fragmentation behavior is
defined in Section 3. defined in Section 3.
The CAPWAP Protocol begins with a discovery phase. The WTPs send a The CAPWAP Protocol begins with a Discovery phase. The WTPs send a
Discovery Request message, causing any Access Controller (AC) Discovery Request message, causing any Access Controller (AC)
receiving the message to respond with a Discovery Response message. receiving the message to respond with a Discovery Response message.
From the Discovery Response messages received, a WTP selects an AC From the Discovery Response messages received, a WTP selects an AC
with which to establish a secure DTLS session. In order to establish with which to establish a secure DTLS session. In order to establish
the secure DTLS connection, the WTP will need some amount of pre- the secure DTLS connection, the WTP will need some amount of pre-
provisioning, which is specified in Section 12.5. CAPWAP protocol provisioning, which is specified in Section 12.5. CAPWAP protocol
messages will be fragmented to the maximum length discovered to be messages will be fragmented to the maximum length discovered to be
supported by the network. supported by the network.
Once the WTP and the AC have completed DTLS session establishment, a Once the WTP and the AC have completed DTLS session establishment, a
configuration exchange occurs in which both devices agree on version configuration exchange occurs in which both devices agree on version
information. During this exchange the WTP may receive provisioning information. During this exchange, the WTP may receive provisioning
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 are 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.
The CAPWAP protocol provides for a keep alive feature that preserves The CAPWAP protocol provides for a keep-alive feature that preserves
the communication channel between the WTP and AC. If the AC fails to the communication channel between the WTP and AC. If the AC fails to
appear alive, the WTP will try to discover a new AC. appear alive, the WTP will try to discover a new AC.
2.1. Wireless Binding Definition 2.1. Wireless Binding Definition
The CAPWAP protocol is independent of a specific WTP radio The CAPWAP protocol is independent of a specific WTP radio
technology, as well its associated wireless link layer protocol. technology, as well its associated wireless link layer protocol.
Elements of the CAPWAP protocol are designed to accommodate the Elements of the CAPWAP protocol are designed to accommodate the
specific needs of each wireless technology in a standard way. specific needs of each wireless technology in a standard way.
Implementation of the CAPWAP protocol for a particular wireless Implementation of the CAPWAP protocol for a particular wireless
technology MUST follow the binding requirements defined for that technology MUST follow the binding requirements defined for that
technology. 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 element, 1. The definition for a binding-specific Statistics message 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 Discovery, 3. A WTP Radio Information message element carried in the Discovery,
Primary Discovery and Join Request and Response messages, Primary Discovery, and Join Request and Response messages,
indicating the binding specific radio types supported at the WTP indicating the binding-specific radio types supported at 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 [I-D.ietf-capwap-protocol-binding-ieee80211], begins with provided in [RFC5416], begins with "IEEE 802.11".
"IEEE 802.11".
The CAPWAP binding concept MUST also be used in any future The CAPWAP binding concept MUST also be used in any future
specification that add functionality to either the base CAPWAP specifications that add functionality to either the base CAPWAP
protocol specification, or any published CAPWAP binding protocol specification, or any published CAPWAP binding
specification. A separate WTP Radio Information message element MUST specification. A separate WTP Radio Information message element MUST
be created to properly advertise support for the specification. This be created to properly advertise support for the specification. This
mechanism allows for future protocol extensibility, while providing mechanism allows for future protocol extensibility, while providing
the 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 between a CAPWAP WTP and AC. The annotated ladder diagram exchanges between a CAPWAP WTP and AC. The annotated ladder diagram
shows the AC on the right, the WTP on the left, and assumes the use shows the AC on the right, the WTP on the left, and assumes the use
of certificates for DTLS authentication. The CAPWAP Protocol State of 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 asterisk in Figure 3. denoted via an asterisk in Figure 3.
============ ============ ============ ============
WTP AC WTP AC
============ ============ ============ ============
[----------- begin optional discovery ------------] [----------- begin optional discovery ------------]
Discover Request Discover Request
------------------------------------> ------------------------------------>
skipping to change at page 16, line 4 skipping to change at page 15, line 21
Echo Response Echo Response
<------------------------------------ <------------------------------------
: :
: :
Event Request Event Request
------------------------------------> ------------------------------------>
Event Response Event Response
<------------------------------------ <------------------------------------
: :
: :
Figure 3: CAPWAP Control Protocol Exchange Figure 3: CAPWAP Control Protocol Exchange
At the end of the illustrated CAPWAP message exchange, the AC and WTP At the end of the illustrated CAPWAP message exchange, the AC and WTP
are securely exchanging CAPWAP control messages. This illustration are securely exchanging CAPWAP Control messages. This illustration
is provided to clarify protocol operation, and does not include any is provided to clarify protocol operation, and does not include any
possible error conditions. Section 2.3 provides a detailed possible error conditions. Section 2.3 provides a detailed
description of the corresponding state machine. description of the corresponding state machine.
2.3. CAPWAP State Machine Definition 2.3. CAPWAP State Machine Definition
The following state diagram represents the lifecycle of a WTP-AC The following state diagram represents the lifecycle of a WTP-AC
session. Use of DTLS by the CAPWAP protocol results in the session. Use of DTLS by the CAPWAP protocol results in the
juxtaposition of two nominally separate yet tightly bound state juxtaposition of two nominally separate yet tightly bound state
machines. The DTLS and CAPWAP state machines are coupled through an machines. The DTLS and CAPWAP state machines are coupled through an
skipping to change at page 17, line 51 skipping to change at page 16, line 51
| | | | | +-------+ | | | | | +-------+
*| |u | \---------+---| Start | *| |u | \---------+---| Start |
| | |@ | +-------+ | | |@ | +-------+
| \->+---------+<------/ | \->+---------+<------/
\--->| Sulking | \--->| Sulking |
+---------+& +---------+&
Figure 4: CAPWAP Integrated State Machine Figure 4: 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 message 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 state machine works single instance of the CAPWAP state machine. The state machine works
differently on the AC since it communicates with many WTPs. The AC differently on the AC since it communicates with many WTPs. The AC
uses the concept of three threads. Note that the term thread used uses the concept of three threads. Note that the term thread used
here does not necessarily imply that implementers must use threads, here does not necessarily imply that implementers must use threads,
but it is one possible way of implementing the AC's state machine. but it is one possible way of implementing the AC's state machine.
Listener Thread: The AC's Listener thread handles inbound DTLS Listener Thread: The AC's Listener thread handles inbound DTLS
session establishment requests, through the DTLSListen command. session establishment requests, through the DTLSListen command.
Upon creation, the Listener thread starts in the DTLS Setup state. Upon creation, the Listener thread starts in the DTLS Setup state.
Once a DTLS session has been validated, which occurs when the Once a DTLS session has been validated, which occurs when the
state machine enters the "Authorize" state, the Listener thread state machine enters the "Authorize" state, the Listener thread
creates a WTP session specific Service thread and state context. creates a WTP session-specific Service thread and state context.
The state machine transitions in Figure 4 are represented by The state machine transitions in Figure 4 are represented by
numerals. It is necessary for the AC to protect itself against numerals. It is necessary for the AC to protect itself against
various attacks that exist with non-authenticated frames. See various attacks that exist with non-authenticated frames. See
Section 12 for more information. Section 12 for more information.
Discovery Thread: The AC's Discovery thread is responsible for Discovery Thread: The AC's Discovery thread is responsible for
receiving, and responding to, Discovery Request messages. The receiving, and responding to, Discovery Request messages. The
state machine transitions in Figure 4 are represented by numerals. state machine transitions in Figure 4 are represented by numerals.
Note that the Discovery thread does not maintain any per-WTP Note that the Discovery thread does not maintain any per-WTP-
specific context information, and a single state context exists. specific context information, and a single state context exists.
It is necessary for the AC to protect itself against various It is necessary for the AC to protect itself against various
attacks that exist with non-authenticated frames. See Section 12 attacks that exist with non-authenticated frames. See Section 12
for more information. for more information.
Service Thread: The AC's Service thread handles the per-WTP states, Service Thread: The AC's Service thread handles the per-WTP states,
and one such thread exists per-WTP connection. This thread is and one such thread exists per-WTP connection. This thread is
created by the listener thread when the Authorize state is created by the Listener thread when the Authorize state is
reached. When created, the Service thread inherits a copy of the reached. When created, the Service thread inherits a copy of the
state machine context from the Listener thread. When state machine context from the Listener thread. When
communication with the WTP is complete, the Service thread is communication with the WTP is complete, the Service thread is
terminated and all associated resources are released. The state terminated and all associated resources are released. The state
machine transitions in Figure 4 are represented by alphabetic and machine transitions in Figure 4 are represented by alphabetic and
punctuation characters. punctuation characters.
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
skipping to change at page 19, line 19 skipping to change at page 18, line 19
state machine. state machine.
AC: The AC creates the Discovery and Listener threads and starts AC: The AC creates the Discovery and Listener threads and starts
the CAPWAP state machine. the CAPWAP state machine.
Idle to Discovery (1): This transition occurs to support the CAPWAP Idle to Discovery (1): This transition occurs to support the CAPWAP
discovery process . discovery process .
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
(see Section 4.7). The WTP resets the DiscoveryCount counter timer (see Section 4.7). The WTP resets the DiscoveryCount
to zero (0) (see Section 4.8). The WTP also clears all counter to zero (0) (see Section 4.8). The WTP also clears
information from ACs it may have received during a previous all information from ACs it may have received during a
Discovery phase. previous Discovery phase.
AC: This state transition is executed by the AC's Discovery AC: This state transition is executed by the AC's Discovery
thread, and occurs when a Discovery Request message is thread, and occurs when a Discovery Request message is
received. The AC SHOULD respond with a Discovery Response received. The AC SHOULD respond with a Discovery Response
message (see Section 5.2). message (see Section 5.2).
Discovery to Discovery (#): In the Discovery state, the WTP Discovery to Discovery (#): In the Discovery state, the WTP
determines which AC to connect to. determines to which AC to connect.
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
has not received a Discovery Response message. For every it 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
counter. See Section 5.1 for more information on how the WTP DiscoveryCount counter. See Section 5.1 for more
knows the ACs to which it should transmit the Discovery Request information on how the WTP knows the ACs to which it should
messages. The WTP restarts the DiscoveryInterval timer transmit the Discovery Request messages. The WTP restarts
whenever it transmits Discovery Request messages. the DiscoveryInterval timer whenever it transmits Discovery
Request messages.
AC: This is an invalid state transition for the AC. AC: This is an invalid state transition for the AC.
Discovery to Idle (2): This transition occurs on the AC's Discovery Discovery to Idle (2): This transition occurs on the AC's Discovery
thread when the Discovery processing is complete. thread when the Discovery processing is complete.
WTP: This is an invalid state transition for the WTP. WTP: This is an invalid state transition for the WTP.
AC: This state transition is executed by the AC's Discovery AC: This state transition is executed by the AC's Discovery
thread when it has transmitted the Discovery Response, in thread when it has transmitted the Discovery Response, in
response to a Discovery Request. response to a Discovery Request.
Discovery to Sulking (!): This transition occurs on a WTP when AC Discovery to Sulking (!): This transition occurs on a WTP when AC
Discovery fails. Discovery fails.
WTP: The WTP enters this state when the DiscoveryInterval timer WTP: The WTP enters this state when the DiscoveryInterval timer
expires and 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
state, the WTP MUST start the SilentInterval timer. While in this state, the WTP MUST start the SilentInterval timer.
the Sulking state, all received CAPWAP protocol messages MUST While in the Sulking state, all received CAPWAP protocol
be ignored. messages MUST be ignored.
AC: This is an invalid state transition for the AC. AC: This is an invalid state transition for the AC.
Sulking to Idle (@): This transition occurs on a WTP when it must Sulking to Idle (@): 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
to zero. reset to zero.
AC: This is an invalid state transition for the AC. AC: This is an invalid state transition for the AC.
Sulking to Sulking (&): The Sulking state provides the silent Sulking to Sulking (&): 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: This is an invalid state transition for the AC. AC: This is an invalid state transition for the AC.
Idle to DTLS Setup (3): This transition occurs to establish a secure Idle to DTLS Setup (3): 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(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 and the WaitDTLS timer is establishment with the chosen AC and the WaitDTLS timer is
started (see Section 4.7). When the discovery phase is started (see Section 4.7). When the Discovery phase is
bypassed, it is assumed the WTP has locally configured ACs. bypassed, it is assumed the WTP has locally configured ACs.
AC: Upon entering the Idle state from the Start state, the newly AC: Upon entering the Idle state from the Start state, the newly
created Listener thread automatically transitions to the DTLS created Listener thread automatically transitions to the
Setup and invokes the DTLSListen command (see Section 2.3.2.1), DTLS Setup and invokes the DTLSListen command (see
and the WaitDTLS timer is started (see Section 4.7). Section 2.3.2.1), and the WaitDTLS timer is started (see
Section 4.7).
Discovery to DTLS Setup (%): This transition occurs to establish a Discovery to DTLS Setup (%): 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 to which
connect to is the result of the discovery phase, which is AC to connect is the result of the Discovery phase, which is
described in Section 3.3. described in Section 3.3.
AC: This is an invalid state transition for the AC. AC: This is an invalid state transition for the AC.
DTLS Setup to Idle ($): This transition occurs when the DTLS DTLS Setup to Idle ($): This transition occurs when the DTLS
connection setup fails. 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
and the FailedDTLSSessionCount or the FailedDTLSAuthFailCount Section 2.3.2.2), and the FailedDTLSSessionCount or the
counter have not reached the value of the FailedDTLSAuthFailCount counter have not reached the value
MaxFailedDTLSSessionRetry variable (see Section 4.8). This of the MaxFailedDTLSSessionRetry variable (see Section 4.8).
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. This state FailedDTLSSessionCount counter is incremented. This state
transition also occurs if the WaitDTLS timer has expired. transition also occurs if the WaitDTLS timer has expired.
AC: This is an invalid state transition for the AC. AC: This is an invalid state transition for the AC.
DTLS Setup to Sulking (*): This transition occurs when repeated DTLS Setup to Sulking (*): This transition occurs when repeated
attempts to setup the DTLS connection have failed. attempts to setup the DTLS connection have failed.
WTP: The WTP enters this state when the FailedDTLSSessionCount or WTP: The WTP enters this state when the FailedDTLSSessionCount or
skipping to change at page 22, line 20 skipping to change at page 21, line 25
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 is handled by the AC's Listener thread AC: This state transition is handled by the AC's Listener thread
when the DTLS module initiates the DTLSPeerAuthorize when the DTLS module initiates the DTLSPeerAuthorize
notification (see Section 2.3.2.2). The Listener thread forks notification (see Section 2.3.2.2). The Listener thread
an instance of the Service thread, along with a copy of the forks an instance of the Service thread, along with a copy
state context. Once created, the Service thread performs an of the state context. Once created, the Service thread
authorization check against the WTP credentials. See performs an authorization check against the WTP credentials.
Section 2.4.4 for more information on WTP authorization. See Section 2.4.4 for more information on WTP authorization.
Authorize to DTLS Setup (6): This transition is executed by the Authorize to DTLS Setup (6): This transition is executed by the
Listener thread to enable it to listen for new incoming sessions. Listener thread to enable it to listen for new incoming sessions.
WTP: This is an invalid state transition for the WTP. WTP: This is an invalid state transition for the WTP.
AC: This state transition occurs when the AC's Listener thread AC: This state transition occurs when the AC's Listener thread
has created the WTP context and the Service thread. The has created the WTP context and the Service thread. The
Listener thread then invokes the DTLSListen command (see Listener thread then invokes the DTLSListen command (see
Section 2.3.2.1). Section 2.3.2.1).
Authorize to DTLS Connect (a): This transition occurs to notify the Authorize to DTLS Connect (a): 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 successfully WTP: This state transition occurs when the WTP has successfully
authorized the AC's credentials (see Section 2.4.4). This is authorized the AC's credentials (see Section 2.4.4). This
done by invoking the DTLSAccept DTLS command (see is done by 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 successfully AC: This state transition occurs when the AC has successfully
authorized the WTP's credentials (see Section 2.4.4). This is authorized the WTP's credentials (see Section 2.4.4). This
done by invoking the DTLSAccept DTLS command (see is done by invoking the DTLSAccept DTLS command (see
Section 2.3.2.1). Section 2.3.2.1).
Authorize to DTLS Teardown (b): This transition occurs to notify the Authorize to DTLS Teardown (b): 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 has been 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). This state transition also command (see Section 2.3.2.1). This state transition also
occurs if the WaitDTLS timer has expired. The WTP starts the occurs if the WaitDTLS timer has expired. The WTP starts
DTLSSessionDelete timer (see Section 4.7.6). the DTLSSessionDelete timer (see Section 4.7.6).
AC: This state transition occurs when the AC was unable to AC: This state transition occurs when the AC has been 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). This state transition also command (see Section 2.3.2.1). This state transition also
occurs if the WaitDTLS timer has expired. The AC starts the occurs if the WaitDTLS timer has expired. The AC starts the
DTLSSessionDelete timer (see Section 4.7.6). DTLSSessionDelete timer (see Section 4.7.6).
DTLS Connect to DTLS Teardown (c): This transition occurs when the DTLS Connect to DTLS Teardown (c): This transition occurs when the
DTLS 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
the DTLSAuthenticateFail notification, the to the DTLSAuthenticateFail notification, the
FailedDTLSAuthFailCount is incremented, otherwise the FailedDTLSAuthFailCount is incremented; otherwise, the
FailedDTLSSessionCount counter is incremented. This state FailedDTLSSessionCount counter is incremented. This state
transition also occurs if the WaitDTLS timer has expired. The transition also occurs if the WaitDTLS timer has expired.
WTP starts the DTLSSessionDelete timer (see Section 4.7.6). The WTP starts the DTLSSessionDelete timer (see
Section 4.7.6).
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, and both of the successfully established, and both of the
FailedDTLSAuthFailCount and FailedDTLSSessionCount counters FailedDTLSAuthFailCount and FailedDTLSSessionCount counters
have not reached the value of the MaxFailedDTLSSessionRetry have not reached the value of the MaxFailedDTLSSessionRetry
variable (see Section 4.8). This state transition also occurs variable (see Section 4.8). This state transition also
if the WaitDTLS timer has expired. The AC starts the occurs if the WaitDTLS timer has expired. The AC starts the
DTLSSessionDelete timer (see Section 4.7.6). DTLSSessionDelete timer (see Section 4.7.6).
DTLS Connect to Join (d): This transition occurs when the DTLS DTLS Connect to Join (d): 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),
that the DTLS session was successfully established. When this indicating that the DTLS session was successfully
notification is received, the FailedDTLSSessionCount counter is established. When this notification is received, the
set to zero. The WTP enters the Join state by transmiting the FailedDTLSSessionCount counter is set to zero. The WTP
Join Request to the AC. The WTP stops the WaitDTLS timer. enters the Join state by transmitting the Join Request to
the AC. The WTP stops the WaitDTLS timer.
AC: This state transition occurs when the AC receives the 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),
that the DTLS session was successfully established. When this indicating that the DTLS session was successfully
notification is received, the FailedDTLSSessionCount counter is established. When this notification is received, the
set to zero. The AC stops the WaitDTLS timer, and starts the FailedDTLSSessionCount counter is set to zero. The AC stops
WaitJoin timer. the WaitDTLS timer, and starts the WaitJoin timer.
Join to DTLS Teardown (e): This transition occurs when the join Join to DTLS Teardown (e): This transition occurs when the join
process failed. process has 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
an error, or if the Image Identifier provided by the AC in the containing an error, or if the Image Identifier provided by
Join Response message differs from the WTP's currently running the AC in the Join Response message differs from the WTP's
firmware version and the WTP has the requested image in its currently running firmware version and the WTP has the
non-volatile memory. This causes the WTP to initiate the requested image in its non-volatile memory. This causes the
DTLSShutdown command (see Section 2.3.2.1). This transition WTP to initiate the DTLSShutdown command (see
also occurs if the WTP receives one of the following DTLS Section 2.3.2.1). This transition also occurs if the WTP
notifications: DTLSAborted, DTLSReassemblyFailure or receives one of the following DTLS notifications:
DTLSPeerDisconnect. The WTP starts the DTLSSessionDelete timer DTLSAborted, DTLSReassemblyFailure, or DTLSPeerDisconnect.
(see Section 4.7.6). The WTP starts the DTLSSessionDelete timer (see
Section 4.7.6).
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
Result Code message element containing an error. This causes a Result Code message element containing an error. This
the AC to initiate the DTLSShutdown command (see causes 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:
DTLSReassemblyFailure or DTLSPeerDisconnect. The AC starts the DTLSAborted, DTLSReassemblyFailure, or DTLSPeerDisconnect.
DTLSSessionDelete timer (see Section 4.7.6). The AC starts the DTLSSessionDelete timer (see
Section 4.7.6).
Join to Image Data (f): This state transition is used by the WTP and Join to Image Data (f): 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 that the successful Join Response message and determines that the
software version in the Image Identifier message element is not software version in the Image Identifier message element is
the same as its currently running image. The WTP also detects not the same as its currently running image. The WTP also
that the requested image version is not currently available in detects that the requested image version is not currently
the WTP's non-volatile storage (see Section 9.1 for a full available in the WTP's non-volatile storage (see Section 9.1
description of the firmware download process). The WTP for a full description of the firmware download process).
initializes the EchoInterval timer (see Section 4.7), and The WTP initializes the EchoInterval timer (see
transmits the Image Data Request message (see Section 9.1.1) Section 4.7), and transmits the Image Data Request message
requesting the start of the firmware download. (see Section 9.1.1) requesting the start 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, after having sent its Join Data Request message from the WTP, after having sent its
Response to the WTP. The AC stops the WaitJoin timer. The AC Join Response to the WTP. The AC stops the WaitJoin timer.
MUST transmit an Image Data Response message (see The AC MUST transmit an Image Data Response message (see
Section 9.1.2) to the WTP, which includes a portion of the Section 9.1.2) to the WTP, which includes a portion of the
firmware. firmware.
Join to Configure (g): This state transition is used by the WTP and Join to Configure (g): 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 message, and determines that the successful Join Response message, and determines that the
included Image Identifier message element is the same as its included Image Identifier message element is the same as its
currently running image. The WTP transmits the Configuration currently running image. The WTP transmits the
Status Request message (see Section 8.2) to the AC with message Configuration Status Request message (see Section 8.2) to
elements describing its current configuration. the AC with message elements describing its current
configuration.
AC: This state transition occurs when it receives the AC: This state transition occurs when it receives the
Configuration Status Request message from the WTP (see Configuration Status Request message from the WTP (see
Section 8.2), which MAY include specific message elements to Section 8.2), which MAY include specific message elements to
override the WTP's configuration. The AC stops the WaitJoin override the WTP's configuration. The AC stops the WaitJoin
timer. The AC transmits the Configuration Status Response timer. The AC transmits the Configuration Status Response
message (see Section 8.3) and starts the message (see Section 8.3) and starts the
ChangeStatePendingTimer timer (see Section 4.7). ChangeStatePendingTimer timer (see Section 4.7).
Configure to Reset (h): This state transition is used to reset the Configure to Reset (h): 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. The CAPWAP Reset command is used to configuration to take effect. The CAPWAP Reset command is used to
indicate to the peer that it will initiate a DTLS teardown. indicate to the peer that it will initiate a DTLS teardown.
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 message indicating an error or Configuration Status Response message indicating an error or
when it determines that a reset of the WTP is required, due to when it determines that a reset of the WTP is required, due
the characteristics of a new configuration. to 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
for which AC policy does not permit the WTP to provide service. error for which AC policy does not permit the WTP to provide
This state transition also occurs when the AC service. This state transition also occurs when the AC
ChangeStatePendingTimer timer expires. ChangeStatePendingTimer timer expires.
Configure to DTLS Teardown (i): This transition occurs when the Configure to DTLS Teardown (i): 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
receives frequent DTLSDecapFailure notifications. The WTP it receives frequent DTLSDecapFailure notifications. The
starts the DTLSSessionDelete timer (see Section 4.7.6). WTP starts the DTLSSessionDelete timer (see Section 4.7.6).
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 AC MAY tear down the DTLS session if it Section 2.3.2.2). The AC MAY tear down the DTLS session if
receives frequent DTLSDecapFailure notifications. The AC it receives frequent DTLSDecapFailure notifications. The AC
starts the DTLSSessionDelete timer (see Section 4.7.6). starts the DTLSSessionDelete timer (see Section 4.7.6).
Image Data to Image Data (j): The Image Data state is used by the Image Data to Image Data (j): 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. This state transition also occurs when the WTP data to send. This state transition also occurs when the
receives the subsequent Image Data Requests, at which time it WTP receives the subsequent Image Data Requests, at which
resets the ImageDataStartTimer time to ensure it receives the time it resets the ImageDataStartTimer time to ensure it
next expected Image Data Request from the AC. This state receives the next expected Image Data Request from the AC.
transition can also occur when the WTP's EchoInterval timer This state transition can also occur when the WTP's
(see Section 4.7.7) expires, in which case the WTP transmits an EchoInterval timer (see Section 4.7.7) expires, in which
Echo Request message (see Section 7.1), and resets its case the WTP transmits an Echo Request message (see
EchoInterval timer. The state transition also occurs when the Section 7.1), and resets its EchoInterval timer. The state
WTP receives an Echo Response from the AC (see Section 7.2. transition also occurs when the WTP receives an Echo
Response from the AC (see Section 7.2).
AC: This state transition occurs either when the AC receives the AC: This state transition occurs when the AC receives the Image
Image Data Response message from the WTP while already in the Data Response message from the WTP while already in the
Image Data state. This state transition also occurs when the Image Data state. This state transition also occurs when
AC receives an Echo Request (see Section 7.1) from the WTP, in the AC receives an Echo Request (see Section 7.1) from the
which case it responds with an Echo Response (see Section 7.2), WTP, in which case it responds with an Echo Response (see
and resets its EchoInterval timer (see Section 4.7.7). Section 7.2), and resets its EchoInterval timer (see
Section 4.7.7).
Image Data to Reset (k): This state transition is used to reset the Image Data to Reset (k): 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, or if the WTP: When an image download completes, or if the
ImageDataStartTimer timer expires, the WTP enters the Reset ImageDataStartTimer timer expires, 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 either when the image transfer AC: The AC enters the Reset state either when the image transfer
has successfully completed or an error occurs during the image has successfully completed or an error occurs during the
download process. image download process.
Image Data to DTLS Teardown (l): This transition occurs when the Image Data to DTLS Teardown (l): 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
receives frequent DTLSDecapFailure notifications. The WTP it receives frequent DTLSDecapFailure notifications. The
starts the DTLSSessionDelete timer (see Section 4.7.6). WTP starts the DTLSSessionDelete timer (see Section 4.7.6).
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 AC MAY tear down the DTLS session if it Section 2.3.2.2). The AC MAY tear down the DTLS session if
receives frequent DTLSDecapFailure notifications. The AC it receives frequent DTLSDecapFailure notifications. The AC
starts the DTLSSessionDelete timer (see Section 4.7.6). starts the DTLSSessionDelete timer (see Section 4.7.6).
Configure to Data Check (m): This state transition occurs when the Configure to Data Check (m): This state transition occurs when the
WTP and AC confirm the configuration. WTP and AC confirm the configuration.
WTP: The WTP enters this state when it receives a successful WTP: The WTP enters this state when it receives a successful
Configuration Status Response message from the AC. The WTP Configuration Status Response message from the AC. The WTP
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
Section 8.7). The AC MUST start the DataCheckTimer timer and (see Section 8.7). The AC MUST start the DataCheckTimer
stops the ChangeStatePendingTimer timer (see Section 4.7). timer and stops the ChangeStatePendingTimer timer (see
Section 4.7).
Data Check to DTLS Teardown (n): This transition occurs when the WTP Data Check to DTLS Teardown (n): 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 message before a CAPWAP Change State Event Response message before a CAPWAP
retransmission timeout occurs. The WTP also transitions to retransmission timeout occurs. The WTP also transitions to
this state if the underlying reliable transport's this state if the underlying reliable transport's
RetransmitCount counter has reached the MaxRetransmit variable RetransmitCount counter has reached the MaxRetransmit
(see Section 4.7). The WTP starts the DTLSSessionDelete timer variable (see Section 4.7). The WTP starts the
(see Section 4.7.6). DTLSSessionDelete timer (see Section 4.7.6).
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). The AC starts the DTLSSessionDelete expires (see Section 4.7). The AC starts the
timer (see Section 4.7.6). DTLSSessionDelete timer (see Section 4.7.6).
Data Check to Run (o): This state transition occurs when the linkage Data Check to Run (o): This state transition occurs when the linkage
between the control and data channels is established, causing the between the control and data channels is established, causing the
WTP 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
of a DTLS session, starts the DataChannelKeepAlive timer (see establishment of a DTLS session, starts the
Section 4.7.2) and transmits a Data Channel Keep Alive packet DataChannelKeepAlive timer (see Section 4.7.2) and transmits
(see Section 4.4.1). The WTP then starts the EchoInterval a Data Channel Keep-Alive packet (see Section 4.4.1). The
timer and DataChannelDeadInterval timer (see Section 4.7). WTP then starts the EchoInterval timer and
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
ID message element matching that included by the WTP in the Session ID message element matching that included by the WTP
Join Request message. The AC disables the DataCheckTimer in the Join Request message. The AC disables the
timer. Note that if AC policy is to require the data channel DataCheckTimer timer. Note that if AC policy is to require
to be encrypted, this process would also require the the data channel to be encrypted, this process would also
establishment of a data channel DTLS session. Upon receiving require the establishment of a data channel DTLS session.
the Data Channel Keep Alive packet, the AC transmits its own Upon receiving the Data Channel Keep-Alive packet, the AC
Data Channel Keep Alive packet. transmits its own Data Channel Keep Alive packet.
Run to DTLS Teardown (p): This state transition occurs when an error Run to DTLS Teardown (p): This state transition occurs when an error
has occurred in the DTLS stack, causing the DTLS session to be has occurred in the DTLS stack, causing the DTLS session to be
torn down. torn down.
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
receives frequent DTLSDecapFailure notifications. The WTP also it receives frequent DTLSDecapFailure notifications. The
transitions to this state if the underlying reliable WTP also transitions to this state if the underlying
transport's RetransmitCount counter has reached the reliable transport's RetransmitCount counter has reached the
MaxRetransmit variable (see Section 4.7). The WTP starts the MaxRetransmit variable (see Section 4.7). The WTP starts
DTLSSessionDelete timer (see Section 4.7.6). the DTLSSessionDelete timer (see Section 4.7.6).
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 AC MAY tear down the DTLS session if it Section 2.3.2.2). The AC MAY tear down the DTLS session if
receives frequent DTLSDecapFailure notifications. The AC it 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). This state MaxRetransmit variable (see Section 4.7). This state
transition also occurs when the AC's EchoInterval timer (see transition also occurs when the AC's EchoInterval timer (see
Section 4.7.7) expires. The AC starts the DTLSSessionDelete Section 4.7.7) expires. The AC starts the DTLSSessionDelete
timer (see Section 4.7.6). timer (see Section 4.7.6).
Run to Run (q): This is the normal state of operation. Run to Run (q): This is the normal state of operation.
WTP: This is the WTP's normal state of operation. The WTP resets WTP: This is the WTP's normal state of operation. The WTP resets
its EchoInterval timer whenever it transmits a request to the its EchoInterval timer whenever it transmits a request to
AC. There are many events that result this state transition: the AC. There are many events that result in this state
transition:
Configuration Update: The WTP receives a Configuration Update Configuration Update: The WTP receives a Configuration
Request message(see Section 8.4). The WTP MUST respond with Update Request message (see Section 8.4). The WTP
a Configuration Update Response message (see Section 8.5). MUST respond with 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
Change State Event Request message, as a result of a failure a Change State Event Request message, as a result of a
or change in the state of a radio. failure or change in the state of a radio.
Echo Request: The WTP sends an Echo Request message Echo Request: The WTP sends an Echo Request message
(Section 7.1) or receives the corresponding Echo Response (Section 7.1) or receives the corresponding Echo
message, (see Section 7.2) from the AC. When the WTP Response message, (see Section 7.2) from the AC. When
receives the Echo Response, it resets its EchoInterval timer the WTP receives the Echo Response, it resets its
(see Section 4.7.7). EchoInterval timer (see Section 4.7.7).
Clear Config Request: The WTP receives a Clear Configuration Clear Config Request: The WTP receives a Clear
Request message (see Section 8.8) and MUST generate a Configuration Request message (see Section 8.8) and
corresponding Clear Configuration Response message (see MUST generate a corresponding Clear Configuration
Section 8.9). The WTP MUST reset its configuration back to Response message (see Section 8.9). The WTP MUST
manufacturer defaults. reset its configuration back to manufacturer defaults.
WTP Event: The WTP sends a WTP Event Request message, WTP Event: The WTP sends a WTP Event Request message,
delivering information to the AC (see Section 9.4). The WTP delivering information to the AC (see Section 9.4).
receives a WTP Event Response message from the AC (see The WTP receives a WTP Event Response message from the
Section 9.5). AC (see Section 9.5).
Data Transfer: The WTP sends a Data Transfer Request or Data Data Transfer: The WTP sends a Data Transfer Request or
Transfer Response message to the AC (see Section 9.6). The Data Transfer Response message to the AC (see
WTP receives a Data Transfer Request or Data Transfer Section 9.6). The WTP receives a Data Transfer
Response message from the AC (see Section 9.6). Upon Request or Data Transfer Response message from the AC
receipt of a Data Transfer Request, the WTP transmits a Data (see Section 9.6). Upon receipt of a Data Transfer
Transfer Response to the AC. Request, the WTP transmits a Data Transfer Response to
the AC.
Station Configuration Request: The WTP receives a Station Station Configuration Request: The WTP receives a Station
Configuration Request message (see Section 10.1), to which Configuration Request message (see Section 10.1), to
it MUST respond with a Station Configuration Response which it MUST respond with a Station Configuration
message (see Section 10.2). Response message (see Section 10.2).
AC: This is the AC's normal state of operation. Note that the AC: This is the AC's normal state of operation. Note that the
receipt of any Request from the WTP causes the AC to reset its receipt of any Request from the WTP causes the AC to reset
EchoInterval timer (see Section 4.7.7). its EchoInterval timer (see Section 4.7.7).
Configuration Update: The AC sends a Configuration Update Configuration Update: The AC sends a Configuration Update
Request message (see Section 8.4) to the WTP to update its Request message (see Section 8.4) to the WTP to update
configuration. The AC receives a Configuration Update its configuration. The AC receives a Configuration
Response message (see Section 8.5) from the WTP. Update Response message (see Section 8.5) from the
WTP.
Change State Event: The AC receives a Change State Event Change State Event: The AC receives a Change State Event
Request message (see Section 8.6), to which it MUST respond Request message (see Section 8.6), to which it MUST
with the Change State Event Response message (see respond with the Change State Event Response message
Section 8.7). (see Section 8.7).
Echo Request: The AC receives an Echo Request message (see Echo Request: The AC receives an Echo Request message (see
Section 7.1), to which it MUST respond with an Echo Response Section 7.1), to which it MUST respond with an Echo
message(see Section 7.2). Response message (see Section 7.2).
Clear Config Response: The AC sends a Clear Configuration Clear Config Response: The AC sends a Clear Configuration
Request message (see Section 8.8) to the WTP to clear its Request message (see Section 8.8) to the WTP to clear
configuration. The AC receives a Clear Configuration its configuration. The AC receives a Clear
Response message from the WTP (see Section 8.9). Configuration Response message from the WTP (see
Section 8.9).
WTP Event: The AC receives a WTP Event Request message from WTP Event: The AC receives a WTP Event Request message from
the WTP (see Section 9.4) and MUST generate a corresponding the WTP (see Section 9.4) and MUST generate a
WTP Event Response message (see Section 9.5). corresponding WTP Event Response message (see
Section 9.5).
Data Transfer: The AC sends a Data Transfer Request or Data Data Transfer: The AC sends a Data Transfer Request or Data
Transfer Response message to the WTP (see Section 9.6). The Transfer Response message to the WTP (see
AC receives a Data Transfer Request or Data Transfer Section 9.6). The AC receives a Data Transfer Request
Response message from the WTP (see Section 9.6). Upon or Data Transfer Response message from the WTP (see
receipt of a Data Transfer Request, the AC transmits a Data Section 9.6). Upon receipt of a Data Transfer
Transfer Response to the WTP. Request, the AC transmits a Data Transfer Response to
the WTP.
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
the corresponding Station Configuration Response message receives the corresponding Station Configuration
(see Section 10.2) from the WTP. Response message (see Section 10.2) from the WTP.
Run to Reset (r): This state transition is used when either the AC Run to Reset (r): This state transition is used when either the AC
or WTP tear down the connection. This may occur as part of normal or WTP tears down the connection. This may occur as part of
operation, or due to error conditions. normal 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 (s): This transition occurs when the CAPWAP Reset to DTLS Teardown (s): 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 transmits a Reset WTP: This state transition occurs when the WTP transmits a Reset
Response message. The WTP does not invoke the DTLSShutdown Response message. The WTP does not invoke the DTLSShutdown
command (see Section 2.3.2.1). The WTP starts the command (see Section 2.3.2.1). The WTP starts the
DTLSSessionDelete timer (see Section 4.7.6). DTLSSessionDelete timer (see Section 4.7.6).
AC: This state transition occurs when the AC receives a Reset AC: This state transition occurs when the AC receives a Reset
Response message. This causes the AC to initiate the Response message. This causes the AC to initiate the
DTLSShutdown command (see Section 2.3.2.1). The AC starts the DTLSShutdown command (see Section 2.3.2.1). The AC starts
DTLSSessionDelete timer (see Section 4.7.6). the DTLSSessionDelete timer (see Section 4.7.6).
DTLS Teardown to Idle (t): This transition occurs when the DTLS DTLS Teardown to Idle (t): 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
session, or if the DTLSSessionDelete timer (see Section 4.7.6) DTLS session, or if the DTLSSessionDelete timer (see
expires. The data plane DTLS session is also shutdown, and all Section 4.7.6) expires. The data plane DTLS session is also
resources released, if a DTLS session was established for the shut down, and all resources released, if a DTLS session was
data plane. Any timers set for the current instance of the established for the data plane. Any timers set for the
state machine are also cleared. current instance of the state machine are also cleared.
AC: This is an invalid state transition for the AC. AC: This is an invalid state transition for the AC.
DTLS Teardown to Sulking (u): This transition occurs when repeated DTLS Teardown to Sulking (u): This transition occurs when repeated
attempts to setup the DTLS connection have failed. attempts to setup the DTLS connection have failed.
WTP: The WTP enters this state when the FailedDTLSSessionCount or WTP: The WTP enters this state when the FailedDTLSSessionCount or
the FailedDTLSAuthFailCount counter reaches the value of the the FailedDTLSAuthFailCount counter reaches the value of the
MaxFailedDTLSSessionRetry variable (see Section 4.8). Upon MaxFailedDTLSSessionRetry variable (see Section 4.8). Upon
entering this state, the WTP MUST start the SilentInterval entering this state, the WTP MUST start the SilentInterval
skipping to change at page 32, line 6 skipping to change at page 31, line 23
DTLS protocol messages received MUST be ignored. DTLS protocol messages received MUST be ignored.
AC: This is an invalid state transition for the AC. AC: This is an invalid state transition for the AC.
DTLS Teardown to Dead (w): This transition occurs when the DTLS DTLS Teardown to Dead (w): This transition occurs when the DTLS
session has been shutdown. session has been shutdown.
WTP: This is an invalid state transition for the WTP. 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
session , or if the DTLSSessionDelete timer (see Section 4.7.6) DTLS session , or if the DTLSSessionDelete timer (see
expires. The data plane DTLS session is also shutdown, and all Section 4.7.6) expires. The data plane DTLS session is also
resources released, if a DTLS session was established for the shut down, and all resources released, if a DTLS session was
data plane. Any timers set for the current instance of the established for the data plane. Any timers set for the
state machine are also cleared. The AC's Service thread is current instance of the state machine are also cleared. The
terminated. 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
function calls. This API definition is provided to clarify function calls. This API definition is provided to clarify
interactions between the DTLS and CAPWAP components of the integrated interactions between the DTLS and CAPWAP components of the integrated
CAPWAP state machine. CAPWAP state machine.
Below is a list of the minimal command API: Below is a list of the minimal command APIs:
o DTLSStart is sent to the DTLS component to cause a DTLS session to o DTLSStart is sent to the DTLS component to cause a DTLS session to
be established. Upon invoking the DTLSStart command, the WaitDTLS be established. Upon invoking the DTLSStart command, the WaitDTLS
timer is started. The WTP initiates this DTLS command, as the AC timer is started. The WTP initiates this DTLS command, as the AC
does not initiate DTLS sessions. does not initiate DTLS sessions.
o DTLSListen is sent to the DTLS component to allow the DTLS o DTLSListen is sent to the DTLS component to allow the DTLS
component to listen for incoming DTLS session requests. component to listen for incoming DTLS session requests.
o DTLSAccept is sent to the DTLS component to allow the DTLS session o DTLSAccept is sent to the DTLS component to allow the DTLS session
skipping to change at page 33, line 8 skipping to change at page 32, line 24
o DTLSShutdown is sent to the DTLS component to cause session o DTLSShutdown is sent to the DTLS component to cause session
teardown. teardown.
o DTLSMtuUpdate is sent by the CAPWAP component to modify the MTU o DTLSMtuUpdate is sent by the CAPWAP component to modify the MTU
size used by the DTLS component. See Section 3.5 for more size used by the DTLS component. See Section 3.5 for more
information on MTU Discovery. The default size is 1468 bytes. information on MTU Discovery. The default size is 1468 bytes.
2.3.2.2. DTLS to CAPWAP Notifications 2.3.2.2. DTLS to CAPWAP Notifications
DTLS notifications are defined for the DTLS to CAPWAP API. These DTLS notifications are defined for the DTLS to CAPWAP API. These
"notifications" are conceptual, and may be implemented in numerous "notifications" are conceptual and may be implemented in numerous
ways (e.g. as function return values). This API definition is ways (e.g., as function return values). This API definition is
provided to clarify interactions between the DTLS and CAPWAP provided to clarify interactions between the DTLS and CAPWAP
components of the integrated CAPWAP state machine. It is important components of the integrated CAPWAP state machine. It is important
to note that the notifications listed below MAY cause the CAPWAP to note that the notifications listed below MAY cause the CAPWAP
state machine to jump from one state to another using a state state machine to jump from one state to another using a state
transition not listed in Section 2.3.1. When a notification listed transition not listed in Section 2.3.1. When a notification listed
below occurs, the target CAPWAP state shown in Figure 4 becomes the below occurs, the target CAPWAP state shown in Figure 4 becomes the
current state. current state.
Below is a list of the API notifications: Below is a list of the API notifications:
o DTLSPeerAuthorize is sent to the CAPWAP component during DTLS o DTLSPeerAuthorize is sent to the CAPWAP component during DTLS
session establishment once the peer's identity has been received. session establishment once the peer's identity has been received.
This notification MAY be used by the CAPWAP component to authorize This notification MAY be used by the CAPWAP component to authorize
the session, based on the peer's identity. The authorization the session, based on the peer's identity. The authorization
process will lead to the CAPWAP component initiating either the process will lead to the CAPWAP component initiating either the
DTLSAccept or DTLSAbortSession commands. DTLSAccept or DTLSAbortSession commands.
o DTLSEstablished is sent to the CAPWAP component to indicate that o DTLSEstablished is sent to the CAPWAP component to indicate that a
that a secure channel now exists, using the parameters provided secure channel now exists, using the parameters provided during
during the DTLS initialization process. When this notification is the DTLS initialization process. When this notification is
received, the FailedDTLSSessionCount counter is reset to zero. received, the FailedDTLSSessionCount counter is reset to zero.
When this notification is received, the WaitDTLS timer is stopped. When this notification is received, the WaitDTLS timer is stopped.
o DTLSEstablishFail is sent when the DTLS session establishment has o DTLSEstablishFail is sent when the DTLS session establishment has
failed, either due to a local error, or due to the peer rejecting failed, either due to a local error or due to the peer rejecting
the session establishment. When this notification is received, the session establishment. When this notification is received,
the FailedDTLSSessionCount counter is incremented. the FailedDTLSSessionCount counter is incremented.
o DTLSAuthenticateFail is sent when DTLS session establishment o DTLSAuthenticateFail is sent when DTLS session establishment has
failed due to an authentication error. When this notification is failed due to an authentication error. When this notification is
received, the FailedDTLSAuthFailCount counter is incremented. received, the FailedDTLSAuthFailCount counter is incremented.
o DTLSAborted is sent to the CAPWAP component to indicate that o DTLSAborted is sent to the CAPWAP component to indicate that
session abort (as requested by CAPWAP) is complete; this occurs to session abort (as requested by CAPWAP) is complete; this occurs to
confirm a DTLS session abort, or when the WaitDTLS timer expires. confirm a DTLS session abort or when the WaitDTLS timer expires.
When this notification is received, the WaitDTLS timer is stopped. When this notification is received, the WaitDTLS timer is stopped.
o DTLSReassemblyFailure MAY be sent to the CAPWAP component to o DTLSReassemblyFailure MAY be sent to the CAPWAP component to
indicate DTLS fragment reassembly failure. indicate DTLS fragment reassembly failure.
o DTLSDecapFailure MAY be sent to the CAPWAP module to indicate a o DTLSDecapFailure MAY be sent to the CAPWAP module to indicate a
decapsulation failure. DTLSDecapFailure MAY be sent to the CAPWAP decapsulation failure. DTLSDecapFailure MAY be sent to the CAPWAP
module to indicate an encryption/authentication failure. This module to indicate an encryption/authentication failure. This
notification is intended for informative purposes only, and is not notification is intended for informative purposes only, and is not
intended to cause a change in the CAPWAP state machine (see intended to cause a change in the CAPWAP state machine (see
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 entities; 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.
2.4.1. DTLS Handshake Processing 2.4.1. DTLS Handshake Processing
Details of the DTLS handshake process are specified in [RFC4347]. Details of the DTLS handshake process are specified in [RFC4347].
This section describes the interactions between the DTLS session This section describes the interactions between the DTLS session
establishment process and the CAPWAP protocol. Note that the establishment process and the CAPWAP protocol. Note that the
conceptual DTLS state is shown below to help understand the point at conceptual DTLS state is shown below to help understand the point at
which the DTLS states transition. In the normal case, the DTLS which the DTLS states transition. In the normal case, the DTLS
handshake will proceed as shown in Figure 5. (NOTE: this example handshake will proceed as shown in Figure 5. (NOTE: this example
uses certificates, but preshared keys are also supported): uses certificates, but pre-shared keys are also supported.)
============ ============ ============ ============
WTP AC WTP AC
============ ============ ============ ============
ClientHello ------> ClientHello ------>
<------ HelloVerifyRequest <------ HelloVerifyRequest
(with cookie) (with cookie)
ClientHello ------> ClientHello ------>
(with cookie) (with cookie)
<------ ServerHello <------ ServerHello
skipping to change at page 36, line 6 skipping to change at page 35, line 8
implementation on the WTP MUST provide an interface that allows the implementation on the WTP MUST provide an interface that allows the
CAPWAP module to request session resumption despite the use of the CAPWAP module to request session resumption despite the use of the
different port numbers (TLS implementations usually attempt session different port numbers (TLS implementations usually attempt session
resumption only when connecting to the same IP address and port resumption only when connecting to the same IP address and port
number). Note that session resumption is not guaranteed to occur, number). Note that session resumption is not guaranteed to occur,
and a full DTLS handshake may occur instead. and a full DTLS handshake may occur instead.
The DTLS implementation used by CAPWAP MUST use replay detection, per The DTLS implementation used by CAPWAP MUST use replay detection, per
Section 3.3 of [RFC4347]. Since the CAPWAP protocol handles Section 3.3 of [RFC4347]. Since the CAPWAP protocol handles
retransmissions by re-encrypting lost frames, any duplicate DTLS retransmissions by re-encrypting lost frames, any duplicate DTLS
frames are either unintentional or malicious, and should be silently frames are either unintentional or malicious and should be silently
discarded. discarded.
2.4.2. DTLS Session Establishment 2.4.2. DTLS Session Establishment
The WTP, either through the Discovery process, or through pre- The WTP, either through the Discovery process or through pre-
configuration, determines the AC to connect to. The WTP uses the configuration, determines to which AC to connect. The WTP uses the
DTLSStart command to request that a secure connection be established DTLSStart command to request that a secure connection be established
to the selected AC. Prior to initiation of the DTLS handshake, the to the selected AC. Prior to initiation of the DTLS handshake, the
WTP sets the WaitDTLS timer. Upon invoking the DTLSStart or WTP sets the WaitDTLS timer. Upon invoking the DTLSStart or
DTLSListen commands, the WTP and AC, respectively, set the WaitDTLS DTLSListen commands, the WTP and AC, respectively, set the WaitDTLS
timer. If the DTLSEstablished notification is not received prior to timer. If the DTLSEstablished notification is not received prior to
timer expiration, the DTLS session is aborted by issuing the timer expiration, the DTLS session is aborted by issuing the
DTLSAbortSession DTLS command. This notification causes the CAPWAP DTLSAbortSession DTLS command. This notification causes the CAPWAP
module to transition to the Idle state. Upon receiving a module to transition to the Idle state. Upon receiving a
DTLSEstablished notification, the WaitDTLS timer is deactivated. DTLSEstablished notification, the WaitDTLS timer is deactivated.
2.4.3. DTLS Error Handling 2.4.3. DTLS Error Handling
If the AC or WTP does not respond to any DTLS handshake messages sent If the AC or WTP does not respond to any DTLS handshake messages sent
by its peer, the DTLS specification calls for the message to be by its peer, the DTLS specification calls for the message to be
retransmited. Note that during the handshake, when both the AC and retransmitted. Note that during the handshake, when both the AC and
the WTP are expecting additional handshake messages, they both the WTP are expecting additional handshake messages, they both
retransmit if an expected message has not been received (note that retransmit if an expected message has not been received (note that
retransmissions for CAPWAP Control messages work differently: all retransmissions for CAPWAP Control messages work differently: all
CAPWAP Control messages are either requests or responses, and the CAPWAP Control messages are either requests or responses, and the
peer who sent the request is responsible for retransmissions). peer who sent the request is responsible for retransmissions).
If the WTP or the AC does not receive an expected DTLS handshake If the WTP or the AC does not receive an expected DTLS handshake
message despite of retransmissions, the WaitDTLS timer will message despite of retransmissions, the WaitDTLS timer will
eventually expire, and the session will be terminated. This can eventually expire, and the session will be terminated. This can
happen if communication between the peers has completely failed, or happen if communication between the peers has completely failed, or
if one of the peers sent a DTLS Alert message which was lost in if one of the peers sent a DTLS Alert message that was lost in
transit (DTLS does not retransmit Alert messages). transit (DTLS does not retransmit Alert messages).
If a cookie fails to validate, this could represent a WTP error, or If a cookie fails to validate, this could represent a WTP error, or
it could represent a DoS attack. Hence, AC resource utilization it could represent a DoS attack. Hence, AC resource utilization
SHOULD be minimized. The AC MAY log a message indicating the SHOULD be minimized. The AC MAY log a message indicating the
failure, and SHOULD treat the message as though no cookie were failure, and SHOULD treat the message as though no cookie were
present. present.
Since DTLS handshake messages are potentially larger than the maximum Since DTLS Handshake messages are potentially larger than the maximum
record size, DTLS supports fragmenting of handshake messages across record size, DTLS supports fragmenting of Handshake messages across
multiple records. There are several potential causes of re-assembly multiple records. There are several potential causes of re-assembly
errors, including overlapping and/or lost fragments. The DTLS errors, including overlapping and/or lost fragments. The DTLS
component MUST send a DTLSReassemblyFailure notification to the component MUST send a DTLSReassemblyFailure notification to the
CAPWAP component. Whether precise information is given along with CAPWAP component. Whether precise information is given along with
notification is an implementation issue, and hence is beyond the notification is an implementation issue, and hence is beyond the
scope of this document. Upon receipt of such an error, the CAPWAP scope of this document. Upon receipt of such an error, the CAPWAP
component SHOULD log an appropriate error message. Whether component SHOULD log an appropriate error message. Whether
processing continues or the DTLS session is terminated is processing continues or the DTLS session is terminated is
implementation dependent. implementation dependent.
skipping to change at page 37, line 33 skipping to change at page 36, line 35
error message. error message.
There is currently only one encapsulation error defined: MTU There is currently only one encapsulation error defined: MTU
exceeded. As part of DTLS session establishment, the CAPWAP exceeded. As part of DTLS session establishment, the CAPWAP
component informs the DTLS component of the MTU size. This may be component informs the DTLS component of the MTU size. This may be
dynamically modified at any time when the CAPWAP component sends the dynamically modified at any time when the CAPWAP component sends the
DTLSMtuUpdate command to the DTLS component (see Section 2.3.2.1). DTLSMtuUpdate command to the DTLS component (see Section 2.3.2.1).
The value provided to the DTLS stack is the result of the MTU The value provided to the DTLS stack is the result of the MTU
Discovery process, which is described in Section 3.5. The DTLS Discovery process, which is described in Section 3.5. The DTLS
component returns this notification to the CAPWAP component whenever component returns this notification to the CAPWAP component whenever
a transmission request will result in a packet which exceeds the MTU. a transmission request will result in a packet that exceeds the MTU.
2.4.4. DTLS EndPoint Authentication and Authorization 2.4.4. DTLS Endpoint Authentication and Authorization
DTLS supports endpoint authentication with certificates or preshared DTLS supports endpoint authentication with certificates or pre-shared
keys. The TLS algorithm suites for each endpoint authentication keys. The TLS algorithm suites for each endpoint authentication
method are described below. method are described below.
2.4.4.1. Authenticating with Certificates 2.4.4.1. Authenticating with Certificates
CAPWAP implementations only use cipher suites that are recommended CAPWAP implementations only use cipher suites that are recommended
for use with DTLS, see [DTLS-DESIGN]. At present, the following for use with DTLS, see [DTLS-DESIGN]. At present, the following
algorithms MUST be supported when using certificates for CAPWAP algorithms MUST be supported when using certificates for CAPWAP
authentication: authentication:
o TLS_RSA_WITH_AES_128_CBC_SHA [RFC4346] o TLS_RSA_WITH_AES_128_CBC_SHA [RFC5246]
The following algorithms SHOULD be supported when using certificates: The following algorithms SHOULD be supported when using certificates:
o TLS_DHE_RSA_WITH_AES_128_CBC_SHA [RFC4346] o TLS_DHE_RSA_WITH_AES_128_CBC_SHA [RFC5246]
The following algorithms MAY be supported when using certificates: The following algorithms MAY be supported when using certificates:
o TLS_RSA_WITH_AES_256_CBC_SHA [RFC4346] o TLS_RSA_WITH_AES_256_CBC_SHA [RFC5246]
o TLS_DHE_RSA_WITH_AES_256_CBC_SHA [RFC4346] o TLS_DHE_RSA_WITH_AES_256_CBC_SHA [RFC5246]
Additional ciphers MAY be defined in follow on CAPWAP specifications. Additional ciphers MAY be defined in subsequent CAPWAP
specifications.
2.4.4.2. Authenticating with Preshared Keys 2.4.4.2. Authenticating with Pre-Shared Keys
Pre-shared keys present significant challenges from a security Pre-shared keys present significant challenges from a security
perspective, and for that reason, their use is strongly discouraged. perspective, and for that reason, their use is strongly discouraged.
Several methods for authenticating with preshared keys are defined Several methods for authenticating with pre-shared keys are defined
[RFC4279], and we focus on the following two: [RFC4279], and we focus on the following two:
o Pre-Shared Key (PSK) key exchange algorithm - simplest method, o Pre-Shared Key (PSK) key exchange algorithm - simplest method,
ciphersuites use only symmetric key algorithms ciphersuites use 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 algorithm 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: pre-shared keys:
o TLS_PSK_WITH_AES_128_CBC_SHA [RFC4346] o TLS_PSK_WITH_AES_128_CBC_SHA [RFC5246]
o TLS_DHE_PSK_WITH_AES_128_CBC_SHA [RFC4346] o TLS_DHE_PSK_WITH_AES_128_CBC_SHA [RFC5246]
The following algorithms MAY be supported when using preshared keys: The following algorithms MAY be supported when using pre-shared keys:
o TLS_PSK_WITH_AES_256_CBC_SHA [RFC4346] o TLS_PSK_WITH_AES_256_CBC_SHA [RFC5246]
o TLS_DHE_PSK_WITH_AES_256_CBC_SHA [RFC4346] o TLS_DHE_PSK_WITH_AES_256_CBC_SHA [RFC5246]
Additional ciphers MAY be defined in follow on CAPWAP specifications. Additional ciphers MAY be defined in following CAPWAP specifications.
2.4.4.3. Certificate Usage 2.4.4.3. Certificate Usage
Certificate authorization by the AC and WTP is required so that only Certificate authorization by the AC and WTP is required so that only
an AC may perform the functions of an AC and that only a WTP may an AC may perform the functions of an AC and that only a WTP may
perform the functions of a WTP. This restriction of functions to the perform the functions of a WTP. This restriction of functions to the
AC or WTP requires that the certificates used by the AC MUST be AC or WTP requires that the certificates used by the AC MUST be
distinguishable from the certificate used by the WTP. To accomplish distinguishable from the certificate used by the WTP. To accomplish
this differentiation, the x.509 certificates MUST include the this differentiation, the x.509 certificates MUST include the
Extended Key Usage (EKU) certificate extension [RFC5280]. Extended Key Usage (EKU) certificate extension [RFC5280].
skipping to change at page 40, line 6 skipping to change at page 39, line 6
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 For instance, an AC SHOULD NOT accept a connection request from
another AC, and therefore MUST verify that the id-kp-capwapWTP EKU is another AC, and therefore MUST verify that the id-kp-capwapWTP EKU is
present in the certificate. present in the certificate.
CAPWAP implementations MUST support certificates where the common CAPWAP implementations MUST support certificates where the common
name (CN) for both the WTP and AC is the MAC address of that device. name (CN) for both the WTP and AC is the MAC address of that device.
The MAC address MUST be encoded in the PrintableString format, using The MAC address MUST be encoded in the PrintableString format, using
the well recognized MAC address format of 01:23:45:67:89:ab. The CN the well-recognized MAC address format of 01:23:45:67:89:ab. The CN
field MAY contain either of the EUI-48 [EUI-48] or EUI-64 [EUI-64] field MAY contain either of the EUI-48 [EUI-48] or EUI-64 [EUI-64]
MAC Address formats. This seemingly unconventional use of the CN MAC Address formats. This seemingly unconventional use of the CN
field is consistent with other standards that rely on device field is consistent with other standards that rely on device
certificates that are provisioned during the manufacturing process, certificates that are provisioned during the manufacturing process,
such as Packet Cable [PacketCable], Cable Labs [CableLabs] and WiMAX such as Packet Cable [PacketCable], Cable Labs [CableLabs], and WiMAX
[WiMAX]. See Section 12.8 for more information on the use of the MAC [WiMAX]. See Section 12.8 for more information on the use of the MAC
Address in the CN field. address in the CN field.
ACs and WTPs MUST 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, e.g., based on certificates of devices to which they are connecting, e.g., based on
the issuer, MAC address, or organizational information specified in the issuer, MAC address, or organizational information specified in
the certificate. 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. The particulars of authorization and authorized MAC addresses. The particulars of authorization
filter construction are implementation details which are, for the filter construction are implementation details which are, for the
most part, not within the scope of this specification. However, at most part, not within the scope of this specification. However, at
minimum, all devices MUST verify that the appropriate EKU bit is set 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 according to the role of the peer device (AC versus WTP), and that
issuer of the certificate is appropriate for the domain in question. 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.
The PSK Hint SHOULD uniquely identify the AC and the PSK Identity The PSK Hint SHOULD uniquely identify the AC and the PSK Identity
SHOULD uniquely identify the WTP. It is RECOMMENDED that these hints SHOULD uniquely identify the WTP. It is RECOMMENDED that these hints
and identities be the ASCII HEX-formatted MAC addresses of the and identities be the ASCII HEX-formatted MAC addresses of the
respective devices, since each pairwise combination of WTP and AC respective devices, since each pairwise combination of WTP and AC
SHOULD have a unique PSK. The PSK hint and identity SHOULD be SHOULD have a unique PSK. The PSK Hint and Identity SHOULD be
sufficient to perform authorization, as simply having knowledge of a sufficient to perform authorization, as simply having knowledge of a
PSK does not necessarily imply authorization. PSK does not necessarily imply authorization.
If a single PSK is being used for multiple devices on a CAPWAP If a single PSK is being used for multiple devices on a CAPWAP
network, which is NOT RECOMMENDED, the PSK Hint and Identity can no network, which is NOT RECOMMENDED, the PSK Hint and Identity can no
longer be a MAC address, so appropriate hints and identities SHOULD longer be a MAC address, so appropriate hints and identities SHOULD
be selected to identify the group of devices to which the PSK is be selected to identify the group of devices to which the PSK is
provisioned. provisioned.
3. CAPWAP Transport 3. CAPWAP Transport
Communication between a WTP and an AC is established using the Communication between a WTP and an AC is established using the
standard UDP client/server model. The CAPWAP protocol supports both standard UDP client/server model. The CAPWAP protocol supports both
UDP and UDP-Lite [RFC3828] transport protocols. When run over IPv4, UDP and UDP-Lite [RFC3828] transport protocols. When run over IPv4,
UDP is used for the CAPWAP control and data channels. UDP 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.14 describes the rules to use in message element, Section 4.6.14, describes the rules to use in
determining which transport protocol is to be used. determining which transport protocol is to be used.
In order for CAPWAP to be compatible with potential middleboxes in In order for CAPWAP to be compatible with potential middleboxes in
the network, CAPWAP implementations MUST send return traffic from the the network, CAPWAP implementations MUST send return traffic from the
same port on which it received traffic from a given peer. Further, same port on which they received traffic from a given peer. Further,
any unsolicited requests generated by a CAPWAP node MUST be sent on any unsolicited requests generated by a CAPWAP node MUST be sent on
the same port. the same port.
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
device. Since a CAPWAP session is initiated by the WTP (client) to (NAT) device. Since a CAPWAP session is initiated by the WTP
the well-known UDP port of the AC (server), the use of UDP is a (client) to the well-known UDP port of the AC (server), the use of
logical choice. When CAPWAP is run over IPv4, the UDP checksum field UDP is a logical choice. When CAPWAP is run over IPv4, the UDP
in CAPWAP packets MUST be set to zero. checksum field in CAPWAP packets MUST be set to zero.
CAPWAP protocol control packets sent from the WTP to the AC use the CAPWAP protocol control packets sent from the WTP to the AC use the
CAPWAP control channel, as defined in Section 1.4. The CAPWAP CAPWAP Control channel, as defined in Section 1.4. The CAPWAP
control port at the AC is the well known UDP port 5246. The CAPWAP control port at the AC is the well-known UDP port 5246. The CAPWAP
control port at the WTP can be any port selected by the WTP. control port at the WTP can be any port selected by the WTP.
CAPWAP protocol data packets sent from the WTP to the AC use the CAPWAP protocol data packets sent from the WTP to the AC use the
CAPWAP data channel, as defined in Section 1.4. The CAPWAP data port CAPWAP Data channel, as defined in Section 1.4. The CAPWAP data port
at the AC is the well known UDP port 5247. If an AC permits the at the AC is the well-known UDP port 5247. If an AC permits the
administrator to change the CAPWAP control port, the CAPWAP data port administrator to change the CAPWAP control port, the CAPWAP data port
MUST be the next consecutive port number. The CAPWAP data port at MUST be the next consecutive port number. The CAPWAP data port at
the WTP can be any port selected by the WTP. the WTP can be any port selected by the WTP.
3.2. UDP-Lite Transport 3.2. UDP-Lite Transport
When CAPWAP is run over IPv6, UDP-Lite is the default transport When CAPWAP is run over IPv6, UDP-Lite is the default transport
protocol, which reduces the checksum processing required for each protocol, which reduces the checksum processing required for each
packet (compared to the use of UDP over IPv6 [RFC2460]). When UDP- packet (compared to the use of UDP over IPv6 [RFC2460]). When UDP-
Lite is used, the checksum field MUST have a coverage of 8 [RFC3828]. Lite is used, the checksum field MUST have a coverage of 8 [RFC3828].
UDP-Lite uses the same port assignments as UDP. UDP-Lite uses the same port assignments as UDP.
3.3. AC Discovery 3.3. AC Discovery
The AC discovery phase allows the WTP to determine which ACs are The AC Discovery phase allows the WTP to determine which ACs are
available, and chose the best AC with which to establish a CAPWAP available and choose the best AC with which to establish a CAPWAP
session. The discovery phase occurs when the WTP enters the optional session. The Discovery phase occurs when the WTP enters the optional
Discovery state. A WTP does not need to complete the AC Discovery Discovery state. A WTP does not need to complete the AC Discovery
phase if it uses a pre-configured AC. This section details the phase if it uses a pre-configured AC. This section details the
mechanism used by a WTP to dynamically discover candidate ACs. mechanism used by a WTP to dynamically discover candidate ACs.
A WTP and an AC will frequently not reside in the same IP subnet A WTP and an AC will frequently not reside in the same IP subnet
(broadcast domain). When this occurs, the WTP must be capable of (broadcast domain). When this occurs, the WTP must be capable of
discovering the AC, without requiring that multicast services are discovering the AC, without requiring that multicast services are
enabled in the network. enabled in the network.
When the WTP attempts to establish communication with an AC, it sends When the WTP attempts to establish communication with an AC, it sends
the Discovery Request message and receives the Discovery Response the Discovery Request message and receives the Discovery Response
message from the AC(s). The WTP MUST send the Discovery Request message from the AC(s). The WTP MUST send the Discovery Request
message to either the limited broadcast IP address (255.255.255.255), message to either the limited broadcast IP address (255.255.255.255),
the well known CAPWAP multicast address (xx.xx.xx.xx) or to the the well-known CAPWAP multicast address (224.0.1.140), or to the
unicast IP address of the AC. For IPv6 networks, since broadcast unicast IP address of the AC. For IPv6 networks, since broadcast
does not exist, the use of "All ACs multicast address" is used does not exist, the use of "All ACs multicast address" (FF0X:0:0:0:0:
instead. Upon receipt of the Discovery Request message, the AC sends 0:0:18C) is used instead. Upon receipt of the Discovery Request
a Discovery Response message to the unicast IP address of the WTP, message, the AC sends a Discovery Response message to the unicast IP
regardless of whether the Discovery Request message was sent as a address of the WTP, regardless of whether the Discovery Request
broadcast, multicast or unicast message. message was sent as a broadcast, multicast, or unicast message.
WTP use of a limited IP broadcast, multicast or unicast IP address is WTP use of a limited IP broadcast, multicast, or unicast IP address
implementation dependent. ACs, on the other hand, MUST support is implementation dependent. ACs, on the other hand, MUST support
broadcast, multicast and unicast discovery. broadcast, multicast, and unicast discovery.
When a WTP transmits a Discovery Request message to a unicast When a WTP transmits a Discovery Request message to a unicast
address, the WTP must first obtain the IP address of the AC. Any address, the WTP must first obtain the IP address of the AC. Any
static configuration of an AC's IP address on the WTP non-volatile static configuration of an AC's IP address on the WTP non-volatile
storage is implementation dependent. However, additional dynamic storage is implementation dependent. However, additional dynamic
schemes are possible, for example: schemes are possible, for example:
DHCP: See [I-D.ietf-capwap-dhc-ac-option] for more information on DHCP: See [RFC5417] for more information on the use of DHCP to
the use of DHCP to discover AC IP addresses. discover AC IP addresses.
DNS: The WTP MAY support use of DNS SRV records [RFC2782] to DNS: The WTP MAY support use of DNS Service Records (SRVs) [RFC2782]
discover the AC address(es). In this case, the WTP first obtains to discover the AC address(es). In this case, the WTP first
(e.g., from local configuration) the correct domain name suffix obtains (e.g., from local configuration) the correct domain name
(e.g., "example.com") and performs a SRV lookup with Service name suffix (e.g., "example.com") and performs an SRV lookup with
"capwap-control" and Proto "udp". Thus, the name resolved in DNS Service name "capwap-control" and Proto "udp". Thus, the name
would be, e.g., "_capwap-control._udp.example.com". Note that the resolved in DNS would be, e.g., "_capwap-
SRV record MAY specify a non-default port number for the control control._udp.example.com". Note that the SRV record MAY specify a
channel; the port number for the data channel is the next port non-default port number for the control channel; the port number
number (control channel port + 1). for the data channel is the next port number (control channel port
+ 1).
An AC MAY also communicate alternative ACs to the WTP within the An AC MAY also communicate alternative ACs to the WTP within the
Discovery Response message through the AC IPv4 List (see Discovery Response message through the AC IPv4 List (see
Section 4.6.2) and AC IPv6 List (see Section 4.6.2). The addresses Section 4.6.2) and AC IPv6 List (see Section 4.6.2). The addresses
provided in these two message elements are intended to help the WTP provided in these two message elements are intended to help the WTP
discover additional ACs through means other than those listed above. discover additional ACs through means other than those listed above.
The AC Name with Priority message element (see Section 4.6.5), is The AC Name with Priority message element (see Section 4.6.5) is used
used to communicate a list of preferred ACs to the WTP. The WTP to communicate a list of preferred ACs to the WTP. The WTP SHOULD
SHOULD attempt to utilize the ACs listed in the order provided by the attempt to utilize the ACs listed in the order provided by the AC.
AC. The Name to IP Address mapping is handled via the Discovery The Name-to-IP Address mapping is handled via the Discovery message
message exchange, in which the ACs provide their identity in the AC exchange, in which the ACs provide their identity in the AC Name (see
Name (see Section 4.6.4) message element in the Discovery Response Section 4.6.4) message element in the Discovery Response message.
message.
Once the WTP has received Discovery Response messages from the Once the WTP has received Discovery Response messages from the
candidate ACs, it MAY use other factors to determine the preferred candidate ACs, it MAY use other factors to determine the preferred
AC. For instance, each binding defines a WTP Radio Information AC. For instance, each binding defines a WTP Radio Information
message element (see Section 2.1), which the AC includes in Discovery message element (see Section 2.1), which the AC includes in Discovery
Response messages. The presence of one or more of these message Response messages. The presence of one or more of these message
elements is used to identify the CAPWAP bindings supported by the AC. elements is used to identify the CAPWAP bindings supported by the AC.
A WTP MAY connect to an AC based on the supported bindings A WTP MAY connect to an AC based on the supported bindings
advertised. advertised.
3.4. Fragmentation/Reassembly 3.4. Fragmentation/Reassembly
While fragmentation and reassembly services are provided by IP, the While fragmentation and reassembly services are provided by IP, the
CAPWAP protocol also provides such services. Environments where the CAPWAP protocol also provides such services. Environments where the
CAPWAP protocol is used involve firewall, NAT and "middle box" CAPWAP protocol is used involve firewall, NAT, and "middlebox"
devices, which tend to drop IP fragments to minimize possible DoS devices, which tend to drop IP fragments to minimize possible DoS
attacks. By providing fragmentation and reassembly at the attacks. By providing fragmentation and reassembly at the
application layer, any fragmentation required due to the tunneling application layer, any fragmentation required due to the tunneling
component of the CAPWAP protocol becomes transparent to these component of the CAPWAP protocol becomes transparent to these
intermediate devices. Consequently, the CAPWAP protocol can be used intermediate devices. Consequently, the CAPWAP protocol can be used
in any network topology including firewall, NAT and middlebox in any network topology including firewall, NAT, and middlebox
devices. devices.
It is important to note that the fragmentation mechanism employed by It is important to note that the fragmentation mechanism employed by
CAPWAP has known limitations and deficiencies, which are similar to CAPWAP has known limitations and deficiencies, which are similar to
those described in [RFC4963]. The limited size of the Fragment ID those described in [RFC4963]. The limited size of the Fragment ID
field (see Section 4.3 can cause wrapping of the field, and hence field (see Section 4.3) can cause wrapping of the field, and hence
cause fragments from different datagrams to be incorrectly spliced cause fragments from different datagrams to be incorrectly spliced
together (known as "mis-associated"). For example, a 100Mpbs link together (known as "mis-associated"). For example, a 100Mpbs link
with an MTU of 1500 (causing fragmentation at 1450 bytes) would cause with an MTU of 1500 (causing fragmentation at 1450 bytes) would cause
the Fragment ID field wrap in 8 seconds. Consequently, CAPWAP the Fragment ID field wrap in 8 seconds. Consequently, CAPWAP
implementors are warned to properly size their buffers for reassembly implementers are warned to properly size their buffers for reassembly
purposes based on the expected wireless technology throughput. purposes based on the expected wireless technology throughput.
CAPWAP implementations SHOULD perform MTU Discovery (see CAPWAP implementations SHOULD perform MTU Discovery (see
Section 3.5), which can avoid the need for fragmentation. At the Section 3.5), which can avoid the need for fragmentation. At the
time of writing of this specification, most enterprise switching and time of writing of this specification, most enterprise switching and
routing infrastructure were capable of supporting "mini-jumbo" frames routing infrastructure were capable of supporting "mini-jumbo" frames
(1800 bytes), which eliminates the need for fragmentation (assuming (1800 bytes), which eliminates the need for fragmentation (assuming
the station's MTU is 1500 bytes). The need for fragmentation the station's MTU is 1500 bytes). The need for fragmentation
typically continues to exist when the WTP communicates with the AC typically continues to exist when the WTP communicates with the AC
over a Wide Area Network (WAN). Therefore, future versions of the over a Wide Area Network (WAN). Therefore, future versions of the
CAPWAP protocol SHOULD either consider increasing the size of the CAPWAP protocol SHOULD consider either increasing the size of the
Fragment ID field, or provide alternatives extensions. Fragment ID field or providing alternative extensions.
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 with which it wishes to establish a
session with, it SHOULD perform a Path MTU (PMTU) discovery. One CAPWAP session, it SHOULD perform a Path MTU (PMTU) discovery. One
recommendation for performing PMTU discovery is to have the WTP recommendation for performing PMTU discovery is to have the WTP
transmit Discovery Request (see Section 5.1) messages, and include transmit Discovery Request (see Section 5.1) messages, and include
the MTU Discovery Padding message element (see Section 4.6.32). The the MTU Discovery Padding message element (see Section 4.6.32). The
actual procedures used for PMTU discovery are described in [RFC1191], actual procedures used for PMTU discovery are described in [RFC1191]
for IPv4, or for IPv6 [RFC1981] SHOULD be used. Alternatively, for IPv4; for IPv6, [RFC1981] SHOULD be used. Alternatively,
implementers MAY use the procedures defined in [RFC4821]. The WTP implementers MAY use the procedures defined in [RFC4821]. The WTP
SHOULD also periodically re-evaluate the PMTU using the guidelines SHOULD also periodically re-evaluate the PMTU using the guidelines
provided in these two RFCs, using the Primary Discovery Request (see provided in these two RFCs, using the Primary Discovery Request (see
Section 5.3) along with the MTU Discovery Padding message element Section 5.3) along with the MTU Discovery Padding message element
(see Section 4.6.32). When the MTU is initially known, or updated in (see Section 4.6.32). When the MTU is initially known, or updated in
the case where an existing session already exists, the discovered the case where an existing session already exists, the discovered
PMTU is used to configure the DTLS component (see Section 2.3.2.1), PMTU is used to configure the DTLS component (see Section 2.3.2.1),
while non-DTLS frames need to be fragmented to fit the MTU, defined while non-DTLS frames need to be fragmented to fit the MTU, defined
in Section 3.4. in Section 3.4.
skipping to change at page 45, line 27 skipping to change at page 44, line 20
Response message. These messages need to be in the clear to allow Response message. These messages need to be in the clear to allow
the CAPWAP protocol to properly identify and process them. The the CAPWAP protocol to properly identify and process them. The
format of these packets are as follows: format of these packets are as follows:
CAPWAP Control Packet (Discovery Request/Response): CAPWAP Control Packet (Discovery Request/Response):
+-------------------------------------------+ +-------------------------------------------+
| IP | UDP | CAPWAP | Control | Message | | IP | UDP | CAPWAP | Control | Message |
| Hdr | Hdr | Header | Header | Element(s) | | Hdr | Hdr | Header | Header | Element(s) |
+-------------------------------------------+ +-------------------------------------------+
All other CAPWAP control protocol messages MUST be protected via the All other CAPWAP Control protocol messages MUST be protected via the
DTLS protocol, which ensures that the packets are both authenticated DTLS protocol, which ensures that the packets are both authenticated
and encrypted. These packets include the CAPWAP DTLS Header, which and encrypted. These packets include the CAPWAP DTLS Header, which
is described in Section 4.2. The format of these packets is as is described in Section 4.2. The format of these packets is as
follows: follows:
CAPWAP Control Packet (DTLS Security Required): CAPWAP Control Packet (DTLS Security Required):
+------------------------------------------------------------------+ +------------------------------------------------------------------+
| IP | UDP | CAPWAP | DTLS | CAPWAP | Control| Message | DTLS | | IP | UDP | CAPWAP | DTLS | CAPWAP | Control| Message | DTLS |
| Hdr | Hdr | DTLS Hdr | Hdr | Header | Header | Element(s)| Trlr | | Hdr | Hdr | DTLS Hdr | Hdr | Header | Header | Element(s)| Trlr |
+------------------------------------------------------------------+ +------------------------------------------------------------------+
\---------- authenticated -----------/ \---------- authenticated -----------/
\------------- encrypted ------------/ \------------- encrypted ------------/
The CAPWAP protocol allows optional protection of data packets, using The CAPWAP protocol allows optional protection of data packets, using
DTLS. Use of data packet protection is determined by AC policy. DTLS. Use of data packet protection is determined by AC policy.
When DTLS is utilized, the optional CAPWAP DTLS Header is present, When DTLS is utilized, the optional CAPWAP DTLS Header is present,
which is described in Section 4.2. The format of CAPWAP data packets which is described in Section 4.2. The format of CAPWAP Data packets
is shown below: is shown below:
CAPWAP Plain Text Data Packet : CAPWAP Plain Text Data Packet :
+-------------------------------+ +-------------------------------+
| IP | UDP | CAPWAP | Wireless | | IP | UDP | CAPWAP | Wireless |
| Hdr | Hdr | Header | Payload | | Hdr | Hdr | Header | Payload |
+-------------------------------+ +-------------------------------+
DTLS Secured CAPWAP Data Packet: DTLS Secured CAPWAP Data Packet:
+--------------------------------------------------------+ +--------------------------------------------------------+
skipping to change at page 46, line 24 skipping to change at page 45, line 24
| Hdr | Hdr | DTLS Hdr | Hdr | Hdr | Payload | Trlr | | Hdr | Hdr | DTLS Hdr | Hdr | Hdr | Payload | Trlr |
+--------------------------------------------------------+ +--------------------------------------------------------+
\------ authenticated -----/ \------ authenticated -----/
\------- encrypted --------/ \------- encrypted --------/
UDP Header: All CAPWAP packets are encapsulated within either UDP, UDP Header: All CAPWAP packets are encapsulated within either UDP,
or UDP-Lite when used over IPv6. Section 3 defines the specific or UDP-Lite when used over IPv6. Section 3 defines the specific
UDP or UDP-Lite usage. UDP or UDP-Lite usage.
CAPWAP DTLS Header: All DTLS encrypted CAPWAP protocol packets are CAPWAP DTLS Header: All DTLS encrypted CAPWAP protocol packets are
prefixed with the CAPWAP DTLS header (see Section 4.2). prefixed with the CAPWAP DTLS Header (see Section 4.2).
DTLS Header: The DTLS header provides authentication and encryption DTLS Header: The DTLS Header provides authentication and encryption
services to the CAPWAP payload it encapsulates. This protocol is services to the CAPWAP payload it encapsulates. This protocol is
defined in RFC 4347 [RFC4347]. defined in [RFC4347].
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 signaling 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
CAPWAP message of length 4096 bytes. A CAPWAP implementation MAY CAPWAP message of length 4096 bytes. A CAPWAP implementation MAY
indicate that it supports a higher maximum message length, by indicate that it supports a higher maximum message length, by
including the Maximum Message Length message element, see including the Maximum Message Length message element, see
Section 4.6.31 in the Join Request message or the Join Response Section 4.6.31, in the Join Request message or the Join Response
message. message.
4.1. CAPWAP Preamble 4.1. CAPWAP Preamble
The CAPWAP preamble is common to all CAPWAP transport headers and is The CAPWAP preamble is common to all CAPWAP transport headers and is
used to identify the header type that immediately follows. The used to identify the header type that immediately follows. The
reason for this preamble is to avoid needing to perform byte reason for this preamble is to avoid needing to perform byte
comparisons in order to guess whether the frame is DTLS encrypted or comparisons in order to guess whether or not the frame is DTLS
not. It also provides an extensibility framework that can be used to encrypted. It also provides an extensibility framework that can be
support additional transport types. The format of the preamble is as used to support additional transport types. The format of the
follows: preamble is as follows:
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|Version| Type | |Version| Type |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Version: A 4 bit field which contains the version of CAPWAP used in Version: A 4-bit field that contains the version of CAPWAP used in
this packet. The value for this specification is zero (0). this packet. The value for this specification is zero (0).
Type: A 4 bit field which specifies the payload type that follows Type: A 4-bit field that specifies the payload type that follows the
the UDP header. The following values are supported: UDP header. The following values are supported:
0 - CAPWAP Header. The CAPWAP Header (see Section 4.3) 0 - CAPWAP Header. The CAPWAP Header (see Section 4.3)
immediately follows the UDP header. If the packet is received immediately follows the UDP header. If the packet is
on the CAPWAP data channel, the CAPWAP stack MUST treat the received on the CAPWAP Data channel, the CAPWAP stack MUST
packet as a clear text CAPWAP data packet. If received on the treat the packet as a clear text CAPWAP Data packet. If
CAPWAP control channel, the CAPWAP stack MUST treat the packet received on the CAPWAP Control channel, the CAPWAP stack
as a clear text CAPWAP control packet. If the control packet MUST treat the packet as a clear text CAPWAP Control packet.
is not a Discovery Request or Discovery Response packet, the If the control packet is not a Discovery Request or
packet MUST be dropped. Discovery Response packet, the packet MUST be dropped.
1 - CAPWAP DTLS Header. The CAPWAP DTLS Header, and DTLS packet, 1 - CAPWAP DTLS Header. The CAPWAP DTLS Header (and DTLS
immediately follows the UDP header (see Section 4.2). packet) immediately follows the UDP header (see
Section 4.2).
4.2. CAPWAP DTLS Header 4.2. CAPWAP DTLS Header
The CAPWAP DTLS Header is used to identify the packet as a DTLS The CAPWAP DTLS Header is used to identify the packet as a DTLS
encrypted packet. The first eight bits includes the common CAPWAP encrypted packet. The first eight bits include the common CAPWAP
Preamble. The remaining 24 bits are padding to ensure 4 byte Preamble. The remaining 24 bits are padding to ensure 4-byte
alignment, and MAY be used in a future version of the protocol. The alignment, and MAY be used in a future version of the protocol. The
DTLS packet [RFC4347] always immediately follows this header. The DTLS packet [RFC4347] always immediately follows this header. The
format of the CAPWAP DTLS Header is as follows: format of the CAPWAP DTLS Header is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|CAPWAP Preamble| Reserved | |CAPWAP Preamble| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 48, line 50 skipping to change at page 47, line 50
| (optional) Wireless Specific Information | | (optional) Wireless Specific Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload .... | | Payload .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CAPWAP Preamble: The CAPWAP Preamble is defined in Section 4.1. The CAPWAP Preamble: The CAPWAP Preamble is defined in Section 4.1. The
CAPWAP Preamble's Payload Type field MUST be set to zero (0). If CAPWAP Preamble's Payload Type field MUST be set to zero (0). If
the CAPWAP DTLS Header is present, the version number in both the CAPWAP DTLS Header is present, the version number in both
CAPWAP Preambles MUST match. The reason for this duplicate field CAPWAP Preambles MUST match. The reason for this duplicate field
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 that 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 that contains the Radio ID number for this
packet, whose value is between one (1) and 31. Given that MAC packet, whose value is between one (1) and 31. Given that MAC
Addresses are not necessarily unique across physical radios in a Addresses are not necessarily unique across physical radios in a
WTP, the Radio Identifier (RID) field is used to indicate which WTP, the Radio Identifier (RID) field is used to indicate with
physical radio the message is associated with. which physical radio the message is associated.
WBID: A 5 bit field which is the wireless binding identifier. The WBID: A 5-bit field that is the wireless binding identifier. The
identifier will indicate the type of wireless packet associated identifier will indicate the type of wireless packet associated
with the radio. The following values are defined: with the radio. The following values are defined:
0 - Reserved 0 - Reserved
1 - IEEE 802.11 1 - IEEE 802.11
2 - Reserved 2 - Reserved
3 - EPCGlobal [EPCGlobal] 3 - EPCGlobal [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.
When this bit is zero (0) the payload is an IEEE 802.3 frame. When this bit is zero (0), the payload is an IEEE 802.3 frame.
F: The Fragment 'F' bit indicates whether this packet is a fragment. F: The Fragment 'F' bit indicates whether this packet is a fragment.
When this bit is one (1), the packet is a fragment and MUST be When this bit is one (1), the packet is a fragment and MUST be
combined with the other corresponding fragments to reassemble the combined with the other corresponding fragments to reassemble the
complete information exchanged between the WTP and AC. complete information exchanged between the WTP and AC.
L: The Last 'L' bit is valid only if the 'F' bit is set and indicates L: The Last 'L' bit is valid only if the 'F' bit is set and indicates
whether the packet contains the last fragment of a fragmented whether the packet contains the last fragment of a fragmented
exchange between WTP and AC. When this bit is 1, the packet is exchange between WTP and AC. When this bit is one (1), the packet
the last fragment. When this bit is 0, the packet is not the last is the last fragment. When this bit is (zero) 0, the packet is
fragment. not the last fragment.
W: The Wireless 'W' bit is used to specify whether the optional W: The Wireless 'W' bit is used to specify whether the optional
Wireless Specific Information field is present in the header. A Wireless Specific Information field is present in the header. A
value of one (1) is used to represent the fact that the optional value of one (1) is used to represent the fact that the optional
header is present. header is present.
M: The M bit is used to indicate that the Radio MAC Address optional M: The Radio MAC 'M' bit is used to indicate that the Radio MAC
header is present. This is used to communicate the MAC address of Address optional header is present. This is used to communicate
the receiving radio. the MAC address of the receiving radio.
K: The 'Keep-alive' K bit indicates the packet is a Data Channel Keep K: The Keep-Alive 'K' bit indicates the packet is a Data Channel
Alive packet. This packet is used to map the data channel to the Keep-Alive packet. This packet is used to map the data channel to
control channel for the specified Session ID and to maintain the control channel for the specified Session ID and to maintain
freshness of the data channel. The K bit MUST NOT be set for data freshness of the data channel. The 'K' bit MUST NOT be set for
packets containing user data. data packets containing user data.
Flags: A set of reserved bits for future flags in the CAPWAP header. Flags: A set of reserved bits for future flags in the CAPWAP Header.
All implementations complying with this protocol MUST set to zero All implementations complying with this protocol MUST set to zero
any bits that are reserved in the version of the protocol any bits that are reserved in the version of the protocol
supported by that implementation. Receivers MUST ignore all bits supported by that implementation. Receivers MUST ignore all bits
not defined for the version of the protocol they support. not defined for the version of the protocol they support.
Fragment ID: A 16 bit field whose value is assigned to each group of Fragment ID: A 16-bit field whose value is assigned to each group of
fragments making up a complete set. The fragment ID space is fragments making up a complete set. The Fragment ID space is
managed individually for each direction for every WTP/AC pair. managed individually for each direction for every WTP/AC pair.
The value of Fragment ID is incremented with each new set of The value of Fragment ID is incremented with each new set of
fragments. The Fragment ID wraps to zero after the maximum value fragments. The Fragment ID wraps to zero after the maximum value
has been used to identify a set of fragments. has been used to identify a set of fragments.
Fragment Offset: A 13 bit field that indicates where in the payload Fragment Offset: A 13-bit field that indicates where in the payload
this fragment belongs during re-assembly. This field is valid this fragment belongs during re-assembly. This field is valid
when the 'F' bit is set to 1. The fragment offset is measured in when the 'F' bit is set to 1. The fragment offset is measured in
units of 8 octets (64 bits). The first fragment has offset zero. units of 8 octets (64 bits). The first fragment has offset zero.
Note the CAPWAP protocol does not allow for overlapping fragments. Note that the CAPWAP protocol does not allow for overlapping
fragments.
Reserved: The 3-bit field is reserved for future use. All Reserved: The 3-bit field is reserved for future use. All
implementations complying with this protocol MUST set to zero any implementations complying with this protocol MUST set to zero any
bits that are reserved in the version of the protocol supported by bits that are reserved in the version of the protocol supported by
that implementation. Receivers MUST ignore all bits not defined that implementation. Receivers MUST ignore all bits not defined
for the version of the protocol they support. for the version of the protocol they support.
Radio MAC Address: This optional field contains the MAC address of Radio MAC Address: This optional field contains the MAC address of
the radio receiving the packet. Because the native wireless frame the radio receiving the packet. Because the native wireless frame
format to IEEE 802.3 format causes the MAC address of the WTP's format to IEEE 802.3 format causes the MAC address of the WTP's
radio to be lost, this field allows the address to be communicated radio to be lost, this field allows the address to be communicated
to the AC. This field is only present if the 'M' bit is set. The to the AC. This field is only present if the 'M' bit is set. The
HLEN field assumes 4 byte alignment, and this field MUST be padded HLEN field assumes 4-byte alignment, and this field MUST be padded
with zeroes (0x00) if it is not 4 byte aligned. with zeroes (0x00) if it is not 4-byte aligned.
The field contains the basic format: The field contains the basic 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | MAC Address | Length | MAC Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: The length of the MAC Address field. The following
formats, and lengths, are supported [EUI-48] and [EUI-64].
MAC Address: The MAC Address of the receiving radio. Length: The length of the MAC address field. The formats and
lengths specified in [EUI-48] and [EUI-64] are supported.
MAC Address: The MAC address of the receiving radio.
Wireless Specific Information: This optional field contains 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 WBID field in the CAPWAP header is used to 'W' bit is set. The WBID field in the CAPWAP Header is used to
identify the format of the wireless specific information optional identify the format of the Wireless-Specific Information optional
field. The HLEN field assumes 4 byte alignment, and this field field. The HLEN field assumes 4-byte alignment, and this field
MUST be padded with zeroes (0x00) if it is not 4 byte aligned. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Data... | Length | Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: The 8 bit field contains the length of the data field, Length: The 8-bit field contains the length of the data field,
with a maximum size of 255. with a maximum size of 255.
Data: Wireless specific information, defined by the wireless Data: Wireless-specific information, defined by the wireless-
specific binding specified in the CAPWAP Header's WBID field. 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
maintain freshness of the data channel. The second is used to maintain freshness of the data channel. The second is used to
transmit user payloads between the AC and WTP. This section transmit user payloads between the AC and WTP. This section
describes both types of CAPWAP data packet formats. describes both types of CAPWAP Data packet formats.
Both CAPWAP data messages are transmitted on the CAPWAP data channel. Both CAPWAP Data messages are transmitted on the CAPWAP Data channel.
4.4.1. CAPWAP Data Channel Keepalive 4.4.1. CAPWAP Data Channel Keep-Alive
The CAPWAP Data Channel Keep Alive packet is used to bind the CAPWAP The CAPWAP Data Channel Keep-Alive packet is used to bind the CAPWAP
control channel with the data channel, and to maintain freshness of control channel with the data channel, and to maintain freshness of
the data channel, ensuring that the channel is still functioning. the data channel, ensuring that the channel is still functioning.
The CAPWAP Data Channel Keep Alive packet is transmitted by the WTP The CAPWAP Data Channel Keep-Alive packet is transmitted by the WTP
when the DataChannelKeepAlive timer expires (see Section 4.7.2). when the DataChannelKeepAlive timer expires (see Section 4.7.2).
When the CAPWAP Data Channel Keep Alive packet is transmitted, the When the CAPWAP Data Channel Keep-Alive packet is transmitted, the
WTP sets the DataChannelDeadInterval timer. WTP sets the DataChannelDeadInterval timer.
In the CAPWAP Data Channel Keep Alive packet, all of the fields in In the CAPWAP Data Channel Keep-Alive packet, all of the fields in
the CAPWAP header, except the HLEN field and the K bit, are set to the CAPWAP Header, except the HLEN field and the 'K' bit, are set to
zero upon transmission. Upon receiving a CAPWAP Data Channel Keep zero upon transmission. Upon receiving a CAPWAP Data Channel Keep-
Alive packet, the AC transmits a CAPWAP Data Channel Keep Alive Alive packet, the AC transmits a CAPWAP Data Channel Keep-Alive
packet back to the WTP. The contents of the transmitted packet are packet back to the WTP. The contents of the transmitted packet are
identical to the contents of the received packet. identical to the contents of the received packet.
Upon receiving a CAPWAP Data Channel Keep Alive packet, the WTP Upon receiving a CAPWAP Data Channel Keep-Alive packet, the WTP
cancels the DataChannelDeadInterval timer and resets the cancels the DataChannelDeadInterval timer and resets the
DataChannelKeepAlive timer. The CAPWAP Data Channel Keep Alive DataChannelKeepAlive timer. The CAPWAP Data Channel Keep-Alive
packet is retransmitted by the WTP in the same manner as the CAPWAP packet is retransmitted by the WTP in the same manner as the CAPWAP
control messages. If the DataChannelDeadInterval timer expires, the Control messages. If the DataChannelDeadInterval timer expires, the
WTP tears down the control DTLS session, and the data DTLS session if WTP tears down the control DTLS session, and the data DTLS session if
one existed. one existed.
The CAPWAP Data Channel Keep Alive packet contains the following The CAPWAP Data Channel Keep-Alive packet contains the following
payload immediately following the CAPWAP Header (see Section 4.3) payload immediately following the CAPWAP Header (see Section 4.3).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Element Length | Message Element [0..N] ... | Message Element Length | Message Element [0..N] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Element Length: The 16 bit Length field indicates the Message Element Length: The 16-bit Length field indicates the
number of bytes following the CAPWAP Header, with a maximum size number of bytes following the CAPWAP Header, with a maximum size
of 65535. of 65535.
Message Element[0..N]: The message element(s) carry the information Message Element[0..N]: The message element(s) carry the information
pertinent to each of the CAPWAP Data Channel Keepalive message. pertinent to each of the CAPWAP Data Channel Keep-Alive message.
The following message elements MUST be present in this CAPWAP The following message elements MUST be present in this CAPWAP
message: 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 for 802.11 frames, the 802.11 encapsulation requires that for 802.11 frames, the 802.11
*Integration* function be performed in the WTP. An IEEE 802.3 *Integration* function be performed in the WTP. An IEEE 802.3-
encapsulated user payload frame has the following 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.
For 802.3 payload frames, the 802.3 frame is encapsulated (excluding For 802.3 payload frames, the 802.3 frame is encapsulated (excluding
the IEEE 802.3 Preamble, Start Frame Delimiter (SFD) and Frame Check the IEEE 802.3 Preamble, Start Frame Delimiter (SFD), and Frame Check
Sequence (FCS) Fields). If the encapsulated frame would exceed the Sequence (FCS) fields). If the encapsulated frame would exceed the
transport layer's MTU, the sender is responsible for fragmentation of transport layer's MTU, the sender is responsible for the
the frame, as specified in Section 3.4. The CAPWAP protocol can fragmentation of the frame, as specified in Section 3.4. The CAPWAP
support IEEE 802.3 frames whose length is defined in the IEEE 802.3as protocol can support IEEE 802.3 frames whose length is defined in the
specification [FRAME-EXT]. IEEE 802.3as specification [FRAME-EXT].
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
SHOULD be initiated using the TLS session resumption feature SHOULD be initiated using the TLS session resumption feature
[RFC4346]. [RFC5246].
The AC DTLS implementation MUST NOT initiate a data channel session The AC DTLS implementation MUST NOT initiate a data channel session
for a DTLS session for which there is no active control channel for a DTLS session for which there is no active control channel
session. session.
4.5. CAPWAP Control Messages 4.5. CAPWAP Control Messages
The CAPWAP Control protocol provides a control channel between the The CAPWAP Control protocol provides a control channel between the
WTP and the AC. Control messages are divided into the following WTP and the AC. Control messages are divided into the following
message types: message types:
Discovery: CAPWAP Discovery messages are used to identify potential Discovery: CAPWAP Discovery messages are used to identify potential
ACs, their load and capabilities. ACs, their load and capabilities.
Join: CAPWAP Join messages are used by a WTP to request service from Join: CAPWAP Join messages are used by a WTP to request service from
an AC, and for the AC to respond to the WTP. an AC, and for the AC to respond to the WTP.
Control Channel Management: CAPWAP control channel management Control Channel Management: CAPWAP Control channel management
messages are used to maintain the control channel. messages are used to maintain the control channel.
WTP Configuration Management: The WTP Configuration messages are WTP Configuration Management: The WTP Configuration messages are
used by the AC to deliver a specific configuration to the WTP. used by the AC to deliver a specific configuration to the WTP.
Messages which retrieve statistics from a WTP are also included in Messages that retrieve statistics from a WTP are also included in
WTP Configuration Management. WTP Configuration Management.
Station Session Management: Station Session Management messages are Station Session Management: Station Session Management messages are
used by the AC to deliver specific station policies to the WTP. used by the AC to deliver specific station policies to the WTP.
Device Management Operations: Device management operations are used Device Management Operations: Device management operations are used
to request and deliver a firmware image to the WTP. to request and deliver a firmware image to the WTP.
Binding Specific CAPWAP Management Messages: Messages in this Binding-Specific CAPWAP Management Messages: Messages in this
category are used by the AC and the WTP to exchange protocol- category are used by the AC and the WTP to exchange protocol-
specific CAPWAP management messages. These messages may or may specific CAPWAP management messages. These messages may or may
not be used to change the link state of a station. not be used to change the link state of a station.
Discovery, Join, Control Channel Management, WTP Configuration Discovery, Join, Control Channel Management, WTP Configuration
Management and Station Session Management CAPWAP control messages Management, and Station Session Management CAPWAP Control messages
MUST be implemented. Device Management Operations messages MAY be MUST be implemented. Device Management Operations messages MAY be
implemented. implemented.
CAPWAP control messages sent from the WTP to the AC indicate that the CAPWAP Control messages sent from the WTP to the AC indicate that the
WTP is operational, providing an implicit keep-alive mechanism for WTP is operational, providing an implicit keep-alive mechanism for
the WTP. The Control Channel Management Echo Request and Echo the WTP. The Control Channel Management Echo Request and Echo
Response messages provide an explicit keep-alive mechanism when other Response messages provide an explicit keep-alive mechanism when other
CAPWAP control messages are not exchanged. CAPWAP Control messages are not exchanged.
4.5.1. Control Message Format 4.5.1. Control Message Format
All CAPWAP control messages are sent encapsulated within the CAPWAP All CAPWAP Control messages are sent encapsulated within the CAPWAP
header (see Section 4.3). Immediately following the CAPWAP header, Header (see Section 4.3). Immediately following the CAPWAP Header is
is the control header, which has the following format: the control header, which has 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | | Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq Num | Msg Element Length | Flags | | Seq Num | Msg Element Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Msg Element [0..N] ... | Msg Element [0..N] ...
+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+
4.5.1.1. Message Type 4.5.1.1. Message Type
The Message Type field identifies the function of the CAPWAP control The Message Type field identifies the function of the CAPWAP Control
message. To provide extensibility, the Message Type field is message. To provide extensibility, the Message Type field is
comprised of an IANA Enterprise Number [RFC3232] and an enterprise comprised of an IANA Enterprise Number [RFC3232] and an enterprise-
specific message type number. The first three octets contain the specific message type number. The first three octets contain the
IANA Enterprise Number in network byte order, with zero used for IANA Enterprise Number in network byte order, with zero used for
CAPWAP base protocol (this specification) defined message types. The CAPWAP base protocol (this specification) defined message types. The
last octet is the enterprise specific message type number, which has last octet is the enterprise-specific message type number, which has
a range from 0 to 255. a range from 0 to 255.
The message type field is defined as: The Message Type field is defined as:
Message Type = Message Type =
IANA Enterprise Number * 256 + IANA Enterprise Number * 256 +
Enterprise Specific Message Type Number Enterprise Specific Message Type Number
The CAPWAP protocol reliability mechanism requires that messages be The CAPWAP protocol reliability mechanism requires that messages be
defined in pairs, consisting of both a Request and a Response defined in pairs, consisting of both a Request and a Response
message. The Response message MUST acknowledge the Request message. message. The Response message MUST acknowledge the Request message.
The assignment of CAPWAP control Message Type Values always occurs in The assignment of CAPWAP Control Message Type Values always occurs in
pairs. All Request messages have odd numbered Message Type Values, pairs. All Request messages have odd numbered Message Type Values,
and all Response messages have even numbered Message Type Values. and all Response messages have even numbered Message Type Values.
The Request value MUST be assigned first. As an example, assigning a The Request value MUST be assigned first. As an example, assigning a
Message Type Value of 3 for a Request message and 4 for a Response Message Type Value of 3 for a Request message and 4 for a Response
message is valid, while assigning a Message Type Value of 4 for a message is valid, while assigning a Message Type Value of 4 for a
Response message and 5 for the corresponding Request message is Response message and 5 for the corresponding Request message is
invalid. invalid.
When a WTP or AC receives a message with a Message Type Value field When a WTP or AC receives a message with a Message Type Value field
that is not recognized and is an odd number, the number in the that is not recognized and is an odd number, the number in the
skipping to change at page 56, line 36 skipping to change at page 55, line 39
Primary Discovery Response 20 Primary Discovery Response 20
Data Transfer Request 21 Data Transfer Request 21
Data Transfer Response 22 Data Transfer Response 22
Clear Configuration Request 23 Clear Configuration Request 23
Clear Configuration Response 24 Clear Configuration Response 24
Station Configuration Request 25 Station Configuration Request 25
Station Configuration Response 26 Station Configuration Response 26
4.5.1.2. Sequence Number 4.5.1.2. Sequence Number
The Sequence Number Field is an identifier value used to match The Sequence Number field is an identifier value used to match
Request and Response packets. When a CAPWAP packet with a Request Request and Response packets. When a CAPWAP packet with a Request
Message Type Value is received, the value of the Sequence Number Message Type Value is received, the value of the Sequence Number
field is copied into the corresponding Response message. field is copied into the corresponding Response message.
When a CAPWAP control message is sent, the sender's internal sequence When a CAPWAP Control message is sent, the sender's internal sequence
number counter is monotonically incremented, ensuring that no two number counter is monotonically incremented, ensuring that no two
pending Request messages have the same Sequence Number. The Sequence pending Request messages have the same sequence number. The Sequence
Number field wraps back to zero. Number field wraps back to zero.
4.5.1.3. Message Element Length 4.5.1.3. Message Element Length
The Length field indicates the number of bytes following the Sequence The Length field indicates the number of bytes following the Sequence
Number field. Number field.
4.5.1.4. Flags 4.5.1.4. Flags
The Flags field MUST be set to zero. The Flags field MUST be set to zero.
skipping to change at page 57, line 35 skipping to change at page 56, line 35
discarded. If the received message was a Request message for which discarded. If the received message was a Request message for which
the corresponding Response message carries message elements, then a the corresponding Response message carries message elements, then a
corresponding Response message with a Result Code message element corresponding Response message with a Result Code message element
indicating "Failure - Unrecognized Message Element" and one or more indicating "Failure - Unrecognized Message Element" and one or more
Returned Message Element message elements is included, containing the Returned Message Element message elements is included, containing the
unrecognized message element(s). unrecognized message element(s).
4.5.2. Quality of Service 4.5.2. Quality of Service
The CAPWAP base protocol does not provide any Quality of Service The CAPWAP base protocol does not provide any Quality of Service
(QoS) recommendations for use with the CAPWAP data messages. Any (QoS) recommendations for use with the CAPWAP Data messages. Any
wireless specific CAPWAP binding specification that has QoS wireless-specific CAPWAP binding specification that has QoS
requirements MUST define the application of QoS to the CAPWAP data requirements MUST define the application of QoS to the CAPWAP Data
messages. messages.
The IP header also includes the Explicit Congestion Notification The IP header also includes the Explicit Congestion Notification
(ECN) bits [RFC3168]. Section 9.1.1 of [RFC3168] describes two (ECN) bits [RFC3168]. Section 9.1.1 of [RFC3168] describes two
levels of ECN functionality, full functionality and limited levels of ECN functionality: full functionality and limited
functionality. CAPWAP ACs and WTPs SHALL implement the limited functionality. CAPWAP ACs and WTPs SHALL implement the limited
functionality and are RECOMMENDED to implement the full functionality functionality and are RECOMMENDED to implement the full functionality
described in [RFC3168]. described in [RFC3168].
4.5.2.1. Applying QoS to CAPWAP Control Message 4.5.2.1. Applying QoS to CAPWAP Control Message
It is recommended that CAPWAP control messages be sent by both the AC It is recommended that CAPWAP Control messages be sent by both the AC
and the WTP with an appropriate Quality of Service precedence value, and the WTP with an appropriate Quality-of-Service precedence value,
ensuring that congestion in the network minimizes occurrences of ensuring that congestion in the network minimizes occurrences of
CAPWAP control channel disconnects. Therefore, a Quality of Service CAPWAP Control channel disconnects. Therefore, a QoS-enabled CAPWAP
enabled CAPWAP device SHOULD use the following values: device SHOULD use the following values:
802.1Q: The priority tag of 7 SHOULD be used. 802.1Q: The priority tag of 7 SHOULD be used.
DSCP: The CS6 per-hop behavior Service Class SHOULD be used, which DSCP: The CS6 per-hop behavior Service Class SHOULD be used, which
is described in [RFC2474]). is described in [RFC2474]).
4.5.3. Retransmissions 4.5.3. Retransmissions
The CAPWAP control protocol operates as a reliable transport. For The CAPWAP Control protocol operates as a reliable transport. For
each Request message, a Response message is defined, which is used to each Request message, a Response message is defined, which is used to
acknowledge receipt of the Request message. In addition, the control acknowledge receipt of the Request message. In addition, the control
header Sequence Number field is used to pair the Request and Response header Sequence Number field is used to pair the Request and Response
messages (see Section 4.5.1). messages (see Section 4.5.1).
Response messages are not explicitly acknowledged, therefore if a Response messages are not explicitly acknowledged; therefore, if a
Response message is not received, the original Request message is Response message is not received, the original Request message is
retransmitted. retransmitted.
Implementations MUST keep track of the Sequence Number of the last Implementations MUST keep track of the sequence number of the last
received Request message, and MUST cache the corresponding Response received Request message, and MUST cache the corresponding Response
message. If a retransmission with the same Sequence Number is message. If a retransmission with the same sequence number is
received, the cached Response message MUST be retransmitted without received, the cached Response message MUST be retransmitted without
re-processing the Request. If an older Request message is received, re-processing the Request. If an older Request message is received,
meaning one where the sequence number is smaller, it MUST be ignored. meaning one where the sequence number is smaller, it MUST be ignored.
A newer Request message, meaning one whose sequence number is larger, A newer Request message, meaning one whose sequence number is larger,
is processed as usual. is processed as usual.
Note: A sequence number is considered "smaller" when s1 is smaller Note: A sequence number is considered "smaller" when s1 is smaller
than s2 modulo 256 if and only if (s1<s2 and (s2-s1)<128) or (s1>s2 than s2 modulo 256 if and only if (s1<s2 and (s2-s1)<128) or
and (s1-s2)>128) (s1>s2 and (s1-s2)>128).
Both the WTP and the AC can only have a single request outstanding at Both the WTP and the AC can only have a single request outstanding at
any given time. Retransmitted Request messages MUST NOT be altered any given time. Retransmitted Request messages MUST NOT be altered
by the sender. by the sender.
After transmitting a Request message, the RetransmitInterval (see After transmitting a Request message, the RetransmitInterval (see
Section 4.7) timer and MaxRetransmit (see Section 4.8) variable are Section 4.7) timer and MaxRetransmit (see Section 4.8) variable are
used to determine if the original Request message needs to be used to determine if the original Request message needs to be
retransmitted. The RetransmitInterval timer is used the first time retransmitted. The RetransmitInterval timer is used the first time
the Request is retransmitted. The timer is then doubled every the Request is retransmitted. The timer is then doubled every
skipping to change at page 59, line 9 skipping to change at page 58, line 16
Section 4.7.7). Response messages are not subject to these timers. Section 4.7.7). Response messages are not subject to these timers.
If the sender stops retransmitting a Request message before reaching If the sender stops retransmitting a Request message before reaching
MaxRetransmit retransmissions (which leads to transition to DTLS MaxRetransmit retransmissions (which leads to transition to DTLS
Teardown, as described in Section 2.3.1), it cannot know whether the Teardown, as described in Section 2.3.1), it cannot know whether the
recipient received and processed the Request or not. In most recipient received and processed the Request or not. In most
situations, the sender SHOULD NOT do this, and instead continue situations, the sender SHOULD NOT do this, and instead continue
retransmitting until a Response message is received, or transition to retransmitting until a Response message is received, or transition to
DTLS Teardown occurs. However, if the sender does decide to continue DTLS Teardown occurs. However, if the sender does decide to continue
the connection with a new or modified Request message, the new the connection with a new or modified Request message, the new
message MUST have a new Sequence Number, and be treated as a new message MUST have a new sequence number, and be treated as a new
Request message by the receiver. Note that there is a high chance Request message by the receiver. Note that there is a high chance
that both the WTP and the AC's sequence numbers will become out of that both the WTP and the AC's sequence numbers will become out of
sync. sync.
When a Request message is retransmitted, it MUST be re-encrypted via When a Request message is retransmitted, it MUST be re-encrypted via
the DTLS stack. If the peer had received the Request message, and the DTLS stack. If the peer had received the Request message, and
the corresponding Response message was lost, it is necessary to the corresponding Response message was lost, it is necessary to
ensure that retransmitted Request messages are not identified as ensure that retransmitted Request messages are not identified as
replays by the DTLS stack. Similarly, any cached Response messages replays by the DTLS stack. Similarly, any cached Response messages
that are retransmitted as a result of receiving a retransmitted that are retransmitted as a result of receiving a retransmitted
Request message MUST be re-encrypted via DTLS. Request message MUST be re-encrypted via DTLS.
Duplicate Response messages, identified by the Sequence Number field Duplicate Response messages, identified by the Sequence Number field
in the CAPWAP control message header, SHOULD be discarded upon in the CAPWAP Control message header, SHOULD be discarded upon
receipt. receipt.
4.6. CAPWAP Protocol Message Elements 4.6. CAPWAP Protocol Message Elements
This section defines the CAPWAP Protocol message elements which are This section defines the CAPWAP Protocol message elements that are
included in CAPWAP protocol control messages. included in CAPWAP protocol control messages.
Message elements are used to carry information needed in control Message elements are used to carry information needed in control
messages. Every message element is identified by the Type Value messages. Every message element is identified by the Type Value
field, defined below. The total length of the message elements is field, defined below. The total length of the message elements is
indicated in the message element Length field. indicated in the message element's length field.
All of the message element definitions in this document use a diagram All of the message element definitions in this document use a diagram
similar to the one below in order to depict its format. Note that to similar to the one below in order to depict its format. Note that to
simplify this specification, these diagrams do not include the header simplify this specification, these diagrams do not include the header
fields (Type and Length). The header field values are defined in the fields (Type and Length). The header field values are defined in the
message element descriptions. message element descriptions.
Unless otherwise specified, a control message that lists a set of Unless otherwise specified, a control message that lists a set of
supported (or expected) message elements MUST NOT expect the message supported (or expected) message elements MUST NOT expect the message
elements to be in any specific order. The sender MAY include the elements to be in any specific order. The sender MAY include the
skipping to change at page 60, line 18 skipping to change at page 59, line 28
The format of a message element uses the TLV format shown here: The format of a message element uses the TLV format shown here:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ... | | Value ... |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
The 16 bit Type field identifies the information carried in the Value The 16-bit Type field identifies the information carried in the Value
field and Length (16 bits) indicates the number of bytes in the Value field and Length (16 bits) indicates the number of bytes in the Value
field. The value of zero (0) is reserved and MUST NOT be used. The field. The value of zero (0) is reserved and MUST NOT be used. The
rest of the Type field values are allocated as follows: rest of the Type field values are allocated as follows:
Usage Type Values Usage Type Values
CAPWAP Protocol Message Elements 1 - 1023 CAPWAP Protocol Message Elements 1 - 1023
IEEE 802.11 Message Elements 1024 - 2047 IEEE 802.11 Message Elements 1024 - 2047
Reserved for Future Use 2048 - 3071 Reserved for Future Use 2048 - 3071
EPCGlobal Message Elements 3072 - 4095 EPCGlobal Message Elements 3072 - 4095
skipping to change at page 62, line 29 skipping to change at page 61, line 41
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 mask specifying the authentication credential Security: An 8-bit mask specifying the authentication credential
type supported by the AC (See Section 2.4.4). The field has the type supported by the AC (see Section 2.4.4). The field has the
following format: following format:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|Reserved |S|X|R| |Reserved |S|X|R|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Reserved: A set of reserved bits for future use. All Reserved: A set of reserved bits for future use. All
implementations complying with this protocol MUST set to zero implementations complying with this protocol MUST set to zero
any bits that are reserved in the version of the protocol any bits that are reserved in the version of the protocol
supported by that implementation. Receivers MUST ignore all supported by that implementation. Receivers MUST ignore all
bits not defined for the version of the protocol they support. bits not defined for the version of the protocol they support.
S: The AC supports the pre-shared secret authentication, as S: The AC supports the pre-shared secret authentication, as
described in Section 12.6. described in Section 12.6.
X: The AC supports X.509 Certificate authentication, as X: The AC supports X.509 Certificate authentication, as
skipping to change at page 63, line 5 skipping to change at page 62, line 16
any bits that are reserved in the version of the protocol any bits that are reserved in the version of the protocol
supported by that implementation. Receivers MUST ignore all supported by that implementation. Receivers MUST ignore all
bits not defined for the version of the protocol they support. bits not defined for the version of the protocol they support.
S: The AC supports the pre-shared secret authentication, as S: The AC supports the pre-shared secret authentication, as
described in Section 12.6. described in Section 12.6.
X: The AC supports X.509 Certificate authentication, as X: The AC supports X.509 Certificate authentication, as
described in Section 12.7. described in Section 12.7.
R: A reserved bit for future use. All implementations complying R: A reserved bit for future use. All implementations
with this protocol MUST set to zero any bits that are reserved complying with this protocol MUST set to zero any bits that
in the version of the protocol supported by that are reserved in the version of the protocol supported by
implementation. Receivers MUST ignore all bits not defined for that implementation. Receivers MUST ignore all bits not
the version of the protocol they support. defined for the version of the protocol they support.
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). The following in the CAPWAP transport header (see Section 4.3). The following
enumerated values are supported: enumerated values are supported:
0 - Reserved 0 - Reserved
1 - Supported 1 - Supported
2 - Not Supported 2 - Not Supported
Reserved: A set of reserved bits for future use. All Reserved: A set of reserved bits for future use. All
implementations complying with this protocol MUST set to zero any implementations complying with this protocol MUST set to zero any
skipping to change at page 63, line 37 skipping to change at page 63, line 4
DTLS Policy: The AC communicates its policy on the use of DTLS for DTLS Policy: The AC communicates its policy on the use of DTLS for
the CAPWAP data channel. The AC MAY communicate more than one the CAPWAP data channel. The AC MAY communicate more than one
supported option, represented by the bit field below. The WTP supported option, represented by the bit field below. The WTP
MUST abide by one of the options communicated by AC. The field MUST abide by one of the options communicated by AC. The field
has the following format: has the following format:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|Reserved |D|C|R| |Reserved |D|C|R|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Reserved: A set of reserved bits for future use. All Reserved: A set of reserved bits for future use. All
implementations complying with this protocol MUST set to zero implementations complying with this protocol MUST set to zero
any bits that are reserved in the version of the protocol any bits that are reserved in the version of the protocol
supported by that implementation. Receivers MUST ignore all supported by that implementation. Receivers MUST ignore all
bits not defined for the version of the protocol they support. bits not defined for the version of the protocol they support.
D: DTLS Enabled Data Channel Supported D: DTLS-Enabled Data Channel Supported
C: Clear Text Data Channel Supported C: Clear Text Data Channel Supported
R: A reserved bit for future use. All implementations complying R: A reserved bit for future use. All implementations
with this protocol MUST set to zero any bits that are reserved complying with this protocol MUST set to zero any bits that
in the version of the protocol supported by that are reserved in the version of the protocol supported by
implementation. Receivers MUST ignore all bits not defined for that implementation. Receivers MUST ignore all bits not
the version of the protocol they support. defined for the version of the protocol they support.
AC Information Sub-Element: The AC Descriptor message element AC Information Sub-Element: The AC Descriptor message element
contains multiple AC Information sub-elements, and defines two contains multiple AC Information sub-elements, and defines two
sub-types, each of which MUST be present. The AC Information sub- sub-types, each of which MUST be present. The AC Information sub-
element has the following format: element has 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC Information Vendor Identifier | | AC Information Vendor Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC Information Type | AC Information Length | | AC Information Type | AC Information Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC Information Data... | AC Information Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AC Information Vendor Identifier: A 32-bit value containing the AC Information Vendor Identifier: A 32-bit value containing the
IANA assigned "SMI Network Management Private Enterprise Codes" IANA-assigned "Structure of Management Information (SMI)
Network Management Private Enterprise Codes".
AC Information Type: Vendor specific encoding of AC information AC Information Type: Vendor-specific encoding of AC information
in the UTF-8 format [RFC3629]. The following enumerated values in the UTF-8 format [RFC3629]. The following enumerated values
are supported. Both the Hardware and Software Version sub- are supported. Both the Hardware and Software Version sub-
elements MUST be included in the AC Descriptor message element. elements MUST be included in the AC Descriptor message element.
The values listed below are used in conjunction with the AC The values listed below are used in conjunction with the AC
Information Vendor Identifier field, whose value MUST be set to Information Vendor Identifier field, whose value MUST be set to
zero (0). This field, combined with the AC Information Vendor zero (0). This field, combined with the AC Information Vendor
Identifier set to a non-zero (0) value, allows vendors to use a Identifier set to a non-zero (0) value, allows vendors to use a
private namespace. private namespace.
4 - Hardware Version: The AC's hardware version number. 4 - Hardware Version: The AC's hardware version number.
5 - Software Version: The AC's Software (firmware) version 5 - Software Version: The AC's Software (firmware) version
number. number.
AC Information Length: Length of vendor specific encoding of AC AC Information Length: Length of vendor-specific encoding of AC
information, with a maximum size of 1024. information, with a maximum size of 1024.
AC Information Data: Vendor specific encoding of AC information. AC Information Data: Vendor-specific encoding of AC information.
4.6.2. AC IPv4 List 4.6.2. AC IPv4 List
The AC IPv4 List message element is used to configure a WTP with the The AC IPv4 List message element is used to configure a WTP with the
latest list of ACs available for the WTP to join. latest list of ACs available for the WTP to join.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC IP Address[] | | AC IP Address[] |
skipping to change at page 65, line 40 skipping to change at page 65, line 14
Type: 3 for AC IPV6 List Type: 3 for AC IPV6 List
Length: >= 16 Length: >= 16
AC IP Address: An array of 128-bit integers containing AC IPv6 AC IP Address: An array of 128-bit integers containing AC IPv6
Addresses, containing no more than 1024 addresses. Addresses, containing no more than 1024 addresses.
4.6.4. AC Name 4.6.4. AC Name
The AC Name message element contains an UTF-8 [RFC3629] The AC Name message element contains an UTF-8 [RFC3629]
representation of the AC identity. The value is a variable length representation of the AC identity. The value is a variable-length
byte string. The string is NOT zero terminated. byte string. The string is NOT zero terminated.
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Name ... | Name ...
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Type: 4 for AC Name Type: 4 for AC Name
Length: >= 1 Length: >= 1
Name: A variable length UTF-8 encoded string [RFC3629] containing Name: A variable-length UTF-8 encoded string [RFC3629] containing
the AC's name, whose maximum size MUST NOT exceed 512 bytes. the AC's name, whose maximum size MUST NOT exceed 512 bytes.
4.6.5. AC Name with Priority 4.6.5. AC Name with Priority
The AC Name with Priority message element is sent by the AC to the The AC Name with Priority message element is sent by the AC to the
WTP to configure preferred ACs. The number of instances of this WTP to configure preferred ACs. The number of instances of this
message element is equal to the number of ACs configured on the WTP. message element is equal to the number of ACs configured on the WTP.
The WTP also uses this message element to send its configuration to The WTP also uses this message element to send its configuration to
the AC. the AC.
skipping to change at page 66, line 34 skipping to change at page 66, line 5
Type: 5 for AC Name with Priority Type: 5 for AC Name with Priority
Length: >= 2 Length: >= 2
Priority: A value between 1 and 255 specifying the priority order Priority: A value between 1 and 255 specifying the priority order
of the preferred AC. For instance, the value of one (1) is used of the preferred AC. For instance, the value of one (1) is used
to set the primary AC, the value of two (2) is used to set the to set the primary AC, the value of two (2) is used to set the
secondary, etc. secondary, etc.
AC Name: A variable length UTF-8 encoded string [RFC3629] AC Name: A variable-length UTF-8 encoded string [RFC3629]
containing the AC name, whose maximum size MUST NOT exceed 512 containing the AC name, whose maximum size MUST NOT exceed 512
bytes. bytes.
4.6.6. AC Timestamp 4.6.6. AC Timestamp
The AC Timestamp message element is sent by the AC to synchronize the The AC Timestamp message element is sent by the AC to synchronize the
WTP clock. WTP clock.
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 67, line 4 skipping to change at page 66, line 19
4.6.6. AC Timestamp 4.6.6. AC Timestamp
The AC Timestamp message element is sent by the AC to synchronize the The AC Timestamp message element is sent by the AC to synchronize the
WTP clock. WTP clock.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 6 for AC Timestamp Type: 6 for AC Timestamp
Length: 4 Length: 4
Timestamp: The AC's current time, allowing all of the WTPs to be Timestamp: The AC's current time, allowing all of the WTPs to be
time synchronized in the format defined by Network Time Protocol time synchronized in the format defined by Network Time Protocol
(NTP) in RFC 1305 [RFC1305]. Only the most significant 32 bits of (NTP) in RFC 1305 [RFC1305]. Only the most significant 32 bits of
the NTP time is included in this field. the NTP time are included in this field.
4.6.7. Add MAC ACL Entry 4.6.7. Add MAC ACL Entry
The Add MAC Access Control List (ACL) Entry message element is used The Add MAC Access Control List (ACL) Entry message element is used
by an AC to add a MAC ACL list entry on a WTP, ensuring that the WTP by an AC to add a MAC ACL list entry on a WTP, ensuring that the WTP
no longer provides service to the MAC addresses provided in the no longer provides service to the MAC addresses provided in the
message. The MAC Addresses provided in this message element are not message. The MAC addresses provided in this message element are not
expected to be saved in non-volatile memory on the WTP. The MAC ACL expected to be saved in non-volatile memory on the WTP. The MAC ACL
table on the WTP is cleared everytime the WTP establishes a new table on the WTP is cleared everytime the WTP establishes a new
session with an AC. session with an AC.
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: 7 for Add MAC ACL Entry Type: 7 for Add MAC ACL Entry
Length: >= 8 Length: >= 8
Num of Entries: The number of instances of the Length/MAC Addresses Num of Entries: The number of instances of the Length/MAC Address
fields in the array. This value MUST NOT exceed 255. fields in the array. This value MUST NOT exceed 255.
Length: The length of the MAC Address field. The following formats, Length: The length of the MAC Address field. The formats and
and lengths, are supported [EUI-48] and [EUI-64]. lengths specified in [EUI-48] and [EUI-64] are supported.
MAC Address: MAC Addresses to add to the ACL. MAC Address: MAC addresses to add to the ACL.
4.6.8. Add Station 4.6.8. Add Station
The Add Station message element is used by the AC to inform a WTP The Add Station message element is used by the AC to inform a WTP
that it should forward traffic for a station. The Add Station that it should forward traffic for a station. The Add Station
message element is accompanied by technology specific binding message element is accompanied by technology-specific binding
information element(s) which may include security parameters. information element(s), which may include security parameters.
Consequently, the security parameters MUST be applied by the WTP for Consequently, the security parameters MUST be applied by the WTP for
the station. the station.
After station policy has been delivered to the WTP through the Add After station policy has been delivered to the WTP through the Add
Station message element, an AC MAY change any policies by sending a Station message element, an AC MAY change any policies by sending a
modified Add Station message element. When a WTP receives an Add modified Add Station message element. When a WTP receives an Add
Station message element for an existing station, it MUST override any Station message element for an existing station, it MUST override any
existing state for the station. existing state for the station.
0 1 2 3 0 1 2 3
skipping to change at page 68, line 23 skipping to change at page 67, line 40
| VLAN Name... | VLAN Name...
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Type: 8 for Add Station Type: 8 for Add Station
Length: >= 8 Length: >= 8
Radio ID: An 8-bit value representing the radio, whose value is Radio ID: An 8-bit value representing the radio, whose value is
between one (1) and 31. between one (1) and 31.
Length: The length of the MAC Address field. The following formats, Length: The length of the MAC Address field. The formats and
and lengths, are supported [EUI-48] and [EUI-64]. lengths specified in [EUI-48] and [EUI-64] are supported.
MAC Address: The station's MAC Address MAC Address: The station's MAC address.
VLAN Name: An optional variable length UTF-8 encoded VLAN Name: An optional variable-length UTF-8 encoded string
string[RFC3629], with a maximum length of 512 octets, containing [RFC3629], with a maximum length of 512 octets, containing the
the VLAN Name on which the WTP is to locally bridge user data. VLAN Name on which the WTP is to locally bridge user data. Note
Note this field is only valid with WTPs configured in Local MAC this field is only valid with WTPs configured in Local MAC mode.
mode.
4.6.9. CAPWAP Control IPv4 Address 4.6.9. CAPWAP Control IPv4 Address
The CAPWAP Control IPv4 Address message element is sent by the AC to The CAPWAP Control IPv4 Address message element is sent by the AC to
the WTP during the discovery process and is used by the AC to provide the WTP during the Discovery process and is used by the AC to provide
the interfaces available on the AC, and the current number of WTPs the interfaces available on the AC, and the current number of WTPs
connected. When multiple CAPWAP Control IPV4 Address message connected. When multiple CAPWAP Control IPV4 Address message
elements are returned, the WTP SHOULD perform load balancing across elements are returned, the WTP SHOULD perform load balancing across
the multiple interfaces (see Section 6.1). the multiple interfaces (see Section 6.1).
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 69, line 4 skipping to change at page 68, line 21
elements are returned, the WTP SHOULD perform load balancing across elements are returned, the WTP SHOULD perform load balancing across
the multiple interfaces (see Section 6.1). the multiple interfaces (see Section 6.1).
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Count | | WTP Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 10 for CAPWAP Control IPv4 Address Type: 10 for CAPWAP Control IPv4 Address
Length: 6 Length: 6
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,
with a maximum value of 65535. with a maximum value of 65535.
4.6.10. CAPWAP Control IPv6 Address 4.6.10. CAPWAP Control IPv6 Address
The CAPWAP Control IPv6 Address message element is sent by the AC to The CAPWAP Control IPv6 Address message element is sent by the AC to
the WTP during the discovery process and is used by the AC to provide the WTP during the Discovery process and is used by the AC to provide
the interfaces available on the AC, and the current number of WTPs the interfaces available on the AC, and the current number of WTPs
connected. This message element is useful for the WTP to perform connected. This message element is useful for the WTP to perform
load balancing across multiple interfaces (see Section 6.1). load balancing across multiple interfaces (see Section 6.1).
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address | | IP Address |
skipping to change at page 69, line 34 skipping to change at page 69, line 4
| IP Address | | IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address | | IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address | | IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address | | IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Count | | WTP Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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,
with a maximum value of 65535. with a maximum value of 65535.
4.6.11. CAPWAP Local IPv4 Address 4.6.11. 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, in the Join Request, or by the AC, in the Join Response. The WTP, in the Join Request, or by the AC, in the Join Response. The
CAPWAP Local IPv4 Address message element is used to communicate the CAPWAP Local IPv4 Address message element is used to communicate the
IP Address of the transmitter. The receiver uses this to determine IP Address of the transmitter. The receiver uses this to determine
skipping to change at page 70, line 16 skipping to change at page 69, line 33
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: 30 for CAPWAP Local IPv4 Address Type: 30 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.12. CAPWAP Local IPv6 Address 4.6.12. 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, in the Join Request, or by the AC, in the Join Response. The WTP, in the Join Request, or by the AC, in the Join Response. The
CAPWAP Local IPv6 Address message element is used to communicate the CAPWAP Local IPv6 Address message element is used to communicate the
IP Address of the transmitter. The receiver uses this to determine IP Address of the transmitter. The receiver uses this to determine
whether a middlebox exists between the two peers, by comparing the whether a middlebox exists between the two peers, by comparing the
source IP address of the packet against the value of the message source IP address of the packet against the value of the message
element. element.
skipping to change at page 70, line 44 skipping to change at page 70, line 21
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address | | IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address | | IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 50 for CAPWAP Local IPv6 Address Type: 50 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.13. CAPWAP Timers 4.6.13. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 12 for CAPWAP Timers Type: 12 for CAPWAP Timers
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. This value is used to when the WTP is in the Discovery phase. This value is used to
configure the MaxDiscoveryInterval timer (see Section 4.7.10). configure the MaxDiscoveryInterval timer (see Section 4.7.10).
Echo Request: The number of seconds between WTP Echo Request CAPWAP Echo Request: The number of seconds between WTP Echo Request CAPWAP
messages. This value is used to configure the EchoInterval timer messages. This value is used to configure the EchoInterval timer
(see Section 4.7.7). The AC sets its EchoInterval timer to this (see Section 4.7.7). The AC sets its EchoInterval timer to this
value, plus the maximum retransmission time as described in value, plus the maximum retransmission time as described in
Section 4.5.3. Section 4.5.3.
4.6.14. CAPWAP Transport Protocol 4.6.14. CAPWAP Transport Protocol
skipping to change at page 72, line 15 skipping to change at page 71, line 41
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Transport | | Transport |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Type: 51 for CAPWAP Transport Protocol Type: 51 for CAPWAP Transport Protocol
Length: 1 Length: 1
Transport: The transport to use for the CAPWAP data channel. The Transport: The transport to use for the CAPWAP Data channel. The
following enumerated values are supported: following enumerated values are supported:
1 - UDP-Lite: The UDP-Lite transport protocol is to be used for 1 - UDP-Lite: The UDP-Lite transport protocol is to be used for
the CAPWAP data channel. Note that this option MUST NOT be the CAPWAP Data channel. Note that this option MUST NOT be
used if the CAPWAP control channel is being used over IPv4. used if the CAPWAP Control channel is being used over IPv4.
2 - UDP: The UDP transport protocol is to be used for the CAPWAP 2 - UDP: The UDP transport protocol is to be used for the CAPWAP
data channel. Data channel.
4.6.15. Data Transfer Data 4.6.15. 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Type | Data Mode | Data Length | | Data Type | Data Mode | Data Length |
skipping to change at page 72, line 45 skipping to change at page 72, line 25
| Data .... | Data ....
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Type: 13 for Data Transfer Data Type: 13 for Data Transfer Data
Length: >= 5 Length: >= 5
Data Type: An 8-bit value representing the transfer Data Type. The Data Type: An 8-bit value representing the transfer Data Type. The
following enumerated values are supported: following enumerated values are supported:
1 - Transfer data is included 1 - Transfer data is included.
2 - Last Transfer Data Block is included (EOF) 2 - Last Transfer Data Block is included (End of File (EOF)).
5 - An error occurred. Transfer is aborted 5 - An error occurred. Transfer is aborted.
Data Mode: An 8-bit value the type of information being
Data Mode: An 8-bit value describing the type of information being
transmitted. The following enumerated values are supported: transmitted. The following enumerated values are supported:
0 - Reserved 0 - Reserved
1 - WTP Crash Data 1 - WTP Crash Data
2 - WTP Memory Dump 2 - WTP Memory Dump
Data Length: Length of data field, with a maximum size of 65535. Data Length: Length of data field, with a maximum size of 65535.
skipping to change at page 73, line 34 skipping to change at page 73, line 21
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Data Mode | | Data Mode |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Type: 14 for Data Transfer Mode Type: 14 for Data Transfer Mode
Length: 1 Length: 1
Data Mode: An 8-bit value the type of information being requested. Data Mode: An 8-bit value describing the type of information being
The following enumerated values are supported: requested. The following enumerated values are supported:
0 - Reserved 0 - Reserved
1 - WTP Crash Data 1 - WTP Crash Data
2 - WTP Memory Dump 2 - WTP Memory Dump
4.6.17. Decryption Error Report 4.6.17. Decryption Error Report
The Decryption Error Report message element value is used by the WTP The Decryption Error Report message element value is used by the WTP
skipping to change at page 74, line 18 skipping to change at page 73, line 50
| Radio ID |Num Of Entries | Length | MAC Address... | Radio ID |Num Of Entries | Length | MAC Address...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 15 for Decryption Error Report Type: 15 for Decryption Error Report
Length: >= 9 Length: >= 9
Radio ID: The Radio Identifier refers to an interface index on the Radio ID: The Radio Identifier refers to an interface index on the
WTP, whose value is between one (1) and 31. WTP, whose value is between one (1) and 31.
Num of Entries: The number of instances of the Length/MAC Addresses Num of Entries: The number of instances of the Length/MAC Address
fields in the array. This field MUST NOT exceed the value of 255. fields in the array. This field MUST NOT exceed the value of 255.
Length: The length of the MAC Address field. The following formats, Length: The length of the MAC Address field. The formats and
and lengths, are supported [EUI-48] and [EUI-64]. lengths specified in [EUI-48] and [EUI-64] are supported.
MAC Address: MAC addresses of the station that has caused MAC Address: MAC address of the station that has caused decryption
decryption errors. errors.
4.6.18. Decryption Error Report Period 4.6.18. Decryption Error Report Period
The Decryption Error Report Period message element value is used by The Decryption Error Report Period message element value is used by
the AC to inform the WTP how frequently it should send decryption the AC to inform the WTP how frequently it should send decryption
error report messages. Note that this error reporting mechanism is error report messages. Note that this error reporting mechanism is
not used if encryption and decryption services are provided in the not used if encryption and decryption services are provided in the
AC. AC.
0 1 2 0 1 2
skipping to change at page 75, line 20 skipping to change at page 75, line 4
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: 17 for Delete MAC ACL Entry Type: 17 for Delete MAC ACL Entry
Length: >= 8 Length: >= 8
Num of Entries: The number of instances of the Length/MAC Address
Num of Entries: The number of instances of the Length/MAC Addresses
fields in the array. This field MUST NOT exceed the value of 255. fields in the array. This field MUST NOT exceed the value of 255.
Length: The length of the MAC Address field. The following formats, Length: The length of the MAC Address field. The formats and
and lengths, are supported [EUI-48] and [EUI-64]. lengths specified in [EUI-48] and [EUI-64] are supported.
MAC Address: An array of MAC Addresses to delete from the ACL. MAC Address: An array of MAC addresses to delete from the ACL.
4.6.20. Delete Station 4.6.20. Delete Station
The Delete Station message element is used by the AC to inform a WTP The Delete Station message element is used by the AC to inform a WTP
that it should no longer provide service to a particular station. that it should no longer provide service to a particular station.
The WTP MUST terminate service to the station immediately upon The WTP MUST terminate service to the station immediately upon
receiving this message element. receiving this message element.
The transmission of a Delete Station message element could occur for The transmission of a Delete Station message element could occur for
various reasons, including for administrative reasons, or if the various reasons, including for administrative reasons, or if the
skipping to change at page 76, line 4 skipping to change at page 75, line 34
Event Request message, to inform the AC that a particular station is Event Request message, to inform the AC that a particular station is
no longer being provided service. This could occur as a result of an no longer being provided service. This could occur as a result of an
Idle Timeout (see section 4.4.43), due to internal resource shortages Idle Timeout (see section 4.4.43), due to internal resource shortages
or for some other reason. or for some other reason.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Length | MAC Address... | Radio ID | Length | MAC Address...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 18 for Delete Station Type: 18 for Delete Station
Length: >= 8 Length: >= 8
Radio ID: An 8-bit value representing the radio, whose value is Radio ID: An 8-bit value representing the radio, whose value is
between one (1) and 31. between one (1) and 31.
Length: The length of the MAC Address field. The following formats, Length: The length of the MAC Address field. The formats and
and lengths, are supported [EUI-48] and [EUI-64]. lengths specified in [EUI-48] and [EUI-64] are supported.
MAC Address: The station's MAC Address MAC Address: The station's MAC address.
4.6.21. Discovery Type 4.6.21. Discovery Type
The Discovery Type message element is used by the WTP to indicate how The Discovery Type message element is used by the WTP to indicate how
it has come to know about the existence of the AC to which it is it has come to know about the existence of the AC to which it is
sending the Discovery Request message. sending the Discovery Request message.
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
skipping to change at page 77, line 7 skipping to change at page 76, line 37
the AC IPv4 List or AC IPv6 List message element) the AC IPv4 List or AC IPv6 List message element)
4.6.22. Duplicate IPv4 Address 4.6.22. Duplicate IPv4 Address
The Duplicate IPv4 Address message element is used by a WTP to inform The Duplicate IPv4 Address message element is used by a WTP to inform
an AC that it has detected another IP device using the same IP an AC that it has detected another IP device using the same IP
address that the WTP is currently using. address that the WTP is currently using.
The WTP MUST transmit this message element with the status set to 1 The WTP MUST transmit this message element with the status set to 1
after it has detected a duplicate IP address. When the WTP detects after it has detected a duplicate IP address. When the WTP detects
that the duplicate IP address has been cleared, it MUSY send this that the duplicate IP address has been cleared, it MUST send this
message element with the status set to 0. message element with the status set to 0.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Length | MAC Address ... | Status | Length | MAC Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 21 for Duplicate IPv4 Address Type: 21 for Duplicate IPv4 Address
Length: >= 12 Length: >= 12
IP Address: The IP Address currently used by the WTP. IP Address: The IP address currently used by the WTP.
Status: The status of the duplicate IP address. The value MUST be Status: The status of the duplicate IP address. The value MUST be
set to 1 when a duplicate address is detected, and 0 when the set to 1 when a duplicate address is detected, and 0 when the
duplicate address has been cleared. duplicate address has been cleared.
Length: The length of the MAC Address field. The following formats, Length: The length of the MAC Address field. The formats and
and lengths, are supported [EUI-48] and [EUI-64]. lengths specified in [EUI-48] and [EUI-64] are supported.
MAC Address: The MAC Address of the offending device. MAC Address: The MAC address of the offending device.
4.6.23. Duplicate IPv6 Address 4.6.23. Duplicate IPv6 Address
The Duplicate IPv6 Address message element is used by a WTP to inform The Duplicate IPv6 Address message element is used by a WTP to inform
an AC that it has detected another host using the same IP address an AC that it has detected another host using the same IP address
that the WTP is currently using. that the WTP is currently using.
The WTP MUST transmit this message element with the status set to 1 The WTP MUST transmit this message element with the status set to 1
after it has detected a duplicate IP address. When the WTP detects after it has detected a duplicate IP address. When the WTP detects
that the duplicate IP address has been cleared, it MUST send this that the duplicate IP address has been cleared, it MUST send this
skipping to change at page 78, line 23 skipping to change at page 77, line 43
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address | | IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Length | MAC Address ... | Status | Length | MAC Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 22 for Duplicate IPv6 Address Type: 22 for Duplicate IPv6 Address
Length: >= 24 Length: >= 24
IP Address: The IP Address currently used by the WTP. IP Address: The IP address currently used by the WTP.
Status: The status of the duplicate IP address. The value MUST be Status: The status of the duplicate IP address. The value MUST be
set to 1 when a duplicate address is detected, and 0 when the set to 1 when a duplicate address is detected, and 0 when the
duplicate address has been cleared. duplicate address has been cleared.
Length: The length of the MAC Address field. The following formats, Length: The length of the MAC Address field. The formats and
and lengths, are supported [EUI-48] and [EUI-64]. lengths specified in [EUI-48] and [EUI-64] are supported.
MAC Address: The MAC Address of the offending device. MAC Address: The MAC address of the offending device.
4.6.24. Idle Timeout 4.6.24. Idle Timeout
The Idle Timeout message element is sent by the AC to the WTP to The Idle Timeout message element is sent by the AC to the WTP to
provide the idle timeout value that the WTP SHOULD enforce for its provide the Idle Timeout value that the WTP SHOULD enforce for its
active stations. The value applies to all radios on the WTP. active stations. The value applies to all radios 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timeout | | Timeout |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 23 for Idle Timeout Type: 23 for Idle Timeout
Length: 4 Length: 4
Timeout: The current idle timeout, in seconds, to be enforced by
Timeout: The current Idle Timeout, in seconds, to be enforced by
the WTP. The default value for this message element is specified the WTP. The default value for this message element is specified
in Section 4.7.8. in Section 4.7.8.
4.6.25. ECN Support 4.6.25. ECN Support
The ECN Support message element is sent by both the WTP and the AC to The ECN Support message element is sent by both the WTP and the AC to
indicate their support for the Explicit Congestion Notification (ECN) indicate their support for the Explicit Congestion Notification (ECN)
bits, as defined in [RFC3168]. bits, as defined in [RFC3168].
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| ECN Support | | ECN Support |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Type: 53 for ECN Support Type: 53 for ECN Support
Length: 1 Length: 1
ECN Support: An 8-bit value representing the sender's support for ECN Support: An 8-bit value representing the sender's support for
ECN, as defined in [RFC3168]. ECN, as defined in [RFC3168]. All CAPWAP Implementations MUST
support the Limited ECN Support mode. Full ECN Support is used if
both the WTP and AC advertise the capability for "Full and Limited
ECN" Support; otherwise, Limited ECN Support is used.
0 - Limited ECN Support 0 - Limited ECN Support
1 - Full and Limited ECN Support 1 - Full and Limited ECN Support
4.6.26. Image Data 4.6.26. Image Data
The Image Data message element is present in the Image Data Request The Image Data message element is present in the Image Data Request
message sent by the AC and contains the following fields. message sent by the AC and contains the following fields.
skipping to change at page 80, line 5 skipping to change at page 79, line 23
| Data Type | Data .... | Data Type | Data ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 24 for Image Data Type: 24 for Image Data
Length: >= 1 Length: >= 1
Data Type: An 8-bit value representing the image Data Type. The Data Type: An 8-bit value representing the image Data Type. The
following enumerated values are supported: following enumerated values are supported:
1 - Image data is included 1 - Image data is included.
2 - Last Image Data Block is included (EOF) 2 - Last Image Data Block is included (EOF).
5 - An error occurred. Transfer is aborted 5 - An error occurred. Transfer is aborted.
Data: The Image Data field contains up to 1024 characters, and its Data: The Image Data field contains up to 1024 characters, and its
length is inferred from this message element's length field. If length is inferred from this message element's length field. If
the block being sent is the last one, the Data Type field is set the block being sent is the last one, the Data Type field is set
to 2. The AC MAY opt to abort the data transfer by setting the to 2. The AC MAY opt to abort the data transfer by setting the
Data Type field to 5. When the Data Type field is 5, the Value Data Type field to 5. When the Data Type field is 5, the Value
field has a zero length. field has a zero length.
4.6.27. Image Identifier 4.6.27. Image Identifier
The Image Identifier message element is sent by the AC to the WTP to The Image Identifier message element is sent by the AC to the WTP to
indicate the expected active software version that is to be run on indicate the expected active software version that is to be run on
the WTP. The WTP sends the Image Identifier message element in order the WTP. The WTP sends the Image Identifier message element in order
to request a specific software version from the AC. The actual to request a specific software version from the AC. The actual
download process is defined in Section 9.1. The value is a variable download process is defined in Section 9.1. The value is a variable-
length UTF-8 encoded string [RFC3629], which is NOT zero terminated. length UTF-8 encoded string [RFC3629], which is NOT zero terminated.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data... | Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 25 for Image Identifier Type: 25 for Image Identifier
Length: >= 5 Length: >= 5
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" Network Management Private Enterprise Codes".
Data: A variable length UTF-8 encoded string [RFC3629] containing Data: A variable-length UTF-8 encoded string [RFC3629] containing
the firmware identifier to be run on the WTP, whose length MUST the firmware identifier to be run on the WTP, whose length MUST
NOT exceed 1024 octets. The length of this field is inferred from NOT exceed 1024 octets. The length of this field is inferred from
this message element's length field. this message element's length field.
4.6.28. Image Information 4.6.28. Image Information
The Image Information message element is present in the Image Data The Image Information message element is present in the Image Data
Response message sent by the AC to the WTP and contains the following Response message sent by the AC to the WTP and contains the following
fields. fields.
skipping to change at page 81, line 26 skipping to change at page 80, line 43
| Hash | | Hash |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 26 for Image Information Type: 26 for Image Information
Length: 20 Length: 20
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 transferred by the AC to the WTP. bytes, that will be transferred by the AC to the WTP.
Hash: A 16 octet MD5 hash of the image using the procedures defined Hash: A 16-octet MD5 hash of the image using the procedures defined
in [RFC1321]. in [RFC1321].
4.6.29. Initiate Download 4.6.29. Initiate Download
The Initiate Download message element is used by the WTP to inform The Initiate Download message element is used by the WTP to inform
the AC that the AC SHOULD initiate a firmware upgrade. The AC the AC that the AC SHOULD initiate a firmware upgrade. The AC
subsequently transmits an Image Data Request message which includes subsequently transmits an Image Data Request message, which includes
the Image Data message element. This message element does not the Image Data message element. This message element does not
contain any data. contain any data.
Type: 27 for Initiate Download Type: 27 for Initiate Download
Length: 0 Length: 0
4.6.30. Location Data 4.6.30. Location Data
The Location Data message element is a variable length byte UTF-8 The Location Data message element is a variable-length byte UTF-8
encoded string [RFC3629] containing user defined location information encoded string [RFC3629] containing user-defined location information
(e.g. "Next to Fridge"). This information is configurable by the (e.g., "Next to Fridge"). This information is configurable by the
network administrator, and allows the WTP location to be determined. network administrator, and allows the WTP location to be determined.
The string is not zero terminated. The string is not zero terminated.
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-
| Location ... | Location ...
+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-
Type: 28 for Location Data Type: 28 for Location Data
Length: >= 1 Length: >= 1
Location: A non-zero terminated UTF-8 encoded string [RFC3629] Location: A non-zero-terminated UTF-8 encoded string [RFC3629]
containing the WTP location, whose maximum size MUST NOT exceed containing the WTP location, whose maximum size MUST NOT exceed
1024. 1024.
4.6.31. Maximum Message Length 4.6.31. Maximum Message Length
The Maximum Message Length message element is included in the Join The Maximum Message Length message element is included in the Join
Request message by the WTP to indicate the maximum CAPWAP message Request message by the WTP to indicate the maximum CAPWAP message
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
skipping to change at page 82, line 29 skipping to change at page 82, 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Message Length | | Maximum Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 29 for Maximum Message Length Type: 29 for Maximum Message Length
Length: 2 Length: 2
Maximum Message Length An 16-bit unsigned integer indicating the Maximum Message Length A 16-bit unsigned integer indicating the
maximum message length. maximum message length.
4.6.32. MTU Discovery Padding 4.6.32. MTU Discovery Padding
The MTU Discovery Padding message element is used as padding to The MTU Discovery Padding message element is used as padding to
perform MTU discovery, and MUST contain octets of value 0xFF, of any perform MTU discovery, and MUST contain octets of value 0xFF, of any
length. length.
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
skipping to change at page 83, line 4 skipping to change at page 82, line 22
The MTU Discovery Padding message element is used as padding to The MTU Discovery Padding message element is used as padding to
perform MTU discovery, and MUST contain octets of value 0xFF, of any perform MTU discovery, and MUST contain octets of value 0xFF, of any
length. length.
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Padding... | Padding...
+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-
Type: 52 for MTU Discovery Padding Type: 52 for MTU Discovery Padding
Length: variable Length: Variable
Pad: A variable length pad, filled with the value 0xFF. Pad: A variable-length pad, filled with the value 0xFF.
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
message element is sent by the AC to change the state of the WTP. message element is sent by the AC to change the state of the WTP.
The WTP saves the value, to ensure that it remains across WTP resets. The WTP saves the value, to ensure that it remains across WTP resets.
The WTP communicates this message element during the configuration The WTP communicates this message element during the configuration
phase, in the Configuration Status Request message, to ensure that AC phase, in the Configuration Status Request message, to ensure that
has the WTP radio current administrative state settings. The message the AC has the WTP radio current administrative state settings. The
element contains the following fields. message element contains the following fields:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Admin State | | Radio ID | Admin State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 31 for Radio Administrative State Type: 31 for Radio Administrative State
Length: 2 Length: 2
skipping to change at page 84, line 33 skipping to change at page 83, line 49
Type: 32 for Radio Operational State Type: 32 for Radio Operational State
Length: 3 Length: 3
Radio ID: The Radio Identifier refers to an interface index on the Radio ID: The Radio Identifier refers to an interface index on the
WTP, whose value is between one (1) and 31. A value of 0xFF is WTP, whose value is between one (1) and 31. A value of 0xFF is
invalid, as it is not possible to change the WTP's operational invalid, as it is not possible to change the WTP's operational
state. state.
State: An 8-bit boolean value representing the state of the radio. State: An 8-bit Boolean value representing the state of the radio.
The following enumerated values are supported: The following enumerated values are supported:
0 - Reserved 0 - Reserved
1 - Enabled 1 - Enabled
2 - Disabled 2 - Disabled
Cause: When a radio is inoperable, the cause field contains the Cause: When a radio is inoperable, the cause field contains the
reason the radio is out of service. The following enumerated reason the radio is out of service. The following enumerated
skipping to change at page 85, line 4 skipping to change at page 84, line 18
2 - Disabled 2 - Disabled
Cause: When a radio is inoperable, the cause field contains the Cause: When a radio is inoperable, the cause field contains the
reason the radio is out of service. The following enumerated reason the radio is out of service. The following enumerated
values are supported: values are supported:
0 - Normal 0 - Normal
1 - Radio Failure 1 - Radio Failure
2 - Software Failure 2 - Software Failure
3 - Administratively Set 3 - Administratively Set
4.6.35. Result Code 4.6.35. Result Code
The Result Code message element value is a 32-bit integer value, The Result Code message element value is a 32-bit integer value,
indicating the result of the Request message corresponding to the indicating the result of the Request message corresponding to the
Sequence Number included in the Response message. sequence number included in the Response message.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | | Result Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 33 for Result Code Type: 33 for Result Code
Length: 4 Length: 4
Result Code: The following enumerated values are defined: Result Code: The following enumerated values are defined:
0 Success 0 Success
1 Failure (AC List message element MUST be present) 1 Failure (AC List Message Element MUST Be Present)
2 Success (NAT detected) 2 Success (NAT Detected)
3 Join Failure (unspecified) 3 Join Failure (Unspecified)
4 Join Failure (Resource Depletion) 4 Join Failure (Resource Depletion)
5 Join Failure (Unknown Source) 5 Join Failure (Unknown Source)
6 Join Failure (Incorrect Data) 6 Join Failure (Incorrect Data)
7 Join Failure (Session ID already in use) 7 Join Failure (Session ID Already in Use)
8 Join Failure (WTP Hardware not supported) 8 Join Failure (WTP Hardware Not Supported)
9 Join Failure (Binding Not Supported) 9 Join Failure (Binding Not Supported)
10 Reset Failure (Unable to Reset) 10 Reset Failure (Unable to Reset)
11 Reset Failure (Firmware Write Error) 11 Reset Failure (Firmware Write Error)
12 Configuration Failure (Unable to Apply Requested Configuration 12 Configuration Failure (Unable to Apply Requested Configuration
- Service Provided Anyhow) - Service Provided Anyhow)
13 Configuration Failure (Unable to Apply Requested Configuration 13 Configuration Failure (Unable to Apply Requested Configuration
- Service Not Provided) - Service Not Provided)
14 Image Data Error (Invalid Checksum) 14 Image Data Error (Invalid Checksum)
15 Image Data Error (Invalid Data Length) 15 Image Data Error (Invalid Data Length)
skipping to change at page 86, line 18 skipping to change at page 85, line 30
- Service Not Provided) - Service Not Provided)
14 Image Data Error (Invalid Checksum) 14 Image Data Error (Invalid Checksum)
15 Image Data Error (Invalid Data Length) 15 Image Data Error (Invalid Data Length)
16 Image Data Error (Other Error) 16 Image Data Error (Other Error)
17 Image Data Error (Image Already Present) 17 Image Data Error (Image Already Present)
18 Message Unexpected (Invalid in current state) 18 Message Unexpected (Invalid in Current State)
19 Message Unexpected (Unrecognized Request) 19 Message Unexpected (Unrecognized Request)
20 Failure - Missing Mandatory Message Element 20 Failure - Missing Mandatory Message Element
21 Failure - Unrecognized Message Element 21 Failure - Unrecognized Message Element
22 Data Transfer Error (No Information to Transfer) 22 Data Transfer Error (No Information to Transfer)
4.6.36. Returned Message Element 4.6.36. Returned Message Element
skipping to change at page 86, line 47 skipping to change at page 86, line 15
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason | Length | Message Element... | Reason | Length | Message Element...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 34 for Returned Message Element Type: 34 for Returned Message Element
Length: >= 6 Length: >= 6
Reason: The reason why the configuration in the offending message Reason: The reason the configuration in the offending message
element could not be applied by the WTP. The following enumerated element could not be applied by the WTP. The following enumerated
values are supported: values are supported:
0 - Reserved 0 - Reserved
1 - Unknown Message Element 1 - Unknown Message Element
2 - Unsupported Message Element 2 - Unsupported Message Element
3 - Unknown Message Element Value 3 - Unknown Message Element Value
skipping to change at page 88, line 22 skipping to change at page 87, line 34
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 Vendor vendor-specific information between the WTP and the AC. The Vendor
Specific Payload message element MAY be present in any CAPWAP Specific Payload message element MAY be present in any CAPWAP
message. The exchange of vendor specific data between the MUST NOT message. The exchange of vendor-specific data between the MUST NOT
modify the behavior of the base CAPWAP protocol and state machine. modify the behavior of the base CAPWAP protocol and state machine.
The message element uses the following format: 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 | Data... | Element ID | Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 37 for Vendor Specific Payload Type: 37 for Vendor Specific Payload
Length: >= 7 Length: >= 7
Vendor Identifier: A 32-bit value containing the IANA-assigned "SMI
Network Management Private Enterprise Codes" [RFC3232].
Vendor Identifier: A 32-bit value containing the IANA assigned "SMI Element ID: A 16-bit Element Identifier that is managed by the
Network Management Private Enterprise Codes" [RFC3232]
Element ID: A 16-bit Element Identifier which is managed by the
vendor. vendor.
Data: Variable length vendor specific information, whose contents Data: Variable-length vendor-specific information, whose contents
and format are proprietary and understood based on the Element ID and format are proprietary and understood based on the Element ID
field. This field MUST NOT exceed 2048 octets. field. This field MUST NOT exceed 2048 octets.
4.6.40. WTP Board Data 4.6.40. WTP Board Data
The WTP Board Data message element is sent by the WTP to the AC and The WTP Board Data message element is sent by the WTP to the AC and
contains information about the hardware present. contains information about the hardware present.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Board Data Sub-Element... | Board Data Sub-Element...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 38 for WTP Board Data Type: 38 for WTP Board Data
Length: >=14 Length: >=14
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", identifying the WTP Network Management Private Enterprise Codes", identifying the WTP
hardware manufacturer. The Vendor Identifier field MUST NOT be hardware manufacturer. The Vendor Identifier field MUST NOT be
set to zero. set to zero.
Board Data Sub-Element: The WTP Board Data message element contains Board Data Sub-Element: The WTP Board Data message element contains
multiple Board Data sub-elements, some of which are mandatory and multiple Board Data sub-elements, some of which are mandatory and
some are optional, as described below. The Board Data Type values some are optional, as described below. The Board Data Type values
are not extensible by vendors, and is therefore not coupled along are not extensible by vendors, and are therefore not coupled along
with the Vendor Identifier field. The Board Data sub-element has with the Vendor Identifier field. The Board Data sub-element has
the following format: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Board Data Type | Board Data Length | | Board Data Type | Board Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Board Data Value... | Board Data Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 89, line 41 skipping to change at page 89, line 4
with the Vendor Identifier field. The Board Data sub-element has with the Vendor Identifier field. The Board Data sub-element has
the following format: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Board Data Type | Board Data Length | | Board Data Type | Board Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Board Data Value... | Board Data Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Board Data Type: The Board Data Type field identifies the data Board Data Type: The Board Data Type field identifies the data
being encoded. The CAPWAP protocol defines the following being encoded. The CAPWAP protocol defines the following
values, and each of these types identify whether their presence values, and each of these types identify whether their presence
is mandatory or optional: is mandatory or optional:
0 - WTP Model Number: The WTP Model Number MUST be included 0 - WTP Model Number: The WTP Model Number MUST be included in
in the WTP Board Data message element. the WTP Board Data message element.
1 - WTP Serial Number: The WTP Serial Number MUST be included 1 - WTP Serial Number: The WTP Serial Number MUST be included in
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 message element. the WTP Board Data message element.
3 - Board Revision A revision number of the board, which MAY 3 - Board Revision: A revision number of the board, which MAY be
be included in the WTP Board Data message element. included in the WTP Board Data message element.
4 - Base MAC Address 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.
Board Data Length: The length of the data in the Board Data Board Data Length: The length of the data in the Board Data Value
Value field, whose length MUST NOT exceed 1024 octets. field, whose length MUST NOT exceed 1024 octets.
Board Data Value: The data associated with the Board Data Type Board Data Value: The data associated with the Board Data Type
field for this Board Data sub-element. field for this Board Data sub-element.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Radios | Radios in use | Num Encrypt |Encryp Sub-Elmt| | Max Radios | Radios in use | Num Encrypt |Encryp Sub-Elmt|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encryption Sub-Element | Descriptor Sub-Element... | Encryption Sub-Element | Descriptor Sub-Element...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 39 for WTP Descriptor Type: 39 for WTP Descriptor
skipping to change at page 90, line 40 skipping to change at page 90, line 4
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Radios | Radios in use | Num Encrypt |Encryp Sub-Elmt| | Max Radios | Radios in use | Num Encrypt |Encryp Sub-Elmt|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encryption Sub-Element | Descriptor Sub-Element... | Encryption Sub-Element | Descriptor Sub-Element...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 39 for WTP Descriptor Type: 39 for WTP Descriptor
Length: >= 33 Length: >= 33
Max Radios: An 8-bit value representing the number of radios (where Max Radios: An 8-bit value representing the number of radios (where
each radio is identified via the Radio ID field) supported by the each radio is identified via the Radio ID field) supported by the
WTP. WTP.
Radios in use: An 8-bit value representing the number of radios in Radios in use: An 8-bit value representing the number of radios in
use in the WTP. use in the WTP.
Num Encrypt: The number of 3 byte Encryption Sub-Elements that Num Encrypt: The number of 3-byte Encryption sub-elements that
follow this field. The value of the Num Encrypt field MUST be follow this field. The value of the Num Encrypt field MUST be
between one (1) and 255. between one (1) and 255.
Encryption Sub-Element: The WTP Descriptor message element MUST Encryption Sub-Element: The WTP Descriptor message element MUST
contain at least one Encryption sub-element. One sub-element is contain at least one Encryption sub-element. One sub-element is
present for each binding supported by the WTP. The Encryption present for each binding supported by the WTP. The Encryption
sub-element has the following format: sub-element has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Resvd| WBID | Encryption Capabilities | |Resvd| WBID | Encryption Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Resvd: The 3-bit field is reserved for future use. All Resvd: The 3-bit field is reserved for future use. All
implementations complying with this protocol MUST set to zero implementations complying with this protocol MUST set to zero
any bits that are reserved in the version of the protocol any bits that are reserved in the version of the protocol
supported by that implementation. Receivers MUST ignore all supported by that implementation. Receivers MUST ignore all
bits not defined for the version of the protocol they support. bits not defined for the version of the protocol they support.
WBID: A 5 bit field which is the wireless binding identifier. WBID: A 5-bit field that is the wireless binding identifier.
The identifier will indicate the type of wireless packet The identifier will indicate the type of wireless packet
associated with the radio. The WBIDs defined in this associated with the radio. The WBIDs defined in this
specification can be found in Section 4.3 specification can be found in Section 4.3.
Encryption Capabilities: This 16-bit field is used by the WTP to Encryption Capabilities: This 16-bit field is used by the WTP to
communicate its capabilities to the AC. A WTP that does not communicate its capabilities to the AC. A WTP that does not
have any encryption capabilities sets this field to zero (0). have any encryption capabilities sets this field to zero (0).
Refer to the specific wireless binding for further Refer to the specific wireless binding for further
specification of the Encryption Capabilities field. specification of the Encryption Capabilities field.
Descriptor Sub-Element: The WTP Descriptor message element contains Descriptor Sub-Element: The WTP Descriptor message element contains
multiple Descriptor sub-elements, some of which are mandatory and multiple Descriptor sub-elements, some of which are mandatory and
some are optional, as described below. The Descriptor sub-element some are optional, as described below. The Descriptor sub-element
skipping to change at page 91, line 48 skipping to change at page 91, line 15
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Descriptor Vendor Identifier | | Descriptor Vendor Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Descriptor Type | Descriptor Length | | Descriptor Type | Descriptor Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Descriptor Data... | Descriptor Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Descriptor Vendor Identifier: A 32-bit value containing the IANA Descriptor Vendor Identifier: A 32-bit value containing the
assigned "SMI Network Management Private Enterprise Codes". IANA-assigned "SMI Network Management Private Enterprise
Codes".
Descriptor Type: The Descriptor Type field identifies the data Descriptor Type: The Descriptor Type field identifies the data
being encoded. The format of the data is vendor specific being encoded. The format of the data is vendor-specific
encoded in the UTF-8 format [RFC3629]. The CAPWAP protocol encoded in the UTF-8 format [RFC3629]. The CAPWAP protocol
defines the following values, and each of these types identify defines the following values, and each of these types identify
whether their presence is mandatory or optional. The values whether their presence is mandatory or optional. The values
listed below are used in conjunction with the Descriptor Vendor listed below are used in conjunction with the Descriptor Vendor
Identifier field, whose value MUST be set to zero (0). This Identifier field, whose value MUST be set to zero (0). This
field, combined with the Descriptor Vendor Identifier set to a field, combined with the Descriptor Vendor Identifier set to a
non-zero (0) value, allows vendors to use a private namespace. non-zero (0) value, allows vendors to use a private namespace.
0 - Hardware Version: The WTP hardware version number MUST be 0 - Hardware Version: The WTP hardware version number MUST be
present. present.
1 - Active Software Version: The WTP running software version 1 - Active Software Version: The WTP running software version
number MUST be present. number MUST be present.
2 - Boot Version: The WTP boot loader version number MUST be 2 - Boot Version: The WTP boot loader version number MUST be
present. present.
3 - Other Software Version: The WTP non-running software 3 - Other Software Version: The WTP non-running software
(firmware) version number MAY be present. This type is used (firmware) version number MAY be present. This type is
to communicate alternate software versions that are used to communicate alternate software versions that are
available on the WTP's non-volatile storage. available on the WTP's non-volatile storage.
Descriptor Length: Length of vendor specific encoding of Descriptor Length: Length of the vendor-specific encoding of the
Descriptor Data field, whose length MUST NOT exceed 1024 Descriptor Data field, whose length MUST NOT exceed 1024
octets. octets.
Descriptor Data: Vendor specific data of WTP information encoded Descriptor Data: Vendor-specific data of WTP information encoded
in the UTF-8 format [RFC3629]. in the UTF-8 format [RFC3629].
4.6.42. WTP Fallback 4.6.42. WTP Fallback
The WTP Fallback message element is sent by the AC to the WTP to The WTP Fallback message element is sent by the AC to the WTP to
enable or disable automatic CAPWAP fallback in the event that a WTP enable or disable automatic CAPWAP fallback in the event that a WTP
detects its preferred AC, and is not currently connected to it. detects its preferred AC to which it is not currently connected.
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Mode | | Mode |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Type: 40 for WTP Fallback Type: 40 for WTP Fallback
Length: 1 Length: 1
Mode: The 8-bit value indicates the status of automatic CAPWAP Mode: The 8-bit value indicates the status of automatic CAPWAP
fallback on the WTP. When enabled, if the WTP detects that its fallback on the WTP. When enabled, if the WTP detects that its
primary AC is available, and that the WTP is not connected to the primary AC is available, and that the WTP is not connected to the
primary AC, the WTP SHOULD automatically disconnect from its primary AC, the WTP SHOULD automatically disconnect from its
current AC and reconnect to its primary AC. If disabled, the WTP current AC and reconnect to its primary AC. If disabled, the WTP
will only reconnect to its primary AC through manual intervention will only reconnect to its primary AC through manual intervention
(e.g., through the Reset Request message). The default value for (e.g., through the Reset Request message). The default value for
this field is specified in Section 4.8.9. The following this field is specified in Section 4.8.9. The following
skipping to change at page 93, line 25 skipping to change at page 92, line 40
0 - Reserved 0 - Reserved
1 - Enabled 1 - Enabled
2 - Disabled 2 - Disabled
4.6.43. WTP Frame Tunnel Mode 4.6.43. WTP Frame Tunnel Mode
The WTP Frame Tunnel Mode message element allows the WTP to The WTP Frame Tunnel Mode message element allows the WTP to
communicate the tunneling modes of operation which it supports to the communicate the tunneling modes of operation that it supports to the
AC. A WTP that advertises support for all types allows the AC to AC. A WTP that advertises support for all types allows the AC to
select which type will be used, based on its local policy. select which type will be used, based on its local policy.
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|Reservd|N|E|L|U| |Reservd|N|E|L|U|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Type: 41 for WTP Frame Tunnel Mode Type: 41 for WTP Frame Tunnel Mode
Length: 1 Length: 1
Reservd: A set of reserved bits for future use. All Reservd: A set of reserved bits for future use. All
implementations complying with this protocol MUST set to zero any implementations complying with this protocol MUST set to zero any
bits that are reserved in the version of the protocol supported by bits that are reserved in the version of the protocol supported by
that implementation. Receivers MUST ignore all bits not defined that implementation. Receivers MUST ignore all bits not defined
for the version of the protocol they support. for the version of the protocol they support.
skipping to change at page 94, line 4 skipping to change at page 93, line 17
Reservd: A set of reserved bits for future use. All Reservd: A set of reserved bits for future use. All
implementations complying with this protocol MUST set to zero any implementations complying with this protocol MUST set to zero any
bits that are reserved in the version of the protocol supported by bits that are reserved in the version of the protocol supported by
that implementation. Receivers MUST ignore all bits not defined that implementation. Receivers MUST ignore all bits not defined
for the version of the protocol they support. for the version of the protocol they support.
N: Native Frame Tunnel mode requires the WTP and AC to encapsulate N: Native Frame Tunnel mode requires the WTP and AC to encapsulate
all user payloads as native wireless frames, as defined by the all user payloads as native wireless frames, as defined by the
wireless binding (see for example Section 4.4) wireless binding (see for example Section 4.4)
E: The 802.3 Frame Tunnel Mode requires the WTP and AC to E: The 802.3 Frame Tunnel Mode requires the WTP and AC to
encapsulate all user payload as native IEEE 802.3 frames (see encapsulate all user payload as native IEEE 802.3 frames (see
Section 4.4). All user traffic is tunneled to the AC. This value Section 4.4). All user traffic is tunneled to the AC. This
MUST NOT be used when the WTP MAC Type is set to Split-MAC. value MUST NOT be used when the WTP MAC Type is set to Split
MAC.
L: When Local Bridging is used, the WTP does not tunnel user L: When Local Bridging is used, the WTP does not tunnel user
traffic to the AC; all user traffic is locally bridged. This traffic to the AC; all user traffic is locally bridged. This
value MUST NOT be used when the WTP MAC Type is set to Split-MAC. value MUST NOT be used when the WTP MAC Type is set to Split
MAC.
R: A reserved bit for future use. All implementations complying R: A reserved bit for future use. All implementations complying
with this protocol MUST set to zero any bits that are reserved in with this protocol MUST set to zero any bits that are reserved
the version of the protocol supported by that implementation. in the version of the protocol supported by that
Receivers MUST ignore all bits not defined for the version of the implementation. Receivers MUST ignore all bits not defined for
protocol they support. the version of the protocol they support.
4.6.44. WTP MAC Type 4.6.44. WTP MAC Type
The WTP MAC-Type message element allows the WTP to communicate its The WTP MAC-Type message element allows the WTP to communicate its
mode of operation to the AC. A WTP that advertises support for both mode of operation to the AC. A WTP that advertises support for both
modes allows the AC to select the mode to use, based on local policy. modes allows the AC to select the mode to use, based on local policy.
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
skipping to change at page 94, line 32 skipping to change at page 94, line 4
mode of operation to the AC. A WTP that advertises support for both mode of operation to the AC. A WTP that advertises support for both
modes allows the AC to select the mode to use, based on local policy. modes allows the AC to select the mode to use, based on local policy.
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| MAC Type | | MAC Type |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Type: 44 for WTP MAC Type Type: 44 for WTP MAC Type
Length: 1 Length: 1
MAC Type: The MAC mode of operation supported by the WTP. The MAC Type: The MAC mode of operation supported by the WTP. The
following enumerated values are supported: following enumerated values are supported:
0 - Local-MAC: Local-MAC is the default mode that MUST be 0 - Local MAC: Local MAC is the default mode that MUST be
supported by all WTPs. When tunneling is enabled (see supported by all WTPs. When tunneling is enabled (see
Section 4.6.43), the encapsulated frames MUST be in the 802.3 Section 4.6.43), the encapsulated frames MUST be in the
format (see Section 4.4.2), unless a wireless management or 802.3 format (see Section 4.4.2), unless a wireless
control frame which MAY be in its native format. Any CAPWAP management or control frame which MAY be in its native
binding needs to specify the format of management and control format. Any CAPWAP binding needs to specify the format of
wireless frames. management and control wireless frames.
1 - Split-MAC: Split-MAC support is optional, and allows the AC 1 - Split MAC: Split MAC support is optional, and allows the AC
to receive and process native wireless frames. to receive and process native wireless frames.
2 - Both: WTP is capable of supporting both Local-MAC and Split- 2 - Both: WTP is capable of supporting both Local MAC and Split
MAC. MAC.
4.6.45. WTP Name 4.6.45. WTP Name
The WTP Name message element is a variable length byte UTF-8 encoded The WTP Name message element is a variable-length byte UTF-8 encoded
string [RFC3629]. The string is not zero terminated. string [RFC3629]. The string is not zero terminated.
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-
| WTP Name ... | WTP Name ...
+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-
Type: 45 for WTP Name Type: 45 for WTP Name
Length: >= 1 Length: >= 1
WTP Name: A non-zero terminated UTF-8 encoded string [RFC3629] WTP Name: A non-zero-terminated UTF-8 encoded string [RFC3629]
containing the WTP name, whose maximum size MUST NOT exceed 512 containing the WTP name, whose maximum size MUST NOT exceed 512
bytes. bytes.
4.6.46. WTP Radio Statistics 4.6.46. WTP Radio Statistics
The WTP Radio Statistics message element is sent by the WTP to the AC The WTP Radio Statistics message element is sent by the WTP to the AC
to communicate statistics on radio behavior and reasons why the WTP to communicate statistics on radio behavior and reasons why the WTP
radio has been reset. These counters are never reset on the WTP, and radio has been reset. These counters are never reset on the WTP, and
will therefore roll over to zero when the maximum size has been will therefore roll over to zero when the maximum size has been
reached. reached.
skipping to change at page 96, line 24 skipping to change at page 95, line 39
0 - Statistic Not Supported 0 - Statistic Not Supported
1 - Software Failure 1 - Software Failure
2 - Hardware Failure 2 - Hardware Failure
3 - Other Failure 3 - Other Failure
255 - Unknown (e.g., WTP doesn't keep track of info) 255 - Unknown (e.g., WTP doesn't keep track of info)
Reset Count: The number of times that that the radio has been Reset Count: The number of times that the radio has been reset.
reset.
SW Failure Count: The number of times that the radio has failed due SW Failure Count: The number of times that the radio has failed due
to software related reasons. to software-related reasons.
HW Failure Count: The number of times that the radio has failed due HW Failure Count: The number of times that the radio has failed due
to hardware related reasons. to hardware-related reasons.
Other Failure Count: The number of times that the radio has failed Other Failure Count: The number of times that the radio has failed
due to known reasons, other than software or hardware failure. due to known reasons, other than software or hardware failure.
Unknown Failure Count: The number of times that the radio has Unknown Failure Count: The number of times that the radio has
failed for unknown reasons. failed for unknown reasons.
Config Update Count: The number of times that the radio Config Update Count: The number of times that the radio
configuration has been updated. configuration has been updated.
Channel Change Count: The number of times that the radio channel Channel Change Count: The number of times that the radio channel
has been changed. has been changed.
Band Change Count: The number of times that the radio has changed Band Change Count: The number of times that the radio has changed
frequency bands. frequency bands.
Current Noise Floor: A signed integer which indicates the noise Current Noise Floor: A signed integer that indicates the noise
floor of the radio receiver in units of dBm. floor of the radio receiver in units of dBm.
4.6.47. WTP Reboot Statistics 4.6.47. WTP Reboot Statistics
The WTP Reboot Statistics message element is sent by the WTP to the The WTP Reboot Statistics message element is sent by the WTP to the
AC to communicate reasons why WTP reboots have occurred. These AC to communicate reasons why WTP reboots have occurred. These
counters are never reset on the WTP, and will therefore roll over to counters are never reset on the WTP, and will therefore roll over to
zero when the maximum size has been reached. zero when the maximum size has been reached.
0 1 2 3 0 1 2 3
skipping to change at page 97, line 42 skipping to change at page 97, line 9
AC Initiated Count: The number of reboots that have occurred at the AC Initiated Count: The number of reboots that have occurred at the
request of a CAPWAP protocol message, such as a change in request of a CAPWAP protocol message, such as a change in
configuration that required a reboot or an explicit CAPWAP configuration that required a reboot or an explicit CAPWAP
protocol reset request. A value of 65535 implies that this protocol reset request. A value of 65535 implies that this
information is not available on the WTP. information is not available on the WTP.
Link Failure Count: The number of times that a CAPWAP protocol Link Failure Count: The number of times that a CAPWAP protocol
connection with an AC has failed due to link failure. connection with an AC has failed due to link failure.
SW Failure Count: The number of times that a CAPWAP protocol SW Failure Count: The number of times that a CAPWAP protocol
connection with an AC has failed due to software related reasons. connection with an AC has failed due to software-related reasons.
HW Failure Count: The number of times that a CAPWAP protocol HW Failure Count: The number of times that a CAPWAP protocol
connection with an AC has failed due to hardware related reasons. connection with an AC has failed due to hardware-related reasons.
Other Failure Count: The number of times that a CAPWAP protocol Other Failure Count: The number of times that a CAPWAP protocol
connection with an AC has failed due to known reasons, other than connection with an AC has failed due to known reasons, other than
AC initiated, link, SW or HW failure. AC initiated, link, SW or HW failure.
Unknown Failure Count: The number of times that a CAPWAP protocol Unknown Failure Count: The number of times that a CAPWAP protocol
connection with an AC has failed for unknown reasons. connection with an AC has failed for unknown reasons.
Last Failure Type: The failure type of the most recent WTP failure. Last Failure Type: The failure type of the most recent WTP failure.
The following enumerated values are supported: The following enumerated values are supported:
skipping to change at page 98, line 47 skipping to change at page 98, line 21
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gateway | | Gateway |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Static | | Static |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Type: 49 for WTP Static IP Address Information Type: 49 for WTP Static IP Address Information
Length: 13 Length: 13
IP Address: The IP Address to assign to the WTP. This field is IP Address: The IP address to assign to the WTP. This field is
only valid if the static field is set to one. only valid if the static field is set to one.
Netmask: The IP Netmask. This field is only valid if the static Netmask: The IP Netmask. This field is only valid if the static
field is set to one. field is set to one.
Gateway: The IP address of the gateway. This field is only valid Gateway: The IP address of the gateway. This field is only valid
if the static field is set to one. if the static field is set to one.
Static: An 8-bit boolean stating whether the WTP should use a Static: An 8-bit Boolean stating whether or not the WTP should use
static IP address or not. A value of zero disables the static IP a static IP address. A value of zero disables the static IP
address, while a value of one enables it. address, while a value of one enables it.
4.7. CAPWAP Protocol Timers 4.7. CAPWAP Protocol Timers
This section contains the definition of the CAPWAP timers. This section contains the definition of the CAPWAP timers.
4.7.1. ChangeStatePendingTimer 4.7.1. ChangeStatePendingTimer
The maximum time, in seconds, the AC will wait for the Change State The maximum time, in seconds, the AC will wait for the Change State
Event Request from the WTP after having transmitted a successful Event Request from the WTP after having transmitted a successful
Configuration Status Response message. Configuration Status Response message.
Default: 25 seconds Default: 25 seconds
4.7.2. DataChannelKeepAlive 4.7.2. DataChannelKeepAlive
The DataChannelKeepAlive timer is used by the WTP to determine the The DataChannelKeepAlive timer is used by the WTP to determine the
next opportunity when it must transmit the Data Channel KeepAlive, in next opportunity when it must transmit the Data Channel Keep-Alive,
seconds. in seconds.
Default: 30 seconds Default: 30 seconds
4.7.3. DataChannelDeadInterval 4.7.3. DataChannelDeadInterval
The minimum time, in seconds, a WTP MUST wait without having received The minimum time, in seconds, a WTP MUST wait without having received
a Data Channel Keep Alive packet before the destination for the Data a Data Channel Keep-Alive packet before the destination for the Data
Channel Keep Alive packets may be considered dead. The value of this Channel Keep-Alive packets may be considered dead. The value of this
timer MUST be no less than 2*DataChannelKeepAlive seconds and no timer MUST be no less than 2*DataChannelKeepAlive seconds and no
greater that 240 seconds. greater that 240 seconds.
Default: 60 Default: 60
4.7.4. DataCheckTimer 4.7.4. DataCheckTimer
The number of seconds the AC will wait for the Data Channel Keep The number of seconds the AC will wait for the Data Channel Keep
Alive, which is required by the CAPWAP state machine's Data Check Alive, which is required by the CAPWAP state machine's Data Check
state. The AC resets the state machine if this timer expires prior state. The AC resets the state machine if this timer expires prior
skipping to change at page 101, line 15 skipping to change at page 100, line 38
4.7.12. RetransmitInterval 4.7.12. RetransmitInterval
The minimum time, in seconds, in which a non-acknowledged CAPWAP The minimum time, in seconds, in which a non-acknowledged CAPWAP
packet will be retransmitted. packet will be retransmitted.
Default: 3 Default: 3
4.7.13. SilentInterval 4.7.13. SilentInterval
For a WTP, this is the minimum time, in seconds, a WTP MUST wait For a WTP, this is the minimum time, in seconds, a WTP MUST wait
before it MAY again send Discovery Request messages or attempt to a before it MAY again send Discovery Request messages or attempt to
establish DTLS session. For an AC, this is the minimum time, in establish a DTLS session. For an AC, this is the minimum time, in
seconds, during which the AC SHOULD ignore all CAPWAP and DTLS seconds, during which the AC SHOULD ignore all CAPWAP and DTLS
packets received from the WTP that is in the Sulking state. packets received from the WTP that is in the Sulking state.
Default: 30 seconds Default: 30 seconds
4.7.14. StatisticsTimer 4.7.14. StatisticsTimer
The StatisticsTimer is used by the WTP to determine the interval the The StatisticsTimer is used by the WTP to determine the interval the
WTP uses between the WTP Events Requests it transmits to the AC to WTP uses between the WTP Events Requests it transmits to the AC to
communicate its statistics, in seconds. communicate its statistics, in seconds.
skipping to change at page 101, line 51 skipping to change at page 101, line 26
has been established until it receives the Join Request from the WTP. has been established until it receives the Join Request from the WTP.
This timer MUST be greater than 20 seconds. This timer MUST be greater than 20 seconds.
Default: 60 Default: 60
4.8. CAPWAP Protocol Variables 4.8. CAPWAP Protocol Variables
This section defines the CAPWAP protocol variables, which are used This section defines the CAPWAP protocol variables, which are used
for various protocol functions. Some of these variables are for various protocol functions. Some of these variables are
configurable, while others are counters or have a fixed value. For configurable, while others are counters or have a fixed value. For
non counter related variables, default values are specified. non-counter-related variables, default values are specified.
However, when a WTP's variable configuration is explicitly overridden However, when a WTP's variable configuration is explicitly overridden
by an AC, the WTP MUST save the new value. by an AC, the WTP MUST save the new value.
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
skipping to change at page 102, line 36 skipping to change at page 102, line 17
The maximum number of Discovery Request messages that will be sent The maximum number of Discovery Request messages that will be sent
after a WTP boots. after a WTP boots.
Default: 10 Default: 10
4.8.6. MaxFailedDTLSSessionRetry 4.8.6. MaxFailedDTLSSessionRetry
The maximum number of failed DTLS session establishment attempts The maximum number of failed DTLS session establishment attempts
before the CAPWAP device enters a silent period. before the CAPWAP device enters a silent period.
Default: 3. Default: 3
4.8.7. MaxRetransmit 4.8.7. MaxRetransmit
The maximum number of retransmissions for a given CAPWAP packet The maximum number of retransmissions for a given CAPWAP packet
before the link layer considers the peer dead. before the link layer considers the peer dead.
Default: 5 Default: 5
4.8.8. RetransmitCount 4.8.8. RetransmitCount
skipping to change at page 103, line 33 skipping to change at page 103, line 11
For WTPs that support multiple Frame Encapsulation Types, it is For WTPs that support multiple Frame Encapsulation Types, it is
useful to save the value configured by the AC. The Frame useful to save the value configured by the AC. The Frame
Encapsulation Type is defined in Section 4.6.43. Encapsulation Type is defined in Section 4.6.43.
4.9.3. LastRebootReason 4.9.3. LastRebootReason
The reason why the WTP last rebooted, defined in Section 4.6.47. The reason why the WTP last rebooted, defined in Section 4.6.47.
4.9.4. MacType 4.9.4. MacType
For WTPs that support multiple MAC Types, it is useful to save the For WTPs that support multiple MAC-Types, it is useful to save the
value configured by the AC. The MACType is defined in value configured by the AC. The MAC-Type is defined in
Section 4.6.44. Section 4.6.44.
4.9.5. PreferredACs 4.9.5. PreferredACs
The preferred ACs, with the index, defined in Section 4.6.5. The preferred ACs, with the index, defined in Section 4.6.5.
4.9.6. RebootCount 4.9.6. RebootCount
The number of times the WTP has rebooted, defined in Section 4.6.47. The number of times the WTP has rebooted, defined in Section 4.6.47.
4.9.7. Static IP Address 4.9.7. Static IP Address
The static IP Address assigned to the WTP, as configured by the WTP The static IP address assigned to the WTP, as configured by the WTP
Static IP Address Information message element (see Section 4.6.48). Static IP address Information message element (see Section 4.6.48).
4.9.8. WTPLinkFailureCount 4.9.8. WTPLinkFailureCount
The number of times the link to the AC has failed, see The number of times the link to the AC has failed, see
Section 4.6.47. Section 4.6.47.
4.9.9. WTPLocation 4.9.9. WTPLocation
The WTP Location, defined in Section 4.6.30. The WTP Location, defined in Section 4.6.30.
skipping to change at page 106, line 8 skipping to change at page 104, line 45
In such cases, any WTP state, including the state machine instance, In such cases, any WTP state, including the state machine instance,
MUST NOT be cleared until another DTLS session has been successfully MUST NOT be cleared until another DTLS session has been successfully
established, communicated via the DTLSSessionEstablished DTLS established, communicated via the DTLSSessionEstablished DTLS
notification (see Section 2.3.2.2). notification (see Section 2.3.2.2).
The binding specific WTP Radio Information message element (see The binding specific WTP Radio Information message element (see
Section 2.1) is included in the Discovery Request message to Section 2.1) is included in the Discovery Request message to
advertise WTP support for one or more CAPWAP bindings. advertise WTP support for one or more CAPWAP bindings.
The Discovery Request message is sent by the WTP when in the The Discovery Request message is sent by the WTP when in the
Discovery State. The AC does not transmit this message. Discovery state. The AC does not transmit this message.
The following message elements MUST be included in the Discovery The following message elements MUST be included in the Discovery
Request message: Request message:
o Discovery Type, see Section 4.6.21 o Discovery Type, see Section 4.6.21
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.44 o WTP MAC Type, see Section 4.6.44
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
skipping to change at page 106, line 46 skipping to change at page 105, line 35
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
AC. AC.
One or more binding specific WTP Radio Information message elements One or more binding-specific WTP Radio Information message elements
(see Section 2.1) are included in the Discovery Request message to (see Section 2.1) are included in the Discovery Request message to
advertise AC support for the CAPWAP bindings. The AC MAY include advertise AC support for the CAPWAP bindings. The AC MAY include
only the bindings it shares in common with the WTP, known through the only the bindings it shares in common with the WTP, known through the
WTP Radio Information message elements received in the Discovery WTP Radio Information message elements received in the Discovery
Request message, or it MAY include all of the bindings supported. Request message, or it MAY include all of the bindings supported.
The WTP MAY use the supported bindings in its AC decision process. The WTP MAY use the supported bindings in its AC decision process.
Note that if the WTP joins an AC that does not support a specific Note that if the WTP joins an AC that does not support a specific
CAPWAP binding, service for that binding MUST NOT be provided by the CAPWAP binding, service for that binding MUST NOT be provided by the
WTP. WTP.
The Discovery Response message is sent by the AC when in the Idle The Discovery Response message is sent by the AC when in the Idle
State. The WTP does not transmit this message. state. The WTP does not transmit this message.
The following message elements MUST be included in the Discovery The following message elements MUST be included in the Discovery
Response Message: Response Message:
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;
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.9 * CAPWAP Control IPv4 Address, see Section 4.6.9
* CAPWAP Control IPv6 Address, see Section 4.6.10 * CAPWAP Control IPv6 Address, see Section 4.6.10
The following message elements MAY be included in the Discovery The following message elements MAY be included in the Discovery
Response message: Response message:
o Vendor Specific Payload, see Section 4.6.39 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:
whether its preferred (or primary) AC is available or to perform a
Path MTU Discovery (see section Section 3.5. o determine whether its preferred (or primary) AC is available, or
o perform a Path MTU Discovery (see Section 3.5).
A Primary Discovery Request message is sent by a WTP when it has a 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
Primary Discovery Request is sent by the WTP when in the Run State. Primary Discovery Request 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 frequency of the Primary Discovery Request messages should be no The frequency of the Primary Discovery Request messages should be no
more often than the sending of the Echo Request message. more often than the sending of the Echo Request message.
Upon receipt of a Primary Discovery Request message, the AC responds Upon receipt of a Primary Discovery Request message, the AC responds
with a Primary Discovery Response message sent to the address in the with a Primary Discovery Response message sent to the address in the
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
skipping to change at page 108, line 13 skipping to change at page 107, line 4
more often than the sending of the Echo Request message. more often than the sending of the Echo Request message.